1.2 チームトポロジーと組織設計

概要と動機

人をどうチームに分けるかが、作れるソフトウェアと、その作る速さを決めます。これは比喩ではありません。コンウェイの法則として知られる、ほぼ機械的な帰結です。組織は、自らのコミュニケーション構造を写したシステムを設計します。三つのチームがコンパイラを作れば、三パスのコンパイラができます。決済のロジックがフロントエンドチーム、バックエンドチーム、データベースチームに分かれていれば、決済に関する変更のたびに三者の調整が必要になります。小さな組織ならそれでも対処できます。大きな組織では、組織図の形がエンジニアリング、アーキテクチャ、デリバリー速度、品質に対する支配的な制約になります。だからチーム構造の設計は、人事の後付けではなく、第一級のエンジニアリング活動です。

チームトポロジーは、この設計のための意図的な語彙を与えてくれます。組織再編や人員数を通じて構造が偶然に積み重なるに任せるのではなく、成熟した組織は、チームの種類と相互作用モードを意図して選び、システムとビジネスの進化に合わせてその選択を見直します。目標は、各チームの認知負荷、つまり有効に働くためにチームが頭に入れておかなければならない総量を低く保つことです。そうすればチームは自分の領域をエンドツーエンドで所有し、絶えず他者を待つことなく、価値の安定した流れを届けられます。

大企業と政府機関にとって、この規律は決定的です。大きな組織は自然に、深い階層、長い待ち行列を持つ共有サービス、2日で済む変更を2か月のプロジェクトに変える引き継ぎの連鎖へと広がります。政府ではさらに、調達上の境界、契約者のチーム、義務づけられた職務分掌がオーナーシップを一層細切れにします。明示的なトポロジー設計は、こうした組織がフローを取り戻す方法です。チームを価値の流れに合わせ、認知負荷を下げるプラットフォームを築き、依存関係を隠れて常態化したものではなく、可視で意図的なものにする相互作用パターンを選びます。

主要原則

コンウェイの法則は避けられません。望むソフトウェアエンジニアリングに合わせてチームを設計します(「逆コンウェイ戦略」)。
個人の稼働率の最大化ではなく、チームの認知負荷を最適化します。
価値の一部分をエンドツーエンドで所有するストリームアラインドチームを優先します。
プラットフォームは、ストリームアラインドチームの認知負荷を下げるために存在するのであって、門番になるためではありません。
チーム間の相互作用は明示的で少なくします。コラボレーション、サービスとしての提供(X-as-a-Service)、ファシリテーションのいずれかです。
依存関係を最小化します。チームをまたぐ引き継ぎは、すべて待ち行列でありリスクです。
チーム構造は生きた設計であり、システムとビジネスの変化に合わせて進化させなければなりません。

推奨事項

四つの基本的なチームタイプを使う

チームトポロジーは、ほとんどの必要を満たす四つのチームタイプを定義します。ストリームアラインドチームが既定です。それぞれが特定のプロダクト、サービス、ユーザージャーニーの仕事の連続した流れをエンドツーエンドで所有します。プラットフォームチームは、ストリームアラインドチームがセルフサービスで利用する社内プロダクト(コンピュート、デプロイ、データパイプライン、アイデンティティ)を提供し、その認知負荷を下げます。イネイブリングチームは、ストリームアラインドチームがある能力を築けるようコーチングし、その後は身を引く専門家(テスト、セキュリティ、オブザーバビリティ)です。複雑なサブシステムのチームは、深い専門知識が必要なコンポーネント(価格エンジン、ビデオコーデック、暗号モジュール)を所有します。すべてのチームがその知識を持つのは意味がないからです。ほとんどのチームはストリームアラインドであるべきで、他の三つのタイプはそれらを支えるために存在します。

逆コンウェイ戦略を適用する

ソフトウェアは組織の構造を写すのですから、望むソフトウェアが生まれるようにチームを形づくります。明確な境界を持つ疎結合のサービスが欲しいなら、明確なオーナーシップの境界を持つ疎結合のチームを作ります。独自のスケジュールで出荷できる決済機能が欲しいなら、それを前から後ろまで所有する決済チームを作ります。ヒーロー的な調整でコンウェイの法則と戦ってはいけません。望むアーキテクチャが最も抵抗の少ない道になるよう、チームの境界を引き直します。

認知負荷を明示的に管理する

チームが習得できる量には限りがあります。認知負荷には、ドメインの複雑さ、技術、運用の負担、ステークホルダーの幅が含まれます。チームが無関係なサービスを抱えすぎると、品質も速度も崩れます。だから各チームの責任を、本当に習得できるドメインに限定し、プラットフォームとイネイブリングチームを使って、差別化にならない複雑さをチームから取り除きます。チームは5人から9人ほどに保ちます。意思疎通が容易で、いわばピザ二枚で養えるくらいの小ささです。

相互作用モードを意図して選ぶ

チーム間の相互作用を三つのモードに限定します。コラボレーションは、二つのチームが一定期間行う、密で高帯域の協働です。探索には強力ですがコストが高いので、一時的に保ちます。X-as-a-Serviceは、明確に定義されたインターフェースを持つ、きれいな提供者と利用者の関係で、大規模なプラットフォーム利用に最適です。ファシリテーションは、あるチームが別のチームの学習を助けることで、イネイブリングチームが行うことです。重要なチーム間関係ごとにモードを名指しし、同じ二つのチームの間で長く続くコラボレーションは、その境界が間違った場所にあるというシグナルとして読みます。

横断的な機能の運用モデルを選ぶ

セキュリティ、データ、デザインなどの専門分野は、三つの方法で組織できます。集中型(一つのチームが全員のために所有)、連合型(専門家が兼務で組み込まれ、ギルドを通じて調整)、組み込み型(各ストリームアラインドチーム内に専任の専門家)です。集中型は一貫性と深さを与えますが、ボトルネックになります。組み込み型は速度と文脈を与えますが、不整合と重複のリスクがあります。連合型(多くはハブ・アンド・スポークや実践コミュニティモデル)は両者の中間です。機能ごと、規模ごとに選びます。大きな組織の多くは、これらの専門分野については連合型に落ち着き、標準を定める小さな中央コアを置きます。

インナーソースに投資する

インナーソースは、オープンソースの協働パターンを組織内に持ち込みます。共有の社内リポジトリ、公開された貢献ガイドライン、チームの境界を越えたコードレビュー、明確なメンテナです。あるチームが別のチームのコンポーネントの変更を必要とするとき、チケットを起票して待ち行列で待つ代わりに、変更を直接貢献できます。これは、オーナーシップを解消することなくチーム間の依存を和らげ、大きなエンジニア集団全体に知識と標準を自然に広げます。

トレードオフ: 長所と短所

横断的機能のモデル	長所	短所
集中型(全体で一つのチーム)	一貫性、深い専門性、明確な標準	ボトルネック、待ち行列、プロダクト文脈の喪失
連合型(ハブ・アンド・スポーク、ギルド)	一貫性と速度のバランス。知識を共有	調整の規律が必要。説明責任がぼやけうる
組み込み型(チームごとに専門家)	速く、文脈が豊か、オーナーシップが高い	重複、不整合、大規模では人員確保が難しい

チームタイプ	最も適する場面	使いすぎた場合のリスク
ストリームアラインド	ほとんどのプロダクトとサービスのデリバリー	なし。これが多数を占めるべき
プラットフォーム	共有の認知負荷の削減	象牙の塔の門番になる
イネイブリング	能力を一時的に広げる	永続的な依存になる
複雑なサブシステム	本当に深い専門領域	ありふれた仕事を囲い込む口実になる

繰り返し現れるトレードオフは、自律性と一貫性です。完全に自律したチームは速く動きますが、標準、ツール、セキュリティ体制でばらばらになっていきます。完全な集中管理は一貫性を保ちますが、フローを絞め殺します。良いトポロジー設計は継ぎ目を見つけます。ストリームアラインドなデリバリーには自律性を、本当に一貫していなければならないものには薄い中央標準と整備された道のプラットフォーム(準拠した選択を容易にする、手厚く支援された既定のツール)を与えます。

チームで議論すべき問い

品質が崩れる前に、チームの認知負荷が高すぎることを知らせる具体的なシグナルは何ですか。 「各チームを習得できるドメインに限定する」ことは、言うのは簡単でも、証拠なしには実行しにくいものです。認知負荷は、デリバリーと信頼性が劣化するまで見えないままだからです。測定できる症状に注意してください。チームが所有する無関係なサービスやリポジトリの数、オンボーディングにかかる時間、一人のエンジニアが一週間に切り替えるドメインの数、チームの担当範囲の隅で上昇するインシデント率です。大きな組織では、過負荷のチームが組織図のどの図にも予測されない形で静かにボトルネックになるため、これは重要です。これらの数字と、チーム自身が頭に保てる範囲についての実感を議論に持ち込んでください。シグナルが過負荷を示すなら、取るべき手は、さらなるヒーロー的な働きを求めることではなく、差別化にならない仕事をプラットフォームやイネイブリングチームに移すことです。
ここで組織再編は本当に混乱に見合うものですか。それとも再編中毒を養っていませんか。 逆コンウェイ戦略を適用するために境界を引き直すことは強力ですが、あらゆる再編は、チームが固まるのに必要な安定を壊し、苦労して得たドメイン知識をリセットします。相反する考慮は、現行構造の継続的な調整税と、それを変える一回限りのコストおよび士気への打撃です。企業や政府では、調達上の境界、契約者のチーム、義務づけられた職務分掌が再編をより遅く、高価にするので、ハードルは高くあるべきです。依存による遅延の証拠を持ち込んでください。別のチームを待って止まっているイニシアチブの数と、その期間です。その待ちが構造的で大きいときに再編し、痛みが一時的な場合や、インナーソースの貢献とより明確なインターフェースのほうが安く解決できる場合には、組み替えを控えます。
セキュリティ、データ、デザインについて、組み込み型、連合型、集中型の間を移るきっかけとなる出来事は何ですか。 本章の推奨は機能ごと、規模ごとに選ぶことですが、より難しい規律は、どんな成長やリスクがその選択を見直す契機になるかをあらかじめ決めておくことです。50人のエンジニアに合うモデルは、500人ではボトルネックにも一貫性の災いにもなりえます。企業や政府機関は特に、小さな中央コアが常に保持する標準に名前を付ける必要があります。機能ごとの現在の待ち時間と一貫性のギャップを持ち込んでください。数週間のレビュー待ち行列を抱える中央セキュリティチームは連合型にするシグナルであり、互換性のないデータモデルを作り出す組み込み専門家は、中央の標準コアを加えるシグナルです。待ち行列の長さの閾値や監査指摘などのトリガーを今決めておけば、変更は危機的な反応ではなく計画的な進化になります。答えは、整備された道と推進役への投資と、中央ハブへの投資のどちらに振るかを決めます。
プラットフォームチームが本当に認知負荷を下げているのか、静かに門番になっているのかを、どうやって知りますか。 プラットフォームは、セルフサービスを通じて準拠した信頼できる選択を容易にするために存在しますが、同じチームが、ツールを強制し、あらゆる依頼を手作業でレビューし、取り除くはずだった摩擦を足す方向へ流されることがあります。大きな組織では、この違いが、プラットフォーム投資が元を取るか、あらゆるストリームアラインドチームが並んで待つ中央のボトルネックになるかを決めます。相反する考慮は、一貫性と統制と、利用者の自律性とフローです。利用者が納得する証拠を持ち込んでください。ストリームアラインドチームがチケットを起票せずに新しい環境やパイプラインをセルフサービスで用意するのにかかる時間、セルフサービス操作と人手を介する操作の比率、そして強制されたチームではなく自ら選んだチームで測ったプラットフォームの採用です。企業や政府では、プラットフォームが手作業のゲートではなく、監査とコンプライアンスの証拠を自動的に生成するよう求めてください。職務分掌の規則を人間のレビュアーを挟むことで満たすプラットフォームは、それが解消するために資金を得たボトルネックを作り直しているからです。
チーム間の関係のうち、永続的なコラボレーションに落ち着いてしまったものはどれで、それぞれをきれいなサービスインターフェースや引き直された境界に変えるには何が必要ですか。コラボレーションモードは、密で一時的であることを意図しており、終わらないペア関係は、たいていオーナーシップが間違った場所にある、あるいは二つのチーム間のインターフェースが明示されたことがないというシグナルです。名前のない常設のコラボレーションは調整コストが隠れる場所なので、規模が大きいと重要になります。それはどの組織図にも現れませんが、二つのチームが触れるあらゆる変更に税を課します。相反する考慮は、近くにいることの探索価値と、関係を定義されたインターフェースを持つX-as-a-Serviceの契約に変える、あるいは責任を一つのチームにまとめることで得られるフローです。四半期以上続けてコラボレーションしているチームの組のリスト、ここ数か月で両チームを必要とした変更、そして両者間の安定したインターフェースを書き下せるかどうかを持ち込んでください。契約者の境界や調達ロットが引き継ぎを何年も固定しうる企業や政府では、インターフェースとインナーソースの貢献で変換できる関係と、契約上固定され明示的な依存として管理しなければならない関係とを区別してください。
イネイブリングチームがあるチームの能力構築を助けるとき、永続的な依存になるのではなく、成功して身を引ける状態になったことをどう知りますか。イネイブリングチームは、ストリームアラインドチームがテスト、セキュリティ、オブザーバビリティを習得するようコーチングし、その後は次へ移ることが想定されています。明確な終了条件がなければ、コーチング関係は、ストリームアラインドチームが決して吸収しない常設サービスに固まります。大きな組織では、これが、能力を数十のチームに広げることと、毎年悪化する形で新たな共有ボトルネックを作ることとの違いです。相反する考慮は、専門家チームが提供する深さと一貫性と、ストリームアラインドチームに築こうとしているエンドツーエンドの自律性です。能力移転の証拠を持ち込んでください。受け手のチームがイネイブリングチームなしで仕事をこなせるようになったか、固定のイネイブリング集団が同時に何チームに関与しているか、各エンゲージメントが予定された引き継ぎを過ぎてどれだけ続いているか。希少な専門スキルが単一の中央チームや単一の契約の背後にあるかもしれない企業や政府では、能力移転と推進役にどう資金を出すかをあらかじめ決めてください。そうすれば専門性は、あらゆる監査とリリースが待たなければならない待ち行列の後ろに閉じ込められたままにならず、デリバリーチームに拡散します。

セクター別の視点

スタートアップ。 少数のエンジニアと短いランウェイのもとでは、適切なトポロジーは、プロダクト全体を所有する単一のストリームアラインドチームであり、必要になる前にサイロを作らないという規律が求められます。門番になってしまう単独の「DevOps」や「QA」の担当者を採用しないでください。それらのスキルは、組み込みの能力として一つのチームに折り込みます。組織をフラットに保って、コンウェイの法則を味方につけてください。そうすればアーキテクチャは、チームと同じくらいシンプルで変更しやすいままです。

小規模事業者。 専任のプラットフォームやイネイブリングチームは置けないので、プラットフォームを買ってください。マネージドクラウドサービス、ホスト型パイプライン、既製のセキュリティツールを使って、差別化にならない認知負荷を、一つか二つのチームから取り除きます。セキュリティやデータなどの横断的な関心事は、築く機能ではなく、設定して使うものとして位置づけます。独自のオーナーシップは、本当に差別化になる複雑なサブシステムだけに取っておき、残りはベンダーに担わせます。

大企業。 規模が大きくなると問題は多数のチームにまたがる調整コストなので、トポロジーを明示的で統治された設計にします。四つのチームタイプの共通の分類、名前の付いた相互作用モード、整備された道のプラットフォーム、そしてチーム間の待ち行列を和らげるインナーソースです。依存による遅延とチームの認知負荷をポートフォリオの指標として追跡し、組織再編を、年次の反射ではなく、高いハードルを課した意図的な進化として行います。薄い中央コアが一貫している必要のある標準を保持し、ストリームアラインドチームはデリバリーに関する自律性を保ちます。

政府。 調達規則、契約者の境界、義務づけられた職務分掌がオーナーシップを細切れにするので、人手による引き継ぎではなく、ツールと明確なインターフェースでそれらの制約を満たすようにトポロジーを設計してください。小さな標準コアと、監査とコンプライアンスの証拠を自動的に生成するプラットフォームを備えた連合型モデルを選び、職務分掌がレビュー待ち行列ではなくパイプラインによって強制されるようにします。チームの境界、相互作用モード、運用モデルを公開で文書化し、構造が監査人、監督機関、資金を出す市民に透明であるようにします。

事例

スタートアップ。 10人のスタートアップには、プロダクト全体をエンドツーエンドで所有する単一のストリームアラインドチームがあり、その規模にはまさに適しています。引き継ぎも調整税もなく、全員が同じ文脈を共有しています。問題が始まるのは、専任の「DevOps担当」と別の「QA担当」を採用して、意図せず機能別サイロを作り直し、すべてのリリースが二人の個人を待つことになったときです。チームは、それらの採用を、仕事が通過すべきゲートではなく、一つのチーム内の組み込みのプラットフォームとテストの能力として扱うことで軌道修正します。この規模では、最も安いトポロジーは、全員を一つの流れの中に保つものです。

大企業。 大手小売業者のチェックアウトは、フロントエンド、バックエンド、フルフィルメントのロジックが三つの機能別チームに分かれていたため、変更のたびに三つのバックログを通る必要があり、変更が遅くなっていました。逆コンウェイ戦略を適用して、顧客ジャーニー(「閲覧」「カートとチェックアウト」「購入後」)を軸にしたストリームアラインドチームに再編し、それぞれが自分の領域を前から後ろまで所有し、デプロイとオブザーバビリティをサービスとして提供するプラットフォームチームが支えました。かつて四半期かかったチェックアウトの変更が数日で出荷されるようになりました。以前はチームをまたいでいた調整が、一つのチーム内で行われるようになったからです。

政府。 ある政府の税務当局では、中央セキュリティチームがあらゆるリリースをレビューし、数週間の待ち行列が重要な修正を遅らせていました。彼らは連合型モデルに移行しました。小さな中央セキュリティ機能が標準を定め、事前承認された自動スキャン付きパイプラインの「整備された道」を提供し、各デリバリーチームに兼務で組み込まれたセキュリティ推進役が日々の判断を担いました。プラットフォームがコンプライアンスの証拠を自動的に生成しました。義務づけられた職務分掌の要件は引き続き満たされましたが、人間のボトルネックではなく、ツールと明確なインターフェースによってであり、リリースのリードタイムを劇的に短縮しながら、監査への備えも向上しました。

ビジネスケース: 動機、ROI、TCO

まずいチーム設計の代償は調整のオーバーヘッドで支払われ、そのオーバーヘッドは、典型的な変更のために同期しなければならないチームの数に対して、線形より速く増えます。引き継ぎはすべて、待ち時間のある待ち行列であり、情報を失う文脈の移転であり、誤解を生む新たな機会です。日常的な変更が三つのチームにロードマップの擦り合わせを求めるとき、本当のコストは彼らの仕事の合計ではなく、スケジューリング、待ち、手戻りというはるかに大きなコストです。ほとんどの変更が一つのチームのオーナーシップに収まるように境界を引き直せば、そのオーバーヘッドは単純に消えます。

導入コストは現実です。組織再編は混乱を招き、プラットフォームやインナーソースの実践を築くには、見返りが来る前に先行投資が必要です。しかし導入しないコストは複利で膨らみます。構造が偶然に積み重なるに任せた組織は、引き継ぎの連鎖、四半期単位の待ち行列を抱える共有ボトルネックチーム、組織図に化石化したアーキテクチャを溜め込みます。経営層にこれを訴えるには、依存による遅延を測定してください。別のチームを待って止まっている進行中のイニシアチブの数と、その期間です。プラットフォームとトポロジーへの投資は、通常、その待ちをフローに変えることで元が取れ、人員を増やさずにリードタイムの短縮とスループットの向上として現れます。

アンチパターンと落とし穴

コンウェイの法則を無視する: 組織構造が実現できないアーキテクチャを設計すること。
機能別サイロ: 変更のたびに調整が必要な、別々のフロントエンド、バックエンド、QA、運用チーム。
共有サービスのボトルネック: すべてのプロジェクトが並んで待たなければならない中央チーム。
門番としてのプラットフォーム: 仕えるのではなく強制し、摩擦を取り除くどころか足してしまうプラットフォームチーム。
認知的な過負荷: 習得できない、広がった無関係なシステムを所有するチーム。
永続的な「コラボレーション」: 二つのチームが永遠に絡み合い、境界の置き間違いを示していること。
再編中毒: 絶えず組み替え、チームが固まるのに必要な安定を壊すこと。

成熟度モデル

レベル1、開始。 チームは偶然、人員数、レガシーな階層で形成されます。チームタイプや相互作用モードに名前を付ける人はいません。機能別サイロと共有サービスのボトルネックがあちこちにあり、依存関係はリリースを止めるまで隠れています。
レベル2、発展。 一部のストリームアラインドチームが存在し、最初のプラットフォームまたはインナーソースの取り組みが現れますが、パターンの適用にはむらがあります。いくつかのチームは自分の領域をエンドツーエンドで所有する一方、他は中央の機能の後ろに並んでおり、認知負荷は管理されるのではなく、逸話として語られます。
レベル3、標準化。 四つのチームタイプと三つの相互作用モードが文書化され、組織全体で意図して使われています。プラットフォームとインナーソースがチーム間の依存を和らげ、セキュリティ、データ、デザインの運用モデルが選ばれて書き留められ、新しいチームは即興ではなくこれらの標準に沿って編成されます。
レベル4、管理。 トポロジーはベースラインに対して測定され、制御されます。チームは認知負荷、依存による遅延(別のチームを待って止まっているイニシアチブとその期間)、プラットフォームのセルフサービス比率と採用、相互作用モードの継続期間、リードタイムや変更頻度などのデリバリーフローの指標を追跡します。閾値が行動を引き起こします。たとえば、待ち行列の長さがある機能を連合型にさせたり、常設のコラボレーションが境界の置き間違いを知らせたりするので、決定は意見ではなく証拠に基づきます。
レベル5、オーケストレーション。 チーム設計は継続的に改善され、アーキテクチャ、プロダクト、リスク計画と統合されています。組織はシステムとビジネスの進化に合わせて境界を再形成し、能力が移転されたらイネイブリングのエンゲージメントを終了し、認知負荷が移ればプラットフォーム投資を再配分します。速いフローは、一度きりの再編ではなく、適応する常設の性質として保たれます。

議論のためのアイデア

典型的な変更のために、いくつのチームが調整しなければならず、それはなぜですか。
私たちのチームのうち、認知負荷を抱えすぎているのはどれで、プラットフォームは何を肩代わりできますか。
境界を引き直す代わりにコンウェイの法則と戦っているのは、どこですか。
私たちのプラットフォームチームは、ストリームアラインドチームに仕えていますか、それとも門番になっていますか。
セキュリティ、データ、デザインは、今の私たちにとって集中型、連合型、組み込み型のどれがよいですか。
「一時的」だったはずのコラボレーションのうち、静かに永続的な依存になったものはどれですか。

要点

組織構造がアーキテクチャとデリバリー速度を決めます。意図して設計してください。
四つのチームタイプを使い、ストリームアラインドを既定とし、残りはその支えとします。
逆コンウェイ戦略を適用して、望むアーキテクチャを楽な道にします。
認知負荷を管理し、各チームを習得できるドメインに限定します。
チーム間の相互作用モードを限定して名前を付け、長引く依存は境界の欠陥として扱います。
横断的機能には、規模に応じて集中型、連合型、組み込み型のモデルを選び、インナーソースで待ち行列を和らげます。

参考文献とさらなる読み物

Matthew Skelton and Manuel Pais, “Team Topologies: Organising Business and Technology Teams for Fast Flow”
Melvin Conway, “How Do Committees Invent?” (the origin of Conway’s Law)
Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate”
Will Larson, “An Elegant Puzzle: Systems of Engineering Management”
Sam Newman, “Building Microservices” (on aligning services to teams)
Danese Cooper and Klaas-Jan Stol, “Adopting InnerSource,” and the InnerSource Commons patterns
Frederick Brooks, “The Mythical Man-Month” (communication overhead)