LIFULL社内に学ぶ「大型サイトの情報設計」～持続可能な開発サイクルのために～
不動産・住宅情報サイト「LIFULL HOME'S」で賃貸領域のプロダクトマネージャーをしている相田です。
私の所属する部署では、市場学習回数、すなわち仮説検証の回数を大幅に増やし「短期的に成果を上げプロダクトをグロースさせていく」ということに取り組んでいます。
この取り組みに関わるチームは部署内で複数チームあり、サービス企画、エンジニア、デザイナーで構成されていて、各チームは即効性のあるインパクトとスピード感が求められます。
グロースチームの悩み
「短期的に成果を上げプロダクトをグロースさせていく」という取り組みはチームの開発サイクルを加速させ、ビジネス成果も出て良い感じに回っている一方、次のような悩みがありました。
施策の案出しが大変
パーツ単位・スポット単位での開発になってしまう
同じミッション下で施策のコンフリクトが起こる
まずひとつめの「施策の案出しが大変」ですが、
ある程度成熟した規模のサービスを担当しているゆえ「少ない工数でインパクトが出せる施策」となると段々とネタ切れしてきます。
また、期が変わるとチームの解散やメンバーの変更があり、ワイワイと議論できる仕組みやチームワークを一から醸成しなくてはなりません。
次の「パーツ単位・スポット単位での開発になってしまう」ですが、
どうしても高いリフトが期待できる施策の優先度が高くなるので「数を増やす施策」や「率を上げる施策」がメインになり、根本的な課題解決や状況の深堀りをしながらPDCAを回すというのはやりにくくなります。
また、施策ごとに一からファクトを集めて調べるといった効率の悪さもあります。
最後の「同じミッション下で施策のコンフリクトが起こる」は、
各ページでユーザーにどんな行動をさせたいか？してくれると良いか？の認識をメンバー間で揃えていなく、「このページではたくさん情報を載せてリッチにすることで、次のアクションに繋げよう」という意図の施策と、「このページでは情報を取捨選択し、ぞぎ落すことで、次のアクションに繋げよう」という施策が行われることがあります。
また、個々の施策のABテストでは成果が出せても、異なる意図の施策が合わさった状態は果たしてユーザーにとって良いのだろうか？という課題感がありました。
これらの悩みを持ちながらプロダクトのグロース施策を担当されている方も少なくないのではと思います。
今回ご紹介する内容は、私が実践したことではなく、上記の課題解決に繋がるプロセスを実践しているチームの活動についてです。
私自身学ぶことが多かったので参考になると思います。
「情報設計」の考え方をベースにする
そのチームの実践しているプロセスというのが『「情報設計」の考え方をベースにする』というものです。
情報設計とは、UXを高めるために、プロダクトビジョンに沿ってユーザーが欲しい情報を適切に届けられるようにUIや導線を設計することです。
不動産ポータルであるLIFULL HOME'Sの基本構造は、家賃相場や住まい探しのノウハウなどのコンテンツの他、住所や駅を指定する「エリア検索」、価格や間取りなどの条件で住まいを絞り込む「物件検索」、各物件の詳細情報や魅力を伝える「物件詳細ページ」が中心となっています。
このチームでは、「初訪問から理想の住まいが見つかるまでの大きなユーザー体験という全体最適化」を基点とし、ページごとに理想を描き、現状とのギャップを埋めていくというアプローチでグロースに挑戦しました。
具体的なステップ
もう少し具体的に説明すると、
過去の社内の定性・定量情報を集める
パーツではなく全体の流れにおいてページごとに理想を定義する
現状を分析する
施策立案
施策の単位を小さくし仮説検証
というようなステップになります。
ステップを書き出してみると当たり前のようですが、1〜3にはとことん時間をかけます。
試行錯誤の時期だったというのもあるのですが、下準備やチームでのワークに時間がかかるというのはこのプロセスのデメリットとも言えそうです。
ただ、やりはじめてから半年後には、その時かけた時間に充分価値があったと周囲が納得する程の土台ができ、成果も出始めました。
また、5の「施策の単位を小さくし仮説検証」もポイントで、
チームのミッションはあくまでも、「短期的に成果上げプロダクトをグロースさせていく」なので、一ケ月以上かけて開発したABテストで負けてしまっては本末転倒です。
周囲からの期待にもシッカリ答える形で実現しています。
その結果
「初訪問から理想の住まいが見つかるまでの大きなユーザー体験という全体最適化」を企画の起点にしたことで、グロースチームに良い変化が起きました。
市場学習を打ち続けられる土台ができる
あるべき姿に向かって少しずつ検証を重ねるため「次の手」が常にある状態が作れます。
また、検証結果が悪かったら『定義した理想』をチューニングすることで、改善案が生まれます。
最終的な理想に向けてPDCAを回せ、期またぎでもすんなり施策実施に入れる
先述したステップを経てベースがあれば、期が変わりチームメンバーが多少変わってもスムーズに開発サイクルが回り始めます。
このやり方を取り入れる前と後で、このチームの期初月の市場学習が3倍になっています。
メンバー間で共通の「あるべき姿」を設定することができる
方向性がブレないというのは勿論のこと、エンジニアやデザイナーと「最終的にこうしたいなら、このアプローチではなくこうしたら？」「こういう実装だとやり直しにならなくて済む」というコミュニケーションが生まれます。
これまでとの違い
では、これまでこのようなやり方ができていなかったのか？と、自分自身に問うてみると、「ここまでコツコツと泥臭く、そして運用に乗って結果を出すところまではやっていなかった」と答えます。
私は、スピード重視で、何事もとりあえずやってみようよというスタンスです。「施策の案出しが大変」「パーツ単位・スポット単位での開発になってしまう」「同ミッションのチーム間でコンフリクトが起こる」という課題が顕在化したら、力技で解決しようとしてしまっていたのではと思います。
疑問を無視せず、本質的なところとじっくり向き合うのはすごいことで、
その結果、持続可能な開発サイクルが発明できたのではないかと考えます。
また、現在では『「情報設計」の考え方をベースにする』ワークを賃貸領域のグロースに関わる全てのチームで行っていて、「同じミッション下で施策のコンフリクトが起こる」という課題に対して、より一歩踏み込んだ解決に繋がる動きができています。
以上となります。最後まで読んでいただきありがとうございました！
同じような悩みを持った方がいましたら、少しでも参考になれば幸いです。
気になる各プロセスの詳細は、近いうちに担当メンバーの一人が執筆してくれる予定ですので、楽しみにお待ちください。