ユーザーアウトカムの追求とプロダクトチームの役割整理
LIFULLの諏訪です。プロダクトとビジネスの境界であれこれ調整する役割を担うことが多い人です。三次元の推しはつばきファクトリーの新沼希空さん、二次元の推しはアイドルマスターシンデレラガールズのニューウェーブの3人（特に村松さくら）です。
今回の記事では、LIFULL HOME'Sがここ1～2年積極的に進めているプロダクトマネジメントの取り組みから、ユーザーのアウトカムを追求するためのプロダクトチームの役割整理について紹介します。
はじめに 本記事の要約を3行で
特定の個人に依存せず、プロダクトマネジメントの文化をプロダクトチーム全体、ひいては組織全体にインストールしていくことが大事と考えています
「何を、何のためにやるか」といったことを考える上流工程での、役割分担・交通整理を行っています
ビジネス上のアウトカムの手前にユーザーのアウトカムを常に意識するよう働きかけています
なぜプロダクトマネジメントに取り組むのか
実は、当初はプロダクトマネジメントではなくプロダクトマネージャーという"役割"の導入を検討していました。
当時のLIFULL HOME'Sにおいては、短期的な売上・利益にヒットしづらい顧客要望への対応や、技術的負債の解消のための施策が劣後しやすい傾向があったため、事業責任者とは別にプロダクト自体に責任を持つ役割を立てることで、プロダクトの成長や開発生産性の維持・向上を図ろうという狙いです。
しかしながら、国内・海外の事例や知見に当たる中で「単一プレイヤーの能力やマインドに依存する形での課題解決は持続しないのでは」という懸念が生じました。そこで、単にそうした役割を創設するのではなく、プロダクトマネジメントの文化をプロダクトチームにひいては組織全体にインストールしていこう、という方向性に軌道修正して、様々な取り組みを始めています。
いろいろと本やイベント等での発信を参考にしていますが、ベースの教科書（参考書）としては『INSPIRED』を採用しています（弊社の課題感に最もフィットしているように感じたため）。
具体的な取り組み事例
特に注力している取り組みを2つピックアップしてご紹介します。
プロダクトチームにおける役割分担・責任の明確化
LIFULLは「利他主義」という社是を掲げていることもあり、エンジニアやデザイナーも含めたものづくりメンバーも「言われたことだけをやる」という人は少なく、事業の課題解決やユーザーへの価値提供を志向する人が数多くいます。
そのため、開発の上流工程、すなわち「何を作るか」「何のためにやるか」という部分の議論にも、多くのメンバーが関わりがちでした。それ自体は即問題になるわけではなくむしろポジティブなことでもありますが、一方で以下のような課題が発生していました。
誰がどのように意思決定したのか、が不透明になる（責任の所在が不明瞭になる）
これだけの人が関わっていれば誰かが考えてくれているはず、と逆にこぼれ球・ルーズボールが増える
連携や調整に大きなコストがかかるようになる（ミーティングが多すぎるなど）
船頭多くしてプロジェクトはカオス化する、というやつですね。
この課題への対応として、まず、各職種の役割や職種としての専門性を、プロダクトの4つの価値（コントロールするリスク）をベースに整理し、プロダクトマネージャー、プロダクトデザイナー、テックリードという新しい役割を用意しました。ほぼ『INSPIRED』に書かれている通りですが、以下のような形です。
ミーティング等では、原則としてこれらの役割をもとに提案をし、役割のもとで意思決定していくことを求めています。定義（境界）は曖昧ですが、ざっくりとした交通整理さえできれば課題解決には繋がるので問題ありません。
また、これらの役割に基づいて、プロダクトへの具体的な関わり方や責任範囲を規定した「基本の型」としてのRACIチャートを用意しています。RACIチャートとは工程や業務区分ごとの意思決定者や説明責任者を明確にする役割分担ツールです（詳細は割愛しますのでググってください）。
例えば、プロダクトバックログの優先順位付けについてはプロダクトマネージャーに実行責任（R）と説明責任（A）があり、テックリードとプロダクトデザイナーはそれを支援する責任（C）があるよ、というようなことを規定しています。
このRACIチャートの運用についても、厳守するようなものではなく、プロダクトのフェーズやチームの特長に応じてカスタマイズ・進化させて使ってね、という形を取っています。プロダクト開発を進める上で、「全員が全部を考える」みたいにならなければOK、という感じです。
アウトプット志向からアウトカム志向へ
アウトプットではなくアウトカムを志向する、というのは当然のことであるかのように感じられます。が、『INSPIRED』には以下のように書かれています。
企業はプロジェクトに資金を付け、スタッフを配置し、組織の中でプロジェクトを通してから、ようやくプロジェクトをスタートさせる。残念なことに、プロジェクト自体がアウトプット（出力）であり、製品はアウトカム（出力）なのだ。予想されるとおり、このプロセスはプロジェクトを当初のアイデアから切り離す。最終的には何かがリリースされるが、それは目的に合致したものではない。
プロジェクトには様々な定義があると思いますが、概ね「何を、いつまでに、どうする」ということが承認時点で固められており、アウトカム追求のための試行錯誤の余地がないことが多いのではないでしょうか。
例えば、私が以前に聞いた某大手企業の話では、年に1回のイベントで発表する製品や機能が決まっており、イベントまでに完成させるべくプロジェクトが組まれる、というサイクルが社内にあったそうです。プロジェクトがアウトプット志向になる典型例と言えるのではないでしょうか。
弊社のLIFULL HOME'Sという事業において最も重要なのは1～3月の住み替え繁忙期です。そのため、しばしば「繁忙期に〇〇をプロモーションするために、12月中に〇〇をリリースする必要がある」というアウトプット志向の動きを求められることがあり、以下のようなネガティブが発生しがちでした。
プロダクトリリース前の仮説検証の動きが限定される（スケジュールが厳しいため）
プロダクトリリース後の磨き込みのリソースが十分に用意されない（繁忙期プロモという目的を完了してしまっているため）
上記の結果、繁忙期終了後にプロダクトの負債として残ってしまう
プロモーションでの活用（による繁忙期のユーザー集客）はアウトカムはアウトカムでも「ビジネスのアウトカム」と表現でき、これはこれでとても大切なものです。しかし、その手前に「ユーザーのアウトカム」がなければ、結局はごく短期的な打ち上げ花火にしかなりません。
常に「ユーザーのアウトカム」ありきで考えることを、まずはプロダクトチームから意識付けしていますが、今後はこれを企業全体の文化にしていく（すなわち、プロダクト主導の組織にしていく）ことが必要であると考えています。
おわりに
ひとまず、プロダクトマネジメントの導入目的に沿って、2つの課題とその課題への向き合い方について書かせていただきました。「プロダクトマネジメントをやっていこう」という前提の下で、他にも様々な取り組みを行っておりますが、それは別の人・別の記事に譲りたいと思います（と言っておきながら、また近いうちに私が書くかもしれませんが）。
プロダクトマネジメントは単に開発フローを変えればOKというような性質のものではなく、常に試行錯誤と学習のサイクルを回し続ける必要があるものだと考えています。試行錯誤の過程や成功・失敗事例を共有しつつ、他社の発信に学ぶことで、自社の枠を超えた学習サイクルを作っていくことができれば幸いです。
この記事が気に入ったらサポートをしてみませんか？