・Part II：有能なプロダクトリーダーにとって最も重要な職責である「コーチング」と「人材開発」に焦点を当てる
・Part III：プロダクトチームの採用について焦点を当てる
・Part IV：これから作ろうとする未来を定義し、プロダクトビジョンと原則について理解する
・Part V：会社のニーズに合うチームトポロジーに編成する方法（★今回はここ）
・Part VI：プロダクト戦略について理解する
・Part VII：各プロダクトチームの目標（解決すべき問題）を決めて、プロダクト戦略を行動に変える方法について理解する
・Part VIII：ケーススタディの紹介
・Part IX：プロダクト組織が他の部門と築くべきコラボレーションについて理解する
・Part X：すべてをつなぎ合わせ、一流のチームや企業のように仕事をする会社へと変革するプラン

・1つのプロダクトチームが1つのプロダクト全体を開発するのは珍しい
・現在のプロダクト組織は、作業を最も適切に分担するためにプロダクトチームの構成を決める問題に対処しなければならない
・チームトポロジーは次の問いへの答えになる
　A）いくつのプロダクトチームを設置すべきか？
　B）各チームの責任範囲はどうすべきか？
　C）各チームはどのようにスキルを備えた人材が何人ずつ必要か？
　D）チーム同士の依存関係は？
・プロダクトリーダーはこの難しい問いに対処するのが重要な職責の一つ
・整合が複雑な業務で、個々のチームの責任範囲を「ビジネスゴール」「顧客の種類」「組織の上下関係」「アーキテクチャ」「プロダクトビジョン」などの広いコンテキストと調和させなければならない
・チームトポロジーは必要性や状況の変化に従って進化させる必要がある

・チームトポロジーはチーム間の境界を定義し、検討する問題の範囲を設定するためにプロダクトリーダーが直面する重要な意思決定
・多くの場合チームトポロジーは最も抵抗の少ないルートをたどるように自然に発生する、また一度設定したチームトポロジーを変えるのが億劫になっているケースも多い

＜エンパワーメントに向けた最適化に関連する3つの要素＞
①オーナーシップ
・オーナーシップは単なるチームの目標ではなく、「機能」「UX」「品質」「性能」「技術的負債」をめぐる完全な責任範囲を規定する
・チームの責任範囲が狭すぎると士気を保つのが難しくなる
・対照的にオーナーシップの範囲が広いほどエンパワーメントが向上するが、チームの規模とスキルセットに対して責任範囲が大きすぎるとエンパワーメントが難しくもなる
・オーナーシップは責任範囲の「広さ」だけでなく「明確さ」も必要

②自律性
・自律性とは解決すべき問題を与えられたチームが自ら適切に考える、可能限り最善の方法で問題を解決できるだけの権限を備えていること
・あまりに多くの依存関係があると、自律性の実現は難しくなる
・チームトポロジーには何らかの依存関係は必要であるが、エンパワーメントに役立つチームトポロジーは依存関係を最小に抑えたもの
・チームのエンパワーメント＝必要なビジネスアウトカムを達成する最善の方法をチームで探せるようにすること

③整合性（アライメント）
・チーム間の境界が戦略的コンテキストの他の要素と一致している度合
・整合性がチームトポロジーの中で最も複雑な要素
・整合性を向上させるために重要な2つの側面は「アーキテクチャ」と「ビジネス」
・「アーキテクチャ」の役目はプロダクトビジョンの実現なので、プロダクトビジョンに基づいているのが理想
・チームは有意義な職務範囲のオーナーとなり、プロダクトに関する重要な意思決定が可能なほどの自律性を得ることができる。しかし技術的負債やレガシーシステムが多いと依存関係と複雑化によりチームが混乱する
・「ビジネス」の整合性は事業部門、市場参入戦略、顧客の種類、マーケットセグメントとの関係が含まれる

＜プロダクトチームの2つの基本的なタイプ＞
①プラットフォームチーム
・他のチームが使いやすいようにサービスをマネジメントする
・プラットフォームチームは成果が分かりにくいが非常に重要

■共通サービスの1度だけ実装すればよくなる例
A）認証や認可などのチーム
B）再利用可能なインターフェイスライブラリの管理をするチーム
C）テストとリリースの自動化ツールを提供するチーム

■難解だったり専門的な部分をカプセル化する例
A）レガシーシステムと統合するための抽象化を担当するチーム
B）決済処理を担当するチーム
C）専門的な税理計算を担当するチーム

②エクスペリエンスチーム
・プロダクトの価値を顧客にどのように体験させるかに責任を負う
・プラットフォームチームと同様にUXも1つのチームで扱う場合と複数のチームで扱う場合がある
・エクスペリエンスチームをUXの一部のオーナーとしてしまいがちだが、エンパワーメントされるのは、可能限りエンドツーエンドに近い責任を与えられたとき

・プラットフォームチームはサービスとアーキテクチャの基礎となる複雑さを抽象化することで、他のチームのエンパワーメントのレベルを向上させる
・プラットフォームチームの貢献はエクスペリエンスチームを経て間接的に顧客に届くためエンパワーメントの話題が扱いにくい
・プラットフォームチームはエクスペリエンスチームと比較して定常業務が多い傾向にある
・重要なことは定常業務とプラットフォームプロダクトの進化につながる主要業務を切り替えればエクスペリエンスチームと同等のチーム目標とエンパワーメントを実現できる

＜プラットフォームチームがエンパワーメントしプラットフォーム開発が促進する2つの方法＞
①チームの共同目標（Chpater57でも後述）
②社外向けプラットフォームプロダクトの目標
・顧客（通常は開発者）が利用するAPI
・APIというプラットフォームがプロダクトとして扱われる

・責任の範囲がエンドツーエンドにある可能性が高いのが、「販売チャネル」「マーケットセグメント」「ユーザーの種類」に従うとき

＜エクスペリエンスチームのトポロジーの例＞
①メディア製品
②ECプロダクト
③法人向けプロダクト
④マーケットプレイスプロダクト
⑤顧客対応プロダクト

・チームの物理的な距離もチームトポロジーを作成する上で非常に重要
・ITオフィスの賃料急騰、人材の確保は予てから課題であったが、パンデミックが追い打ちをかけた
・物理的な距離にはトレードオフが付きまとうため、プロダクトチームの最適化を優先したとき
①PdMをデザイナーと本社に配置するか
②PdMをエンジニアと一緒に配置するか
③PdMとデザイナーを顧客の近くに配置するか
④PdMとデザイナーをエンジニアと一緒に配置するか
を検討する必要がある
・筆者のおすすめは、②、④のようにエンジニアと同じ場所としている

・スタートアップ企業でもエンジニアリングが15名を超えた辺りから、エンパワーメントが社内調整の負担とともに徐々に損なわれる
・製品の戦略的コンテキストに大きな変更を加えたとき＝トポロジーを見なす必要があるとき

①トポロジーの変更タイミングの例
A）新たなマーケットセグメントに参入するためエンジニアを増強するとき
B）新しい戦略に複数のチームが維持されている製品の廃止があるとき
C）コア機能をプラットフォームとして他のチームの利用するとき
D）新しい戦略で拡大するマーケット向けのサービスを開発する場合
E）アーキテクチャに重要なリファクタリングを行う場合

②トポロジー見直しの兆候
A）マネージャーが開発者を複数のチーム間で頻繁に異動させているとき
B）マネージャーが依存関係の衝突解決のために頻繫に介入しているとき
C）他のチームとの依存関係が強くなりすぎているとき
D）各チームのオーナーシップが狭いとき
E）開発者があまりに多くの領域に渡って複雑な仕事を処理する必要があるとき