
LIFULLが取り組むプロダクトマネジメント&賃貸プロダクトにおけるグロース事例(前編)
※この記事は 2023/06/23 に行われた株式会社DearOne主催のGrowth Leaders 2023でLIFULLの大久保、水野が登壇した「LIFULLが取り組むプロダクトマネジメント&賃貸プロダクトにおけるグロース事例」の講演内容を再編集したものです。
LIFULL / LIFULL HOME'Sについて
LIFULL HOME’S(ライフルホームズ)のBtoCプロダクトとBtoBプロダクトの責任者を務めている大久保です。
本セッションではLIFULLにおけるプロダクトマネジメントの取り組みと、賃貸プロダクトという一番大きい事業領域のグロース活動について紹介させていただきます。
まず私たちについて簡単に紹介させてください。
LIFULL HOME’Sは弊社が運営している不動産ポータルサイトのことで、また海外事業としてLIFULL CONNECTという不動産情報を扱うアグリゲーションサービスなども運営しています。

LIFULLは、コーポレートメッセージとして「あらゆるLIFEを、FULLに。」というものを掲げており、不動産のほか介護サービスや地方創生事業を展開しています。近年、D.LEAGUE(Dリーグ)というダンスのプロリーグが発足し、チーム「LIFULL ALT-RHYTHM」の運営などもしています。
最近、話題のChatGPTのプラグインを国内の不動産系サービスで初めてリリースしました。
プロダクトマネジメント導入の背景
それでは今回のテーマである「LIFULLが取り組むプロダクトマネジメント」を紹介させていただきます。
プロダクトマネジメントとは
まず、そもそも「プロダクトマネジメント」と言っても人によって理解にばらつきがあるのではないかと思います。
Wikipediaの定義では、「プロダクトの成功、すなわち『顧客に価値を提供し、ビジネスとして利益を出すこと』を目的・責務とするマネジメント」とあり、私たちはこの定義が妥当であると考えています。

弊社では、約2年半ほど前に、プロダクトマネジメントに取り組むことを決めています。ゆくゆくは「プロダクト主導型組織」を目指すというのが、今の私たちの方向性です。

プロダクトマネジメント導入の経緯
そもそも、なぜLIFULLとしてプロダクトマネジメントを取り入れようと思ったかですが、プロダクトマネジメントをうまくやれていない企業にありがちとされる症状が現れていたからです。

とりわけ、プロダクトチームの権限や責任の不明確さと、開発活動がアウトプット中心であることの2点が、大きな課題でした。
プロダクトチームの権限や責任の不明確さについて、チームが「自分たちでどこまで決めていいのか」、「どこまでの権限があるのか」わからない・定義がされていない・ばらつきがある、という課題がありました。また付随して、各職種の開発上流工程への関わりも弱かったり、チームによってばらつきがある状況でした。
開発活動がアウトプット中心であることについて、どうしてもリリースやロードマップを意識し過ぎてしまうあまり、そこから生まれるアウトカムまで意識されないという課題がありました。
こうした結果、ステークホルダーが多くなってスピードが鈍ったり、技術負債がいつまでも解消されなかったり、メンバーのモチベーションが低下したり、といった現象が生じていました。
プロダクトマネジメントの導入へ
そういった背景を踏まえ、「プロダクトマネジメントというものがあるらしいから、勉強してみよう」ということになり、たまたま手に取ったのがSilicon Valley Product GroupのMarty Cagan氏による『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』という本でした。
いくつかあるプロダクトマネジメント系の本のなかで、INSPIREDを選んだのは偶然でしたが、読んですぐに「これは私たちが取り入れるべきものだ」と感じるくらい、素晴らしい出会いとなりました。
プロダクトの責任者10名くらいでの輪読会を始め、全体として「プロダクトマネジメントをやるべきだ」という機運が形成されます。その後、エンジニア、デザイナーといった他のプロダクトチームの職種にも広げていき、今に至っています。
素晴らしい本なので、まだの方はぜひご一読をお勧めします。
LIFULLにおけるプロダクトマネジメント
LIFULLにおけるプロダクトマネジメントでは、下図の通り、4つの要素を変化させています。
①新しい役割
②3職種それぞれの役割
③上流からの三位一体の連携
④プロダクト開発として重視するもの

以下、それぞれ見ていきましょう。
プロダクトリーダーたる新しい役割の設置
まず「新しい役割」の設置です。
元々プロダクトチームには、サービス企画、デザイナー、エンジニアという職種しかいなかったところに、プロダクトリーダーとなる三つの役割(プロダクトマネジャー、テックリード、プロダクトデザイナー)を置きました。

4つの価値・リスク
また「3職種それぞれの役割」として、それぞれの役割がプロダクトの価値・リスクのうち、どこにコミットするのかについて明確にしました。
例えばプロダクトマネージャーであれば「Valuable(価値)」と「Viable(事業実現性)」にコミットすると定めています。またプロダクトデザイナーであれば「ユーザビリティ」に、テックリードであれば「Feasible(実現可能性)」というところにコミットすると定めています。
これらは、前述の『INSPIRED』の主張にそのまま沿う形で、社内で取り決めをしています。

上流からの三位一体の連携
そして、3つの役割の連携方法についても定めています。
前項で説明したような役割定義を、過度に厳格に線引きしてしまうと、役割間のギャップが生まれます。そうすると、その間に落ちるものが出てきてしまい、それがそのままプロダクト価値の毀損に繋がりかねません。
理想は、それぞれがコミットする範囲を持ちながら、間にこぼれ落ちるものがでないよう意識して交流活動をしていこうというコンセプトで、三つの職種で「上流から三位一体の連携」を掲げています。

一方、そういう風にしてしまうと「皆がすべてのタスクの責任を負うのか」と思われるかもしれませんが、そうではなくあくまでごちゃごちゃの錯綜状態にならないよう、どのタスクに対し誰が責任を持っているかや、誰に情報
を伝えないといけないかなどをしっかり取り決めることも重要です。
そこで、「RACIチャート」というものをチーム運用に活用しています。これはタスクごとに「Responsible」「Accountable」「Consulted」「Informed」の4要素について細かく決めるというもので、簡単にいうと「どのタスクで」「どの役割の人が」「何に対して」責任を負っているかを定義したものです。

あくまでいざというときに参照するための明確化ということで、プロダクトチームごとに話し合って、RACIを決めています。
アウトプット志向からアウトカム志向へ
最後に、プロダクト開発として重視するものを、リリースやアウトプットではなく、そこから生まれたアウトカムを中心に考えていくことを決めています。
LIFULLものづくりのモデルとして、プロダクトチームの活動から生まれるリリースをアウトプットと置き、そのアウトプットからもたらされる顧客への提供価値をアウトカムと定め、さらにアウトカムの先にインパクトとして売上・利益、社会課題解決・ビジョン実現といった形で整理しています。

プロダクトマネジメント定着のための工夫
ただ、これだけでも定着は困難なため、確実に組織として定着させるため、プロダクトマネジメントの取り組みを定めてからは半年ほど、隔週でプロダクトマネージャーの横断会議を開催し「今こういうことに困っている」「このような課題は発生していないか」などと話す場を設けたり、プロダクトチーム単位でもプロダクトマネジメントに対する振り返り会を行うなどしました。
またアウトカム志向の定着に関しては、Retty様の事例を参考に、各プロダクトチーム内で生まれたアウトカムを全社に発信する『アウトカム通信』というニュースレターを月3で発信しています。アウトカムという概念を社内に広めつつ、他のプロダクトチームの施策から、「こうすればうまくいくのか」、「我々のプロダクトでもやってみよう」と意識してもらうための取り組みとなっています。
UXリサーチに関しては、プロダクトマネジメントの取り組み発足前から進めていましたが、プロダクトマネジメントの導入に伴い一気に加速し、企画フェーズから設計・開発・運用に至るまで、かなり大規模に力を入れて取り組んでいます。

プロダクトマネジメントの導入により何が変わったか
プロダクトマネジメントに関する様々な取り組みの結果、変わったといえる部分を見ていきます。
開発プロセスの変化
まず、開発プロセスの部分が大きく変わりました。
従来は、企画プロセスで企画・仕様がまとまり、それを受け取ったデザイナーがデザインし、エンジニアが技術要件をまとめて開発する・・・といった具合に、「職種間ウォーターフォール」と呼べてしまう状況でした。
それが現在では、企画プロセスに、デザイナー、エンジニア、さらにはデータアナリストやUXリサーチャーなども関わるようになりました。

成果面の変化
このように、企画プロセスにおいて他の職種のスペシャリティに基づいたインプットが得られるようになったことで、施策の精度と成功確率がここのところ大きく向上しています。

このあたりは後編の記事で詳細をお伝えいたします。
「市場学習回数」の最大化
プロダクトマネジメントにおいて「継続的な製品発見・製品開発」という概念があります。
LIFULLでは、この考え方をさらに発展させ、「市場学習回数の最大化」という取り組みを目下強化しているところです。

これは端的にいえば市場学習=PDCAの回数を大幅に増やしていこうという考えです。
図中にあるNetflix、Amazon、Google等では、年間の市場学習回数が数千〜数万とされています。この状態を目指していきたいと考えています。
というのも、一般的なプロダクトチームであれば、1%のリフトであれば割と再現性高く生み出せると思います。
大きな事業成長を目指していくとなった場合に、20%のリフト、50%のリフトを実現しようというのは非常に困難です。
一方、頻度を高めるというアプローチは現実性があります。
「1%の法則」のように毎日1%ずつ改善すれば、翌年には37.8倍になるという考えの下、取り組みを進めています。
このために、計測のダッシュボードを社内で作り、プロダクトチームでどれくらい施策・成果が生まれているかを可視化し、まずは年1,000回を目指すという目標を置いています。もちろんその先には年1万回を目指します。
もう一つ、私たちはプロダクトマネジメント改革に合わせ「アナリティクスの刷新」を行っていますが、こちらは、後編で詳細を説明していきます。
後編はこちらからどうぞ。
登壇者紹介
