はじめに
DMM で検索レコメンドの PdM を務めている西潟です。DMM に限らず，検索レコメンドのプロダクトを有している企業において，情報検索，推薦でよく用いられる実装やその評価指標と，ビジネス KPI が整合しないことはよくあると思います。
よくある課題だと思っていますが，これについての記事を見かけることが少ない気がしているため，これから複数回に分けて DMM の検索レコメンドに関わっている中心メンバー，及び共同で取り組んでいる企業の方から本課題についての深堀りやその対策，事例などを紹介していく予定です。
初回の本記事では DMM での取り組みを知ってもらう上で，DMM のサービス紹介や，記事全体で述べたい課題感に触れ，詳細な 別記事 にバトンタッチする内容にします。
執筆の背景
DMM が検索レコメンドの役割を売上貢献とし，本格的にこれに舵を切ったのはおよそ3〜4年前になります。当時は今よりも小さな組織で，短い期間で売上に対して貢献できる施策を模索していました。特に検索の relevancy においてはお世辞にも良い品質と言える状況にはありませんでした。ともすると改善も容易であり，すぐに売上貢献できると考えていましたが，実際は違いました。
AB テストが比較的容易にできる環境にあったので，改善策の効果検証はできましたが，我々に課せられていた ARPU（ユーザー一人あたりの平均売上）に対する向上はなかなか見られませんでした。
ARPU を向上できても，それが狙って向上させられたものだったのか，再現性を持つ施策なのか，どれほど持続した効果を持ち続けるのか，など様々な課題が残りました。実施したエンジニアも，偽陽性である不安や，偽陰性であるかもしれない落胆がありました。
また，1つの改善策だけでは KPI に対して十分に効果を作り出せない状況もよく観測されました。（正確には作り出せないのでは？という仮説）
例えば検索においては，ユーザーからの入力に応じて結果を返す特性を持つため，特定のクエリに弱いなど，エッジケースに対する改善策もよく取られますが，このような1つの改善策が介入できるビジネスインパクトは僅かである可能性が高いですし，そもそもインパクトを与えたか観測すること自体困難かもしれません。プロダクトの品質を考える上では，明らかにおかしな結果を返すクエリは対応すべきでありますが，この対応がビジネスに対してどれほど貢献するか試算しつつ，その他のビジネス貢献価値が高いと思われる改善策と比較して優先度を決める作業は至難の業です。開発リソースが潤沢にあれば，これらの課題は品質管理と Growth 施策として分けて考えて，それぞれ独立して取り組むべきですが，特に DMM の過去の組織体制では，これらを独立して取り組むほどの余裕はなく，当時の少ないメンバーの中で品質向上とビジネスインパクトの両立に苦慮していました。
そして検索レコメンドの組織が，当時も今もエンジニア組織に強く属していることも問題の難易度を上げる原因になっていました。検索レコメンドを売上を上げる装置として見た時，これまで DMM の多くのサービスを支えてきたフロントエンド，バックエンド，それらを支える基盤から見た時の KPI と大きく異なる KPI を持つことになります。検索レコメンドは特に EC サイトや動画配信サービスにおいてはビジネスの売上に直結するプロダクトと考えられますが，インフラとして見た時の検索レコメンドのあるべき姿や品質と，売上を上げる装置としてみた時の検索レコメンドのあるべき姿や品質の考え方を一致させることが難しく，社内的にも検索レコメンドの位置付けが難しいプロダクトになっていました。
結果，検索レコメンドのチューニングから，そのビジネス KPI に対するインパクトの設計や効果検証，それを社内に成果主張するためのスキーム全てにおいて課題感が山積みの状況でした。そしてそれは今も完全には解決できていません。まだまだ道半ばではありますが，本ブログの連載を通して少しでもこの課題に取り組む企業の方々の参考なればと思い，筆を取った次第です。
取り組んでいるサービスの性質
様々な事業を展開している DMM ですが，我々の検索レコメンドが主にコミットしているサービスは PPV（Pay Per View）または SVOD（Subscription Video on Demand）のいずれかのビジネスモデルを持つコンテンツ配信サービス（動画や電子書籍など）です。
どちらのサービスに対しても，ユーザーに刺さるコンテンツを提示できる検索レコメンドを実装することには変わりありませんが，都度購入する PPV は，買えば買うほどに売上が上がるので，ARPU は直接的に狙っていきたい重要な KPI であると考えられます。一方で SVOD は定額制であることから，解約率の減少は重要な KPI と言えます。
どういうことかと言うと，例えば PPV はセール価格を考慮した並びになっていることは重要そうですし，SVOD は視聴時間を多く稼げそうな複数話のコンテンツを推薦すると視聴を継続してもらえそうです。
このことから，ユーザーに刺さるコンテンツを提示すればユーザーにコンバージョンしてもらえそうという解像度で検索レコメンドをチューニングすると，ビジネス KPI と整合しない施策になる可能性，または伸びしろが少ない施策になりそうです。
ちなみに KPI 設計が大きく異なると考えられるこの両方のサービスを大規模に運営している企業は国内でも数少なく，これを経験できる DMM は，エンジニアリングや分析の観点でとてもエキサイティングな環境が整っていると思っています。
未熟な組織
十分な人的，技術的なリソースを持った組織で開発をスタートできることは稀でしょう。特にサービスが成熟し，且つインフラも十分にある状態でスタートする組織の場合，組織目標や人員アサイン，介入可能な KPI 設計を正しくしないと，成果に結びつかず，組織の存続に関わります。
情報検索，推薦はエンジニア人口からすると非常にニッチな領域で，これを専門にしているエンジニアはごく僅かです。DMM も同じで，一般的な機械学習の知識を持ったメンバーを検索レコメンドに配置するところから組織は始まっています。レコメンドはまだ機械学習業界と親和性が高く，テーブルデータを得意とする ML エンジニアであれば参入しやすい領域ですが，検索は検索エンジンというインフラやそのためのバックエンドの実装をある程度分かった上で参入しないと，プロダクトのケイパビリティやスコープが不明瞭で ML エンジニアとの期待値のズレが生じやすいと言えます。
従って，ML エンジニアのみで構成された組織に，検索エンジンの仕様を伝え，検索エンジンレイヤーでのチューニングや，情報検索でよく実施されるルールベースのタスクを与えることは，大きなミスマッチである可能性が高いです。実際，後述する検索エンジンレイヤーでのチューニングによる AB テストで，短期的に成果を得られないと判断してからは，ユーザーや商品のタグ付け，Embedding，それらをハンドリングできる API 層を追加し，クエリをどうパーソナライズして書き換えるか，レスポンスの商品 ID をどうパーソナライズしてリランクするかに焦点を当て，できるだけ ML エンジニアの得意領域で戦う戦略に変えました。
開発初期では，ユーザー，商品にタグ付けしてそのインターセクションの度合いでパーソナライズするような手法でも ARPU の向上は見られました。ようやく ARPU に対する成果を上げられた一方で，この手法は巨大な網で獲物をすくうようで，一部のクエリではむしろ性能低下が発生したり，元からあったユーザーペインを解消するものではありませんでした。あくまで，効果全体で見た時に ARPU は向上していたというだけで，検索で本来取り組むべき泥臭いクエリの意図解釈や検索漏れなどのエッジケースは網の目をくぐって放置されていました。過去には，よく検索されるはずのクエリの並びがおかしいと社内外から指摘が入り，そのたびに ML エンジニアの組織が解くべき課題や，現状の少ないメンバーのケイパビリティとビジネス貢献の優先度を知ってもらう政治的な活動を行っていました。
振れない KPI
情報検索，推薦において，評価指標を向上させることと，ビジネスの成功（売上貢献）が一致しないことは経験的によく知られています。
150 Successful Machine Learning Models: 6 Lessons Learned
at Booking.com
などで知られる状況は，DMM での検索レコメンドにおいても同様に観測されてきました。
検索レコメンドにおいて ARPU を KPI にすることの意義については様々議論はあると思いますが，売上貢献をミッションに掲げている我々にとっては，組織立ち上げ初期から ARPU をメイン KPI に定めていました。
特に検索においては，サービスによってはほぼ検索エンジンを吊るしの状態で使っていた，もしくは売上金額順という1軸でのソートで検索を提供していたサービスもあったほど，簡便な状況でした。
手始めに DMM の主力サービスから検索の relevancy の改善を実施しました。検索ログから nDCG を最大化する検索フィールドの重みを探索し，どのクエリに対しても定性的に明らかに改善が見られる状況を作り出すところまでは簡単に到達できました。これだけでも十分に結果を出るだろうと高を括っていましたが，AB テストに持ち込んで，ARPU に対して変化が見られなかったことは今でも忘れられません。
特に人名での検索においては劇的に改善されたと思われましたが，何故ほぼ変化がなかったのか，当時はこの件について大きく深ぼらなかったので，真相は不明ですが，ノウハウができた今だからこそ言える仮説としては，セール商品を全く考慮できていなかったことが考えられます。DMM の PPV のサービスでは，セール商品が売上の一部を担っていることもあり，これをコントロールできるかどうかが，我々の施策の勝ち負けを左右することが分かっています。当時のチューニングでは検索キーワードに対する relevancy は高められていたと考えられますが，セール商品に対するチューニングが考慮されていなかったことから，セール商品は必要以上に下位に沈み，性能が向上したクエリをかき消すほどに全体の UX は低下していたと考えられます。
セールというパラメータを考慮できない実装での nDCG ベースの relevency 改善が ARPU という KPI 向上に寄与しない分かりやすい例だったかと思います。
噛み合わないビジネスサイドとの貢献価値
ユーザーが購入したら上がる指標という点で，ARPU は良くも悪くも分かりやすい KPI だと考えています。一方で，ARPU はビジネス KPI の中では最上位に近い KPI であることから，最も動かしづらい KPI であるとも言えます。セールやキャンペーンなど，大きく ARPU が変動するマーケティング施策と比べると，検索レコメンドがこれらマーケティング施策ほど ARPU を動かせる余地はないと考える人もいるかもしれません。
ユーザーの財布の中身が決まっていると仮定した時，検索レコメンドができることは，購入までの手数を少なくして，欲しいコンテンツにしっかりと誘導することができれば，それも大きな価値であると考えられます。例えば，検索レコメンドのインプレッションあたりの PV を増加させることは，目的のコンテンツに到達できているかどうかを示せる KPI になりそうです。（真面目にやるなら CVR や滞在時間などを総合的に評価しないとクリックベイトとの切り分けが難しいですが，効果検証の簡便さを考慮するとインプレッションあたりの PV は観測しやすい指標と言えます）
このような，中長期的にはユーザーの再訪や満足度を上げるかもしれない KPI を追うことが，ARPU が向上する施策を差し置く合理性があるかはビジネスサイドからしてみれば疑問です。特に，統計的な有意差がないが，若干の ARPU 低下が見られており，インプあたりの PV は有意に上昇しているような施策はやっかいです。開発サイドとしてはリリースすることにポジティブな気持ちになりがちですが，ビジネスサイドとしては，有意ではないとは言え，ARPU 低下が見られる施策をリリースしたくないでしょう。
中長期の指標を見る難しさは以下の論文でも語られています。
surrogate for long-term user experience in recommender systems
本論文では，再来訪の間隔がスパースすぎるユーザーが多い点や，長期間観測することでノイズが多くなる点など，そもそも指標を長期で正しく計測して評価すること自体が難しいため，LTV に関連する指標のサロゲートとして，消費している商品の多様性や，特定商品を消費したページへの再訪間隔の短さが挙げられています。
ビジネスサイドとのリテラシーが一致していない課題もあります。下位の KPI になるほど検索レコメンド特有の難解な解釈が必要になるため，その点でもビジネスサイドにとって ARPU 向上は分かりやすい真実です。それ以外の KPI の向上は分かりづらく，開発サイドの都合にしか聞こえないこともしばしばあります。特にプロダクトが成熟していない場合は，本当にプロダクトの品質が悪くて ARPU を向上させられなかったのではという心理もビジネスサイド，開発サイド双方に働きます。サービスが十分に成熟している場合だと，本当に ARPU に効果があるのか疑わしい偽陽性のリスクを取ってまでリリースする判断は難しくなると思います。このようなケースがこれまで多かったわけではないですが，リリースの判断に悩むケースも度々ありました。
この点レコメンドは目的や挙動が分かりやすく，売上を上げる装置としての役割は検索よりも圧倒的にステークホルダーに認知されていたと言えます。
そして，ARPU を有意に向上させられたとしても問題は残ります。この向上が AB テスト期間に限った瞬間風速的なものなのか，持続するものなのかという問題です。DMM では通常 AB テストは2週間実施されます。この2週間によって得られた ARPU 差を，例えば1年にスケールして，これをその年の成果とみなすのは他施策との交互作用や，施策がトレンドにフィットできなくなることによる効果の減衰を考えると，少々乱暴なスケールと言えます。検索レコメンドを ARPU を上げることができる装置として見ているはずの我々が今年度どれだけ売上に貢献したかを解像度高く主張できないことは，経営層を含むビジネスサイドからしてみると投資判断がしづらい組織に見えます。
まとめと展望
ビジネスを成功に導くためには，検索レコメンドを実装するだけでは十分と言えないことがお分かりいただけたかと思います。サービスや開発組織の成熟度，ステークホルダーとの関係性にもよりますが，前述したような以下の4点の難易度が高いと考えられます。
- 検索レコメンドが持つ役割と，それぞれが介入可能な KPI の設計
- 1 を解くための適切なエンジニアのアサインとプロダクト方針の早期決定
- ビジネスサイドと 1 についての期待値コントロールとそのための評価，リリース判定の合意
- 3 を満たすためのデータやダッシュボード整備
我々の初期は 1, 3 をなんとなくやってきたこともあり，ともすると，ある程度偶然に頼った改善をしているとも言えました。次回以降のブログ では，上記に関する深堀りや意思決定，これを考慮した実際の検索レコメンド施策の事例を紹介し，DMM が検索レコメンドをどのように仕上げてきているのかを紹介していきたいと思っています。
本ブログに関するセミナーも定期開催する予定です。このセミナーにて本ブログについて改めて詳しくご紹介する予定です。本記事に関心を持っていただけた方は，是非ご参加いただければ幸いです。
2025年6月2日開催予定
Strategic Search & Recommendation Meetup #1
Discussion