本記事は情報検索・検索技術 Advent Calendar 2022の6日目の記事です。

はじめに

最近はプロダクトの検索システムを全文検索エンジンを利用して開発しています。通常の機能開発と同じ難しさもあれば、検索機能独特の難しさもあると感じています。本記事では、以下のよくありそうな場面を想定してみます。

通常の機能開発を行うプロダクトごとの職能横断のチームX
検索技術を専門とし検索APIのようなサブシステムを提供するチームY
マーケやディレクターのようなビジネスサイド

難しさ

難しさには、状況によりさまざまあると思います。まず、プロダクトでの課題がありその原因への打ち手として検索機能開発があるというのが全体像だと思います。その検索機能開発において、チームXとチームYが連携して開発していきます。

本記事では4つの難しさについて触れます。

作るのが難しい
- これはチームYに閉じた話で、文字通りそのままで検索システムは設計実装するのが難しいということです。
検索ロジックの妥当性を示すのが難しい
- これはビジネスサイドとの合意形成やチーム内の検索ロジックの方針を決定する際の問題です。作る/作った検索ロジックについて妥当性を示すのが難しく、新しく機能を追加する際にリターンを明確にできずリスクを取ることが難しいことがあります。
打ち手から課題へアプローチするのが難しい
- これはビジネスサイドとの開発前の合意形成の話で、課題より先に技術(How)からスタートしていくなど特殊なプロセスが必要になるということです。特に検索技術はビジネスサイドにとってはブラックボックスであることもあり、この必要性が大きいと思います。
装着が難しい
- これはチームXとチームYの連携の話であり、バッチで検索エンジンへデータ連携、API仕様、ロジックをどちらが持つのか、非機能要件はどうするのかなど論点が多いです。

難しさ	なぜ難しいのか	具体例
作るのが難しい	API開発に加えてデータ分析・検索エンジンに関するスキルが必要になることが多いため。また、データ分析による定量評価と定性評価→検索ロジック施策決め→実装を繰り返す必要があり、プロジェクト開始時に作る検索ロジックを明確に決定できない場合もあるため。	ElasticsearchやSolrのクエリやテンプレート、運用知識が必要になる。あるロジックを導入したら、Recallは上がったがPrecisonは下がった。
検索ロジックの妥当性を示すのが難しい	検索ロジックの評価が難しいため。オフライン定性評価・定量評価を行い、最終的にはオンラインABテストで評価することが多い。	正解データがないこともしばしばあり定量評価が難しい。その中でもチーム内外問わず合意形成していかなければならない。
打ち手から課題にアプローチするのが難しい	課題から打ち手を考えるだけでなく、打ち手から解決できる課題を提案し、その打ち手が本当に最適なのか確かめるプロセスが必要になるため。検索技術はビジネスサイドにはブラックボックスであることもありエンジニアからこのようなプロセスで提案することも必要になる。	シノニム・辞書登録を導入すると検索品質は向上するため課題とセットでビジネスサイドに提案し、課題解決手段としてシノニム・辞書登録が最適であることを説明する。
装着が難しい	チームYのような検索機能を開発するチームは専門性の高いサブシステムの開発や提供を行うチームであることがあり、この場合にチームXのような一気通貫して価値提供しているチームとは、プロダクトに対する解像度が違うことがあるため。そのため、WANT要件をMUST要件であると勘違いしオーバーエンジニアリングしたりする。	チームYは思い込みで間違えた前提を置き過剰に検索品質(クオリティ)を高めるためにコスト・デリバリーを犠牲にすることがある。

対策

それぞれの難しさに対しての対策は、具体的な状況によりケースバイケースで本記事では深くは触れません。「作るのが難しい」は個人のスキルアップでどうにかできる場合もあれば、開発プロセス・体制を変更することで難しさを減らすこともできると思います。「検索ロジックの妥当性を示すのが難しい」は、プロトタイピングにより具体的に検索ロジックを体験してもらうことでステークホルダーからフィードバックを得られたり評価することができるかもしれません。「打ち手から課題にアプローチするのが難しい」は、現状のプロダクト・システムやUXの理解とその課題を発見し、それを解決できる技術がないかというのと、この技術はなんの課題を解決するんだろうと両面から日頃から考えるのが大事かもしれません。「装着が難しい」は、チーム間の責務を定義・変更したり、密にチーム間でコミュニケーションを取ることで解決できるかもしれません。