第7章: プロダクト主導組織 — 権限委譲と認知負荷

ここまで、PMの仕事——ディスカバリー、優先順位付け、ロードマップ、指標——を見てきました。 しかし、どれほど優れたPMでも、組織が間違っていれば力を発揮できません。 「機能のリストを上から渡されるだけ」のチームに、第2章で見たアウトカムへの責任は持てないからです。 本章は、プロダクトが主導する組織の設計を扱います。縦串は「権限委譲（autonomy）」と「認知負荷（cognitive load）」の2つです。

Empoweredチーム vs Featureチーム

Marty Caganが『EMPOWERED』で打ち出した、組織論の核心がこの対比です。 第2章で触れた「ビルドトラップ」が、チームの構造レベルで現れたものと考えてください。

Caganの定義はシンプルです——「Empoweredとは、チームに問題を与え、最良の解決策を見つける裁量を与えること」。 Empoweredチームは解決すべき問題を割り当てられ、完全にアウトカムに集中します。 どんな機能を作るかは完全にチーム次第。一方Featureチームは、機能リストを受け取って作るだけで、 その機能が価値を生むかどうかの責任は、要求した経営層にあります。

PLG — 製品自体が成長エンジンになる

組織が「何を成長の駆動エンジンにするか」も、プロダクト主導かどうかを分けます。 PLG（Product-Led Growth）は、Wes Bushが2019年の同名著書で一般化した概念で、 製品自体を顧客獲得・転換・拡大の一次ドライバーにするモデルです。

代表例はSlack・Figma・Notion。たとえばSlackは無料で始められ、直感的すぎてIT部門の関与が不要で、 個々のチームが勝手に使い始める。しかもネットワーク効果が内蔵されており、チームメイトが増えるほど価値が増します。

チームトポロジー — 認知負荷でチームを設計する

もう一つの縦串「認知負荷」を中心に据えたのが、Matthew SkeltonとManuel PaisのTeam Topologies（チームトポロジー）です。 チームを4つのタイプに分類します。

graph TD
  SA[Stream-aligned team\n単一の事業能力を全スタックで所有]
  PL[Platform team\n内部サービスで認知負荷を軽減]
  EN[Enabling team\n専門家がコーチングで支援]
  CS[Complicated-subsystem team\n高度な専門領域に専念]
  PL -.->|認知負荷を下げる| SA
  EN -.->|コーチング| SA
  CS -.->|専門性を提供| SA
  style SA fill:#3b82f6,stroke:#2563eb,color:#fff
  style PL fill:#14b8a6,stroke:#0d9488,color:#fff
  style EN fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style CS fill:#f97316,stroke:#c2410c,color:#fff

すべての設計の中心軸は認知負荷です。プラットフォームチームの主目的は「Stream-alignedチームの認知負荷を下げること」。 また逆Conway戦略——チーム編成を望ましいソフトウェアアーキテクチャに整合させる——や、 システムを自然な切れ目で分割するFracture planes（破断面）といった概念も、認知負荷の管理に根ざしています。

Spotifyモデルとその「失敗」

組織論で最も有名で、最も誤解されているのがSpotifyモデルです。 Henrik KnibergとAnders Ivarssonが2012年の白書で記述した、4つの構成要素から成る編成です。

Spotifyモデルが目指したのは「高アラインメント × 高自律」の象限です。 チームは組織の方向性を知る（alignment）必要がある一方、実行手法の自由（autonomy）を保つ。 自律が低いとマイクロマネジメント、アラインメントなき高自律はカオスになります。

Product Opsの台頭とCPO

組織がスケールすると、PMの仕事を支える専門機能が必要になります。それがProduct Ops（プロダクトオペレーション）です。 Melissa Perriが中心となり提唱したこの規律は、プロダクトマネジメント機能を「受注生産」から 「スケーラブルなリソース・機能」へ転換します。3つの主要コンポーネントは—— ①ビジネスデータ&インサイト、②顧客&市場インサイト、③運用標準（プロセス&実践）。 LinkedInで「product operations」を肩書きに持つ人は2019→2025で760%増と、急成長中の領域です。

そして、プロダクト組織の頂点に立つのがCPO（Chief Product Officer）です。 複数プロダクトを全社ビジョンに結びつけ、3年ビジョンを設定し、プロダクトポートフォリオのP&Lを所有します。 組織のラダーはPM → Director of Product → VP of Product → CPOと上がっていきます（第2章のキャリアパス参照）。

まとめ — 構造より文化、そして権限委譲

本章では、プロダクト主導組織を「権限委譲」と「認知負荷」の2つの縦串で解剖しました。 Empoweredチームは問題と裁量を与えられアウトカムに責任を持ち（宣教師）、Featureチームは機能を作るだけ（傭兵）。 PLGは製品自体を成長エンジンにし、チームトポロジーは認知負荷を中心にチームを設計する。 Spotifyモデルの失敗が教えるのは「構造だけ真似ても、文化と権限委譲を欠けば機能しない」こと。 そしてProduct OpsがPMをスケールさせ、CPOが組織の頂点に立ちます。

ここまで、PMの歴史・役割・手法・組織を体系的に見てきました。最終章では、視点を未来へ向けます。 生成AIは、これらすべてをどう変えるのか。「PMは不要になるのか」という問いに、正面から向き合います。