はじめにのはじめに
この記事では、検索サイトをインスタントに検討するときに、こんな形でサバきかたをしたらほどよく効率的・効果的なのではないかというところの自説をつらづらと書き綴ってみました。 （前置きが長いです。）
はじめに: Elasticsearchのユースケース
最近Elasticsearch周辺を探索しておるのですが、私なりの理解＆ネットウォッチャー的視点で言うと、大きく次の適用領域や実際のコミュニティに分かれているような気がします。 *1*2
例によって、雑文もとより、使用している用語のチョイスは少々雑ですのでご了承。
- Elastic Stackまわりでの、タイムリーなログ分析やkibanaをキラーアプリとした可視化、あえての得意領域に絞ったカジュアルBI。
- サイト内検索
- 検索サイト
- エンタープライズサーチ
- ナレッジをストリームのように扱って、集約するまとめ・キュレーション手法
「検索サイト」ユースケースについて
2項目と3項目は似ていますが、次のような考え方で別ものとしました。
前者はWebサイト内のドキュメントにダイレクトアクセスできるようにする検索（全文検索らしいユースケースですね）。
後者は、商品情報などメタ情報（価格とか商品カテゴリ等）を含むドキュメントあるいはドキュメントというよりは、ある程度規格化されたメタ情報や属性情報に全文検索に向くクチコミ情報や商品説明ドキュメントがくっついている半構造化データでしょうか。*3
2項目目と3項目目を分けるべきか、（あえて）分けないべきかはありますが、検索サイトの方は、例えばECサイトであれば、基幹システム等から商品情報が連携されたり、カートに入るところまでがコンバージョンだったりと一般にサイト内検索より色々おまけが付いてくるように思うので、私の中では今は分けています。
個人的な立場としては、
3項目を主戦場に、2項目は副業が現業。
1項目は、昨今だとウケが良さそうなので、これができますエキスパートですと喧伝して、小銭稼ぎやドアノック。
4項目は、SoEの次に投資するなら、SoRではなくて、SoEとSoRの中間のナレッジマネジメント系じゃね？ということで、私の思うところの世の中的にはこの分野が育って欲しいところではありますが、実のところ社内にクローズでナレッジ的にイケている文書って思うほどないのかもという悲しい現実もあるのかもというところ。（ちなみに単純に比較するものでもなさそうですが、solrとElasticsearchで言うと、この分野はsolrにからめたソリューションの方を目にするような気がします。あくまで気がするだけですが。）
あと、5項目については、「ナレッジマネジメント」の新しいカタチとしては非常に可能性を感じていますし、好きなカテゴリです。というか他の分野ほどイメージをしていなかったのですが、↓のリンク先の方の試みを見て、こういう使い方あるよねと、自分の中で5つ目のカテゴリ化にしました。
★しかも、今見ると、実際にElasticsearchで仕掛けとして機能させる方式に発展しているのですね。スバラシイ!! elasticlover.hatenablog.jp
前置きが長くなりましたが（実際竜頭蛇尾）、この記事では、上記の箇条書きの中でいえば、他にも当てはまるものはあるものの、3項目の「検索サイト」をイメージしました。
検索サイトのある種のビジネスモデルキャンパス的なものあるいは3C的なもの
検索サイトを検討したり、全面リニューアルしたりしようとした場合に、まあ今だったらカスタマジャーニーマップとかペルソナをあぶり出してデザイン思考しましょうとかいろいろあるのかもしれません。
ただ、じっくり検討したいのはやまやまですが、ペルソナを頑張って定義したあたりで力尽きませんか？
そのような手法を否定するものでは無く、どちらかといえば歓迎したいのですが、おおよそ発想は同じものの少し軽量かつ逆により本質的な段取りもあるのではないかと考えています。
というのも、Elasticsearchのような全文検索エンジン（＋α）が充実してきたり、Googleのググるを筆頭に、検索するという行為が日常的になったというシーンにおいては、暗黙のデファクトや定石のようなものがあり、それとの比較でモデルをあぶり出していくことができるのではないかと考えています。
何やら小難しいことを言いましたが、私としては、次のような、データ、シーン、(その検索の)ゴールに注目して、頭を整理すると、どのような検索サイトなのか、どのような検索サイトになっていくべきなのかということがおぼろげながら見えてくるのではないかと思い、あんちょことしてまとめてみました。
注：縦方向も横方向もMECEではないです。
使い方のイメージを 以降しらく続けます。 （学校のテストのための対策ではないので、いずれも見取り図程度の扱いでこの表をウィザード形式で読み解けば自然に解が得られるものではありません。 *4
ベンチマーキング・定性分析
- 自身のかかわる検索サイトについて、各行にどれが当てはまるか◯や網掛けでマーキングしてみる。
- ひととおりマーキングしてみたら、縦方向に眺めてみて、相性が良さそうなものに◯がついている組み合わせになっているか確認してみる。
- 組み合わせに難がありそうなら、相性の良い組み合わせになるように検索サイトに足りないものを検討してみる。
- 縦方向の組み合わせもさることながら、横方向に見てみてそもそもなんだっけという話があるなら、右端の備考欄なども参考に足りないものやキャラクターをはっきりさせるために必要なものが何か考察する。
ボキャブラリー集
言っておきながらです、実際のところボキャブラリー集としてはそのままでは少し弱いのです。ですが、例えば、新たな検索サイトを立ち上げる時や検索サイトのオーナーをクライアントに初見でこんな感じのサイトですねみたいな話をする時に、ここに書いてあるようなワードを使ったり、自分なりに膨らませた、相手に響きそうなワードを使って対話をして話を広げるという際の元ネタに使えるのではと思っています。
※そもそも上記表は、ボキャブラリー集としては弱いという自覚はあるのですが、一方うさんくさくなるような気取った言葉はできるだけ使わないようにしました。...というこだわりはあります。
アプローチの点検
使い方の手順はベンチマーキング・定性分析と同じですが、これらが現状分析の用途だとすると、ここでは新しい検索サイトで「こうしたい」という明確なアイディアがあってそのアプローチが整合性が取れているかをこの表を使って点検する。
ペルソナの導出
冒頭で「ペルソナはな〜」みたいなことを言いましたが、何もペルソナを使った手法に問題があるわけではないいです。
私見では、検索サイトの検討にペルソナを持ち出す場合、無理やりペルソナを絞り出した後にサイトのありようやマーケティングを検討するよりも、ペルソナはUXやUIの実現案に対して、これで良いかと言うのをA/Bテスト前に神様の声として勇気付けるために使用する方が良いと考えています。
例えば、上記の表などでおおまかなサイトの整合性を確認した上で、この検索サイトを好んで利用してくれそうな人の例をペルソナとしていくつか作り上げておきます。このペルソナは市場に存在しそうな人が良いと思われますが、それはここではおいておきます。サイトの具体的なUXやそれを実現するUIをワイヤーフレーム等で検討します。
検索サイトの検討では、チームである案について意見が対立したりといった場合に、ペルソナを活用するのが良いと思います。検索サイトと関係ないあるいは時としてテーマが大きくなりすぎるサイトのビジネスモデルのレベルからペルソナを導出するより、この用途においては、上記表でプロファイリングして、それに見合ったペルソナを仮設定した方が楽だと考えます。
コレだという検索サイトのイメージがある場合に手早く考えを収束させる
前項は私の中でいろいろあんちょことして積み上げしておきたく、抽象的なものも含めて分析の目線で幅をひろげすぎてしまったかもしれません。
実際のところ、ある程度の規模に収まる/収めるべき検索サイトにおいて、速攻でPoCに入りたいというような場合、次の図ようなことをチェックすると良いと思います。
この図の内容は、（以前として抽象的かもしれませんが）ここにあるようなチェックポイントに対して、ウチはこうだ！と言えるようになっていると、 頭でっかちにならない程度に、自分の中で軸が定まっているかが見極められるように感じています。
このチェックポイントがなぜ有効かをうまく説明する術は持ち合わせていないのですが、もう少し後で、検索のヒットの仕方や具体的なUIを検討する際に、ペルソナに訊いてみるだけではうまく整理ができないものがあります。整理というかそもそも案や方向性が見出せいないものや、逆にどこまでやるべきかの線引きが難しいという例に遭遇することがあります。
その時、ここにあげたようなもので自分なりにこの検索サイトのありようを見出しておけば、全体コンセプトにそっているかどうか原点にたちもどることができるように思います。
実は検索UXの型は決まっている
決まっているというと言い過ぎですが、実際の検索BOXやファセットの表示のUIの実際はともかく、もしかしてといった代替検索もふくめGoogleの検索にならわざるを得ないと感じています。
これはGoogleの検索のUXが優れているのもありますが、みんながGoogleを使っている現状、単なる真似やオリジナリティの欠如という話以前に、検索においては検索対象は異なるもののまずGoogleと似たような操作感やできることがスタートになります。 *5
ポイントとなりそうな要素をイメージイラストにして、それに対応するElasticsearchの機能を対応付けてみました。
論文ではないので、厳密な対応にはしていません。私はこう考えましたというものになります。
こうやってみると、それぞれチューニングは必要ですが、大半のものはある程度型にはめれそうです。
実は検索UX実現のフローもおおよそ決まっている
現在のデファクトだとこちらもあえていうまでもないのでしょうが、1つの検索結果を出すにあたっての処理の流れ（≒設計として考えなければならないステップ）は次の図のようになると思います。
前の項目と重複する観点もありますが、どの技術を使うか、あるいはそのステップでどんなことがポイントになりそうか、考えをめぐらせて、思考実験をすると良いと思います。
何かサーベイをあたった訳ではありませんが、現在はフリー検索BOXになんらかのサジェストやオートコンプリートが入ることを前提に、手軽く検索して、思ったような結果が得られない場合は検索をやり直したり、検索サービスから提案される絞込みや別の検索条件で再検索を手軽に繰り返すアプローチが主流だと思います。 （エンタープライズサーチや製品マニュアル等ドキュメント数が3桁行かないようなものは、BOX入力時点で検索結果を表示するものもありますが、それ以外は検索窓入力中に検索結果を動的に切り替える例は減ったように思います。）
以前は、RDBに全文検索のエンジンを追加したり、RDBだけで頑張っていた時代、あるいは検索エンジンが全文検索オンリーで属性検索の併用ができなかったような時代には、（今思えばそれが正解とは思えませんが）1回の検索結果を出すために、何回も検索を繰り返していたように記憶しています。
今だとスコアリングやファセットが検索エンジンに備わっているので、今は何回SQLを発行するかというところやSQLの発行順序といったことはそこまで考えなくて良さそうです。
あえて少しこだわってみるなら、
- 質の良くない検索ワードで検索される前にキーワードを確定させるフェーズを組み込む、もしくはメインの検索を走らせる前に検索語の確定論理を個別実装する。
- 検索結果が0件の場合に限り、代替の検索結果を出す。
という図中で点線で示した部分を検討しても良いと思います。
これはサイト内検索では必要ないでしょうが、費用対効果見合いですが検索サイトでは悪くない仕掛けだと思います。特に、専門色が強い一方で一見さんやビギナーさんの来訪が多い検索サイトでは、有効だと思われます。
... と言っておきながらですが、素直にディクトリ型のリンクを辿っていく検索に自然に誘導できるならその方向性をファーストチョイスとした方が良いです。
検索フィールドの扱いを整理
続いて、実際に検索する部分です。
ここも、Elasticsearchなど、製品で設定できる項目（のデフォルト）≒設計ポイントになっていると言えるので、甘く見るのは（特に日本語環境の場合）禁物ですが、Elasticsearchでどんなクエリが使えるのか、設定バリエーションがあるのか確認した上で、どれをどれにあてはめていくと良いか...という考え方でなんとかなりそうです。
先人に感謝ですね。ただ、逆に機能充実しすぎという嬉しい悲鳴もあり、考えすぎ中毒になってしまうので、PoCに向けて初回の頭の整理としては、次のようなステップが良いのではないかとまとめてみました。
図を少しだけ補足すると、
STEP1で
ドキュメントの各フィールドでなんらか力の入るフィールドがどれか見通してみます。優先する項目や厳密にヒットさせたい項目が何かマーキングします。 フィールド数が多い場合は無理に全てをあげる必要もないと思います。
STEP2で
STEP1であげた項目の検索での扱いを分類します。日本語解析で注意が必要かどうかなどの目印もつけておきます。
STEP3で
ペルソナの想定される検索シーンにおいて、STEP2で仮置きしたモデルでほど良いサーチUXが得られそうか軽く思考実験してみます。
ここから先はPoCの出番なのかなと思います。
補足：
ここから先はPoCと言いましたが、可能ならこのタイミングで思考実験をしておいても良いかなと思っていることが2点あります。
- 検索BOXに複数ワードを入れられた場合に、デフォルトでANDにするかORするか、それともあえてそのまま、検索クエリのmatchプロパティ等に食わせるか。(もっと踏み込むと、フレーズ検索を使うかどうか）。
- 検索BOXに複数ワードをORで検索したいユースケースがあるか。あった方が良いのは便利だが、それはディレクトリ検索方式に寄せられないか。
長くなるのでごまかしたのですが、これらの2点については、資料にまとめるかどうかは別として、ディレクターの方は、頭の片隅においておいた方が良いかもしれません。 → ちょっとだけ関係ある記事をこちらに書きました。
PoCと並行して、ローンチ後のチューニングのサイクルを見据えよう
注：前項のとおり、ここらあたりでPoCで実際にElasticsearchを動かした方が良いのですが、そこについてはここでは置いて置き、少し観点を変えます。
PoCや実際のプロダクト開発をしている中で気づきがあると思います。
もちろん、気づきとともに、ローンチに向けて自己改善・チューニングを進めてゴールに達するものもあると思います。
一方で、これはという答えにたどり着けないものもあると思います。.... というか無理にそのように進めるべきではないと思います。
ペルソナを使ってもそうでなくても、絶対と言って良いほど、実際のサイト運営に入ると想定外、想定以上の利用のされ方になることになり、どれだけ自己満でカリカリにチューニングしても限界があります。
笑えない話ですが、オンライン・オフラインともに、集客の仕組みがよろしくないと、そもそもサイトに人が来ないということも当然ありえます。
来訪者が少ない話は別として、PoCや実際のプロダクト開発をしている際に、積み残しや気になったことは書き留めておきましょう。
また、チューニングした際の作業サイクルや段取りはできるだけ残して置きましょう。
またまた、実のところ、ローンチ後の実際の検索のされかた・利用のされ方に応じて、どうやってチューニングしていくかのエコシステムについて考えをまとめておきましょう。
と言っても、やはり昨今ではやれることがある程度型にはまってくるので、例えば次の図のようなものにおおよそ集約されるのではないかと思いますので、もしよろしければ、これをたたき台に少し、ご自分の検索サイトだとこうかなというところにアレンジすると良いかなと思います。 *6
検索チューニングのエコシステムイメージ
ここで、もうひとつ掘り下げたいことがあります。
実のところ、Elasticsearchについては、そもそものaccessログとX-Packで多少ログが出るようですが、ユーザーがどんな検索をしたのかというログについては出力されません。
ということで、チューニングしたいと思うなら、検索ログをアプリで出力するようにプロダクト開発しておく必要があります。
また、その検索ログですが、様々な分析が考えられますが、主な観点としてこんなものかなというところを次の図にあげました。
検索チューニングのための検索ログの分析観点
図に例示した観点は、幹部への報告や逆にユーザー向けのアクセス上位ページランキング等の観点と一見似ていますが、検索の改善のために掘り下げる必要があります。例えば検索ワードランキングではアクセス上位ページランキングの例だとひとまず集計をして終わりですが、サイトとして使って欲しい用途の検索がされているか、その逆はないか、想定外だがビジネスチャンスにつながるような利用方法の芽があるのかというところの視点で確認することになります。
ここは万能薬はないものの、良くあるパターンでチェックリストを作れそうな気がしますが、今回はそこまで手が回らずなので気持ちの表明にとどめておきます。
また、ある種のBI的な営みなので、検索ログをElastic Stackに取り込んでモニタリングや分析するというのも検索ディレクターとしてうまいやり方のような気がします。
長くなったので、ここでは記事にしませんが、先人にまとめていただいている良記事を見つけましたのでリンクさせていただきます。
さいごに
Elasticsearchの影響をうけて、あるいはElasticsearchのような検索エンジンがあるからこその自説を述べることができたのは事実ですが、さほどElasticsearchのテクニカルな情報等は盛り込めず、雰囲気のみの話題になってしまいました。
どこかで誰かの役に立つかもしれないので、本記事の例をもう少しElasticsearchでの実例に展開した記事を書けたらなと思っています。
*1:コミュニティが分かれているというのは、派閥があるのでは？という意味ではありません。もちろん。そもそも諸事情により私自身は、こそこそ間違っているかもしれない自分忘備録をネットの片隅で書き溜めている次第なのでそこには明るくありませんが、次の5つの特に1項目とそれ以外では何をターゲットに話をしているかによっては大きく違ってくるので各種サイトや勉強会資料を参照させていただく際にはどのコンテキストか意識しながら読むようにしています...ぐらいの意味です。
*2:Elasticsearch公式？？的には、Application Search, Site Search, BUsiness Analytics, Enterprise Search, Metrics Analytics, Operational Log Analytics, Security Analytics
Use Cases · Elastic Stack Success Stories | Elastic
ですかね。
*3:私見では、半構造化データと構造化データのさらに中間の位置ですが、それはここではどうでも良いことかもしれません。
*4:最初はそのような古のエキスパートシステムのようなものを構想していたのですが無理があって断念しました。
*5:少し前は、検索UIや見せ方について群雄割拠の時代もあったように感じています。少し寂しい気持ちもありますが、一旦収束することで、それを下敷きに新しいものが出てくるので、全体としては歓迎すべき流れだと思います。
*6:説明の都合、皆さんもどうですかという話っぷりですが、実際は、未来の自分へのカンペです。ご了承ください。
