はじめまして、上津原といいます。 スマホアプリの組み込み系のデータベースとして、SQLiteしか選択肢がなかった最近ですが、NoSQLのCouchbaseが「 Couchbase Lite 」という、モバイル用のNoSQLフレームワークをリリースしました（まだベータですけど）。 スマホ開発者の一員として、触らねばなるまいということで動かしてみました。 今回は、大体のCouchbaseLiteの特徴や使い勝手についてお伝えします。 そもそもCouchbaseってなんなのよ Couchbaseは、ドキュメントベースのNoSQLで、よくMongoDBと比較の引き合いに出されます。 もともとはCouchDBというオープンソースデータベースがあり、それを商用版にしたのがCouchbase、という感じで考えてもらえればわかりやすいかと思います。 それじゃあCouchbase Liteって何者なのよ そのCouchbaseみたいにモバイルデータベースを動かそう、というのがCouchbase Liteです。 実際にCouchbase Liteというデータベースが生成されるわけではなく、裏っかわではSQLiteがデータ保存をしています。 つまり、CouchbaseのようにSQLiteを操作するインターフェースやAPIをCouchbase Liteが提供している、というのが正しい考え方になるか思います。 Couchbase Liteの特徴 じゃあそのCouchbase Lite、こいつはSQLiteとどうちがうの？という話になってくるのですが、以下の様な特徴があります。 ・JSON形式でのデータの取扱 Couchbaseが「JSON Everywhere」と提唱している通り、データ形式はJSONとなります。 実際に扱うと、それぞれのドキュメントは連想配列のオブジェクトとして扱われているため、データのパースなどの面倒くささがありません。 ・同期が非常に簡単 Couchbaseはもともとレプリケーションがとても簡単なデータベースです。 その特徴をCouchbase Liteも引き継いでおり、とっても簡単にサーバー上のCouchbaseと同期することができます。 以前は、CouchDBとしかSyncできなかったのですが、今回SyncGatewayがリリースされ、それを介することでCouchbase ServerとのSyncも可能になりました。 ・データ型・Date型なども簡単に保存が可能 Objective-Cで言う、NSDataやNSDateをそのまんま渡せば保存することが可能です。 NSDataに関しては自動でBase64に変換するように作られています。 なので、特にデータの変換を意識することなく、データを保存してくれます。 ・ユーザごとの認証機能が付いている まだ試してはいませんが、Facebookを使った認証機能なども付いているようです。 これもおいおい試してみようと思います。 大体は以下のスライドにも書いてあります。 Couchbase_for mobile_Couchbase_SF_2013 from Couchbase   サーバーサイドよくわからないけど、ウェブサービス作りたいモバイル開発者におすすめかも。 私自身がサーバー周りの開発はしない、という背景もありますが、サーバーサイドわかんない、面倒くさいという人にはおすすめだと思います。 アプリを作ろうとすると、やっぱりサーバーが必要で、認証が必要で、とサーバーサイドの悩みが増えてきて誰かやってくれる人いないかな～なんて考えているうちにやる気が失せていきます。（少なくとも私はそうです） だけど、Couchbase Liteは ローカルでDB保存　→　連想配列で簡単！！ サーバー通信　→　Syncすればそれでできる！ ユーザー認証　→　Couchbase Liteがやってくれる SQL？なにそれ美味しいの？　→　JSONならわかるよ！ あれ？なんだかいい感じ。 と言った感じで、モバイル開発者だけでサーバーサイドの実装なしにサーバ同期型のアプリは作成可能になりそう。 といったところで、今回はここまで。 次回は、Xcodeで実際にCouchbase Liteを動かしてみましょう。  

というわけで楽天テクノロジーカンファレンスの報告第２弾にして、私のメインミッション。ライトニングトークでの「 へやくる！ 」発表です。しかしそこに至るまでの道のりについても書かなくてはと思うのです。     楽天テクノロジーカンファレンスに参加するのは去年に続いて２度目。子供の授業参観が終わってからかけつけたので、到着したのはカフェテリアが閉まる30分前。いそいで13Fにあがります。   メニューは２種類用意されており、そのなかからカラアゲを選択。副菜も二品ついて、普段の「コンビニ塩おにぎり一個」とはレベルの違う昼食を御馳走になりました。   この時点で既に楽天の方々のホスピタリティを実感することができます。エレベータホールに必ず案内の人がいるし、各エレベータにも黄色いTシャツを着た社員の方が。カフェテリアにも「何か困った人はいないかな？」といった雰囲気で社員の方が立っていてくれます。使用済みの食器を下げるところが少し離れているのですが、ちょっと聞けば丁寧に教えてくれる。 東京オリンピック実行委員会は、是非楽天テクノロジーカンファレンスに参加して「おもてなし」とは何かを実感すべきだと思う。（真顔）   さて、   先日書いたMatz氏の基調講演 の次に聞いたのが"Innovate or Die"という題名で、楽天社内でどのようにイノベーションに取り組んでいるかの紹介。質疑応答が非常に盛り上がりました。過去の重要特許を見てみると、大企業からでているようだが？いや、そもそも大企業からイノベーションがでていないとは言っていない、とか様々なやりとりが続きます。質問しているのがEnglish Speakerばかりというのが少し残念でした。これは言語としての英語に対する壁がある、というだけの問題ではないように思います。   自分の出番前に聞いたのが"The approch of Big Sale in Japan Ichiba".平たく言えば   「突発的なトラフィック増とエンジニア達との果て無き戦い」   楽天スーパーセール、あるいはプロ野球での楽天優勝の際に、 楽天のインフラがどのような試練にさらされ、 どういう問題が生じたかを赤裸々に語ってくれます。なんでも最初のスーパーセールの際の反省点を活かすため、２度めは実運用環境で負荷試験を行ったとのこと。すごいなあ。自分たちの失敗事例とその対策をここまでオープンに語ってくれる ことに感動しました。   といったところでライトニングトークの時間が迫ってきます。発表者は前の方の一角に順番に座る。深呼吸をしていると   「英語でプレゼンする機会はありますか？」   と声をかけてもらえました。そうだなあ。英語でプレゼンしたのは去年のこのカンファレンスか.. 自分で発表することのディメリットは、緊張のあまり自分より前の発表が耳に入らず、終わった後の開放感のあまり自分より後の発表が耳に入らないことです。従って他の方の発表についてここで書くことはできません。自分がしゃべったことの要旨を書いておきます。私のカタカナ英語では理解しがたいところも多々あったと思うので。使った動画も合わせて載せておきます。    ・ネクストの大坪といいます。今日は我々は開発したiPadアプリ「へやくる！」について話します。このアプリは不動産情報を検索するために設計されています。   ・不動産情報検索アプリは、他にも何種類か存在しています。しかしほとんどのアプリでは情報とユーザの距離が長過ぎる。具体的にお見せしましょう。   ・例えばあるアプリでは、起動してから最初の不動産情報を見るまでに１０回も画面をタップする必要があります。いくらなんでも長すぎます。情報にたどり着くころには、ユーザは何を探していたか忘れてしまうかもしれません。   ・「へやくる！」はこの点どうか？起動すると、使っている場所近くの不動産情報を表示します。ここからユーザは好きな様に検索結果を変更できる。例えば東京に住もうと思ったとして、（東京の住宅事情について詳しくないので）有名な東京の駅を設定してみましょう。東京、新宿、池袋、それに渋谷。（ここで結果がアップデートされる）   ・なかなかいい結果です。しかし月に５万円以上は払えない。この条件を設定するためには、ドラッグ-ドロップして指をくるりと回す。たった２タップです。駅から１０分以上歩きたくない？ドラッグ-ドロップしてタップ。同じく２タップ。このように「へやくる！」ではほとんどの場合1-2タップで条件を設定したり変更することができます。     ・このように情報とユーザ間の距離が近いので、「極端なケース」を試してみたくなるかもしれません。例えば「お金持ちの生活を覗いてみたい」、と月の家賃を200万円に設定してみましょう。するとでてくるのは豪華ホテルのような写真です。     ・ここで「間取り表示モード」に切り替えるとあることに気が付きます。高額物件の間取り図はほとんど英語で表記されている。理由はよくわかりませんが、もし豪華な家に住もうと思えば、まず英語を勉強する必要があるかもしれません。（注：これは最後までいれるかどうか躊躇したボケでした。笑ってもらえてほっとしました。実はこのあと「楽天社員が全員英語をしゃべる理由がわかったような気がします」というボケをいれようかと思ったのですが、さすがにそれは思いとどまりました）     ・逆のケースではどうでしょう？東京に住みたいけど、月２万円以上は払えない、という場合でもちゃんと物件が見つかります。検索結果の写真を見ると、学生時代を思い出します。これは日本の昭和スタイルのアパートです。     ・というわけで、もし引っ越ししようとかアパートを探そうと思っているなら是非このアプリをダウンロードして使ってみてください。引っ越しの計画など全くない、という方も是非使ってみてください。今日お見せしたように条件設定・変更がとても簡単にできるので、考えうる限り「一番変な」条件を試してはどうでしょう。結果にきっと驚くと思います。   --- といったところで無事しゃべり終え、プレゼンを終えます。今回の制限時間は４分間で、時間がくるとドラがドシャーンとなる。私がプレゼンを終えたのは、ちょうどドラを鳴らそうとしたところだったようです。   英語でプレゼンするのは心理的にとてつもないプレッシャーですが、English Speakerの観客に聞いてもらえるというメリットがある。English Speakerの人たちはリアクションがはっきりしています。ドラッグ-ドロップしたところとか、東京中心で200万円の物件、2万円の物件を出したところで   「ををー」   という声が聞けたのは嬉しい限りでした。   ライトニングトークが終わると、楽天アワードの発表。その後は皆で13Fに移動しビアバッシュ。こちらはプレゼンが無事終わったのでご機嫌モード。何人かの方からプレゼンの感想を聞かせてもらったり、いろいろ興味深い議論ができました。   私は朝と夜が早い人なので、途中でおいとまします。出口付近に箱がいくつか置かれており、"Excellent",（真ん中忘れた）、"So So"と書かれています。今日使った名札の台紙を 箱にいれることで、今日の感想を伝えられる仕組みとのこと。台紙をExcellentに入れるのに躊躇はありませんでした。   楽天は常に新しいことに取り組んでおり、それにはいろいろな意見があると思います。しかしこのカンファレンスで感じた「楽天社員のおもてなしの心」「エンジニア達の技術にかける情熱」は疑いようがない。もっと多くの人がこのカンファレンスに参加したり、発表したりしていろいろなことを考える切っ掛けになれば、と思いました。

Apple原理主義者であることを公言している大坪と申します。 Apple原理主義者なので、Appleに関する記事だったら、 英語であってもがんばって読もうとします。「おもしろい」 と思うと訳する力もないのに紹介したくなります。 というわけで 「面白いと思ったところだけ訳します。 訳せないところは抜かします。 気になる方はどうぞ原文にあたってください」   がモットーのAppleに関する英語記事紹介シリーズ。 第一弾は「謎のEjectボタン」(原文： http:// www.dadhacker.com/blog/?p=2080 )   先日Appleの新キャンパスが話題になりました。 まるで宇宙船のような円形の建物がCupertinoの 市議会に 承認された とのこと。 では今あるキャンパスはどうなるのでしょうか？そこには「 謎のEjectボタン」があるらしいのです。   ちなみにejectを 辞書 で調べてみると 《 野球 》 退場させる ,  追い出す 　とか ( 飛行機 などから) 緊急脱出 する.　とかいう意味がでてきます。 話は1992年。今のAppleのビルが新築だったころのこと。ビルができて 一番目か二番目に引っ越してきたのがNewtonのグループでし た。なぜかというとNewtonはジョン・スカリー（ 当時AppleのCEOだった人です） のお気に入りプロジェクトだったから。 まだ建築中だったので、火災警報がなったり、 いろいろ妙なことがありました。そしてトイレの近くの壁に「 何に使うのかわからない」ボタンがありました。 何の表示もないし、 勇気を出して押してみても何も起こらないようでした。さて、 このボタンは何だろう？ その頃のNewtonプロジェクトの様子はこのように描写されて います。 "Nearly everyone in Newton was working crazy hours at this point; eighty hour weeks were pretty common. While the end wasn’t in sight, we were making good progress on some hard problems. Well, handwriting recognition was still a big bet, and there were a lot of issues around memory footprint and storage, and the development environment was behind, and the language the applications would be written in was still being designed, and PCMCIA card support was rocky, and IR and faxing were flaky, and the built-in applications were still in a lot of flux, not to mention gesture recognition, shape drawing and sound, and battery life, and ROM space, and how we were going to patch ROMs with only a 20K budget of RAM. But aside from those issues, and a few other things (like the schedule), the project was going okay."   Newtonプロジェクトに関わる人は全員狂ったように働い ていた。週80時間労働はあたりまえだった。 まだ終わりは見えなかったがいくつかの困難な問題に関して結構前 進していた。もちろん手書き認識は「賭け」 としかいいようがない状態だったし、メモリや記憶容量のサイズは問題だったし、開発環境は遅れていたし、 アプリを書くための言語はまだ設計されている段階だったし、 PCMCIAカードはバグだらだけだったし、 赤外線とFAXの機能は不安定だったし、 搭載されたアプリはflux(?)だらけだし、 ジェスチャー認識、図形描画、サウンド、バッテリーの持ち、 ROM,RAMのサイズは言うまでもない状態だった。 しかしそうした問題と他の問題（例えばスケジュールとか） を除けばプロジェクトはまあまあうまくいっていた。   さて、 この記事の著者は自宅でLinuxをインストールするためSON Y製のCD-ROMドライブを買いました。 それにはボタンの説明シールが何枚かついていた。 捨てるのはもったいないので、 何枚かポケットに突っ込んで出勤したそうです。 夜の10時か11時頃、 ビルドが終わるのを待ちながらぶらぶらしていた著者の前に例の「 謎のボタン」が目に入りました。 周りに誰もいないのを確かめた後、ポケットから"Eject" シールと矢印シールを取り出して謎のボタンの周りに貼ったのです 。 ２－３日もすれば、ビルの管理人かだれかが剥がすだろう、 と思っていたのですが、それから数ヶ月間、「謎のボタン」は「 謎のEjectボタン」として有名になりました。 Ejectというからには押すと何かが「排出」 されるのだろうか。押してみたけど何も起こらない、一体何が「 排出」されるんだろう。謎は深まるばかりでしたが、著者は「 秘密」を守りつづけました。 何ヶ月かが過ぎ、Newtonが出荷されました（ 著者の意見では「数ヶ月早すぎた」とのこと） 一年後に著者はAppleを去り別の会社で働き始めました。 Newtonは成功せず、スカリーが去り、ジョブスが復帰し、 iPhoneが発表され、、 そして先日著者のもとにある写真が届いたそうです。それは「 謎のEjectボタン」の写真でした。 ２０年たった今でもそこにあるらしいのです。 著者はこう述べています。 I wonder if Steve ever pressed that button, or wondered what it did?   Steve (ジョブス）はこのボタンを押して、「何をするんだろう？」 と考えたことがあっただろうか？   --------------- Newtonを「時代に先駆けすぎていた」 というのは簡単ですが、 個人的にはその失敗から多くのことを学ぶことができると思います 。 G.M.ワインバーグの「コンサルタントの秘密」 という名著にこういう言葉があります。 エドセルの訓令 新しいものとつき合わなければならないときは、 二つではなく一つにしよう。 上記文章の中で述べられているように、 Newtonは開発言語と、 それで動くアプリケーションを同時に新規開発しようとしました。 そして私はそれが技術的に彼らが失敗した原因の一つだと思ってい ます。もっともエンジニアの端くれとして「 何もかも新しくしたい」という要求は理解できるところですが、「 エドセルの訓令」はほとんどの場合冷酷に立ちはだかります。 UIのデザインで冒険するなら、 開発環境は実績のあるものを使う。 新しいシステムを基盤にするなら、 アプリケーションは堅実なものを選ぶ。 どちらか一つにしない限りプロジェクトが失敗する可能性は高くなる。 iPhoneの開発もNewtonに負けず劣らず大きな賭けだっ たようです。しかし少なくともアプリを作成するための言語、 Objective- Cは長く使われていて実績があったわけです。 それでも彼らの困難は想像を絶するものだったようですが、 その物語については別の機会に。

大坪と申します。先日10/26に行われました楽天テクノロジーカンファレンスに参加しました。主たる目的はライトニングトークでiPadアプリ「 へやくる！ 」について話すことだったのですが、いろいろ興味深い発表をいくつも聞くことができました。   本日はその中からまつもとひろゆき氏の講演について概要を紹介をしたいと思います。ちなみに本来基調講演は楽天の三木谷会長が行う予定だったのですが、「急遽」まつもと氏が講演することになったとのこと。そんな事情を話し、笑いをとるところから講演が始まりました。（個人的にはこの「急遽登板」は歓迎するところでしたが）     -------------- 1990年に学校を卒業し働き始めた。そのころはエンタープライズソフトの開発をしていた。一つのシステムを３年かけ、ウォーターフォールで開発する時代だった。その時から「この開発方法は何かが間違っている」と思ったが何が間違っているかを説明できなかった。   その頃のソフトウェア開発は間違った前提に基づいていた。 ・私たちは何を作ろうとしているかわかっている ・私たちは何が欲しいかわかっている ・状況は変化しない   しかしこれらの前提は馬鹿げている。実際台風がくるとか地震がくるとか誰が予測できるというのか。（注：このカンファレンス自体、台風が接近した場合には中止になりかねませんでした）   このように前提が間違っていたが、当時の企業はどういう戦略を選べたか？   一番目の方法はダチョウのように、頭を穴に突っ込み状況が好転するのを待つこと。   二番目の方法は保守的戦略。「過去から学ぶ」ことである。たとえば人間性は聖書の時代から変わっていないから多くの分野では過去から学ぶことができる。しかしIT業界ではそうはいかない。不思議の国のアリスで赤の女王が言った「同じ場所にいるためには、必死に走らなくちゃ」というのがIT業界にも当てはまる。   ３番目の方法は「おとぎの世界に住む」こと。「間違った前提に基づいて進む」ことだが、これは「穴に頭を突っ込んだダチョウ」より悪い戦略だ。   ２０年前、日本の会社はどのような戦略をとったか？多くの会社は３番目を選んだがこれは間違いだった。   今から考えて、唯一とるべき方法はTry and Error。この戦略を機能させる為には何度も挑戦できなくてはならない。   ２０年前ソフトウェア開発にはものすごいコストがかかった。それ故Try and Errorは選択しにくかった。最優先は「失敗しないこと」であり、その戦略にプロセスが最適化した。その結果ユーザ満足度は犠牲にされた。   時代は変わり、ソフトウェア開発のコストは劇的に下がった。Network,ツール,プログラミング言語全てがよくなった。今はSocial Codingが可能。   ２０年前は、とにかくソフトウェアを作る事がゴールだった。すごい金をかけてシステム構築すれば、それだけで差別化できた。しかし今のゴールは「すごいソフトウェア」を作る事。ただソフトウェアを持っているだけでは差別化できない。   ではどうやって「すごいソフトウェア」をつくれるか？   その方法はもちろんわからない。しかしまず無知を自覚する必要がある。ここで機能する唯一の戦略はTry and Errorだ。そして失敗したときのコストを最小化する必要がある。そのためにはOpen source Softwareを使うべきだ。巨人の肩にのって開発をすることで、コストを下げることができる。   コアコンピタンス以外のすべてをOpen Sourceにするべきだ。そしてオープンな開発コミュニティを作り、プロジェクトを最小化する。それによりプロジェクト「組織」を解体し、ソフトウェアが万人にとって開かれるようにすべきだ。   Rubyは元々個人的な興味から作り出した（ペットプロジェクトと言っていました）が、今や世界中で多くの人が使っている。このように将来を見通すことはできない。   唯一の方法は進み続けること。サメのように進み続けなければ死ぬ。Open source　projectで偉大なソフトウェアを作るためには開発コミュニティが多くの人を引きつけなくてはならない。そしてできるだけ早く走り、何度も試し、失敗したら早めに撤退すること。 ソフトウェア開発に関する大きな図式を変換する必要がある。「失敗したら終わり」から"失敗もOK"にすべきだ。（もちろん大失敗をしないという条件下でだが） -------- 以上が講演内容。その後何件かQ&Aがありました。私が特に興味深いと思ったのは以下のやりとり   Q:"失敗もOK"という風に会社のカルチャーをかえられるか？多くの会社ではなかなかそうはいかないが。   A:基本的にはそんな会社は辞めるべきだと思う。多くの大きな日本のIT企業は歯車を求めている。従業員に敬意を払っていない。エンジニアの動機の一つは自由度があることであり、自由を得るためにはリーダーになる必要がある。だから歯車を求めているような会社は辞めるべきだ。 ------- 特に最後の言葉は、「そういわれても..」とも思う反面、多くのエンジニアの心に響いたのではないでしょうか。   基本設計-詳細設計-コーディング-試験という整然としたウォーターフロープロセスの間に多くの書類が作られ、レビューが行われ,,という開発に携わった人は多いと思いますし、「何かが間違っている」と感じた人も多いと思います。その「何か」についてまつもと氏の意見を聞けたことは貴重な体験でした。   ちなみに昨年のテクノロジーカンファレンスでは、Design Thinkingというセッションでウォーターフォール型開発についてこんな話がありました。   ノードストロームではウォーターフォール式に開発段階でのチェックを厳格に行った。その結果、全てのinnovationが消えてしまった。ウォーターフォール式の開発がうまくいかない、ということは誰もが知っている。しかしいつまでもそれがなくならないことについて考える必要がある。つまりメリットがあるわけだ。ウォーターフローの利点は、個人にとって「安全」であること。うまく行かなかった時に、「自分じゃない誰か」を非難できる。ソフトウェアの開発が遅れたのは、仕様が出るのが遅れたからだ、とか、無茶苦茶な仕様がでてきたからだ、と非難できる。しかし製品を作るのには向いていない。   来年のテクノロジーカンファレンスではどんな話が聞けるか今から楽しみです。    

皆様はじめまして。 不動産ポータルサイト「HOME'S」を運営しています株式会社ネクストの秋山と申します。   この度、ネクストからのエンジニアによる技術情報を中心とした情報発信を行っていくこととなりました。 弊社は基本的に内製で開発を行っており、そこで得られた様々なナレッジや技術、活動をお伝えしていこうと思います。   本ブログで主にお伝えする内容を下記に列挙します。 サービス開発、運用時に得た知識や技術 R&D の進捗や得た知識 弊社エンジニアの日常や新しい取り組み 新サービスやイベントの告知   株式会社ネクストのメイン事業である不動産ポータルサイト「HOME'S」をメインに、 弊社エンジニアの活動を通して有益な情報や活動をお伝えすることで、 株式会社ネクストを知っていただくと共に、皆様に少しでもお役に立てる情報を 発信してまいります。   今後とも、「株式会社ネクスト エンジニアBlog」を宜しくお願い致します。

こんにちは、ネクスト　清田です。 前回の記事 では、情報検索システムの研究で評価に使われてきた「再現率」「精度」という指標について紹介するとともに、現実の情報検索システムでは、システムの「ユーザー」を巻き込まないと本当の姿は分からないことを示しました。今回は、ユーザーを巻き込んでシステムを評価するには、どんなことを考えておく必要があるのかについて紹介します。 システムとユーザー、どちらにフォーカスを当てるのか? 前回の記事では、情報検索システムを研究するには、システムを「入力と出力を持つブラックボックス」として扱うやり方と、システムとユーザーをセットにして1つの系として扱うやり方の、2つの方法があることを示しました。しかし、この2つの方法は完全に区別できるものではなく、場合に応じて両者を組み合わせて利用されます。 情報検索システムの評価を専門としているノース カロライナ大学のDiane Kelly博士は、著書「Methods for Evaluating Interactive Information Retrieval Systems with Users *1 」の中で、情報検索システムの2つの研究の方法の間には、図1に示すようなさまざまなバリエーションが連続体として存在することを示しています。この図について簡単に説明しましょう。 図1. 情報検索システムの研究アプローチの連続体 (Diane Kelly 「Methods for Evaluating Interactive Information Retrieval Systems with Users」 p.10 より引用) 左側に行けば行くほどシステム側に寄った研究、右側に行けば行くほどユーザー（人間）側に寄った研究になっています。最も左側にある「TRECスタイルの研究」は、TREC（Text REtrieval Conference）という情報検索研究ワークショップで主流とされてきた研究のやり方、つまり情報検索システムをブラックボックスとして扱い、あらかじめ準備されている正解データを使って、再現率と精度という指標で性能を測定するというタイプの研究です。定量的な評価が可能なので、異なるシステム同士の比較も簡単ですし、工学的アプローチによって研究を進めることができます。一方、最も右側にある「コンテキストの中での情報探索の挙動」は、完全にユーザーにフォーカスを絞って、ユーザーの情報要求とふるまいの関係を明らかにしようとするタイプの研究です。そこでは標準的な評価手法が確立されていないため、定量的な評価手法が適用できず、定性的な評価によらざるを得ません。 現実には、これらの極端なケースで研究が行われることはあまりなく、多くの情報検索システムの研究は両者の中間のやり方で行われます。 例えば、図1の左から2番目の「ユーザーによる適合性評価」は、再現率・精度の指標は用いるものの、正解データはあらかじめ準備されてはおらず、研究者自身がユーザーを募集することによって、正解データなどの評価に必要な基盤を作っていくタイプの研究です。他の研究者が扱っていない新しいタイプの情報検索システムの研究に取り組むには、正解データを自分で作る必要があるため、ある程度ユーザーを巻き込んでいく必要が出てきます。 左から4番目の「ログ解析」は、ユーザーが情報検索システムを利用する際に収集できるログデータを用いるタイプの研究です。大規模なWeb情報サービスが普及するにつれて、ログ解析による研究が非常に盛んになってきています。例えば、新しいユーザー インタフェースやアルゴリズムを試したい場合、その潜在的な効果を測る場合にログ解析はきわめて強力な手法です。 真ん中の「TRECインタラクティブ研究」は、インタラクティブ情報検索システムを対象とした研究で、最近のTRECでは研究が非常に盛んになってきています。このタイプの研究は、主にユーザーに直接関連した機能を研究の対象としていて、さまざまなデータ収集手法を用いてユーザビリティを評価します。また、ユーザーへのインタビューによって質的評価を得ることも行われます。 情報検索システム評価の歴史 歴史的にみると、情報検索システムの研究は、工学的アプローチを適用できる図1の左側に寄った研究アプローチが中心でした。情報検索システムがユーザーの存在を前提としている以上、ユーザーを巻き込んだ評価をする必要があることは、1970年代にはすでに認識されていました。しかし、確立された評価手法が存在しなかったため、少数の探索的研究を除いてユーザーの方に重きを置いた評価は行われてきませんでした。1990年代中頃までは、情報検索システムはある程度訓練を受けたユーザーのみを対象としていたため、典型的なユーザー像を想定しやすいという理由もありました。 しかし、Webベースの情報検索システムが広く普及するにつれて、さまざまなレベルのユーザーによってシステムが利用されるようになってきたため、ユーザーを巻き込んで評価を行うための手法を確立する努力が本格的に始められました。現在は、大規模なWebサービスを展開する企業などを中心に、ユーザーを巻き込んださまざまな評価が行われるようになってきています。 上記で紹介したKelly博士の著書では、ユーザーを巻き込んだ評価手法が体系的にまとめられており、非常に参考になります。現在、筑波大学の上保秀夫先生を中心として本書の邦訳を出版する準備が進められており、今年秋頃には出版される予定です（清田も一部の翻訳を担当させていただいています）。興味をお持ちの方はぜひチェックしてみてください。 情報検索システムを「科学」するということ これまで述べてきたように、情報検索システムの研究には「システム」と「ユーザー」という2つの極があって、歴史的には「システム」側からスタートして徐々に「ユーザー」側に中心が移ってくるという変遷を経てきました。エンジニアの立場から見ると、図1の「システム」側の単純化されたアプローチの方が馴染みがあります。「ユーザー」を巻き込んで評価を行うことは、問題を非常に複雑にしてしまうことから、これまではあえて避けられてきたと考えられます。しかし、今日のように情報検索システムが広く使われるようになった状況では、「ユーザー」を巻き込むことはむしろ必然的に求められるようになってきています。情報検索システムの本来の姿である「システムとユーザーの組み合わせ」を研究対象として扱うことは、複雑な問題の本質に迫るという大きなチャレンジです。工学という枠組みを脱皮して、複雑な問題の本質に迫ること、つまり「科学」という枠組みで考えることが求められます。 20世紀からの科学の発展は、「統計」という強力なツールの存在なくしては語れません。情報検索システムの研究分野でも、恣意的な要素がどうしても入ってしまう「少数のユーザーによる評価実験」や「あらかじめ準備されているクエリーと正解データの組み合わせ」というアプローチから脱皮して、「ユーザーのサンプリング」や、「実験結果の検定」などといった統計的アプローチが利用されるようになってきています。たとえば、新しいアルゴリズムの有用性を知りたいときには、一部のユーザーを無作為抽出して、元々のアルゴリズムを使っているユーザーとの違いを調べるという方法（A/Bテストと呼ばれます）がよく利用されますが、いったい何人くらいのユーザーを抽出すれば良いのかを知るには、基本的な統計的検定の知識が役に立ちます。また、情報検索システムのクエリーログデータの分析に利用されている手法の多くは、統計的アプローチそのものです。 次回の記事 では、評価の対象とするユーザーを選ぶ場合に気を付けておく必要があることについて紹介しています。 記事のリスト ユーザー向け情報サービスの「評価」を考える (第1回) - 株式会社ネクスト エンジニアBlog ユーザー向け情報サービスの「評価」を考える (第3回) - 株式会社ネクスト エンジニアBlog *1 : Methods for Evaluating Interactive Information Retrieval Systems and Users (Foundations and Trends(r) in Information Retrieval) 作者: Diane Kelly 出版社/メーカー: Now Publishers 発売日: 2009/04/30 メディア: ペーパーバック 購入 : 1人 クリック : 6回 この商品を含むブログを見る

こんにちは、株式会社ネクスト 清田です。 ネクストでは、HOME'Sをはじめとしてネクストが提供する情報サービスに新たな価値を加えるため、膨大なデータベースから最適な情報を提示する検索技術や、潜在的なニーズを抽出して一人ひとりにぴったりな情報を提供するレコメンデーション エンジンの研究開発に日々取り組んでいます。このブログでも、オープン ソースの全文検索エンジンSolrの拡張などの活動を紹介してきています。 今回は、情報検索やレコメンデーションの研究を行う上でどうしても避けられない、「評価」にまつわる話題を紹介します。 情報検索システムの評価とは？ 情報検索システムの研究には長い歴史があり、研究の「評価」に使われる指標が確立しています。情報検索システムの研究で最も良く使われるのは、「再現率」と「精度」という2つの指標です。「再現率」（recall）とは「ユーザーのニーズに合った情報のうち、検索にヒットした情報の割合」、「精度」（precision）とは「検索にヒットした情報のうち、ユーザーのニーズに合った情報の割合」のことです。 近所の図書館で「プログラミング言語の学習」について書かれた本を借りる場合を例にとって説明します。この図書館では、「プログラミング言語の学習」について書かれた本が10冊あります。あなたが図書館のロビーに置いてある検索端末で「プログラミング言語」というキーワードで検索すると、20冊の本がヒットしたとします。ヒットした20冊の中には、あなたが探していた「プログラミング言語の学習」についての本は8冊あり、その他の12冊は、「プログラミング言語の開発」や「プログラミング言語の歴史」など、あなたが探しているものとは違う本だったとしましょう。 再現率は、あなたが探していてかつ見つかった8冊を、図書館の中であなたが探している本すべての冊数10冊で割ったもの、すなわち80％です。いっぽう精度は、あなたが探していてかつ見つかった8冊を、ヒットしたすべての本の冊数20冊で割ったもの、すなわち40％です。再現率と精度は、100％に近ければ近いほど「良い検索システム」であるということになります。理想の検索システムは再現率、精度ともに100％のシステムということになりますが、多くの場合、再現率と精度はトレード オフの関係にあります。 例えば、具体的なプログラミング言語の名前（C、JavaやPython）を検索キーワードとして自動的に追加すれば、再現率を上げることができますが、多くの場合は精度が下がってしまいます（「ベンツCクラス」や、「ジャワ（Java）島」、「モンティ・パイソン」についての本もヒットしてしまうから）。逆に精度を上げようとすれば再現率は下がってしまいます。このトレードオフの存在を前提に、できるだけ再現率・精度ともに高くしようという努力の積み重ねが、今日の検索エンジン技術の土台となっています。 現実の情報検索システムの評価にまつわる問題 しかし、再現率や精度という指標は、Webの爆発的な普及にともなって出現してきた新しいタイプの情報検索システムには、必ずしも使えなくなってきています。たとえばHOME'Sでは、日本全国の300万件以上の物件データベースの中からあなたが探したい物件を自由に検索することができますが、そもそも「あなたが探したい物件」が300万件のデータベースの中に何件含まれるのかを知ることは不可能です。ある物件があなたの本当に探しているものかどうかは、HOME'Sで探して不動産会社さんを訪問し、物件を見学することによってはじめて分かります（実際にはしばらく住んでみないと分からないこともあるでしょう）。全国の300万件の物件をすべて見学することは一生かけても無理ですし、探す地域を限っていたとしても、そのエリアのすべての物件を調べるほどの時間はとれないことが多いでしょう。 図1. 工学的アプローチによる情報検索システム研究のモデル 情報検索システムには、評価を難しくする本質的な課題があります。再現率・適合率を測るためには、図1に示すように、情報検索システムを「入力」と「出力」を持つブラックボックスとしてとらえ、どの「入力」に対してどのような「出力」が正しいのかを決めておく必要があります。しかし、現実の情報検索システムには必ず「人間」がユーザーとして関わっています。例えばHOME'Sというサービスは、皆さん一人ひとりの「家探し」というニーズの上に成り立っています。そのため、情報検索システムを評価するためには、必ずユーザーとしての人間を巻き込まなければなりません（図2）。 図2. 現実世界の情報検索システムのモデル 次回の記事 では、情報検索システムの評価に人間を巻き込むこと、すなわちユーザベースの評価をする際に、何を考える必要があるかについて紹介します。 記事のリスト ユーザー向け情報サービスの「評価」を考える (第2回) - 株式会社ネクスト エンジニアBlog ユーザー向け情報サービスの「評価」を考える (第3回) - 株式会社ネクスト エンジニアBlog

初めまして、ネクストでデータマイニング・レコメンドを担当している古川と申します。本ブログでは、日々の業務でお世話になっている、アルゴリズムやソフトウェアなどを紹介していきたいと思います。 まず第 1 弾として、全文検索エンジン Solr の検索 plugin 作成方法について数回の連載に分けて紹介します。 導入 Solr は、 日本語の全文検索が可能である RDMBS 同様、フィールド値を使ったソート、複数フィールドを使った高速なソートが可能である 分散処理機能を備え、スケーラビリティに優れている キャッシュ機能を備え高速なレスポンスが可能である レプリケーション可能である オンラインでのデータ更新がサポートされている などの多くの利点を持つオープンソースの全文検索エンジンで、様々なサイトでの利用が広がっています。 課題 デフォルト機能でも多くのニーズに答えてくれる Solr ですが、サイト固有のニーズを実現するためには、多少のカスタマイズが必要になることがあります。 HOME'S でのニーズを例に説明します。 フィールド値として家賃、面積などを保存しておけば、「家賃が 8 万円以下」という検索条件について、合致する物件一覧を、「家賃が安い順-面積の広い順」、「家賃が高い順 - 面積広い順」といった順序でソートすることは、 RDBMS 同様 Solr でも可能です。しかしながら、これでは「家賃がそこそこの割に、面積もそこそこ広い」という条件の良い物件があったとしても検索結果上位に表示されにくい、という問題があります。もちろん、ユーザにより詳細な検索条件を入力して頂ければ解決する問題ですが、 1 度目の検索でサイトを離脱されてしまうユーザも多く、少ない入力条件でいかに“いい感じ”の検索結果を返すかということは、非常に重要な課題です。 “いい感じ” の結果を返すためには、「家賃、面積」という2つのフィールドに関して、個々に考えるのではなく、2つのフィールドを総合的に加味する必要があります。しかし、これを Solr のデフォルト機能で実現するのは難しく、 plugin を作成ました。 Lucene での実現方法 本連載では、検索クエリと複数フィールド値を加味しながらソート順を決定する単純なサンプルプログラムを例に、作成方法を説明していきたいと思います。 連載 1 回目の今回は、 Solr 用の検索 plugin 作成をする前段階として、 Solr の使っている Lucene ライブラリでの実現方法を紹介します。なお、実現方法に関しては、 株式会社ロンウイット の関口さんが、 ブログで紹介されている方法 のうち、 Collector クラスを継承して実現する方法を参考にさせて頂きました。 以下のようにフィールドが id 、 type 、 x 、 y からなるドキュメントセットについて、検索条件として、 type と x 、 y を指定し、同じ type のドキュメントをスコアの小さい順に取得するという検索を考えます。このとき、 Score = weight(type)(qx‐x)(qx-x) + (1-weight(type)) (qy-y)(qy-y) のように、typeによって x 、 y の weight が変わる値を検索用スコアとして考えました。 source.tsv #id type x y 1 a 10 20 2 b 10 20 3 a 11 11 4 b 11 11 次のプログラムは、上記 TSV ファイルを読み込み、検索用のインデックス作成、プログラム内で指定した条件で検索を行うというプログラムです。 BlogTest.java package blog; import java.util.HashMap; import java.util.ArrayList; import java.io.FileReader; import java.io.BufferedReader; import java.io.FileWriter; import java.io.BufferedWriter; import org.apache.lucene.document.Document; import org.apache.lucene.document.Field; import org.apache.lucene.document.NumericField; import org.apache.lucene.index.IndexWriter; import org.apache.lucene.index.IndexWriterConfig; import org.apache.lucene.index.IndexReader; import org.apache.lucene.index.Term; import org.apache.lucene.analysis.SimpleAnalyzer; import org.apache.lucene.util.Version; import org.apache.lucene.store.Directory; import org.apache.lucene.store.RAMDirectory; import org.apache.lucene.search.IndexSearcher; import org.apache.lucene.search.Query; import org.apache.lucene.search.TermQuery; import org.apache.lucene.search.FieldCache; public class BlogTest { public static void main(String[] args) { String srcPath = args[ 0 ]; Directory directory = new RAMDirectory(); System.out.println( "[create index]" ); int numDocuments = createIndex(directory, srcPath); System.out.println( " \t loaded " + numDocuments + " documents" ); System.out.println( "[run test]" ); BlogTestQuery[] testQueries = new BlogTestQuery[ 2 ]; testQueries[ 0 ] = new BlogTestQuery( "a" , 10 , 10 ); testQueries[ 1 ] = new BlogTestQuery( "b" , 10 , 10 ); searchTest(directory, testQueries, 5 ); System.out.println( "[done]" ); } public static int createIndex(Directory directory, String path) { int counter = 0 ; try { IndexWriterConfig config = new IndexWriterConfig( Version.LUCENE_34, new SimpleAnalyzer(Version.LUCENE_34)); IndexWriter iw = new IndexWriter(directory, config); FileReader fr = new FileReader(path); BufferedReader br = new BufferedReader(fr); String strLine; String[] buf; while ( (strLine = br.readLine()) != null ) { if (strLine.charAt( 0 ) == '#' ) continue ; buf = strLine.split( " \\ t" ); if ( buf.length != 4 ) continue ; counter += 1 ; String id = buf[ 0 ]; String type = buf[ 1 ]; int x = Integer.parseInt(buf[ 2 ]); int y = Integer.parseInt(buf[ 3 ]); Document doc = new Document(); doc.add( new Field( "id" , id, Field.Store.YES, Field.Index.NOT_ANALYZED)); doc.add( new Field( "type" , type, Field.Store.YES, Field.Index.NOT_ANALYZED)); doc.add( new NumericField( "x" , Field.Store.YES, true ).setIntValue(x)); doc.add( new NumericField( "y" , Field.Store.YES, true ).setIntValue(y)); iw.addDocument(doc); } br.close(); fr.close(); iw.close(); } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } return counter; } public static void searchTest(Directory directory, BlogTestQuery[] testQueries, int numLimit) { // searcher作成 System.out.print( " \t initializing searcher..." ); IndexSearcher is = null ; IndexReader ir = null ; HashMap<String, Double> weights = new HashMap<String, Double>( 2 ); weights.put( "a" , 0.5 ); weights.put( "b" , 0.999 ); int [][] caches = new int [ 2 ][]; try { is = new IndexSearcher(directory, true ); ir = is.getIndexReader(); caches[ 0 ] = FieldCache.DEFAULT.getInts(ir, "x" ); caches[ 1 ] = FieldCache.DEFAULT.getInts(ir, "y" ); } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } System.out.println( " done." ); // run search for ( int i= 0 ; i<testQueries.length; i++) { BlogTestQuery testQuery = testQueries[i]; Query query = new TermQuery( new Term( "type" , testQuery.type)); double weight = weights.get(testQuery.type); BlogTestCollector collector = new BlogTestCollector(ir, caches, weight, testQuery.x, testQuery.y); try { is.search(query, null , collector); } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } ArrayList<DocIdScore> docIdScores = collector.getDocIdScores(numLimit); System.out.print( " \t type=" + testQuery.type + " \t x=" + testQuery.x + " \t y=" + testQuery.y); System.out.println( " \t weight=" + weight); System.out.println( " \t\t id \t type \t x \t y \t score" ); for ( int j= 0 ; j<docIdScores.size(); j++){ int id = (docIdScores.get(j)).getDocumentId(); double score = (docIdScores.get(j)).getScore(); try { Document doc = is.doc(id); System.out.print( " \t\t " ); System.out.print(doc.get( "id" )+ " \t " ); System.out.print(doc.get( "type" )+ " \t " ); System.out.print(doc.get( "x" )+ " \t " ); System.out.print(doc.get( "y" )+ " \t " ); System.out.print(score+ " \n " ); } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } } } } } BlogTestCollector.java package blog; import java.lang.Math; import java.util.Collections; import java.util.ArrayList; import java.util.Comparator; import org.apache.lucene.document.Document; import org.apache.lucene.index.IndexReader; import org.apache.lucene.search.Collector; import org.apache.lucene.search.Scorer; import org.apache.lucene.search.FieldCache; public class BlogTestCollector extends Collector { private ArrayList<DocIdScore> docIdScores; private IndexReader reader; private int docBase; private int [][] fieldsCaches; private double weight; private int x; private int y; public BlogTestCollector(IndexReader reader, int [][] caches, double weight, int x, int y) { this .reader = reader; this .docIdScores = new ArrayList<DocIdScore>(); try { this .fieldsCaches = caches; this .weight = weight; this .x = x; this .y = y; } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } } @Override public void setNextReader(IndexReader reader , int docBase) { this .docBase = docBase; } @Override public void setScorer(Scorer socorer){} @Override public boolean acceptsDocsOutOfOrder(){ return true ; } @Override public void collect( int id) { try { int docid = this .docBase + id; int x = this .fieldsCaches[ 0 ][docid]; int y = this .fieldsCaches[ 1 ][docid]; double score = 0 ; score = this .weight*( this .x - x)*( this .x - x) + ( 1.0 - this .weight)*( this .y - y)*( this .y - y); this .docIdScores.add( new DocIdScore( docid, score )); } catch (Exception e) { e.printStackTrace(); System.exit( 1 ); } } public ArrayList<DocIdScore> getDocIdScores( int limit) { Collections.sort( this .docIdScores, new ScoreComparator() ); ArrayList<DocIdScore> retvals = new ArrayList<DocIdScore>(limit); int maxSize = this .docIdScores.size(); if ( limit > maxSize ) { limit = maxSize; } for ( int i= 0 ; i<limit; i++) { retvals.add( this .docIdScores.get(i)); } return retvals; } static class ScoreComparator implements Comparator<DocIdScore> { public int compare( DocIdScore a, DocIdScore b) { double a_score = a.getScore(); double b_score = b.getScore(); if ( a_score > b_score ) { return 1 ; } else if (a_score < b_score) { return - 1 ; } else { return 0 ; } } } } BlogTestQuery.java package blog; class BlogTestQuery { public String type; public int x; public int y; public BlogTestQuery(String type, int x, int y) { this .type = type; this .x = x; this .y = y; } } DocidScore.java package blog; class DocIdScore { private int id; private double score; public DocIdScore( int id, double score) { this .id = id; this .score = score; } public int getDocumentId() { return this .id; } public double getScore() { return this .score; } } インデックス作成部分、クエリ指定部分など Lucene の基本的な使い方については、参考文献を参照して頂くとして、今回のポイントは、 BlogTest.java 115 行目の、BlogTestCollector オブジェクトを作成し、 IndexSearcher オブジェクトの search() 関数の引数として渡し検索を行う部分 BlogTest.java 120 行目の、BlogTestCollector オブジェクトの getDocIdScores() 関数で検索結果を取得する部分 になります。 1 のように、 search() 関数の引数として BlogTestCollector オブジェクトを渡すことで、 IndexSearcher の search() 関数が条件に合致するドキュメントを発見するたびに、 BlogTestCollector の collect() 関数が実行され、 BlogTestCollector 内部にスコア計算結果が保存されていきます。そして、 2 でその結果一覧をスコア順にソートして取得しているわけです。 collect() 関数、 getDocIdScores() 関数の詳細は、ソースコードをご覧ください。 プログラムの実行結果は、以下の通りです。検索クエリの type の値により、 weight が変更され、 x 、 y が同じ値であっても、異なるソート結果となっていることが分かります。 [create index] loaded 4 documents [run test] initializing searcher... done. type=a x=10 y=10 weight=0.5 id type x y score 3 a 11 11 1.0 1 a 10 20 50.0 type=b x=10 y=10 weight=0.999 id type x y score 2 b 10 20 0.1 4 b 11 11 1.0 Lucene のみで実現しているシステムの場合、検索部分を今回の例のように変更するだけで、ソート順を思いのままに変更できますが、 Solr へ組み込み時には、更に Solr の検索コンポーネントの作法に合わせる必要があります。次回は、その方法に関して解説します。 参考文献 Apache Lucene 入門 ~Java・オープンソース・全文検索システムの構築 作者: 関口宏司 出版社/メーカー: 技術評論社 発売日: 2006/05/17 メディア: 大型本 購入 : 5人 クリック : 156回 この商品を含むブログ (30件) を見る Lucene in Action 作者: Michael McCandless,Erik Hatcher,Otis Gospodnetic 出版社/メーカー: Manning Pubns Co 発売日: 2010/06/30 メディア: ペーパーバック 購入 : 1人 クリック : 10回 この商品を含むブログ (3件) を見る Apache Solr入門 ―オープンソース全文検索エンジン 作者: 関口宏司,三部靖夫,武田光平,中野猛,大谷純 出版社/メーカー: 技術評論社 発売日: 2010/02/20 メディア: 大型本 購入 : 18人 クリック : 567回 この商品を含むブログ (22件) を見る

はじめまして。ネクストの金です。この記事では、GIS (Geographic Information System、地理情報システム) とは何かについて紹介します。今後、ビジネスにおけるGIS導入及び活用と研究に焦点をあててお伝えしていきたいと思います。 GISと活用分野 今回は、GISの定義について解説するとともに、実際にGISで使われているデータについても紹介します。GISは1980年半ばよりいくつかの定義が試みられてきましたが、ビジネスにおけるGISの活用が進展するにつれて、当時とはデータの意味やデータの活用範囲が大きく変わってきています。最後にGISの活用事例を、産業別およびビジネス手法別に整理して紹介します。 1.　GISの定義 皆さんは、「GIS」と聞いて何を連想するでしょうか？　多くの方にとっては、カーナビやGoogle Mapsなどの地図を活用したシステムやサービスはおなじみだと思います。そのため、GISは地図システムやカーナビのイメージで理解されていることが多いようです。GISは「地図画像≠地理情報、地図画像∈地理情報」という概念を持ち、地図画像が地理情報のすべてをカバーできるものではありません。 「地図画像＝地理情報」という間違ったイメージが、GISをビジネスへ活用する際には障害となる場合があります。なぜならば、このようなイメージを持っていると、全てのデータを地図に結び付けようとするからです。 例1) pgRoutingによるバルセロナのルート検索 (経路探索例) 実際には、内部の空間データと外部のデータ (統計データなど) が統合されたシステムが、GISの本当の価値を生み出せるシステムです。地図に強く結びついたGISという考え方を持っている場合、POI (Point of Interest、位置情報) データの検索程度などの簡単なシステムまでしか活用範囲が広がりません。 データの性質から分類すると、 (1) データを地図に表示するための空間データ、 (2) 分析を行うための空間データ、 (3) 関連付けられた統計データがあります。これらのデータを適切に加工表示し、空間データと連動する統計データを分析し、結果を重ねて表現することによって、解決策の発見、経営判断や素早い決定を手助けするのが、GISの本来の意味だと私は考えます。そのため、「空間情報と空間情報ではないデータを同時に保存、分析、表示する情報技術である」という「Parkerの定義」 (後述) が、現在のGISの使われ方に最も適した定義であると考えます。 例2) チェルノブイリ原発事故による子供の甲状腺癌のリスク図 (分析例) ESRI (Environmental Systems Research Institute, Inc.) より引用 地図上に表示することだけがGISではありません。POI座標データと関連データを統計的に分析し、ユーザーにお薦めのお店をレコメンデーションするシステムもGISの領域に含まれます。後述するように、実に様々な分野で活用されています。 以下に、GISに関する主な定義を示します。参考文献に載っていますが、参考URL (各定義のタイトルをクリックしてください) でも引用された内容が確認できます。 国土地理院の定義 地理情報システム (GIS：Geographic Information System) は、地理的位置を手がかりに、位置に関する情報を持ったデータ (空間データ) を総合的に管理・加工し、視覚的に表示し、高度な分析や迅速な判断を可能にする技術である。 ウィキペディアの定義 地理情報システム (GIS, Geographic Information System(s)) は、コンピュータ上に地図情報やさまざまな付加情報を持たせ、作成・保存・利用・管理し、地理情報を参照できるように表示・検索機能をもったシステム。 IT用語辞典 (e-Words) の定義 デジタル化された地図 (地形) データと、統計データや位置の持つ属性情報などの位置に関連したデータとを、統合的に扱う情報システムである。 Department of Environment の定義 (1987) 地球に対し空間参照されたデータを取得、保存、照合、操作、分析、表示するためのシステムである "a system for capturing, storing, checking, manipulating, analysing, and displaying data which are spatially referenced to the Earth." Ozemy,Smith,Sicherman の定義 (1981) 地理的に位置付けられたデータの保存、更新、操作、表示のための先進的可能性を専門家に与える自動化された機能群である。 "an automated set of functions that provides professionals with advanced capabilities for the storage, retrieval, manipulation, and display of geographically located data." Dueker の定義 (1979) 空間的に分布する特徴、活動、事象に関する観測から構成されるデータベースとして情報システムの特殊ケースである。これらの観測は、空間内の点、線、面として定義される。GISは、限定的な用途の問い合わせや分析の為にデータを更新できるように、これらの点、線、面についてのデータを操作する。 "A special case of information systems where the database consists of observations on spatially distributed features, activities or events, which are definable in space as points, lines, or areas. A geographic information system manipulates data about these points, lines, and areas to retrieve data for ad hoc queries and analyses." Smith, Menon, Starr, and Estesの定義 (1987) 一種のデータベース・システムである。その中では、多くのデータは、空間的に索引されて (spatially indexed) おり、データベース内の空間的実体 (spatial entity) に対する問い合わせに答えるため、一連の手続きが実行される。 "Smith et al. (1987) defined GIS as “a database system in which most of the data are spatially indexed, and upon which a set of procedures are operated in order to answer queries about spatial entities in the database." Barlow の定義 (1986) 実世界から空間データを保管、操作、解析、取得するための強力なツールである。 "Geographical Information System (GIS) is to say that it is a set of computer tools capable of storing, manipulating, analysing and retrieving geographic information" Parkerの定義 (1989) 空間情報と非空間情報を同時に保存、分析、表示する情報技術である。 "an information technology which stores, analyses, and displays both spatial and non-spatial data." 参考文献 ビジネス・行政のためのGIS (シリーズGIS) 作者: 村山祐司,柴崎亮介 出版社/メーカー: 朝倉書店 発売日: 2008/03 メディア: 単行本 クリック : 5回 この商品を含むブログを見る Mathematical Modelling in GIS, GPS and DC 作者: H. S. Sharma 出版社/メーカー: Concept Publishing Co 発売日: 2006/12/01 メディア: ハードカバー クリック : 1回 この商品を含むブログを見る Geographical Information Systems, 2 Volume Set 作者: David J. Maguire,Michael F. Goodchild,David W. Rhind 出版社/メーカー: Wiley 発売日: 1991/10 メディア: ハードカバー クリック : 1回 この商品を含むブログを見る Journal of Geographic Information and Decision Analysis, vol.1, no.1, pp. 44-68

ネクスト の大坪と申します。インタラクション + 情報推薦であれこれやっております。2011年12月1日～3日に行われました WISS2011 に参加しましたので、その内容について。 WISS の正式名称は「インタラクティブシステムとソフトウェアに関するワークショップ」だが、誰もこの名前で呼びはしない。ほとんどの場合「ういっす」と呼ぶ。では WISS とは何か？公式サイト ( http://www.wiss.org/WISS2011/ ) には以下のような文字が並んでいる。 「WISS は、2泊3日の泊り込み形式で、インタラクティブシステムにおける未来を切り拓くような新しいアイディア・技術を議論するワークショップです。この分野において国内でもっともアクティブな学術会議のひとつであり、例年170名以上の参加者が朝から深夜まで活発で意義深い情報交換をおこなっています。」 しかし WISS に参加することの意味は、これだけの文字で語り尽くせるものではない。私は今回「参加者」兼「登壇発表者」兼「プログラム委員」兼「スポンサー企業の担当者」という立場で参加した。その経験から "参加しなければわからない" WISS の姿について記述したい。 初日夜 WISS の夜は長い。なぜかといえば夕食後の「ナイトセッション」が延々と続くからだ。そのうちの一つは「プリキュアオールスターズ3の鑑賞会」。いや、ただ鑑賞したわけではない。今回論文賞 & 発表賞をダブル受賞した産総研栗原氏の「動画の極限的な高速鑑賞のためのシステムの開発と評価」を使った高速鑑賞だ。私はこの映画を通常速度で見たことがある。もちろんプリキュアなどに興味はないが娘にせがまれては仕方がない。高速バージョンを観ているうち、 「いやこれではこの映画の面白さが抜け落ちてしまう。そもそもこの映画の面白さは通常は一つのチームにまとまっている赤、青、黄色がそれぞれのチームに、」 と熱く語りそうになる。ふと我に返り、いい大人の行動としていかがなものか、と思い直しぐっとこらえる。 今年の WISS には6社が企業スポンサーとして名を連ねている。ビッグローブ、ソネット、電通、電通国際情報サービス、ミクシィという錚々たる企業に並ぶと弊社の知名度が一段劣るのは否めない。1日目の夕食時には各スポンサーが5分間のプレゼンをする。弊社のプレゼンターは リッテル研究所 所長の清田である。 「 ネクスト 社はそもそも知名度が低く、学生の皆さんの内定が決まり、住むところを探そう、という段になってようやく HOME'S というサービスを通じて存在を知ってもらえるわけです」 という「率直」な言葉で笑いがとれてほっとした。 二日目 長い夜が明けると朝がやってくる。 WISS の朝は 「皆さん。おはようございます！」 という凛とした声で始まる。 (最終日にはこの声を使った目覚ましアプリが発表された) 声の主はプログラム委員長であるところの産総研後藤氏。会場のどんよりした雰囲気が一瞬で吹っ飛ぶ。前方にはスクリーンが5枚並んでいる。登壇発表者用、登壇発表者用サブ、参加者が利用するチャット画面表示用、 WISS Gazer という「 WISS を見ている人はどこに注目しているのか」を表示する画面、それにニコニコ生放送である。 これらのスクリーンを使っての登壇発表が朝から夕方まで続く。普通プレゼンはこんな順序で進むと思う。まず問題定義を行い、次に提案する解決策の紹介、それが新規性、有効性をもっていることの説明を経て最後にデモ、そしてまとめ。しかし WISS で発表する際には注意が必要である。しゃべってばかりで中々デモを出さないとチャットが荒れるからだ。「説明はいいから、早くデモ!」といった文字が飛び交う。対象が「インタラクティブシステム」である以上理論付けも大切だが、そもそもどんなものを提案するのかが重要であるという共通認識があるように思われる。 そうした事情も考慮して、私はデモを最初に持ってきた。その効果はどうだったか。発表後、いろいろな人に感想を聞くと、 「何がなんだかわからん」 というものばかりだった。反省しております。最初にデモを持ってくれば良いというわけではない。この事実を胸に刻んで来年の WISS に備えたいと思います。 発表中参加者は会場内だけで使用できるチャットシステムで議論を交わす。会場外から視聴している人たちのコメントはニコニコ生放送の画面でみることができる。東大の五十嵐教授が質問した際 「ゆとり乙」 というコメントが流れたのには爆笑させてもらった。ある女性が登壇したときには 「お嬢さん、結婚してください」 というコメントが流れる。「既婚です」という上コメが表示されると「orz」が流れる。 発表が終わると、質問者がマイクの前に並ぶ。今回チャットで議論になった点の一つに 「学生さんがなかなか質問をしてくれない」 というものがあった。その理由は何か? 会場で使用されていたチャットシステムには、その場でアンケートをとる機能がある。「年配の人ばかりが質問するから」という答えは意外に少なく、「そもそも質問を思いつかない」という回答が多かったように記憶している。反省点の多い私の発表だったが、学生さんが質問に立ってくれたもののひとつであったことはうれしい点だった。 WISS らしい発表 一参加者としては、登壇発表の時間は最初から最後まで気が抜けない。それくらい興味深い発表が目白押しである。その中で私が「最も WISS らしい」と思った発表について記述したい。東大の五十嵐さんによる「文の構造を明示的に指定・表示することによる異言語間コミュニケーション」だ。 機械による自動翻訳ができたらどんなに便利だろう。誰もがそう考えているが、なかなか実用化されない。単語の置換はできたとしても、文章の構造をちゃんと理解することは、コンピュータには未だ荷が重い。その結果、翻訳後の文章は頓珍漢なものになりがちである。 であれば、元の文章の構造を GUI 上で人間が示してやり、それをコンピュータが翻訳すればより理解しやすい文章になるのではないか。このアイディアには驚いた。私たちが普通話す言葉は1次元で構成される。それは1次元が最適だからではなく、人間が用いることができる手段 (音声) が1次元に限定されているから。 コンピュータをインタフェースとして用いることで、文章が本来持っている構造を2次元上で示すことができるのではないか? というのが提案の肝である。本論文は異言語間コミュニケーションを対象としているが、同じ言語を話す者の間でも、この手法は有効なのではないだろうか。日本語でも何を言っているのかわからない文章は多い。 (私のプレゼンもその類と思う。しくしくしく) この論文はそうした新たな可能性に道を開くものだ。しかしまだ研究は始まったばかり。減点方式の査読を行えば「評価が不十分」あるいは「評価による有効性の証明が不十分」ということでリジェクトされるかもしれない。しかし欠けている点よりも、それが示している方向性が評価され、登壇発表として採択されたのは、実に WISS らしいと私は考える。 二日目晩 2日目の晩には2部屋合同で「全員参加型議論」が行われた。 「今年の会議内容を踏まえて、社会や他のコミュニティにどのようなメッセージを提言したいか」 について議論を行い、結果を翌日発表する。 WISS では「伝統的に」異なる所属、年齢層の人が同部屋に割り当てられる。それ故議論に集まったのは所属も年齢も性別も異なるメンバー。これだけいろいろな立場の人と1つのテーマについて意見を交わす機会というのはそうあるものではない。翌日の発表はバラエティに富んだものだった。その内容は一般に公開されているが、私の意見では参加者のみに公開された「議論の過程を書いたメモ」のほうが面白い。表にでなかった様々な意見を読んでいると各部屋でどんな議論が行われていたかが想像できる。 とはいっても延々議論しているわけにはいかない。プログラム委員長と、運営委員長が宴会場の入り口に座っており、両名に議論結果を渡さないと宴会場に入れないシステムになっているからだ。自分たちが早く飲みたい、両委員長に早く飲んでもらいたいと思えば時間通り議論をまとめる必要がある。無事提出して宴会場に入れば昨日と同じく様々な議論が朝まで続く。 この全員参加型議論は、去年から取り入れられた「改革」の一環である。 WISS の冒頭、プログラム委員長の後藤氏はこう述べた。 「WISS は伝統的に革新的である」 この言葉通り、去年今年と「三大改革」が掲げられた。「改革」という言葉に食傷気味の人は多いだろうが、ここで掲げられている「改革」は永田町のそれとは一味違う。ある参加者の Tweet を以下に引用する。 「ある人が「改革します!」と言って、ほんとうに改革を実感したのって人生初めてかもしれない。」 しかし「改革」には常に不安と危険がつきまとう。それらに対処するため、どれほど委員の方が努力し、配慮をしたか。プログラム委員として参加させてもらったことで、そうした隠れた努力を知ることができたのは貴重な経験であった。 最終日 デモ/ポスターセッション、全員参加型議論の1分プレゼンが終わると今年の総括、引き続いて WISS2012 のアナウンスがある。来年のプログラム委員長は東大の五十嵐さん。最初に「気楽に聞いてもらえればいいですから」と言われるのでやけに低姿勢と思ったが、その後に熱いメッセージが続く。 「WISS の参加者は180名だが、投稿された論文はたったの42件。少なすぎる。論文も出さないで、 WISS はマンネリだとか言うのはいかがなものか。最近発表していないベテランもキチンと投稿するように。」 (全て私のうろ覚えによるものなので間違っているかもしれません) 今年の委員長後藤さんの熱が「赤」だとすれば、五十嵐さんは「青い熱」を放っている。来年も楽しみだ。私は今年でプログラム委員を退任なので、せめて論文を投稿することで WISS の発展に貢献したいと思う。とはいえこのメッセージが浸透すると登壇発表の倍率が上がるのだよね。

こんにちは。ネクストの吉次です。 日本 Hadoop ユーザー会の主催により、2011年9月26日に東京のベルサール汐留で開かれた「 Hadoop Conference Japan 2011 Fall 」カンファレンスの詳細です。 今回の数ある講演の中で、私にとって面白かった「 MapR 」「基幹バッチ処理から見た Hadoop 」と「 Hadoop 0.23 と MapReduce v2 」について報告します。 MapR 「MapR」 ( http://www.mapr.com/ ) は Hadoop をベースとした新しいフレームワーク。 Hadoop との一番大きな違いは、新規に独自の分散ファイルシステムを用いたこと。これにより Hadoop の分散ファイルシステム (HDFS) の持つ欠点 (単一障害点がある、上書きができない、 File Descriptor の浪費など) の解消を狙っています。パフォーマンスは 2～5 倍程度向上したということです。 Hadoop 0.23 の新機能 最新の動向を知ることが私の参加の目的だったので、この講演を今回のメインコンテンツとして紹介したいと思います。 次期安定版であるとされる Hadoop 0.23 では、現行からいくつかの大きな変更点があります。今回の講演ではその中から特に HDFS Federation と MapReduce v2 を取り上げていました。 HDFS Federation は HDFS をいくつかの名前空間に分割することでスケーラビリティを確保するものです。名前空間ごとに存在する Name サーバがダウンしてもデータが失われることはないが、ダウン中はその名前空間内のデータにアクセスできなくなるそうです。 MapReduce v2 による構成変更 MapReduce v2 では、旧バージョンにおける JobTracker (リソース管理およびジョブ スケジューリングとジョブ監視) を、 Resource Manager 、 Application Master という2つのコンポーネントに分割します。 (表1) 表1 JobTracker と Resource Manager の比較   旧バージョン 新バージョン Jpb Tracker Resource Manager Application Master Node Manager リソース管理 〇 〇 - 〇 ジョブ スケジューリング 〇 - 〇 - ジョブ監視 〇 - 〇 - Resource Manager プロセスは、各マシンで起動する Node Manager というユーザープロセス管理用サーバプロセスと協調して動作します。 Application Master は、 Resource Manager に要求してリソースを調達し、 Node Manager と連携してアプリケーションの実行とタスクの監視を行います。 Resource Manager は、どのノードにどのリソースを割り当てるかという仕事だけに注力すればよいので、旧 JobTracker と比較すると実装がシンプルになったそうです。 MapReduce v2 の耐障害性 MapReduce v2 では、 Hadoop を ZooKeeper *1 と連携させることで耐障害性を確保しています。つまり、 ZooKeeper での監視により、 Resource Manager がダウンしても、すぐに Secondary Resource Manager を起動させます。そして、 ZooKeeper に記録してあるクラスタの状態に復帰します。その時点でキューイングされたすべてのアプリケーションが再起動されます *2 。 MapReduce v2 の優位性 MapReduce v2 では、 MapReduce アルゴリズム以外のアルゴリズムを導入可能とするため、ユーザーの選択の余地が広がります。データや MapReduce アプリケーションの互換性といった理由から、アーキテクチャを変えてしまうことには不安がつきまといますが、そこは Wire compatibility *3 を持たせることで過去との互換性を保持させるとのことでした。 Wire compatibility の MapReduce v2 への実装及び統合については、 Owen O'Malley 氏がその必要性をかなり強調していました。データやアプリケーションの互換性が保たれるのであれば、 Hadoop 0.23 にバージョンアップして、可用性とアルゴリズムの柔軟性の向上を見込めるというのはかなり魅力的だと思われます。 なお、現行バージョンの Hadoop はマイナーバージョンアップであってもバージョンアップするとデータの互換性はありません。※アップグレードは可能 基幹バッチ処理から見た Hadoop そもそも基幹処理と Hadoop の相性はあまりよくないと私は思っていたので、ノーチラス・テクノロジーズ社の OSS (オープンソース) フレームワーク「Asakusa」に関するプレゼンテーション「基幹バッチ処理から見た Hadoop 」は、かなり興味深い内容でした。基幹業務処理に用いる上での、 Hadoop のイケてないところには、 HDFS 上のファイルの追記や更新ができない トランザクション処理ができない MapReduce のアルゴリズムしか実行できない Namenode の単一故障点問題 などがあります。そこを独自のフレームワーク「 Thunder Gate 」を組み込む事で補い、顧客毎に異なる基幹業務に Hadoop を適用可能とするフレームワークを作り出しています。 私は不可能を可能にしようとするその技術屋魂に感銘を受け、また「これからの SIer かくあるべし」とも思いました。しかし、 OSS 化されているとはいえ、設計技法として DFD-DAG *4 ベースのDSL *5 を用いるなど、一般の企業が導入するには多少の壁 (主に学習コスト) を感じるだろうことも事実です。 しばらく基幹系 Hadoop はノーチラス・テクノロジーズさんの一人勝ちになるのでしょうか? Hadoop の今後あれこれ 日本における Hadoop は、成熟期に入りつつあるか、その直前だと思います。ノーチラス・テクノロジーズ社やエヌ・ティ・ティ・データ社など一部の先進企業が導入に成功し、それに倣って他の企業が導入を検討し始めた、もしくは導入し始めている時期だと考えられます。 私が想像する日本での Hadoop のこれからは、次のようなシナリオです－－多数の企業が Hadoop にチャレンジし、そして様々な難点 (基幹バッチ処理から見た Hadoop 内でいくつか挙げました) のために、導入し損なって失敗事例が増えていく。バブルがはじけ、結局生き残るのは一部の先進企業のみとなる。もしくは Hadoop を補完もしくは代替するような他の分散処理フレームワークが登場し、多くの企業はそちらへと流れていく－－。 このように私は Hadoop の未来に対してあまり楽観的ではありません。 Hadoop はまだまだ発展途上の技術であり、そのまま発展途上で消えていく可能性も十分にありうると思うのです。一方でノーチラス・テクノロジーズ社や MapR Technologies 社のように、 Hadoop を補完するフレームワークを作り出す組織も徐々に登場しつつあります。今は「補完」ですが、そのうち「代替」する技術になっていくと私は予想しています。今回のカンファレンスへの参加から、私はむしろこれらの技術に可能性を感じました。 *1 : Apache ZooKeeper：クラスタの保守管理サービスを提供する集中型サービスソフトウェア。 *2 : 実行中だったアプリケーションははじめからやり直しとなる。 *3 : 新旧アプリケーションの API 互換性と新旧サーバ・クライアント間の通信プロトコル互換性を総称した機能名。 *4 : DFD (Data Flow Diagram) : データフロー図。DAG (Directed Acyclic Graph) : 有向非循環グラフ。 *5 : DSL (Domain Specific Language) : 特定のタスク向けの仕様記述言語。

こんにちは。ネクストの吉次と申します。 ネクスト リッテル研究所では、大量データを解析してレコメンデーションなどユーザ体験の向上に役立てる研究を行っています。リッテル研究所で大量データの解析に用いるミドルウェアとして用いているのが Hadoop というソフトウェアです。 Hadoop を用いる事で大量データの解析を手軽に分散処理できるので、1台のコンピュータで解析するよりも高速に大容量のデータを扱えるようになりました。 私はリッテル研究所の前身である株式会社リッテルの頃 (2008年頃) から Hadoop を利用しはじめましたが、日本のIT業界でも同様に2008年頃から Hadoop を使う企業が現われはじめ、2009年の日本 Hadoop ユーザー会発足や書籍の刊行などにより、IT業界の関心が高まりました。 この日本 Hadoop ユーザー会の主催により、2011年9月26日に東京のベルサール汐留で「Hadoop Conference Japan 2011 Fall」という催しが開かれました。今回はこのカンファレンスの参加報告をいたします。 通算で3回目の開催となる今回、参加者は1100人となりました。私が Hadoop カンファレンスに参加するのは2009年に開かれた第1回に続いて2回目です。第1回は350人程度の規模だったので、参加者ベースで規模が3倍強に膨れあがったことにまず驚きました。カンファレンスは Keynotes を除いて Technical Track 、 Community Track の 2Track で構成されていました。私は最新動向を知りたかったため、 Technical Track に参加することにしました。 カンファレンスの概要 Keynotes 動画 (USTREAM) The role of the Distribution in the Apache Hadoop Ecosystem About Hortonworks How Hadoop needs to evolve and integrate into the enterprise Cloudera, Inc. *1 の Todd Lipcon 氏、Hortonworks Inc. *2 の Owen O'Malley 氏、 MapR Technologies, Inc. *3 の Ted Dunning 氏。 おおざっぱに言うと、それぞれの会社の事業と Hadoop との関係に関する話題であった。 Technical Track Apache HBase 紹介 (Claudera, Inc. Todd Lipcon 氏) HBase の特徴について MapR テクノロジのアーキテクチャ詳細と実装 (MapR Technologies, Inc. Ted Dunning 氏) MapR は Hadoop をベースとしたフレームワーク。 HDFS の代わりに独自のファイルシステムを採用して効率アップを図った点が特筆される。 基幹バッチ処理からみた Hadoop ( (株) ノーチラス・テクノロジーズ 神林飛志氏) 基幹バッチで Hadoop を動かすフレームワーク Asakusa について。 小売り (スーパー) 、パン屋、中部地方の流通業者の事例、 Asakusa におけるシステム開発の概要、今後のAsakusa について。 インフラ構築・運用の勘所 ( (株) エヌ・ティ・ティ・データ 猿田浩輔氏) エヌ・ティ・ティ・データ社での Hadoop のインフラ構築ノウハウ。キーワードは「全体最適」。 スライドはこちら ( http://slidesha.re/mQanVL ) Hadoop 0.23 と MapReduce v2 (Hortonworks Inc. Owen O'Malley氏) Apache でリリースとなる Hadoop の新バージョンの話。 HDFS Federation 、 Wire Compatibility 、その他の Feature について。 詳細は http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/ に記述してあるとのこと。 MapReduce による大規模データ処理 (ヤフー株式会社 角田直行氏, 吉田一星氏) Yahoo! Japan 社における Hadoop 利用の事例と MapReduce のアルゴリズムについて。 スライドはこちら ( http://slidesha.re/owkedH ) *1 : Cloudera 社 (米国本社： http://www.cloudera.com/ 日本法人： http://www.cloudera.co.jp/) は Hadoop の開発者達によって2008年に設立された、 Hadoop の Distribution パッケージをオープンソースで提供してきた企業。Hadoop の生みの親、Doug Cutting 氏がアーキテクトとして参画している。 *2 : Hortonworks 社 ( http://hortonworks.com/ )は、今年、 Apache Hadoop に関わってきた米国 Yahoo! 社の技術者達が Yahoo! からスピンアウトして作った企業。 Apache コミュニティと協力して Hadoop をより堅牢で使いやすくすることをミッションとして掲げている。 *3 : MapR Technologies 社 ( http://www.mapr.com/ ) は、 MapR という Hadoop を利用したフレームワークを開発販売している企業。独自のフレームワークを組み込んだ Distribution パッケージを EMC 社に供給して販売している。