PMとPOを分ける本当の理由は、役割ではなく不確実性の比率である

Hatched by tttt

May 20, 2026

1 min read

2 views

84%

1つの人に詰め込みすぎると、何が壊れるのか

プロダクトの失敗は、たいてい「能力不足」ではなく、注意力の配分ミスから始まります。ある日は市場を見る。別の日はエンジニアと仕様を詰める。さらに別の日は優先順位を切り替え、ステークホルダーをなだめ、リリースの責任も背負う。すると気づかないうちに、仕事の中心が「何を作るべきか」から「今日どこに火がついているか」へと移ってしまうのです。

ここに、PMとPOが分かれる理由の本質があります。違いは肩書きではありません。外部の不確実性を扱う仕事と、内部の不確実性を扱う仕事を、同じ人にどれだけ同時に持たせるかという設計問題です。

興味深いのは、これは単なる役割分担の話に見えて、実は統計の考え方と深くつながっていることです。仮説を立て、データを集め、そのデータがどれくらいその仮説に合うかを比べる。ここで重要なのは、絶対値ではなく比較です。プロダクトも同じで、顧客側の仮説と開発側の制約を、両方とも完璧に満たすことはできません。だからこそ、どちらをどれだけ見ているのかを明確にしないと、判断が歪みます。

PMとPOの分離は、組織図の都合ではなく、世界の曖昧さをどう分割して扱うかという認知設計である。

プロダクトには2種類の「もっともらしさ」がある

統計で尤度を考えるとき、問いはこうです。この仮説のもとで、このデータはどれくらい起きやすいか。ここで大切なのは、データが正しいかどうかではなく、仮説がデータをどれだけうまく説明するかです。

プロダクトにも、これと同じ構造があります。ひとつは市場に対する尤度です。顧客の課題、競合状況、セグメント、価格、解約理由。これらの断片が、「このプロダクトは本当に必要か」という仮説にどれだけフィットするかを見る仕事です。もうひとつは開発に対する尤度です。設計の一貫性、実装の標準化、チームの成熟度、実装順序、受け入れ条件。これらが、「この機能は今のチームで安全かつ速く届けられるか」という仮説にどれだけフィットするかを見る仕事です。

問題は、多くの組織がこの2つを同じ人に同じ熱量で要求することです。すると、その人は市場仮説の更新に必要な時間を削ってまで、開発の細部に入り込みます。逆に、顧客と話す時間に偏りすぎると、チームは実装の途中で迷子になります。どちらも起こりうるし、どちらも致命的です。

この構造を理解すると、PMとPOの役割分担は「上位職と下位職」ではなく、異なる尤度計算を分業する仕組みだと見えてきます。PMは主に外部の仮説を更新し、POは主に内部の仮説を整合させる。両者は上下関係ではなく、異なる誤差を減らすための別の焦点なのです。

一人でやれるのは、世界が狭いときだけ

役割を一人で兼ねられるかどうかは、その人の優秀さよりも、対象世界の変動幅で決まります。社内向けの限定的な相手だけを対象にする場合、ニーズは比較的近く、発見すべきセグメントの数も少ない。市場に一般化する必要も薄く、外部競争の圧力も限定的です。この環境では、ひとりのPM兼POが十分に機能しやすい。

しかし市場に出た瞬間、前提は変わります。顧客は多様で、比較対象は増え、要件の背後にある文脈もばらつきます。ここで必要なのは、単なる要件整理ではなく、仮説の再分類です。誰のための価値なのか。何を捨てるのか。何を後回しにするのか。これを考えるには、開発の現場から少し距離を取る時間が必要です。

一方で、開発の現場から離れすぎると、今度は別の失敗が起きます。スプリントの終わりに「それは意図したものではない」と言う羽目になる。これは仕様ミスというより、意思決定の遅延です。顧客の声を聴く頻度が低いと、チームは自律的に動いていても、外部の現実から少しずつずれていきます。

ここで重要なのは、問題が「どちらに時間を使うべきか」ではないことです。正しい問いは、どちらの不確実性が今もっとも危険かです。市場が不安定なら外側を優先する。チームが未成熟なら内側を優先する。製品の失敗は、たいてい優先順位そのものではなく、優先順位を固定してしまうことから生まれます。

チーム成熟度とは、速度ではなく翻訳コストの低さである

成熟したエンジニアリングチームとは、単に速いチームではありません。曖昧な意図を、仕様に変換する翻訳コストが低いチームです。標準があり、設計言語が共有され、暗黙の前提が少ない。こうしたチームでは、PMやPOが毎回細部まで手取り足取り説明しなくても、意図が自然に伝わります。

逆に成熟度が低いチームでは、同じ一文がまったく違う実装につながります。たとえば「レポートを見やすくしたい」という要望ひとつ取っても、可視化の軸、フィルター、権限、ダウンロード形式、更新頻度で解釈が割れる。そこで必要なのは、より多くの会議ではなく、意味の摩擦を減らすための具体化です。

ここでPMやPOの仕事は、単に説明することではありません。チームが解釈を誤りやすい部分を先回りして特定することです。要件を細かくするのは、細かさそのものが価値だからではなく、誤読の分布を狭めるためです。

この視点を持つと、成熟度の高いチームに対してPMが過剰に関与することの弊害も見えてきます。過剰な介入は、チームの自律性を奪うだけではありません。むしろ、チームが本来できるはずの解釈と判断の練習を奪います。結果として、組織全体の学習速度が落ちるのです。

良い役割分担とは、仕事を減らすことではなく、誤解が最も起きやすい場所に注意を集中的に置くことである。

尤度比で考えると、プロダクト判断は急にクリアになる

統計で尤度比が役立つのは、仮説を単独で眺めるのではなく、どちらがデータをよりよく説明するかを比べられるからです。プロダクト判断も同じです。たとえば「新機能を追加すべきか」という問いは、単体では曖昧すぎます。しかし「新機能を追加した場合」と「今の導線を改善した場合」を並べると、必要な議論が見えてきます。

PMとPOの分担も、まさにこの比較の発想で設計すると明快になります。

市場仮説の尤度: この問題設定は本当に顧客の痛みを説明しているか。
開発仮説の尤度: この実装方針は本当に今のチームの能力に合っているか。
組織仮説の尤度: この役割配置は、本当に意思決定の遅延を減らしているか。

この3つを比べると、「PMがPOも兼ねるべきか」という質問が、はじめて実務的になります。重要なのは理想論ではありません。どの仮説の誤差が、今もっとも高くつくかです。

たとえば、成長初期で顧客像がまだ曖昧なら、市場仮説の更新が最優先です。ここでPO業務に吸い込まれると、チームは作ることに忙殺され、そもそも何を学ぶべきかを見失います。逆に、顧客要件が固まり、実装の複雑さが主要リスクなら、開発仮説の精度が重要です。ここでPMが市場調査にばかり時間を使うと、プロダクトは「正しい問題に向かっているが、間違った形で作られる」状態になります。

つまり、良いプロダクト組織とは、役職名の整合ではなく、誤差の所在に応じて注意を再配分できる組織です。

実務で使える3つの問い

この考え方を現場に落とすなら、会議で次の3つを毎回確認するとよいです。

1. 今いちばん危険なのは、市場の誤差か、実装の誤差か。
顧客理解がズレているなら外へ出る。実装がズレているならチームに深く入る。

2. この仕事は、仮説更新か、翻訳か、どちらが主目的か。
両方を一度にやろうとすると、たいていどちらも中途半端になります。

3. いまのチームは、何を説明しなくても理解できる成熟度にあるか。
成熟度が低ければ標準化と具体化に時間を使う。高ければ介入を減らし、学習と裁量を増やす。

この3問は、PMとPOを分けるべきかどうかの最終判定にも使えます。固定的な答えはありません。ただし、答えを出すための観点はあります。それが不確実性の種類です。

Key Takeaways

PMとPOの違いは肩書きではなく、不確実性の向きにある。 PMは主に市場の仮説、POは主に開発の仮説を扱う。
一人で両方を担えるかは、能力よりも世界の広さで決まる。 対象が限定されているほど兼務しやすい。
成熟したチームとは、曖昧な意図を高コストなく翻訳できるチーム。 速度よりも翻訳コストの低さが本質。
役割分担の正解は固定ではない。 いま最も誤差が大きい場所に注意を移すことが重要。
判断するときは、単独の理想形ではなく比較で考える。 市場仮説、開発仮説、組織仮説を並べて見ると、最適解が見えやすい。

役割ではなく、誤差を設計する

PMとPOを分けるべきかどうかという問いは、実は表面的です。本当に問うべきなのは、私たちはどの誤差を誰に、どの頻度で、どれだけ扱わせるのかということです。

この問いに答える組織は強いです。なぜなら、役職名に安心しないからです。市場が揺れれば外を見る。チームが未熟なら内に入る。成熟すれば任せる。つまり、変化に合わせて注意の置き方そのものを変えられる。

プロダクトは、正しいものを作る仕事だと言われます。しかし実際には、それ以上に正しい仮説に、正しい注意を配る仕事です。PMとPOの議論をその視点で見直すと、役割分担の話が、組織の知性の話に変わります。そこから先は、誰が何をやるかではなく、誰の時間がどの誤差を最もよく減らすか、という問いになるのです。