チームトポロジー
ソフトウェア開発組織のチーム構造を 4 つの基本型と 3 つのインタラクションモードで設計するフレームワーク
チームトポロジーとは
チームトポロジーは、Matthew Skelton と Manuel Pais が 2019 年に提唱したフレームワークで、ソフトウェア開発組織のチーム構造を 4 つの基本型と 3 つのインタラクションモードで設計する。コンウェイの法則を意図的に活用する。
4 つのチーム型
4 つのチーム型を以下にまとめる。
| チーム型 | 説明 | 例 |
|---|---|---|
| Stream-aligned | ビジネス価値を継続的に届ける | 注文チーム、決済チーム |
| Enabling | 他チームの能力向上を支援 | SRE、セキュリティ |
| Complicated Subsystem | 専門知識が必要な領域を担当 | ML、暗号化 |
| Platform | 内部プラットフォームを提供 | CI/CD、インフラ |
3 つのインタラクションモード
3 つのインタラクションモードを以下にまとめる。
| モード | 説明 |
|---|---|
| Collaboration | 2 チームが密に協力 (一時的) |
| X-as-a-Service | プラットフォームをサービスとして提供 |
| Facilitating | Enabling チームが支援・指導 |
コンウェイの法則
コンウェイの法則を図で示す。
「組織の構造がシステムの構造を決定する」
❌ 意図しないコンウェイの法則:
フロントチーム + バックエンドチーム + DB チーム
→ 3 層アーキテクチャが固定化
✅ 逆コンウェイ戦略:
望ましいアーキテクチャに合わせてチームを設計
注文チーム (フルスタック) → 注文マイクロサービス
決済チーム (フルスタック) → 決済マイクロサービス
認知負荷とチームサイズ
チームが担当するサービスの数と複雑さは、チームの認知負荷の上限内に収める必要がある。認知負荷にはタスク自体の複雑さ (内在的)、ツールやプロセスの複雑さ (外在的)、ドメインの複雑さ (本質的) の 3 種類がある。外在的な認知負荷を Platform チームが吸収し、Stream-aligned チームがドメインの本質的な複雑さに集中できる構造が理想だ。チームサイズは 5〜9 人 (ダンバー数の下位グループ) が目安。
Platform チームの役割
Platform チームは CI/CD パイプライン、IaC テンプレート、監視基盤、セキュリティ基盤などを内部サービスとして提供する。Stream-aligned チームはこれらを X-as-a-Service モードで利用し、ビジネスロジックに集中する。Platform チームの成果物は「使いやすい内部プロダクト」であり、Stream-aligned チームが顧客だ。
チームトポロジーの進化
チーム構造は固定ではなく、組織の成長に合わせて進化させる。初期は 1 チームで全てを担当し、成長に応じて Stream-aligned チームを分割する。
チームトポロジーの関連書籍も参考になる。
この記事は役に立ちましたか?
関連用語
関連する記事
「それ、本に書いてあったよ」が最高の褒め言葉になる職場
チーム全員が技術書を読む文化がある職場では、議論の質とコードの質が変わります。読書文化を持つチームの特徴と、その文化を育てるための具体的な方法を紹介します。
先輩が「あれ読んだ?」と聞いてくる本には理由がある
チームの先輩が繰り返し薦めてくる本は、単なる個人の好みではありません。組織の暗黙知として機能する推薦図書の役割と、その本を読むべき理由を解説します。
チーム開発・マネジメント本ガイド - 技術リーダーが読むべき本
チーム開発、1on1、技術マネジメントを学べる技術書の選び方を紹介。メンバー時代からマネージャーまで、段階別の読書ロードマップを解説します。