システムの特徴と検索機能について(検索システムに関する妄想その1)

今年の頭からシステムの検索周りを手伝う仕事をフリーランスとしてやっています。検索の仕組みを知れば知るほど面白くなってきたからという理由になるのかな? LuceneやSolr、Elasticsearchなどを長く触っているというのもあるかと思います。

ということで、検索についていつも考えています。頭の中でまとまっていない状況ですが、システムにおける検索機能についていくつか頭の中にあることを書き出して、いろんな方にダメ出しやコメントをもらいたいなと思ったので、色々と書いてみようかと。思いつきのままに書いているので、はなしがあちこち飛ぶ可能性もありますが、あしからず。

検索って難しい

「「検索」とは、データの集合から目的のデータを探し出すこと」By Wikipedia

一言で「検索」といっても、使う人、ユースケースによっていろいろな「検索」があります。例えば、新しいスマホを買ったときに、スクリーンロックの時間を設定する機能を「検索」したりします。また、PCで仕事をしているときに、ファイルの中身をある文字列で「検索」したりもします。 TSUTAYAに行って、欲しかった本がおいてあるかどうか店内の端末で「検索」もします。 Rustを書いていて、こんなことをやるライブラリありそうだよな?と思ってGoogleでウェブの検索をしたりもします。

私が特にそうだと思いますが、なにかあったらまず検索をするという生活をしています。ただ、このとき、「検索」といっても望んでいる挙動が違ったりするものです。以下は自分が「検索」しているときに想定していることになります。

ファイル内の検索をしているときはgrep的な検索を想定していることが多い。
書籍の検索をしているときは、特定の項目(著者など)に対してgrep的な検索を想定しているが、名前の読みなどでも検索されることを想定している(漢字覚えてなかったりする。。。)。
Rustを書いているときに機能をGoogleで検索するときは、いい感じに検索してくれることを望んでいる(入力するキーワードが曖昧なことが多々ある。例えば、そのものズバリの名前をしらないときとか)

あくまでも私が想像している挙動です。他の人とは違う可能性もあります。なので、「検索」といってもさまざまな要素があるし、想定しているシーンも異なるので「難しい」なと思っています。また、そんな「検索」ですが、世の中的にはあって当たり前だと思われていたり、お金や時間がかかるものと思われてなかったりもします。ま、けどそういったことも含めてやればやるほど面白いなと感じている今日このごろです。

前置きはこのくらいにして、今回はシステムの特徴と検索機能について感じていることを書いてみようと思います。

システムの特徴と検索機能

先ほども書きましたが、検索は今やシステムに欠かせない機能となっています。が、あればいいというものでもないのではないかなと。とりあえず検索できるべきだということで検索機能を追加しても使いにくいものや、想定している動きをしない場合は使われないものになってしまいます。

システムでの検索機能は特に、「情報検索」(Wikipediaはこちら)と呼ばれたりもします。Wikipediaによるとこんな説明です。

情報検索（じょうほうけんさく）とは、コンピュータを用いて大量のデータ群から目的に合致したものを取り出すこと。検索の対象となるデータには文書や画像、音声、映像、その他さまざまなメディアやその組み合わせとして記録されたデータなどが含まれる。

「目的」と呼ばれるものは「ユーザーのニーズ」と呼ばれたりもします。「合致したもの」というのがシステムが返す「検索結果」になります。検索結果は大体の場合、何かしらの順序でソートされていることが多いです。ざっくり話をすると、「ユーザーのニーズ」を元に「(何かしらの順序でソートされている)検索結果」を返すという処理です。

ただ、この「ユーザーのニーズ」や「何かしらの順序でソートされている検索結果」はシステムの特性、特徴によってぜんぜん違うものになります。検索エンジンを入れただけで解決するものではありません。

また、システムは提供する側のニーズもあります。 ECサイトであればより多くのユーザーに購買してもらったり、コミュニティサイトの場合は利用ユーザーを増やしてコンテンツや広告の収入を増やしたりといったニーズがあります。

これらの両方のニーズが検索機能に影響を与えたりもします。

いくつか例を上げてみましょう。

書籍の検索の場合

ユーザーのニーズは、「ある本を探す」ことです。そのためにユーザーがクエリを入力します。クエリは、例にも出しましたがタイトルや著者名の読みだったりします。検索窓が1つしかないというよりは、著者やタイトル、出版社などそれぞれの項目ごとに検索できるほうが便利だったりしますよね。検索結果については、完全一致したものが一番最初に出てきてほしいこともあれば、出版年月日の降順で並べたいことなど、その時々でやりたいことが変わったりもします。

場合によっては、説明文などでも検索できると嬉しいこともあります。また、システムからは離れますが、図書館や書店で時々、「〇〇について書かれている本ありますか?」といった聞き方をしたりもします。

また、書店としては、探している本を見つけてもらうために検索端末などを用意しますが、それ以外の本も買ってもらえるといいですよね。オンラインの書店などでは、検索結果や書籍詳細の画面に関連書籍が出ていることもあります。

検索とは少し異なり、探索(なにか面白い本とかないかな?というようなニーズ)をしに、書店に行くこともあります。書店で平積みされた本やポップなどを見て新しい本に興味を持つこともあります。

オークションサイトやECサイトでの検索の場合

ユーザーのニーズは、「欲しい物を探す」ことです。ユーザーが入力するクエリは、幅広いものになると思います。製品の型番を入力する人もいれば、メーカー名や製品名だったり、ジャンルで絞り込んで検索することもあります。

探されるもの(コンテンツ、アイテム)も多数に渡ります。検索窓は1つかもしれませんが、検索結果には、絞り込み条件(ファセット)がいくつか並んで、絞り込んでいける仕組みが用意されていることが多いです。

検索結果のソートは、価格順だったり人気順だったりします。ただ、オークションサイトの場合は新しいもの順や、終了日時の早い物順だったりします。

サイト提供者のニーズとしては、より多くのアイテムを購入してもらうこと(売上)です。また、オークションサイトの場合は、アイテムを提供している人のニーズも影響してくるでしょう。売りたい人はより多くの人の目に止まってほしいと思うはずなので、様々な情報を付与していかに目にとまるか?といったことを考えてくると思います。

また、様々な商品を扱うECサイトの場合は、さらに色々と大変になってきます。たとえば、「iPhone」で検索されたときに、 iPhoneそのものが上位に来るべきなのか、ケースなどの周辺商品なのかだったりといった問題が出てきます。商品の提供者が多数に渡る場合は、同一商品でもさまざまなお店から提供されてしまうために、検索結果一覧に多数同じ商品が並んだりもしますよね。

レシピサイトでの検索の場合

ユーザーのニーズは「レシピを探す」です。が、探し方はユーザーによって様々です。冷蔵庫にある材料を入力して検索することもあれば、食べたいものが決まっていてそのレシピを検索することもあります。このとき、重要なのは類義語だったりするでしょう。食材やレシピは同じものでも様々な名前(例:パクチー、コリアンダー、シャンツァイ(香菜)など)を持っていたりします。また、部位や形によっても名前が変わったりもします。

検索結果は人気順で並ぶことが多いでしょうか? ただ、レシピの提供がユーザーによるものなのか、サイト運営者が提供しているものかによっても変わってくるでしょう。

サイト提供者のニーズとしては、レシピコミュニティサイトの場合は、ユーザー数の増加や広告の売上などがあるでしょう。調味料などのメーカーがレシピサイトをやっている場合は、調味料の売上だったりします。この場合は、検索がどの程度売上に寄与しているのか?などを測ることが難しかったりしそうです。

社内文書検索の場合

ユーザーのニーズは「文書を探す」です。探し方はファイル名であったり、ファイルのなかに出てくる単語だったりします。社内用語・略語のような特殊な単語で検索されることもあるでしょう。ユーザーによっては、ぼんやりとした「こんな資料を探している」といったふんわりとした検索をしたくなることもあります。

検索結果の表示順は「それっぽいもの」が上位に出てくることが望まれそうです。ただ、古い文書が出てきても役に立たないこともあります。新しい文書のほうが役に立つことが多いので、最近作られたものというのも重要な情報になります。ただし、権限によっては見ることができなかったり、そもそも探すこともNGだったりもします。

社内文書検索の提供者は、素早く検索できるものを提供することで仕事の効率を上げてもらったり、無駄を省くことができることを期待しているでしょう。

昔からですが、社内の文書は様々な場所に散らばっていることが多いです。顧客管理システム、ファイルサーバー、Wiki、ウェブサイトなどこれらをまとめて検索できるシステムなどが望まれていることも多いです(使われるかはまた別ですが。。。)。

スマートスピーカーの場合

ちょっと特殊な面白い例かなと思ってます。音声で検索(というかお願い?)します。システムとしては、ユーザーのニーズを理解するのに2段階あるのかなと。

音声認識
認識した文章・キーワードで検索(場合によってはコマンド発行)

これだけでも難易度が増します。

さらに、画面のないスピーカーの場合は、結果は1件だけになります。これって結構難しいことだと思うんです。画面があれば、検索結果を上位10件などのリストで表示して、あとはユーザーに選んでもらうことができますが、音声の場合は1件だけしか返せません。また、レスポンスタイムもシビアなものだと想定されます。ずっとスピーカーに黙っていられると困りますよね? きっと大変なんだろうなぁ(妄想)。

このように、検索と言っても、システムごとに要求・想定されるものは変わってきます。

まとめ

例をいくつか上げましたが、ざっくりしすぎて発散してますかね。。。想像している部分もあるので、この通りではないと思います。ただ、システムによって、「検索」といってもシステムの特性上、さまざまな物事、思惑が絡んでくるというのは想像してもらえたと思います?(思いたい)。

システムに検索機能を追加すると言っても、探したいものが何なのか?、探してもらうものはどういったものなのか?、検索機能を追加することで何を達成したいのか?など考えることは色々あります。どうやって、検索機能を実装するのか、その検索機能を実装するためにはどんな情報が必要なのか?などの検索機能のコアな部分を考えるだけでなく、提供しているシステム、コンテンツがどんなものかなど、システム全体を考えながら検索機能を考えていく事が検索をより良いものとして行くことだと思います。

また、検索されるものも検索する人もシステムが成長するのに合わせて変化していきいます。システム同様、一度作ればおしまいというものではないので、やることはいっぱいあるのかなと。

次は、検索のパーツについてなにか書こうかなぁ。

ボヤキ

もう少しまとめてから書いたほうがいいのかもなぁ。もしくは、出てくる要素を整理するとか。ユーザー、コンテンツ、コンテンツ提供者とかで。ふんわりとしたブログになってしまった。個別のシステムごとにもっと書けることもありそう。