はじめまして、リクルートの『SUUMO』でプロダクトデザイン/プロダクトマネジメントを担当している児玉です。こちらのnoteでは賃貸物件のレコメンド機能を導入した話をさせていただきます。簡単に自己紹介をさせていただくと、私は現在プロダクトデザイングループに所属しており、主に『SUUMO』のエンハンスや反響数の増加を目的としたUUCVRの改善、商品企画などを担当しています。社会人歴は3年目で、リクルートには2020年10月に中途入社して2021年10月でちょうど1年になります。今回の内容は入社後1ヶ月で、レコメンドターゲットの選定からデータを活用したレコメンドロジック＆UIの設計についてプロジェクトリーダーとして推進することになった時のお話です。

SUUMOって何？（サービス説明とビジネスモデル）

私は『SUUMO』の中でも賃貸領域のプロダクトデザインを担当しています。このプロダクトは、物件を探しているユーザー（以降、カスタマー）と、物件を貸し出したい不動産仲介会社様や管理会社様（以降、クライアント）とをマッチングさせるプラットフォームです。意外と知られていませんが、『SUUMO』は「Support Useful ＆ Unique for Most One」の頭文字を取ったもので、「便利で独自性があり、最高にぴったりの住まい探しができるサービス」という意味が込められています。賃貸物件以外にも、マンションや戸建てなど、様々な「住まい」を取り扱っているので、一度は耳にしたことのある方もいるのではないかと思います（最近だと、たくさんの著名な方がCMに出ていて、見ていて楽しいです）。

ビジネスモデルは、リクルートのビジネスの基本ともいえる「リボンモデル」でできています。かなりざっくりご説明すると、プラットフォーム上でカスタマーとクライアントのマッチングの機会を創出し、新しい出会いをもたらすことを提供価値として、報酬をいただくビジネスモデルです。

少し細かくご説明すると、マッチングが成立した際にお金が発生する成果報酬型や、マッチングの成約量によらず、媒体への掲載費のみが発生する掲載課金型などのマネタイズ方法があり、複合的に用いられることが多いです。

レコメンド機能の検討背景

まず、今回お話するレコメンド機能の検討を実施することになった背景をお話しします。

私が入社した時、『SUUMO』では、カスタマーにとってより使いやすいプロダクトとなるよう、エンジニア、デザイナー、プロダクトマネジャーによって継続的にUI改善が行われてきており、結果としてUUCVRも大幅な改善を繰り返している状況でした。一方で、こういった改善を繰り返されたUIは世の中に公開されるものであるため、競合サービスに同質化されてしまうリスクがあります。それ故に、「SUUMOのこの機能使いやすいよね」といったUI仕様では競合サービスとの長期的な差別化が難しいという課題感がありました。（これはこれでカスタマーにとっては嬉しいことではあるのですが…）

そこで、業界TOPクラスのプラットフォームである『SUUMO』に蓄積された大量の「データ」と、改善が繰り返されている「UI」を掛け合わせることで、競合にも真似できない（出来たとしてもデータ量による精度で差を生むことのできる）機能が実現できれば、長期的な競合優位性を築くことができることができるのではないかと考えました。

こういった背景から、メディアとしての競合優位性を築く一環として「データ」を用いた施策を進めることになりました。

次に、「データ」を用いてどのカスタマーセグメントをターゲットにアプローチしていくかを決める必要がありました。一番の目的は希望物件とのマッチングの機会を増やすことによる「反響数（CV）の増加」であるので、過去のUI改善の課題仮説/改善ターゲット/改善結果など一通り目を通して、まだ十分な改善に至れていない白地の大きいセグメントを定性的に洗い出し、DSG（データソリューショングループ）の協力の元、セグメントごとに定量的な分析を行い、ターゲットを設定しました。

最終的に、「設定されている検索条件が厳しい」「なかなか物件を決められない」「希望条件が潜在的に代替可能である」といったターゲットキーワードを持つカスタマーの希望物件とのマッチング機会を増やすことを目的として、データを用いたレコメンド機能を検討することになりました。

具体的なレコメンドロジックの設計

レコメンドロジックを考えるにあたり、まずはターゲットキーワードをもとにプラットフォーム上で実現したいことを考えました。例えば、「検索条件を厳し目に設定しているために希望の物件に中々辿り着けないカスタマーに対し、検索条件外の物件を訴求することでマッチングのきっかけを創出する」などです。そういった検討を進めていった結果、レコメンドのコンセプトとして「検索条件を緩和した物件レコメンド機能」にたどり着きました。ここで、検索条件のレコメンドではなく物件のレコメンドを選択したのは、物件の方がよりカスタマーに住まいのイメージを持ってもらいやすいと考えたためです（検索条件のレコメンドとした場合、条件変更後のイメージが持たれにくいので）。

実現したいことを考えた後は、「実現したいこと」と「実際にできること」とのギャップの確認を行いました。具体的には、現在保有しているデータ内容でカスタマーパーソナライズされた有益なレコメンドが実現できるのか、カスタマーにとって魅力的な物件情報をフロントで十分に表出にできるのか、といった内容です。これはDSG（データソリューショングループ）や開発エンジニアの協力もあり、当初想定していたものからほとんど要件変更なく進めることができました。

次に、レコメンドを実際に画面に表示するにあたっての検討についてお話しします。

コンテキストに沿ったレコメンドの表出案の検討

レコメンドロジックの検討が終わった後は、実際の画面への表出を検討しました。カスタマーにとって脈絡の無いレコメンドはユーザビリティの低下を招き、場合によってはネガティブに働く可能性があります。なので、ターゲットカスタマーのコンテキストに沿った形でのUI設計を考える必要がありました。そこで考えたのが、物件一覧画面をタブ化し、カスタマーが設定した条件での検索結果一覧画面とは別に、パーソナライズされた新規画面を設けることでした（「My一覧」タブ）。

これにより、通常の検索行動との棲み分けが行えるとともに、パーソナライズされた新規画面で新しい物件とのマッチングの機会を増やすことができます。また、カスタマーの設定した条件以外の物件に対する反応も行動データとして蓄積されるため、そのデータを用いたレコメンドの更なるエンハンスも見込んでおります。

レコメンド開発＆リリース

実際にリリースされたレコメンドが下に示す画像です。パーソナライズされた画面内には今回検討したレコメンドだけではなく、よりカスタマーパーソナライズされた画面となるよう、お気に入りや閲覧履歴などの項目も追加しています。

学び＆結び

今回は私が入社1ヶ月目にプロジェクトリーダーとして担当することになったレコメンド機能の検討についてお話させていただきました。文章としては短い内容になっていますが、実際の現場では頭を抱えて「ああでもない」「こうでもない」といった議論をたくさん繰り返しました（本当に多くの時間を思考に費やしたように思います）。私は当時、転職して間もない状況でしたが、各分野のスペシャリストが立場を超えて議論を交わす様子はとても刺激的でした。リクルートの文化でもある「なぜやるのか」「なぜこの手法なのか」「なぜこの仕様なのか」といった問いの全てに論理的な根拠が求められる中、妥協せずに考え抜くことの楽しさ、難しさを体感でき、個人的にも成長できたとてもいい経験だったように思います。

このお話が、リクルートにおけるプロダクトデザイン業務へ興味を持っていただくきっかけになれば幸いです。

最後までお読みいただきありがとうございました！