Team Topologies

### 1. コンウェイの法則がチーム構造を通じてソフトウェアアーキテクチャを形成する

> システムのアーキテクチャと組織のアーキテクチャが対立する場合、組織のアーキテクチャが勝つ。

**コミュニケーション構造が重要である。** コンウェイの法則は、組織のコミュニケーション構造がその作成するシステムの設計に直接影響を与えることを明らかにしている。この原則はソフトウェアアーキテクチャとチーム組織に深い影響を与える。チーム構造を望ましいシステムアーキテクチャに合わせることで、組織はコンウェイの法則を有利に活用できる。

**逆コンウェイの手法。** チーム構造がシステム設計を決定するのではなく、組織は意図的にチームを形成して望ましいアーキテクチャを生み出すことができる。このアプローチは「逆コンウェイの手法」として知られ、以下を含む：

- 目標とするシステムアーキテクチャの特定
- このアーキテクチャを反映するチーム構造の設計
- コンウェイの法則の自然な力を利用して開発を導く

**戦略的なチーム設計。** 意識的にチーム構造を設計することで、組織は以下を促進できる：
- モジュラーで疎結合なシステム
- コンポーネント間の明確なインターフェース
- システムの保守性とスケーラビリティの向上

### 2. チーム優先アプローチが認知負荷とフローを最適化する

> チームの認知負荷を減らし、チーム間の相互作用を促進することで、フローを最適化する。

**認知負荷が重要である。** チーム優先アプローチは、チームが効果的に管理できる複雑さには限界があることを認識している。チームの認知能力を優先することで、組織は以下を実現できる：

- 生産性とイノベーションの向上
- ストレスと燃え尽き症候群の軽減
- コード品質とシステム信頼性の向上

**認知負荷を管理するための戦略：**
- チームの責任をその認知能力に合わせる
- 大規模なシステムをチームサイズのコンポーネントに分解する
- チーム間の明確で定義されたインターフェースを提供する
- 複雑なタスクを簡素化するツールやプラットフォームに投資する

**フローの最適化。** 不要な認知負荷を減らすことで、チームは以下の状態を達成できる：
- 高い生産性と創造性
- 仕事の満足度の向上
- 問題解決とイノベーションの迅速化

### 3. 効果的なソフトウェア提供を推進する4つの基本的なチームトポロジー

> 4つの基本的なチームトポロジーは、ストリームアラインド、エネーブリング、複雑なサブシステム、プラットフォームである。

**ストリームアラインドチーム**は組織の中核を形成し、ユーザーや顧客に直接価値を提供する。これらのチームは：
- クロスファンクショナル
- 特定の製品、サービス、またはユーザージャーニーに合わせて調整されている
- エンドツーエンドの価値を提供するために権限を与えられている

**エネーブリングチーム**は、以下を通じてストリームアラインドチームをサポートし、加速する：
- 専門知識の提供
- 研究とプロトタイピングの実施
- 知識の移転の促進

**複雑なサブシステムチーム**は、深い専門知識を必要とする複雑なコンポーネントを管理し、ストリームアラインドチームが価値提供に集中できるようにする。

**プラットフォームチーム**は、ストリームアラインドチームがより効率的かつ自律的に作業できるようにする内部サービスとツールを提供する。

これらの4つのチームタイプを採用することで、組織は以下を実現できる：
- チームの責任と相互作用の明確化
- 依存関係とボトルネックの削減
- 全体的な提供速度と品質の向上

### 4. 明確に定義されたチームの相互作用モードが協力と生産性を向上させる

> チームの相互作用をコラボレーション、X-as-a-Service、ファシリテーションの3つのモードに限定することで、ソフトウェアシステムを構築するチーム間の重要な相互作用を簡素化し、明確にする。

**コラボレーションモード**は、発見とイノベーションのための緊密なチームワークを伴う。これは以下の場合に最適である：
- 新しいシステム開発の初期段階
- 複雑で横断的な問題の解決
- 迅速な学習と適応が重要な場合

**X-as-a-Serviceモード**は、チーム間の明確なプロバイダー-コンシューマー関係を確立する。これは以下の場合に理想的である：
- 安定した、明確に定義されたサービスやコンポーネント
- チームの自律性の最大化
- 予測可能でスケーラブルな相互作用の実現

**ファシリテーションモード**は、あるチームが別のチームを支援して新しい能力を開発することを伴う。これは以下の場合に有用である：
- 知識の移転とスキルの開発
- 移行期間中の一時的なサポート
- チーム間の課題への対処

これらの相互作用モードを明確に定義することで、組織は以下を実現できる：
- チーム関係の曖昧さの削減
- フォーカスと生産性の向上
- スムーズなチーム間の協力の促進

### 5. チームの認知能力に合わせてソフトウェアの境界を設定する

> チームの認知負荷に合わせてソフトウェアの境界を選択する。

**チームサイズのアーキテクチャ。** ソフトウェアの境界をチームの認知能力に合わせることで、チームがシステムの一部を効果的に所有し、進化させることができる。このアプローチは以下をもたらす：
- 所有権と責任の向上
- 開発と問題解決の迅速化
- システムの保守性の向上

**境界を定義するための戦略：**
- ドメイン駆動設計を使用して自然なシステム境界を特定する
- コンポーネントの範囲を定義する際にチームのサイズと専門知識を考慮する
- マイクロサービスアーキテクチャを活用して管理可能なチームサイズのサービスを作成する

**適切な境界設定の利点：**
- チームの認知過負荷の軽減
- チーム間の責任とインターフェースの明確化
- システムの進化とスケーリングの向上

### 6. プラットフォームはストリームアラインドチームをサポートするために「ちょうど良い大きさ」であるべき

> 良いプラットフォームは、Devチームが迅速かつ効果的にイノベーションを行うための標準、テンプレート、API、および実証済みのベストプラクティスを提供する。

**最小限の実行可能なプラットフォーム（TVP）。** 理想的なプラットフォームは、ストリームアラインドチームを加速するために必要なサポートを提供し、過度に複雑または制限的にならない。良いTVPの特徴には以下が含まれる：
- 明確でよく文書化されたAPI
- セルフサービス機能
- 一般的な複雑なタスクの抽象化

**プラットフォームの進化。** 組織が成長し、技術が変化するにつれて、プラットフォームも進化して以下を行うべきである：
- ストリームアラインドチームの新たなニーズに対応する
- 新しい技術とベストプラクティスを取り入れる
- 利用されていない機能を簡素化または削除する

**良いプラットフォームの利点：**
- ストリームアラインドチームの認知負荷の軽減
- 新機能や製品の市場投入までの時間の短縮
- システム全体の一貫性と信頼性の向上

### 7. 変化するニーズに適応するためにチーム構造を継続的に進化させる

> 組織の異なる部分に対して異なるトポロジーと異なるチーム相互作用が必要であり、それらは行っていることや達成しようとしていることに基づいて異なるタイミングで進化する必要がある。

**組織の感知。** チームの効果と相互作用を継続的に監視し、評価して改善の機会を特定する。主要な指標には以下が含まれる：
- 提供速度と品質
- チームの満足度とエンゲージメント
- チーム間の協力の効果

**適応的なチーム構造。** ニーズの変化に応じてチームトポロジーと相互作用モードを調整する準備をする。これには以下が含まれる場合がある：
- チームの分割または統合
- コラボレーションモードとX-as-a-Serviceモードの間のシフト
- エネーブリングチームの作成または解散

**継続的な進化の利点：**
- 市場と技術の変化に対する応答性の向上
- チームの効果と満足度の向上
- 現在の目標と課題に最適化された組織構造

### 8. 運用を開発の高忠実度の感覚入力として扱う

> OpsをDevへの入力として扱うことは、これらのしばしば分離されたグループの役割を根本的に再考することを要求する。

**DevOpsの統合。** 開発と運用の境界を曖昧にすることで、全体的なシステム品質と信頼性を向上させるフィードバックループを作成する。このアプローチには以下が含まれる：
- システムパフォーマンスの共有責任
- 本番環境から開発への継続的なフィードバック
- 伝統的な境界を越えた協力的な問題解決

**Ops-as-Inputの利点：**
- 問題の迅速な特定と解決
- システムの信頼性とパフォーマンスの向上
- 開発と運用チーム間の共感の向上

**実装のための戦略：**
- 堅牢な監視とアラートシステムの実装
- 開発と運用の専門知識を持つクロスファンクショナルチームの設立
- 運用の洞察に基づく迅速なフィードバックと反復のプロセスを作成

### 9. チームサイズのソフトウェアアーキテクチャを設計して所有権を強化する

> 高すぎる認知負荷を必要とするソフトウェアシステムを扱うチームは、効果的に所有したり、安全に進化させたりすることができない。

**チームサイズのコンポーネント。** 大規模なシステムをチームサイズの管理可能なコンポーネントに分解し、チームの認知能力に合わせる。このアプローチは以下をもたらす：
- チームの所有権と責任の向上
- 開発と問題解決の迅速化
- システム全体の保守性の向上

**実装のための戦略：**
- ドメイン駆動設計を使用して自然なシステム境界を特定する
- マイクロサービスアーキテクチャを活用して管理可能なサービスを作成する
- チームの責任を明確に定義されたシステムコンポーネントに合わせる

**チームサイズのアーキテクチャの利点：**
- チームの認知過負荷の軽減
- チーム間の責任とインターフェースの明確化
- システムの進化とスケーリングの向上
- チームの満足度とエンゲージメントの向上

Last updated: August 7, 2024