失敗を経て「KPI別」組織へ
――これはアジャイル開発の話でもよく出てくる悩みですね。全体の大きなロードマップとかち合って、評価とも連携していないのでなかなか進まないという。多くの企業はそこで挫折してしまいます。
山本：単純に目標を2つ持ってしまった、そして片方は評価にひも付かないことが課題だとわかったので、それを整理しようという発想に自然となっていきました。職能別組織でなかなか開発スピードが担保されないことがわかっていたので、戻しても成果は上がらない。というのも、組織が大きくなると大きなロードマップで承認されたことは進んでいくけれど、ちょっとした改善はおざなりになるというのが目に見えていたんですね。なので、たとえ失敗しても、変えていくことが前提だったわけです
石田：次に変えたのは、ユニットの軸を機能からKPIにしたことです。KPI別ユニットで同じ数値目標のもと目指すべきことが明確になりました。
なお、エンジニアについては兼任が予想されたため、あえてユニット内には組み込まず、プロダクトマネージャーと窓口となる開発マネージャーやデザイナーのみの組織にしたことも動きやすさにつながったと思います。それまでデザイナーはプロダクトマネージャーやディレクターの依頼で動くことが多く、いわば受け身だったのですが、それをユニット化して関係性を密にすることで、デザイナー自身も主体的に発想・提案するようになりました。
――KPI別というと、かなり数値目標の管理が必要になってきますが、そこはどのようになさったのですか。
山本：この時に並行して行ったのが、データドリブンな組織としての強化です。初期のプロダクトマネージャーは、リーダーの石田を筆頭に、思いや顧客優先で「気持ちドリブン」な傾向がありました。それは決して悪いことではないのですが、データ分析に熟知した人がほぼいなかったのです。
そこで、データの分析基盤などの環境を整え、BIツールを導入して、全員がクエリを出せるようになろうと勉強会を行い、データ活用の重要性理解から実践力まで徹底して浸透させました。その結果、データからエビデンスを示し、「だからこうしたい」という意見を述べるというファクトとオピニオンがセットで出せるようになり、1年でプロダクトマネージャーが作成するPRD（プロダクト要求仕様書）の質が急速に向上しました。それが説得力になり、自信になり、結果にもつながってきました。
石田：私がプロダクトマネージャーになったばかりの時に一番苦労した、エンジニアへの「WhyとWhat」の説明で、ユーザーの一次情報だけでは理解してもらえなった部分が、データを示すことでスムーズに理解してもらえるようになりました。これは本当に大きな変化で、エンジニアとWhyについてもめることはまずなくなりました。今も、課題が存在する根拠をデータから示したり、改善によってもたらされるKPIを数値化したり、当たり前のように行っています。
一方、組織の方はどんどん大きくなり、どうしてもプロジェクトベースで人をアサインすることになるため、同じエンジニアでワンチームで開発できなくなる可能性が想定されました。そこで、ユニット型のチームのロールモデルをつくることを命題として、プロダクト本部から完全に独立した「グロースエンジニアリング室」を別に構成することにしました。ここにはプロダクトマネージャーの他、開発マネージャーやモバイル、デザイナー、エンジニアがワンチームでそろい、ロードマップや差し込み案件には絶対に影響を受けず、常に機能のデリバリーに特化して開発することにしたわけです。その結果、継続的な開発ができるようになり、機能デリバリー数は一気に150%に向上しました。
山本：「グロースエンジニアリング室」のマネージャーは開発の副本部長をしていた人間だったのですが、元の上司である開発本部長からビジネス周りで強力な差し込みが来た時には、「それではこのチームをつくった意味がない！」と激しく対抗していましたね。その時はさすがに開発本部長が折れていました。現在「グロースエンジニアリング室」は再びプロダクト本部下に入り、開発連携の強化を図っています。
育成は伴走型で、「なぜその仕様にしたか」思考のプロセスを重視
――こうしたPM組織がまわるには、組織づくりもさることながら、一人ひとりのプロダクトマネージャーの育成も重要だと思われます。エンジニアとのコミュニケーションやデータ活用スキルなど、ポイントはうかがったように思うのですが、全体的な教育・育成はどのように行われたのですか。
石田：基本的にはオンボーディングという形で1週間単位、1か月単位でやるべきことを決めています。まず1週間目は「ビジョン・ミッション・バリュー」をしっかりとインプットして、プロダクトの理解、ビジネスモデル、ユーザー・市場の理解、開発組織の理解について、徹底的に行います。そのインプットを踏まえて、全体をどう捉え、自分がどうすべきかということをレポートにまとめます。次に、PRDを1か月で5～10ほど、できるだけたくさんつくって作成し、フィードバックしながら筋がいいものを最初のプロジェクトにして、実践に入るという流れです。
PMチームでは「PRD共有会」を1週間に一度行い、考え方などを共有するようにしています。それぞれバックグラウンドが異なり、タイプも違うので、多面的な知見を得ることが目的です。そこに新人プロダクトマネージャーのPRDも出して、みんなで意見を出し合いながらすり合わせていくことも行っています。
日常的には、特定の機能のプロダクトマネジメントを任せた上で、先輩プロダクトマネージャーが伴走して、裏で定期的な1on1を行うなどしていますね。以前、私がプロダクトマネージャーになったばかりのころ、山本が伴走してくれていたように、課題感を聞きながらフォローし、成功体験として全体のフローを見てもらうことを意図しています。他にもPRDの企画品質を上げていく取り組みや、データ活用についてのナレッジ共有、必要に応じてUXデザインについて教授することもあります。いずれもプロジェクトの中で実行していくという感じですね。
山本：海外で活躍するプロダクトマネージャーの方が外部顧問で付いており、週1回のミーティングで新しい知見があれば入れてもらうようにしています。
あとはプロセスの中に、「PRDの承認」と「リリース前の最終確認」の2つのタイミングで、そこで私に承認されないと開発着手もできなければ、リリースもできないという、かなり緊張感がある「プロダクト企画定例」という会議があるんですね。「なぜその仕様にしたか」という思考の過程から、「技術的最適が担保されているか」まで、相当厳しく聞いているので、プロダクトマネージャーはかなり緊張してやってきますね。石田もそこでは担当プロダクトマネージャーが突っ込まれるのを黙って見ています（笑）。それもいい教育になっていると思いますね。
石田：私としても振る舞いは難しいところですが、壁打ちの練習壁にはいくらでもなるし、検討漏れや修正ポイントなどのアドバイスはするけれど、本番は1人で戦えというスタンスでいます。そうしないと私の企画になってしまいますからね。
山本：そのうち私がやっている壁を石田が担い、私はもっと見るPRDを絞ってもいいかなと思っています。そうやって少しずつ権限委譲しながら、みんながステップアップし、組織として成長していきたいですね。
――それは期待できますね。今後についてはどのようにお考えですか。
石田：一般的に言われることですが、プロダクト開発の領域が、かつては製品を開発するだけだったところから、プロダクトの改善、導入支援、カスタマーサクセスというように広がっています。必然的にプロダクトマネージャーが関与する部分も広がっており、特にユーザー課題を解決しながら事業を成長させていく部分の役割はますます重要になっていくでしょう。その中で、テックやグロース、マーケティングなどそれぞれの領域に強い、多彩なプロダクトマネージャーが活躍することになると思います。今後はそうした人材を育てるのも、私の役割だと認識しています。
山本：開発の視点からいくと、サービス自体が一枚岩のシステムで、いわゆるモノリシックな状態にあるんですね。そのため一部を修正すると全体に影響するため、なかなか手を出せないという状況にありました。それを現在マイクロサービスに切り出すことで、互いに影響を受けずに独立して機能をリリースできるようにしようと、アーキテクチャの大刷新を進めており、来年には完了すると思われます。
そうするとシステムアーキテクチャと開発組織が似てくる「コンウェイの法則」の状態になるわけですが、そうなると当初行おうとしていた機能別ユニットによる開発組織もやりやすくなるのではないかと考えています。組織側もアーキテクチャも変わることでやりたいプロダクトマネジメントの体制も整っていくと思われます。
――プロダクトも組織も、フェーズに合わせて仮説検証を繰り返しながら変化させているのですね。これからの展開も期待しています。ありがとうございました。
