チームの設計がシステムの設計を決める：Matthew Skelton & Manuel Pais『チームトポロジー』

「マイクロサービスを導入したのに、デプロイのたびに他チームと調整が必要で、リリースが遅い」——この状況の原因は技術選択ではなく、チームの設計にある場合が多い。Matthew Skelton と Manuel Pais の『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』は、組織設計とソフトウェアアーキテクチャを一体として考えるための枠組みを提供する。

1. コンウェイの法則の逆用

「組織が設計するシステムは、組織のコミュニケーション構造のコピーになる」というコンウェイの法則は、ソフトウェアエンジニアリングの世界では古くから知られている。

本書はこの法則を受け身に受け入れるのではなく、「逆コンウェイ作戦」として積極的に活用することを提案する。望むアーキテクチャに合わせてチームを設計することで、アーキテクチャを意図的に誘導できる。

例えば、サービスを独立してデプロイできるようにしたいなら、そのサービスを担当するチームが外部との調整なしにリリースできる自律性を持つ必要がある。組織設計とアーキテクチャ設計は切り離せない。

2. 4種類のチームタイプ

本書の中心は4つのチームタイプの定義だ。

ストリームアラインドチーム: 特定のビジネス機能（ユーザージャーニーや製品ライン）の流れに沿い、価値を継続的に届ける自律したチーム。組織の大半のチームがこの形を目指す。

プラットフォームチーム: ストリームアラインドチームが自律的に動けるよう、インフラや共通ツールをサービスとして提供するチーム。

イネイブリングチーム: 特定の技術領域でストリームアラインドチームの能力を高めることを目的とした、一時的な支援チーム。

コンプリケイテッドサブシステムチーム: 特殊な専門知識が必要なコンポーネント（機械学習モデル、高度な数値計算など）を担当するチーム。

3. 3種類のインタラクションモード

チームのタイプと同様に重要なのが、チーム間のインタラクションモードだ。

コラボレーション: 2チームが密接に協力して新しい技術や解決策を発見するモード。発見段階に有効だが、長期化するとオーバーヘッドが大きい。

X-as-a-Service: あるチームが提供するものを別のチームが利用するモード。依存を減らし、速度を上げる。

ファシリテーション: イネイブリングチームがストリームアラインドチームの能力向上を支援するモード。

インタラクションモードを変えることで、チーム間の依存とコミュニケーションのパターンが変わり、アーキテクチャの変化を促せる。

4. 認知負荷という設計の制約

本書が導入する重要な概念が「認知負荷」だ。

チームが担当するドメインが大きすぎると、誰もすべてを理解できない状態になる。コードの変更が安全かどうかを判断するために広い文脈を調べる必要があり、速度と品質の両方が下がる。

チームのサイズや担当範囲は、「そのチームが無理なく理解し続けられる量」を超えてはならない——この上限を認知負荷として設計に組み込むことが、本書の実践的な提言の核心だ。

DevBookPath のマップで確認する

この本の前後の読書順は、DevBookPath のグラフで確認できます。

👉 DevOps の地図を見る

---

本記事のリンクには Amazon アソシエイト等の広告が含まれる場合があります。リンク経由の購入で運営者に紹介料が支払われることがあります。