骨格と血流の設計　B331『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（マシュー・スケルトン , マニュエル・パイス ）

マシュー・スケルトン (著), マニュエル・パイス (著)
日本能率協会マネジメントセンター (2021/12/1)

価値あるソフトウェアを素早く届けるためには、チームをどのように設計すればよいか。

言い換えると、縦割りの組織であっても、硬直化せずに効率よく業務を前に進めるためには何を考えるべきか。

次の課題はこれだ。

チームトポロジーというモデル

それに対し、本書は明快なモデルを提供してくれる。

背景には、これまで同様安定した、かつ素早いリリースや修正を必須にする変化の激しい社会がある。

これに対しアジャイルのような開発手法が生まれたが、従来の組織とのギャップが様々な課題を生んでいる。特にチェーン型のフローにおける開発と運用の間に生まれる速度とキャパシティのギャップが構造的な軋みを生み出した。

そこからDevOps(開発と運用の壁をなくし、継続的に価値を届ける仕組み。詳しくは次回触れる予定)というムーブメントが起こったが、チームトポロジーもこの流れにある。

チームトポロジーはこういう背景の元、成功しているモダンなソフトウエア開発組織に共通する構造とシステムを抽出したモデル、いわばテンプレートのようなものだ。

ではテンプレートを採用する利点は何か。

今参加している組織ではまさしくこのテンプレートを開発しているわけだが、テンプレートは、複雑な構造を単純化し、認知負荷を抑え、やるべきことを明確にする。

同様に、チームトポロジーはチームの​「認知負荷」を​最適化し、責任範囲を明確に絞り込むことで、​やるべきことを明確にする。

つまりチームの焦点を絞り、ビジネス価値を​迅速かつ継続的に​顧客へ​届ける​ための、​具体的で​実践的な​組織設計図を​示すこと。ここにチームトポロジーの意義が​ある。

チームトポロジーの中心的なアイデアには「コンウェイの法則」「チームファースト」「チームAPI」「4つのチームタイプ」「チームインタラクションモード」「トポロジー進化」「組織的センシング」の8つがあるそうだが、備忘録も兼ねてまずこれらに触れておきたい。

コンウェイの法則と逆コンウェイ戦略

コンウェイの法則とは、「成果物としてのシステムの構造は、その組織のコミュニケーション構造をそのまま反映してしまう」というものだ。

たとえば、部門ごとに縦割りで分断された組織がシステムを作れば、その成果物も分断された境界を持つようなものになり、全体としてぎこちなくなる。血流の悪い組織からは、やはり血流の悪いプロダクトしか生まれず、トラブルが頻発したり、迅速かつ適切な価値提供ができなくなる。

逆に、スムーズに情報が流れる組織からは、血流の良いプロダクトが生まれる。ユーザーにとって自然で使いやすく、変化にも素早く対応できるものになる。

ここで難しいのは、たとえ「こういう理想的なシステムを作りたい」と思っていても、実際にはコンウェイの法則に従って組織構造に引っ張られてしまうという点だ。結果として、意図せずして組織の歪みがそのまま成果物に刻み込まれてしまう。

この状況を打破するためのアイデアが「逆コンウェイ戦略」である。つまり、理想のプロダクトのシステム構造を先に思い描き、それを実現できるように組織やチームを設計するというアプローチだ。

どれだけ優れた技術や方法論を掲げても、成果物は組織の姿を映し出してしまう。だからこそ、理想のシステムを思い描くだけでは不十分で、それを支えるチームの設計にまで踏み込む必要がある。

要するに、コンウェイの法則を乗り越えるには、理想のシステム像 → チーム設計 → チーム間の関係性という流れを意識することが欠かせない。そして、そのための具体的な枠組みを与えてくれるのが、チームトポロジーと言える。

チームファーストとチームAPI

チームトポロジーの根幹にあるのが「チームファースト」という考え方だ。

その根本には実証済みの成功するアーキテクチャーの原則がある。

例えば、「疎結合」。チームは他のチームに強く依存せず自律性をもつこと。フローを分断する縦割りのチェーン型組織だと、チーム間の関係は密にならざるを得ず、大きな認知負荷とコミュニケーションコストやリスクが生まれ、安定したすばやい価値提供の妨げになる。

または、「高凝集性」。チームの内外に明確な責任境界を持ち、その内部は凝集されたつよう関連性を持つ。責任が明確で規模が適正であれば、チームは最適なパフォーマンスを発揮できる。

つまり、チームの自律性を高め、適切な規模で責任範囲を明確にすることで、認知不可を低減し、最適なパフォーマンスを発揮できる状況をつくること。

チームトポロジーの核心はおそらくここにある。

そしてもうひとつ、チームトポロジーの実践に欠かせないのが「チームAPI」という考え方だ。

API（アプリケーション・プログラミング・インターフェース）が、ソフトウェア同士のやり取りを明示的に定義するように、チームAPIはチーム同士の関係性をあらかじめ明示する仕組みだ。

「どちらがオーナーシップ（責任と権利）を持つのか」「その関係の目的は何か」をクリアにしておくことで、無用な調整やすれ違いを減らし、チーム間の協働をスムーズで予測可能なものにできる。

これらはいわば、チームの構造（かたち）とシステム（はたらき）という両輪であり、どちらが欠けていても機能しない。そして多くの組織ではこれらを明確に定義できていないために、認知負荷が膨らみすぎて様々な問題を引き起こしている。

では、チームトポロジーではどの様にそれらをモデル化しているだろうか。

4つの基本的なチームタイプ

チームトポロジーではチームを4つの基本的なチームタイプに分類できるという。（逆にこのタイプに分類できないチームはモダンな開発を進めるうえで問題を抱えている可能性が高いという。）

中心となるのは顧客に直接価値を届ける「顧客価値提供チーム（ストリームアラインド・チーム）」であり、他の3つはその主役を支えるサポーターだ。（4つのチームの日本語名は分かりやすくなるように私がとりあえず設定したものです。）

その役割の第一目的は、顧客価値提供チームの認知負荷を下げること。
これにより価値提供チームはフローを途切れさせず、価値を素早く顧客に届けられる。

簡単にそれらをまとめると

■顧客価値提供チーム （ストリームアラインド・チーム　Stream Aligned Team）

顧客に直接的な価値（製品・サービス）を届ける一連の流れをストリームと呼ぶ。そのストリームに対して責任を持つ、最も基本となるチーム。

安定したフローを確立し、フィードバックに対する俊敏性を備え、プロダクトを進化させる。
他チームへの引き継ぎは最小限（理想はゼロ）とする。

目的を達成するために適宜他チームと連携する。（ただし自律性を維持し、依存しない）

■能力向上支援チーム ​（イネイブリング・チーム　Enabling team）​

他の​チームが​新しい​技術や​スキルを​習得し、​自律的に​開発できるよう支援・促進する​専門家チーム。​

このチームの目的は顧客価値提供チームにソリューションを提供することではなく、顧客価値提供チームの認知負荷を抑えながら自律性を高めるための学習を支援をすることであり、いわば専門のコーチのようなものだ。

■専門技術支援チーム（コンプリケイテッドサブシステム・チーム　 Complicated Subsystem team）

​高度な​専門知識を​必要と​する​複雑な​システム部分を​専門に​扱う​チーム。

このチームの目的は、複雑なサブシステムに絡む顧客価値提供チームの認知負荷を低減することにある。

■共通基盤構築チーム（プラットフォーム・チーム　Platform Team ​）

複数の​チームが​利用する​共通の​基盤​（開発・運用環境など）を​開発・​提供し、​開発効率を​向上させる​チーム。​

目的は、顧客価値提供チームが自律的に仕事を届けられるように基盤を作ることにある。顧客価値提供チームのフィードバックを受け、目的にあったプラットフォームをすばやく提供する。いわば、組織内のチームを対象とした開発運用チームである。

チーム配置の設計指針

これら4タイプをどう配置するかは、組織設計の成否を分ける。

ポイントは

• 役割についての曖昧さを排除する。
• 依存関係をできる限り排除する（他チームにフローが制限されないようにする）
• どの依存関係（知識・タスク・リソース）を取り除き、どの依存関係を受け入れるかを明確にする。
• チームを開発や変更のフロー（ストリーム）に添って配置し最適化する。
• チームの適切なサイズと適切な境界を定義する。
• チーム同士の関係性をシンプルにする。
• そのためにチームに分解する適切で自然な節理面を見つけ出す。

要するに、チームをどう切り分け、どう支援するかを意図的に設計することで、価値提供の流れを滞らせないこと。これがチームトポロジーの実践の第一歩となるだろう。

チームインタラクションモード

ここで主役（ストリームアラインド・チーム）とサポーター（3つの補助的チーム）の役割は明確になった。
しかし、それだけでは十分ではない。実際の成果を大きく左右するのは、チーム同士がどう関わるかという関係性そのものだ。

この定義が曖昧なままでは、不要な軋轢が生まれ、チーム間のコミュニケーションは非効率になる。
そこでチームトポロジーは、チーム間のやり取りを 3つのインタラクションモード として明確に整理している。

それぞれ、有効な場面やメリット・デメリットがあるのでそれらをおさえておく。

■協働（コラボレーション　Collaborating）

2つの​チームが​密接に​連携し、​共通の​目標に​向かって​探求や​試行錯誤を​共に​行う​関わり方。​特に、​新しい​技術の​導入や、​解決策が​不明確な​問題に​取り組む際に​有効。​

メリット

• 迅速な​学習と​発見: チーム間の​知識が​融合し、​革新的な​アイデアや​素早い​問題解決が​生まれやすくなる。​
• 複雑な​問題への​対応: 不​確実性が​高い​領域に​おいて、​両チームの​専門知識を​動員して​最適な​解決策を​模索できる。​
• コンテキストの​共有: 暗黙知や​背景情報が​深く​共有され、​チーム間の​信頼関係が​構築される。​

デメリット・​注意点

• 認知負荷が​高い​: 関わる​メンバーは​両方の​チームの​コンテキストを​理解する​必要が​あり、​精神的な​負担が​大きくなる。​
• コミュニケーションコスト大: 頻繁な​ミーティングや​調整が​必要と​なり、​本来の​タスクに​集中する​時間が​削られが​ち。​
• 境界の​曖昧化: チーム間の​責任境界が​曖昧に​なり、​意思決定の​遅延や​責任の​なすり付け合いに​つながるリスクが​ある。​
• 【重要】期間限定で​行うべき: この​モードは​コストが​非常に​高いため、​目的を​達成したら​速やかに​別の​モード​（X-as-a-Serviceなど）に​移行すべき。​長期化は​チームの​疲弊と​自律性の​喪失を​招く。​

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

ある​チーム​（通常は​プラットフォーム・チームや​複雑な​サブシステム・チーム）が​提供する​機能や​基盤を、​もう​一方の​チームが​明確な​APIなどを​通じて​サービスと​して​利用する​関わり方。​

メリット

• 利用側の​負担軽減: サービスの​利用側は、​その​仕組み​（How）を​理解する​必要が​なく、​使い方​（What）に​集中できる​ため、​開発スピードが​向上する。​
• 提供側の​集中: サービスの​提供側は、​信頼性・​使いやすさ・​ドキュメントの​充実に​集中でき、​プロダクトの​品質を​高められる。​
• チーム間の​独立性: チーム間の​依存関係が​疎に​なり、​お互いの​ペースで​並行して​開発を​進める​ことができる。​

デメリット・​注意点

• 提供側の​責任増大: サービスの​提供側には、​安定稼働、​十分な​ドキュメント、​手厚い​サポートなど、​質の​高い​サービスを​提供する​大きな​責任が​伴う。​
• フィードバックの​欠如: 利用側からの​フィードバックが​提供側に​届きにくくなる​可能性が​ある。​意識的な​改善サイクルを​設ける​必要が​ある。​
• ボトルネック化の​リスク: 提供側の​開発スピードが​遅い​場合や、​障害が​発生した​場合、​それを​利用する​全ての​チームが​影響を​受ける​ボトルネックに​なる​危険性が​ある。​

■学習支援（ファシリテーション　Facilitating）

一方の​チーム​（通常は能力向上支援チーム）が​もう​一方の​チームに​対し、​知識や​スキルを​教え、​自律できるよう手助けする​関わり方。​組織全体の​能力向上を​目的とする。​

メリット

• 組織全体の​能力向上: 支援された​チームの​スキルが​向上し、​特定の​チームへの​依存​（ボトルネック）が​解消される。​
• ​自律性の​促進: チームが​新しい​知識や​技術を​自分たち自身で​扱えるようになり、​開発の​自由度と​スピードが​向上する。​
• ベストプラクティスの​横展開: ある​チームで​得られた​知見や​良い​実践方​法を、​組織全体に​効率的に​広める​ことができる。​

デメリット・​注意点

• 支援側の​高い​スキル要求: 支援する​側には、​専門知識だけでなく、​高い​コーチング能力や​コミュニケーション能力が​求められる。​
• 受け身の​姿勢への​注意: 支援される​側が​受け身のままだと、​スキルが​定着せず、​支援が​終わった​途端に​元に​戻ってしまう。​
• 【重要】一時的な​関わりであるべき: この​モードも​コラボレーション同様、​永続的な​関係では​ない。​​「代わりに​やってあげる」のではなく、​あくまで​「自律できるように​手伝う」のが​目的。​明確な​ゴールと​期間を​設定し、​支援が​終われば​速やかに​離れる​ことが​重要。​

インタラクションモードの設計指針

これらの3つのモードは、単なる「関係性の分類」ではない。
チームタイプの配置という“かたち”に対して、“はたらき”を与えるものだ。

それは、「価値あるソフトウェアを素早く届ける」という動的な目的を、現実に結びつけるための見取り図となりうるだろう。

インタラクションモードを設計する際に重要なのは、

• それが「協働」なのか「提供」なのか「支援」なのか、つまりオーナーシップと責任がどこにあるのかを明確にすること
• そして、その関係をできるだけシンプルに、必要十分な数に抑えること
• 適切なタイミングと適切なコラボレーションの量を決めること。

さらにこれらは固定的なものではなく、課題や成熟度に応じて意図的に選び、適切なタイミングで切り替えていくことが求められる。

トポロジー進化

チームトポロジーの重要な特徴のひとつは、組織の形を固定的に考えない点にある。
チームのタイプやインタラクションモードは、環境や課題の変化に応じて進化させることが前提とされている。

組織は一度設計して終わりではない。
市場や技術、プロダクトの成熟度が変われば、チームの構造や関係性もそれに合わせて変化する必要がある。
その進化のプロセスこそが「トポロジー進化」と呼ばれるものだ。

要するに、チームトポロジーは「静的な組織図」ではなく、環境に応じて姿を変える「動的な設計図」を描こうとする試みだと言える。

組織的センシング

トポロジーを進化させるためには、外部環境や内部の状態を敏感に感じ取る「感覚」が必要になる。
本書ではこれを「組織的センシング」と呼び、組織をただの機械ではなく、生きたシステムとして捉える視点を示している。

組織が今どのような負荷を抱えているのか、どこに摩擦や滞留が生まれているのか、あるいはどんな可能性が芽生えつつあるのか――そうした兆しをいち早く感じ取ることができなければ、トポロジー進化は机上の空論に終わってしまう。

DevOps的な視点で考えると、運用部門は開発部門にとって豊富な情報をもたらす入力センサーとして考えることができる。これをチームトポロジーとして明確に配置し、フィードバックループを確立することができれば、自律操舵が可能な組織となりうる。

これは前々回に触れた、心理的安全性に根ざした「環境を探索する機能」とも響き合う。
そして、それを組織設計の中で明確に定義づけることは、仕事のフレーミング――すなわち「環境の編集」の一形態だと言えるだろう。

描かれた組織図がどう動き、どう成果を生むのか。その実証的な視点を次に読む『LeanとDevOpsの科学』で得られそうな気がしている。