第2章: プロダクトマネージャーの役割 — ミニCEO論と4つのリスク

第1章では、プロダクトマネジメントが「3つの源流の合流」として生まれた歴史を辿りました。 では、その伝統を背負ったプロダクトマネージャー（PM）は、現場で何をする人なのでしょうか。 本章では、PMの役割をめぐる最も有名な通説「ミニCEO」を検証することから始め、 混同されがちな他職種との違い、PMが負うべきリスクの所在、そしてキャリアパスまでを整理します。

「ミニCEO」という通説とその誤解

PMを語るとき、最もよく使われる比喩が「ミニCEO（mini-CEO）」です。 プロダクトに対してCEOのように結果責任を負うから、というのがその心です。確かに、PMは 「何を、なぜ作るか」を決める上流の意思決定者であり、プロダクトの成否を一身に背負います。 しかしこの比喩は、ある重大な誤解を生む危険をはらんでいます。

graph LR
  CEO[CEO]
  PM[プロダクトマネージャー]
  CEO -->|予算配分・採用解雇・戦略を| AUTH[執行する権限を持つ]
  PM -->|それらに| INF[影響を与えられるが執行はできない]
  AUTH --> R1[結果責任]
  INF --> R1
  style CEO fill:#f97316,stroke:#c2410c,color:#fff
  style PM fill:#3b82f6,stroke:#2563eb,color:#fff
  style R1 fill:#14b8a6,stroke:#0d9488,color:#fff

誤解の核心は「権限」と「責務」の混同にあります。CEOは予算配分・戦略策定・採用解雇を 自ら執行する権限を持ちます。一方PMは、それらに影響を与えられても、自ら執行はできません。 エンジニアに命令することも、勝手に予算を動かすこともできない。PMの本質的な挑戦は、 まさに「権限ではなく、影響力（influence）で組織を動かすこと」にあります。

Lenny Rachitsky（著名なPM論者）は、PMの仕事をShape（形にする）・Ship（出荷する）・Sync（人を揃える）の 3つに整理しています。そして根本の責務はビジネスインパクトを生むこと。 自分で手を動かすのではなく、デザイナー・エンジニア・データサイエンティストといった チームのレバレッジを最大化するのがPMの役割です。

混同されがちな4つの職種 — PM / PO / PjM / PMM

PMを理解するうえで避けて通れないのが、似た名前の職種との区別です。 特に「プロダクトオーナー」「プロジェクトマネージャー」「プロダクトマーケティングマネージャー」は、 日本語にすると紛らわしく、実務でも混同されます。一覧で整理しましょう。

3つの重要な違いを言葉でも押さえておきましょう。

• PM vs PO: PMが戦略・市場を見る上流の責任者、POはそれを実行可能なタスクに変換する戦術的役割。Marty Caganは「POの責務はPMの責務のごく一部のサブセットに過ぎない」と明言しています。POは本来スクラム上の「役割（role）」であり、チーム内の誰か（多くはPM）が兼ねるべきものです。
• PM vs PjM: PMは「プロダクトの成功」をライフサイクル全体で担う永続的な役割。プロジェクトマネージャーは「特定プロジェクトを期日内に完遂」させる、開始から終了で完結する役割です。
• PM vs PMM: PMが「プロダクトの定義と提供（delivery）」を所有するのに対し、PMMは「市場準備・ナラティブ・商業化（GTM）」を所有します。両者は車の両輪です。

PMが負うべきもの — Caganの「4つのリスク」

PMの責務を最も明快に定義したのが、Marty Cagan（SVPG）の「4つの大きなリスク（The Four Big Risks）」です。 もともとCaganは「成功するプロダクトはValuable・Usable・Feasibleの3条件を満たす」としていました。 しかし「3つだとビジネス価値（viability）のリスクが見落とされやすい」と気づき、 現在は4つに整理しています。それぞれのリスクには「主たる責任者」がいます。

注目すべきは、PMがValueとViabilityという2つのリスクを保証する責務を負う点です。 これは4つのうち最も難しく、最も逃げ出したくなる領域です。Caganはこう指摘します—— 多くの弱いチームは「自分でどうにかできるUsability・Feasibilityのリスク」に引き寄せられ、 ValueとViabilityは"難しくて怖い"ため、シニアや法務に丸投げしがちだ、と。 そこから逃げないことが、優れたPMの条件です。

プロダクトトライアド — 3人で全リスクをカバーする

4つのリスクは、1人では背負いきれません。そこで現代のプロダクトチームの標準的な編成が プロダクトトライアド（Product Trio / Triad）です。

graph TD
  PM[プロダクトマネージャー\nValue + Viability]
  DES[プロダクトデザイナー\nUsability]
  ENG[エンジニア / テックリード\nFeasibility]
  DEC{意思決定は\nチームで共同所有}
  PM --> DEC
  DES --> DEC
  ENG --> DEC
  style PM fill:#3b82f6,stroke:#2563eb,color:#fff
  style DES fill:#ec4899,stroke:#be185d,color:#fff
  style ENG fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style DEC fill:#14b8a6,stroke:#0d9488,color:#fff

トライアドの目的はサイロ化したオーナーシップの解消です。 PMが価値と事業性、デザイナーがユーザビリティ、エンジニアが実現性を担い、 3者がDVF（Desirable=ユーザー価値 / Viable=事業成立 / Feasible=技術実現）の全側面をカバーします。 各領域を誰か1人が「リード」しつつ、意思決定そのものはチームが共同所有する。 早期から継続的に協働することで、誤解の発生を防ぎ、開発を高速化します。

PMのキャリアパス — APMからCPOまで

最後に、PMがどのように成長していくのかを見ておきましょう。標準的なキャリアラダーは次の通りです。

各レベルおおむね2〜4年、APMからCPOまで合計15〜20年以上かかるのが一般的です。 ここで知っておきたいのが、Senior PMとプロダクトリーダー（Director/VP）の間に存在する「キャニオン（峡谷）」です。 多くのキャリアがここで停滞します。理由は、仕事が「自分の実行」から 「組織への影響力とリソース配分」へと質的に変わるためです。 優れたSenior PMが自動的に良いDirectorになるわけではない——事実上、別の職種への転換なのです。

まとめ — 権限なきリーダーシップ

本章では、PMの役割を多面的に解剖しました。PMは「ミニCEO」と呼ばれますが、それは権限ではなく結果責任の意味であり、 本質は影響力で組織を動かすことにあります。PO・PjM・PMMとは工程と問いが異なり、 Caganの4つのリスクのうちPMは最も難しいValueとViabilityを保証する責務を負います。 そして1人では背負えないリスクを、プロダクトトライアドで分担します。 全体を貫くのは、機能の量産（アウトプット）に囚われるビルドトラップを避け、成果（アウトカム）を追うという姿勢です。

では、PMの「本業」とされるディスカバリー——「正しいものを作っているか」を探る営み——とは、 具体的にどう進めるのでしょうか。次章では、JTBDやThe Mom Testといった実践手法に踏み込みます。