PdM組織3人の壁
こんにちは。
STORES 予約 でプロダクトマネージャー（以下、PdM）をしている西岡です。STORES は「お店のデジタル化をまるっとサポートする」というコンセプトで、複数プロダクトを運営している会社です。
スタートアップの人事界隈では、拡大する人員と組織課題をまとめた「組織〇〇人の壁」という表現がしばしば使われています。
直近2年のSTORES 予約 エンジニア増加に伴い、STORES 予約 のPdMチームが有り難いことにわたし1人から3人体制になりました。
今回は人員拡大するPdM組織の中で発生した数々の問題、そして課題に対してどのようにチームとして対応した（している）のかを「PdM組織3人の壁」として紹介します。
STORES 予約 のPdMチーム遍歴
2021年1月- 西岡（@nishiokadaiki1）1人期間
2021年10月 宮里さん（@miyahirok）入社。2人チームへ
2022年 8月 曽根さん（@daisukesone213）入社。3人チームへ
1. 複数PdMでのプロダクトロードマップ運用方法
1人PdM時代は、西岡がプロダクト戦略やロードマップのたたきを作り、それをもとに事業責任者や、エンジニア、ビジネスチームのマネージャーと議論して意思決定をしていました。
PdMが2人に増えたタイミングで、これまで1つだったスクラムチームを2つにわけ、事業戦略をもとに開発テーマをチーム毎に割り振り、そのテーマの中で各PdMが優先度を考える体制に変更しました。
ある日、ビジネスチームから大手の事業者がチャーン（サービスを解約する）するという相談があり、プロダクトロードマップの大幅な入れ替えを議論していました。その時、ロードマップはテーマ別になっており、優先度の高い施策を順番に開発できていなかった重大な問題に気付かされました。
なぜこのような事が起こるのでしょうか。
それは、テーマ別に分けることによって、優先度の低い施策が先に開発されることが発生するからです。
このときの反省は、PdMの独立性を事業全体のプロダクトバックログより優先してしまった点です。わたし自身、複数のPdMで1つのプロダクトバックログを管理した経験が乏しく、PdMが複数人に増えても各PdMの意思決定の独立性を確保したい想いがありました。
しかし、エンジニアリソースが限られている小規模な開発組織では、本当に優先度の高い施策は何なのかを、今これを開発すべきなのか等の議論を尽くすべきです。テーマごとの役割分担はその議論を阻害してしまう可能性がある事に気付かされました。
もう少し組織が大きくなれば事業テーマをいくつかに細分化した方が効率が良いケースもありますが、小規模だと事業成長に直結していない施策にリソースを費やしすぎる無駄が発生する場合もあると思います。
ちなみに現在の3人体制では、プロダクトバックログを1つに管理し（LeSSにおけるプロダクトバックログ）、基本的には優先度の高い施策を各開発チームで進める方式に変更しています。
全体的なプロダクトバックログの決め方は、各PdMで担当領域を分担し、各領域のプロダクト戦略、バリュープロポジションを考え、施策ベースで全体のプロダクトバックログを議論して決めています。
テーマ横断で議論しやすくするため、各PdMが施策ごとにRICE（優先順位づけのフレームワーク）をつけています。共通の評価軸をすり合わせることで、全体のプロダクトバックログを議論しやすくしています。
この方法は半年ぐらい前から試している方法でして、PdMの主体性と事業戦略に直結したプロダクトロードマップづくりをいかに両立させるのかという問いにチーム一同向き合っている最中です。
このお題だけであと2,000文字ぐらい語れそうですが、次に行きます。良い感じに運用しているチーム等ありましたら、ぜひ意見交換させてください！
2. ドキュメント＆開発プロセスがバラバラ
PdMが複数になると各種ドキュメントのフォーマットや開発の進め方が少しずつ違うケースが出てきました。大きな課題として表出してなかったのですが、実際にフォーマットやプロセスが整理されると非常に仕事が進めやすくなった感覚があり、もっと早めに着手しておいた方が良かったという反省があります。
具体的には、社内で情報共有ツールとしてesaを利用しており、PRD（要求仕様書）や機能仕様（詳細な仕様がまとまったドキュメント）をテンプレート化していきました。
開発プロセスにおいても、PRDを作成し関係者を集めてキックオフMTGをする。機能リリース前に STORES 予約 に関わる全員の前でおためし会（実際に動くものをテスト環境で触ってもらいフィードバックをもらう会）を実行する等、機能の検討開始からリリース、振り返りまでを関係部署を巻き込みつつ、推進するプロセスがようやく固まってきました。
ドキュメントや開発プロセスを固める事により、あたらしいPdMの方が入社された時にキャッチアップしやすい副次的な効果もあります。
この部分は宮里さんが STORES 予約 に導入してくれた知見が多く、下記noteにて一部紹介されているので是非読んでみてください。
3. PRDの質を高めるには
上記で記載したようにPRDのテンプレート化はしていたのですが、仕様として悩ましいものだったり、狙っているような成果がでなかった時にPdMチームでもその施策に対する理解や認識が揃っていない時がありました。
PRD検討段階で適切にフィードバックできていれば開発内容がより良くなっていた可能性が高いというチーム内での振り返りがあり、各PRDに対して他のPdMがフィードバックをする運用を開始しました。
専用のslackチャンネルを作り、2営業日以内に反応するルールで運用しています。フィードバックのお作法は、エンジニアのレビュー手法を参考にしており、imo / ask / must などを取り入れています。
あくまで仕様や方針の意思決定者は施策担当のPdMですが、他のPdMからフィードバックを受ける事で施策目的やスコープがシャープになったり、PdM同士の情報共有の手間がなくなる効果を実感しています。
4. 仮説検証をチームでどのように進めていくのか
上述したようにPdMが担当領域を持ち、そのテーマに対して解像度を上げて戦略立案することが、 STORES 予約 PdMとして重要な役割になっています。顧客解像度を上げるためには、PdM各自でユーザーインタビューの企画をし、ビジネスチームを巻き込みながら実行していくスタイルになっています。
有り難い事にPdMが増えてきたおかげで、開発フェーズだけではなくディスカバリーフェーズへ時間を投下できているのは良い傾向なのですが、このフェーズにおける優先順位、方法論が各PdMに依存しており、事業全体として適切に議論できていないのが直近の課題です。
事業として今明らかにすべき仮説は何か、検証結果はどう生かしていくのかという論点をPdMだけではなくPMMや事業責任者をふくめて整理していく必要性を感じています。まずはすぐにできるアクションとして、「ディスカバリーバックログ」で見える化することで、全体の優先度、アウトプットの共有を円滑に行う狙いです。
まとめ
「PdM組織3人の壁」と第して、1人PdMから複数体制になったとき発生した問題をいくつか羅列してきました。
PdMの魅力は、自らの意思決定でいつでも局面を打開できるダイナミックさにあると思います。（とはいえ、PdM1人では何もできないという無力感も常にある）
「PdM組織3人の壁」とは、PdMのダイナミックさを出来る限り失わず、チームとしての相乗効果を生み出し、事業成長に最適なプロダクト開発をいかに推進するのかという問いにぶち当たる現象だと考えています。
1人PdMで自由気ままにやっていた時代が長かったのですが、直近1年間でチームとして取り組んだ内容や知見から学ぶことの方が圧倒的に多かったと実感しています。
今回ご紹介した取り組みは、PdMチームで毎月実施している振り返り（KPT）から実行した内容です。上記のように紹介させてもらいましたが、私個人で考えた内容は少なく、STORES 予約 PdMチームで常に議論し、改善しております。
最後に
STORES では、絶賛採用強化中です。
オーナーさんへの提供価値を最大化するため、複数プロダクトをいかにレバレッジを効かせて実現させていくのかというのが今後の重要テーマになっております。エンジニアやデザイナーなどの開発チームだけではなく、ビジネスチームにとってもチャレンジングな環境になっているので、少しでもご興味ある方は、まずはカジュアルな面談からご応募ください！
他の STORES アドベントカレンダーはこちらから閲覧できます！
この記事が気に入ったらサポートをしてみませんか？