チームトポロジー

すべてのチームは、以下の4タイプのどれかに分類される。

1. Stream-aligned Team（ストリームアラインドチーム）

• 組織のメインの価値の流れに沿って動くチーム。ビジネスの特定のドメインやユーザージャーニーに責任を持つ
• 例: 「決済チーム」「オンボーディングチーム」「BtoBセールスチーム」
• 全チームの大多数がこのタイプであるべき

2. Platform Team（プラットフォームチーム）

• Stream-aligned Teamが自律的に動けるように、内部サービスやツールを提供するチーム
• 例: 「CI/CDパイプライン提供」「社内認証基盤」「データ基盤チーム」
• セルフサービスが原則。Platform Teamに依頼しないと進めないなら、設計が悪い

3. Enabling Team（イネーブリングチーム）

• 他のチームの能力向上を支援するチーム。恒久的にサポートするのではなく、一定期間で自走できるようにする
• 例: 「SREの導入支援」「テスト自動化のコーチング」「新技術の導入支援」
• 期間限定で関わり、支援先チームが自走したら離れる

4. Complicated-subsystem Team（コンプリケイテッド・サブシステムチーム）

• 高度な専門知識が必要なコンポーネントを担当するチーム
• 例: 「機械学習モデル」「決済処理エンジン」「動画トランスコーディング」
• このタイプは本当に必要な場合だけ作る。安易に作るとサイロ化する

チーム間の関わり方を3パターンに限定する。

1. Collaboration（コラボレーション）

• 2つのチームが密に連携して一緒に仕事をする
• 新しいことを発見・学習するフェーズで有効
• 注意: 長期間続けると認知負荷が増大する。期間を区切ること

2. X-as-a-Service（サービス提供）

• あるチームが他のチームにサービスとして機能を提供する
• Platform Teamの基本モード。APIやツールとして提供し、直接のやりとりを最小化
• 成熟したインタラクション。ここを目指す

3. Facilitating（ファシリテーション）

• あるチームが他のチームの学習・成長を支援する
• Enabling Teamの基本モード。答えを教えるのではなく、自走力をつけさせる

今のチームを4タイプに当てはめ、インタラクションモードを可視化する。

やり方:

1. 各チームの名前を書き出す
2. それぞれが4タイプのどれに当たるか分類する
3. チーム間のやりとりを線で結び、3つのモードのどれか特定する
4. 問題点を発見する: 依存が多すぎる箇所、タイプが不明確なチーム、コラボレーションが長期化している箇所

よくある発見:

• 「全チームがStream-alignedのつもりだが、実質的にPlatform的な仕事をしているチームがある」
• 「チーム間がすべてCollaborationで、サービス化されているものがない」

理想のチーム構造を描き、段階的に移行する。

設計のガイドライン:

• Stream-aligned Teamが全体の**70〜80%**を占めるようにする
• チームの認知負荷を考慮する（1チームが担当するドメインが広すぎないか）
• Platform Teamは「依頼ベース」ではなく「セルフサービス」で設計する
• 一気に組織変更せず、1チームずつ移行・実験する