ヘルプページの検索エンジンをAlgoliaに変更した話（導入編）
こんにちは、freeeカスタマーサクセスのamayaです。セルフサクセスというチームで、企画とマネジメントを担当しています。
CS HACK Advent Calendar 2022の16日目を担当させて頂きます。
（もう12月も後半ですね、、👀）
昨年末のアドベントカレンダーで「ヘルプページを7年ぶりに大刷新した話」というnoteを投稿したのですが、今回はその続編？になります。
＊思いのほか前の記事に反響を頂き嬉しかった&調子にのって「ヘルプ関連でもっとニッチな記事を書いてみよう」と思った次第です。笑
このnoteの目的
freeeでの試行錯誤をあえ共することで、同じ悩みを持ったヘルプページ担当者が改修を検討するにあたって、一つのケーススタディになればと考えています。
ヘルプページに関する取り組み事例は、何故かなかなか出会うことがありません。ただ、ヘルプページはBtoBサービスのユーザーにとって、プロダクトの次に接点の多い「サービスの顔」の一つだと思っています。
（freeeのヘルプページも、今や年間1,000万PVを記録し、ユーザー体験を規定しうる重要なユーザー接点になっています）
今回は、ヘルプの検索精度を改修したプロセスをあえ共してみます。
ヘルプの検索精度問題は、サービスが成長しコンテンツ数が増えてくると、多くの会社で課題を感じるタイミングがあると思っています。
超絶ニッチ&至らぬ箇所も多々あると思いますが、1つの事例としてご笑覧いただければと存じます。
freeeヘルプページの課題：検索精度
freeeはBtoB領域のバックオフィス業務を中心とした、各種サービスを展開しております。
そのサービス性質上（＝専門性が高く機能が複雑になりがち）、ヘルプコンテンツも多数用意せざるを得ず、現在は約2,500記事が公開されています💦
ただ、記事数が多くなると、検索精度は反比例して落ちてしまいます。
ヘルプページの課題を洗い出すためのユーザーアンケートや社内ヒアリングを行った際に「検索しても目当ての記事に辿り着けない」という声が多数寄せられていたこともあり、検索精度についてもう一歩深堀りして、課題を明らかにすることにしました。
具体的な検証方法としては「ユーザーの検索ワード⇄表示された記事⇄その後の問合せ」を突き合わせて、おおよそ100セット程度のパターンを確認しました。
地道な作業ですが、結果として「どのような検索ワードで適切な記事が表示されていないか」が、以下のように言語化できました（代表的な課題3点のみ記載）
課題①（検索ワードが複数のプロダクトの記事で利用されている場合）
問題点：ユーザーは特定のプロダクトを想起しながら検索しているが、それとは異なるプロダクトの記事がサジェストされていた
具体例：「検索ワード＝住民税」の時、上位10記事が「人事労務6/会計3/申告1」と3プロダクトを跨いでしまっていた
課題の大きさ：約2割の検索ワードで複数のプロダクトの記事が上位10件のいずれかに存在していた
課題②（検索ワードが粗い場合）
問題点：検索に引っかかる記事が多数存在する中で、ランキングが適切でなかった（マイナー/ニッチな記事が上位に存在していた）
具体例：「検索キーワード＝銀行」の時、特定のマイナーな銀行のFAQが検索上位に来てしまっていた
課題の大きさ：約3割の検索ワードで利用頻度の低いマイナーな記事が上位5件のいずれかに存在していた
課題③（検索ワードが揺れた場合）
問題点：検索ワードの揺れに対応しておらず、適切なヘルプが引っかかっていなかった
具体例：「退会→大会」などの変換ミスに対応できていなかった。「同期→〇〇銀行」などの固有名詞の使用に対応できていなかった
課題の大きさ：特定機能の問合せでは、約3割の検索ワードでこのパターンが存在していた
ここでの学び：一見地道だが、具体的な検索シーンを見ていくことで解像度高く課題を発見できた（ただ見る作業は結構辛かった）
KPIの検討
上記で課題が見えてきたので、次は「どんな指標で"良い検索"を測定すればいいか」を考えることにしました。（都度問合せと突合して良し悪しを測るのはコストがかかりすぎるので、、）
とはいえ当時のチームには、検索まわりで経験が豊富な人はいなかったので、検索が重要な他社サービスの事例を参考にさせて頂きました。
具体的には下記のコンテンツがとても参考になりました。（難しくて2-3割しか理解出来なかったですが、、笑）
「いい検索」とはなにか？検索システムのしくみと評価指標を解説（リクルートで検索改善業務を担当されている方の講演記事）
Interleavingを使った推薦アルゴリズムの評価について（Wnatedlyで推薦や検索の改善を担当されている方の記事）
検討のプロセスは長くなってしまうので割愛しますが、結果として下記の指標をメインとして追っていくことにしました。
CTR：ユーザーがヘルプページ内で検索を行った直後に、ヘルプ記事に遷移した割合
選択された記事の表示順：ユーザーがヘルプページ内で検索を行った直後に、ヘルプ記事に遷移した際、遷移した記事が検索結果一覧画面で、何番目に表示されていたか
ここでの学び：「ヘルプページの検索精度」の事例は見つからなかったが、抽象度を上げて「良い検索とは」で事例を探したら参考になるものがあった
ソリューションの検討
KPIを考えるのと並行してソリューションの検討も並行して行っていきました。
検討①（既存のCMS内で頑張る）
まず最初に、既存のCMSとして利用しているZendeskの機能で解決できないかを検討しました（検索エンジンやCMSのリプレイスは時間がかかるので、Zendesk内で解決できるなら一番リーズナブル）
Zenseskの検索結果の重み付けロジックはヘルプページにて公開されています。ざっくり自分の理解だと、ロジックを変更することはできず、タイトルやラベル付与など記事側に手を加えることによって、ランキングを調整する仕組みになっていました。
検討の結果「ラベルという機能で課題③が解決できること」「独自実装すれば課題①も解決できること」「課題②の解決は難しそうなこと」が分かりました。
また、ラベルを追加した時の効果測定（結果としてCTRが上がったのかなど）はやや難しそうなことも見えてきたので、今回の課題はZendesk内だけで解決することにはせず、次章以降の検討に入っていきました。
検討②（CMSをリプレイスする）
次に考えたのは「これを機にCMSを入れ替えてしまう」というアイデアでした。最近では検索揺れに強いFAQシステムが出てきたり、技術革新が進んでいる感覚があり、数社にお話をお伺いしました。
ただ結果としては、検索ロジックは興味を惹かれる部分はありながら、
「課題①のプロダクト出しわけが難しい」
「検索以外(フロントの柔軟性/APIの有無)でノックアウト要件がある」
「リプレイス時の費用対効果が見合わない」
という理由で、こちらも見送る形になりました。
検討③（検索エンジンだけリプレイスする）
そんな中最終的に辿り着いたのは「検索エンジンだけリプレイスする」という方向性でした。
freeeには「AI-labチーム」という、AIや自然言語処理の専門家集団がおり、彼らと共に検索エンジンの検討を行ってみました。
具体的には「ElasticSearch」「AmazonCloudSearch」「Algolia」の3つの検索エンジンを調査してもらい、上に挙げた課題や運用、料金面での可能性を比較しました。
結果として、運用コストに大きく分があり、上に挙げた課題解決が全て叶えられるAlgoliaで検証を進めてみようということになりました。
（zendeskのサイトでもAlgoliaをお勧めしていた&別サービスでAlgolia導入経験があるのも追い風に）
（この時点では「検証して精度が上がることが分かれば導入しよう！」という温度感）
ここでの学び：色んな解決方法があったが、課題がはっきりしてるとソリューションの選定が楽だった（課題抽出をサボってたら別の打ち手になってたかも）
実装
ここはengの皆さんに(CREチーム)ご尽力頂いたフェーズなので、CREへのQ&A形式でお届けします
Q.そもそもCREってどんなチームですか？
A.最近Saasサービスが拡大しているIT業界では各社でCREという職種を置く会社も増えてきていますが、各社CRE役割は様々です。
freeeのcreがどんな役割を担っているかは、こちらのdevelopers hubの記事にも記載していますが、ユーザーからの問い合わせの早期解決と、そもそも問い合わせせずとも使えるプロダクトを目指して、エンジニアリングで改善しいます。
Q.Zendeskへの繋ぎこみはどのように行いましたか？
A.定期的にzendeskのAPIを叩き、zendesk内の記事を全件取得、整形して、algoliaへ同期するプログラムを作りました。
Q.実装期間はどのくらいかかりましたか？
A.algoliaへのインデックス処理の実装やらヘルプ検索画面のUI変更なども含めておよそ3週間くらいだったかと思います。
Q.eng観点で、今回のPJの良かった部分は？
A.検索精度改善のPDCAにengが関与せずとも回るようになったのが一番の成果だと思っています。algoliaにはUIでポチポチしながらABテストを実行する機能があり、その結果をレポート画面で簡単に見れるダッシュボードも用意されているので、検索順位の設定や同義語を設定するsynonim設定など各種プロパティをサポートメンバー自身でいじって検証、ABテストの結果がよければそちらの設定を採用して全面展開する、といったサイクルをエンジニアの手を一切介さずにできるようになったのは画期的でした。
ここでの学び：3週間で開発完了したCREすごい
リリース（したらクラウド破産しそうになった件）
（この時は下記問題が発覚しておらず、やりきった気持ちでいっぱいだった）
ここまで検討開始から約半年。
ようやくリリースに辿り着いた我々に、いきなりの試練が起こりました。
試練の話をするにあたっては、まずはAlogliaの料金体系についてお話する必要があります。
ざっくり言うと、料金体系は検索回数に応じた従量課金制です。
そのため、ヘルプページ全体や検索ページのPV数を元に見積もりを行っていました。
しかし、いざリリースした後、ふと日次の利用数をAlgoliaのダッシュボードから見てみると、、「あれ、想定の10倍も検索されている、、、😇😇😇」
数十万円/年の予算しか用意していないのに、このままだと数百万円/年が必要になることが分かり、血の気が引いたのを今でも覚えています。
急いでSlackでengに連絡を取り「このままじゃ予算が枯渇しちゃうので、1週間原因を探して見つからなかったらバージョン戻しましょう」という話をしていました。
最終的には「ページに遷移するごとになぜか空のクエリで1度algoliaにリクエストを投げてしまっている」ことが3日目に分かり、シュッと修正して事なきを得ました。（同じように困っている人の投稿をengが見つけてくれた）
ここでの学び：QA項目に「想定以上にリクエストが飛んでないか」を入れるべき（基本的な事だと思うので恥ずかしい限りですが、、）
導入編まとめ
紆余曲折を経ながらも、何とかリリースまで漕ぎ着けることができました。
検討開始からリリースまで半年以上かかってしまったので、ややコスパの悪い企画になってしまったものの、多くのユーザーが利用している機能を改善できて良かったです。
とはいえ、出して終わりではないので、ここから「検索精度改善編」が始まります（1stリリース時点では、従来よりCTRが2%程度しか上がっていなかった為、このままだとROIが見合わない）長くなってしまったので、こちらは後編として、19日にfreeeカスタマーサクセスのアドベントカレンダーに投稿します。
超絶ニッチな記事ですが、ここまでご覧いただきありがとうございます！
ちょい日程が空いてしまい恐縮ですが、よければ後編もご覧いただけると嬉しいです（詳細な効果測定とかも後編に書きます）
この記事が気に入ったらサポートをしてみませんか？