プロダクト開発の優先順位をプロダクトの話から決めるとみんながつらい件
本記事はプロダクトマネージャー Advent Calendar 2024 day19の記事です。
ユニファでプロダクト組織をマネジメントしている山口です。最近よく読まれた記事は猫の記事です。年末の繁忙期も猫のおかげで気持ちが保たれています。とても良い。
優先順位付けのサイクルと大量の要求要件
現職では保育ICTサービスのルクミーを開発・運営しています。園や施設がルクミーを導入すると、園と保護者間のコミュニケーション、園内書類業務のデジタル化による日々の業務負荷の軽減や、写真などを通した子どもの育ちの気づきの機会が増えるようないわゆるBtoBサービスです。
ルクミーの開発優先順位は3ヶ月に1回見直すサイクルです。昔は年1だった時代もあったようなのですが、外部環境の変化に対応しようとすると1年前の戦略がずっと正しい保障はなく、とはいえ毎月ベースで変えていたら検証できることも検証できないので今のペースに落ち着いています。
みなさんは優先順位付けをする時、どんな方法を採っていますか？要求・要望のバックログを一気に並べて工数と期待効果を一覧化して上位からやっていくなど、色々とやり方があると思います。
1つのプロダクトに1つの開発チームがベタ付きであればそれでも回ると思うのですが、ルクミーは複数のプロダクト群を4つのチームで回しており、バックログについても1年で2000件を超えてくるレベルです。
過去にはそれでも優先順位を付けて整理していたものの、検討にかかる工数の大きさや複雑さ、そして最終的にできあがったものの全社的な腹落ち感など様々な課題があり、今ではやり方を変えています。
優先順位って、なんのために決めるのか。
プロダクトの優先順位の世界で言うと、限られた工数の中でどんな要求・要望から着手するかという話が中心になります。
一方、事業全体で考えたときは、事業を成長させる上で早く検証したい、他社より先手を打ちたい、法律に対処しないと補助金対象にならなず今後の導入のブレーキになるので避けたい等、戦略ストーリーの優先順位から考えていきます。
ルクミーには複数のプロダクトがあることをご紹介しました。例えばこの半年の戦略ストーリーではプロダクトAを通して新規領域の仮説検証を真っ先にやりたいが、プロダクトBとCに対しては戦略上も特に重要な場面がないと言うことがあります。
プロダクトの要求は、ボトムアップで上がってくる情報を元に今使っているものをさらに改善したり、技術負債の解消により生産性を向上するなど、必ずしも事業戦略に乗ってこないものもあります。ただ、「この会社の事業を成長させたい」と思ったとき、客観的に見ればプロダクトBやCにかけている人員をプロダクトAに寄せてでも仮説検証を推進したいと言うシーンは当然あります。
そんな時、プロダクトチームから上がってくるロードマップがA~Cを平等に前に進める案だったらどうでしょう。経営ボードや事業責任者から見たときに、何でBとCに今そんなに注力する必要があるの？無駄な開発をしてないか？と疑問を持たれるはずです。
プロダクトからではなく、事業ストーリーの順位付けから関わる。
せっかく大量の要求を分析してプロダクトチーム的にはかなり良さげな計画を作ったとしても、今それは大事じゃないと言う話になると、その計画自体もそうですし、それにかけた時間の多くも今は無駄になってしまいます。
そうならないためには、そもそもの事業ストーリーであったり、自身に関わるプロダクトに対して向こう3〜6ヶ月の機会や脅威を把握した上で、事業全体を見ているキーマンと目線を擦り合わせることが重要です。
その結果次第では「今の担当領域での追加開発ではなく、到底領域の技術検証を行った方が良い」という判断になることも当然あります。
自分としてはプロダクトの優先順位付けはバックログを見ているだけでは足らず、会社の戦略や今後の外部環境も含めた上で何を進めていくべきか？から考えると良いんじゃないかと思っています。そこに足りないパーツは何か、今の目線延長線にあるのか、ないのであればそこのディスカバリーから必要だよね、と言う議論が必要です。
昨今の生成AIとプロダクトの連携などは特にこういった優先度付けになることが多いように感じます。足元の要望・要求が仮になくとも今取り組み、理解を得ておかないと今後の成長の大きなチャンスを逃すこともあるはずで、足元の開発を止めてでもそちらに行こうという場面はまあります。
まとめ
なるほど、じゃあこれからは既存のバックログを無視してひたすら戦略をもとに考えていけばいいのね、と思われたかもしれません。個人的にはそれも否です。
各チームでもバックログに対する工数と効果の分析、優先度自体は当然行っていて、ただその時にシンプルな要求の多さだけでなく戦略への関連性をフィルタに含めて判断します。
プロダクトチームには「戦略への対処は7割、あとの3割は不確実性のためのバッファにして」と伝えています。計画で全てを読めることなんてまずないですし、既存のお客様の課題を解決しなくて良いなんてことも当然ないからです。
ルクミーのロードマップでは戦略系の開発は管理しますが、残りの3割は管理しません。ここはまさに現場の開発チームやプロダクトに関わる営業、CS、サポート部門の担当者（プロダクト大臣としてアサインされています）の意思で進める部分として置いているためです。
明確にROIは語れないけどPdMのエゴでもいいので進めたい改善や検証であったり、技術負債の解消、技術調査など、用途としての縛りはありません。もちろん不確実性の高い戦略案件について、想定より開発規模が膨らんだ場合に吸収するバッファとしても機能します。
大事なことは「日々の要求がこれだから、上から解決すれば良い」だけの視点ではなく、事業全体を進める上での優先順位はどうなっているんだろう？と、一度止まって考えることです。そしてプロダクトマネージャーの仕事は機能を開発してリリースすることではありません。プロダクトの知見を生かし、時には開発と言う手段を選ばなくともプロダクトの関わる事業を前に進めることです。
そういった視点がプロダクトチーム内だけでなく社内全体で共通認識になっていけば、より大胆なプロダクト施策へのチャレンジができ、優先順位付けが単調な分析作業ではなくワクワクしたアイデア出しのシーンに変えられると思います。
現実はそう単純じゃないことも十分理解しているので、皆さんいっしょに頑張りましょう！
<以下、宣伝のコーナー>
来月下記イベントで登壇します。様々な切り口のPM知見を聞けそうで自分も楽しみです。
ユニファ株式会社ではいっしょに保育領域の課題解決や保育の質を向上する取り組みを進めていただける方を募集しています！興味を持っていただけた方はぜひ下記より採用情報をご覧ください。
ユニファのアドベントカレンダーも開催中です。
それでは、良いお年を！