レコメンドで「検索軸を補う」という発想

　レコメンドと聞くと、Amazonに代表されるような大規模ECサイトで利用されている機能を思い浮かべる方が多いと思います。「●●を買った人には××がお薦め」というような内容が自動表示される機能という認識が一般的ですが、多数の商材を扱うサイトにおいては、ユーザーの検索行動を助ける有用な機能とも考えられます。

　サイトにはさまざまな趣味・嗜好を持つユーザーが集まってきますが、検索軸という点からだと、サイト運営者が用意できる軸は限られています。たとえば、ECサイトでは商品ジャンルカテゴリー、価格帯などが用意されていますが、自分の考えるジャンルに当てはまる検索軸が存在せず、フリーワードで検索した経験を持つ方は多いのではないのでしょうか？

　一方、検索軸となる項目を充実させるには、情報収集の労力、システム開発費など膨大なコストがかかります。結果、残念ながら、全ての人が満足できる検索軸をサイト運営側が用意することは、事実上不可能と言わざるを得ません。

　しかしレコメンドには、「サイト運営者側が用意できない多様な検索軸を補う」という使い方もあるのです。実は、リクルートの各サイトでも利便性向上のためにさまざまなレコメンドを実装する取り組みを行っています。ASPが提供するサービスだけでなく、自前でアルゴリズム開発にも取り組んでいます。

ユーザー企業が自前でアルゴリズムを開発するワケ

　ASPが提供するレコメンドサービスは、比較的安価でリアルタイムにレスポンスを返してくれるため、それはそれで非常に有用です。では、自前でアルゴリズムを開発する理由は何でしょうか？　『全体最適の概念が必要なため』と私は考えます。

　どのサイトでも人気の物件やアイテムが必ず存在しますが、一般的なアルゴリズムを用いた場合、レコメンドされるアイテムが人気アイテムに集中する傾向にあります。

　在庫問題を除けば、ECサイトの場合は人気アイテムがたくさん売れることがサイトのKPIに直接繋がるので、レコメンドが効果的に機能していると言えます。

　一方、情報提供サイトでは、各クライアントは一定の期待値を持ってサイトへ出稿します。各クライアントは、ユーザーからのレスポンスに対してフィードバックを行わなくてはいけないため、想定を大きく上回るレスポンスに対しては、リソース的にさばききれないという事態が起こりえます。

　さらに、情報提供サイト運営者の立場からみると、出稿いただいた全てのクライアントにレスポンスのある状態が理想と言えます。では、運営者の都合だけで、レスポンス数が足りていないクライアントをユーザーにレコメンドしたらどうなるでしょうか？　ユーザーから見れば魅力のないサイトになってしまうかも知れません。

　全てのユーザー、全てのクライアントにとってWIN-WINなレコメンドを追求していくことが、ビジネスゴールにつながります。すなわち、本質的にはサイトのゴールに合わせたレコメンドが必要となるため、自前でアルゴリズムを開発する必要があるという結論となります。

アルゴリズム開発を進める際の心構え

　私たちデータサイエンスチームは、高い分析力をコア機能とする専門組織です。レコメンドのような施策開発を目的とした分析に関わる場合は、いわゆる分析業務のみならず、その前後のタスクである「情報の収集」から「開発したレコメンドを世の中に公開する」までをやり切って初めて「情報活用した」といえ、自分たちの業務が完結すると私は考えます。

　各専門家をアサインできるような、大きなプロジェクトとして進めることができれば理想ですが、分析のROIは常に議論の対象となってしまいます。そのため、少人数体制で予算を抑えつつフィジビリティスタディ（以下F／S）【注1】からスタートさせることが、ROI観点の議論に巻き込まれないためのベストプラクティスのひとつと言えます。

　そのため、周辺業務の理解はもちろんのこと、時には自身でそのスキルを習得し、実行する覚悟も必要です。F／Sを成功させ、事業の決裁者に「情報活用」の有意義さを実感してもらうことができれば、予算がつき、分析のPDCAサイクルが回っていくきっかけになるのです。