フレームワーク活用ガイドひとことで言うと#
ソフトウェア組織のチーム構造をストリームアラインド・プラットフォーム・イネーブリング・コンプリケイテッドサブシステムの4つの基本型と、3つのインタラクションモードで設計するフレームワーク。コンウェイの法則（組織構造がシステム構造を決める）を逆手に取り、望ましいシステムアーキテクチャから組織を逆算する。
押さえておきたい用語#
- ストリームアラインドチーム
- ビジネス価値のフロー（ストリーム）に沿ってエンドツーエンドでサービスを開発・運用する主要チーム。組織の大半がこのタイプになる。
- プラットフォームチーム
- ストリームアラインドチームの認知負荷を下げるために、内部サービス（CI/CD・インフラ・認証基盤など）を提供するチーム。
- イネーブリングチーム
- ストリームアラインドチームが新しい技術やプラクティスを習得するのを一時的に支援するチーム。永続的に介入せず、能力移転が完了したら離れる。
- コンプリケイテッドサブシステムチーム
- 高度な専門知識が必要な特定のサブシステム（数理モデル・ビデオコーデック等）を専門的に開発するチーム。必要な場合のみ設置する。
- 認知負荷
- チームが担当する技術・ドメイン・運用の複雑さの総量。認知負荷が高すぎるとチームのパフォーマンスが低下するため、チーム分割やプラットフォーム化で軽減する。
チームトポロジーパターンの全体像#
こんな悩みに効く#
- チーム間の依存関係が複雑で、リリースのたびに調整コストが膨大
- エンジニアの認知負荷が高すぎて、生産性が落ちている
- マイクロサービス化を進めたいが、チーム構造が追いついていない
基本の使い方#
まず組織が提供する価値の流れ（ストリーム）を洗い出す。ストリームアラインドチームの単位になる。
- ストリーム = 顧客セグメント、プロダクトライン、ビジネスドメイン
- 例: 「消費者向けECストリーム」「法人向けAPIストリーム」「決済ストリーム」
- 各ストリームにエンドツーエンドの責任を持つチームを配置する
- チームサイズは 5〜9名 が目安（認知負荷の上限に合わせる）
認知負荷は「本来的（ドメインの複雑さ）」「外在的（ツールやプロセスの複雑さ）」「関連的（チーム間調整の複雑さ）」の3種に分類される。
- 本来的負荷は減らせないので、外在的負荷と関連的負荷を下げることを目指す
- 「このチームは何を知っていなければいけないか」をリストアップすると認知負荷が可視化できる
- 負荷が高すぎるチームはドメイン分割か、プラットフォームチームによるサポートが必要
- プラットフォーム: CI/CD、監視、インフラ、認証基盤などを「サービスとして」提供し、ストリームチームが自力でデプロイ・運用できる環境を作る
- イネーブリング: 新技術（Kubernetes、機械学習など）の導入時に、ストリームチームに伴走して能力を移転する。永続的な介入はしない
- プラットフォームチームの提供物はAPIやドキュメントで「X-as-a-Service」として利用できること
具体例#
状況: 従業員150名のEC企業。エンジニア40名が「フロントエンド」「バックエンド」「インフラ」の機能別チームに分かれていた。新機能のリリースには3チームの調整が必要で、リリース頻度は月 2回。リリース前の調整会議だけで週 6時間 を消費。
チームトポロジーの再設計
- 機能別チーム → ストリームアラインドチーム（EC購買チーム・検索チーム・物流チーム）に再編
- 各チームにフロント・バック・インフラのスキルを持つメンバーを配置し、E2Eで開発可能に
- CI/CD・監視・認証はプラットフォームチーム（5名）が内部サービスとして提供
- Kubernetes導入時はイネーブリングチーム（2名）が3か月間伴走し、能力を移転
| 指標 | 再編前 | 再編1年後 |
|---|---|---|
| リリース頻度 | 月2回 | 月8回 |
| リリース前の調整時間 | 週6時間 | 週1時間 |
| 本番障害の平均復旧時間 | 3時間 | 45分 |
チーム間の依存が減ったことで、各チームが独立してリリースできるようになった。
状況: 従業員80名のフィンテック企業。エンジニア25名・3チーム体制。各チームがそれぞれ独自にAWS環境を構築・運用しており、インフラの知識が属人化。「本来はプロダクト開発に集中したいのに、インフラの問題対応に時間の 35% を取られている」という声がエンジニアから出ていた。
プラットフォームチームの設置
- インフラに詳しいメンバー3名をプラットフォームチームとして編成
- AWS環境のテンプレート化・CI/CDパイプラインの標準化・監視ダッシュボードの提供
- ストリームチームはTerraformテンプレートを使い、5分で新環境を立ち上げ可能に
- セキュリティパッチの適用もプラットフォームチームが一括管理
エンジニアのインフラ対応時間は 35% → 12% に削減。空いた時間で新機能の開発速度が 40% 向上し、プロダクトのリリースサイクルが 3週間 → 2週間 に短縮された。
状況: 従業員400名のSIer。オンプレミス中心の技術スタックで、クラウドネイティブ（コンテナ・Kubernetes・IaC）への移行が経営目標。しかし、既存の10チームはオンプレの知識で手一杯で、新技術を学ぶ余裕がなかった。外部研修を受けても「現場に戻ると使わない」状態が続いていた。
イネーブリングチームの設計
- クラウドネイティブの経験者3名でイネーブリングチームを編成
- 各ストリームチームに 3か月間 常駐し、実際のプロジェクトの中でKubernetesやCI/CDの導入を伴走
- 3か月後に能力移転チェックを実施し、クリアしたら次のチームに移動
- 移転完了後もSlackチャンネルでQ&A対応は継続
| 指標 | 導入前 | 導入2年後 |
|---|---|---|
| クラウドネイティブ対応チーム | 0/10 | 8/10 |
| コンテナ化済みサービス | 0% | 65% |
| デプロイ頻度（対応チーム平均） | 月1回 | 週2回 |
「研修で学ぶのと、実際のプロジェクトで使うのでは定着度が全然違う」というフィードバックが全チームから出ている。
やりがちな失敗パターン#
- 全チームをストリームアラインドにしようとする — プラットフォームの共通基盤がなければ、各チームが車輪の再発明を繰り返す。ストリーム + プラットフォームのセットで設計する
- イネーブリングチームが永続的に介入する — 能力移転が目的なのに、「便利だから」と常駐し続けると依存が生まれる。3か月などの期限を設ける
- 認知負荷を考慮せずにチームを設計する — チームの担当範囲が広すぎると、メンバーが何に集中すべきかわからなくなる。「このチームが知るべきことは何か」を常に問う
- コンウェイの法則を無視する — チーム構造を変えずにアーキテクチャだけ変えようとしても、結局元の構造に引き戻される。チーム構造とシステム構造はセットで設計する
まとめ#
チームトポロジーは、4つのチームタイプと3つのインタラクションモードで組織構造を設計する実践的なフレームワークになる。核心は「認知負荷を管理すること」であり、ストリームアラインドチームが顧客価値の提供に集中できるよう、プラットフォームとイネーブリングで支援する構造が鍵を握る。