チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計

https://www.amazon.co.jp/dp/B09MS8BML8/

1回読んだけど再度読んでみる。2022年4月で自チームの組織改編が携わって、その際に参考にした本。この本のおかげでEnablingチームが立ち上がって、プロダクト開発とは別軸に改善をしたり開発チームとコラボしたりできるようになった。もうちょっと深堀りしてみたいので読む。

事前インプット

まえがき

ソフトウェア開発には「システム設計」と「組織設計」が重要で、コンウェイの法則を踏まえて開発組織の設計に取り組む本。明確な責任と境界を持つチームにすることで認知負荷を減らしていこう、というのが肝。無限の認知負荷というのをどこかでみたな。

はじめに

PART1: コンウェイの法則の掘り下げ
PART2: 実績のあるチームのパターン
PART3: 組織設計を進化させる方法

実際のコンテキストに合わせたChapterの流れについての説明と、あとは本書に影響を与えているものについての説明。

PART1 デリバリーの手段としてのチーム

コミュニケーション構造と組織図がかけ離れている問題。組織図=やるべき仕事ではなくて疎結合なチームがコラボレーションするのがいい言っている。認知不可を下げるという意味合いが大きいのかな。

コンウェイの法則の説明。システムを設計する組織は、その穀蔵をそっくりまねた構造の設計を生みだしてしまう というフレーズが有名だけど、厳密には組織図ではなくて組織のコミュニケーションパスと得られるソフトウェアアーキテクチャに強い総関係があるとのこと。逆コンウェイ戦略はシステムに反映したいアーキテクチャに合うようなチーム構造にする という考え。「LeanとDevOpsの科学」でも逆コンウェイ戦略の重要さが書いているとな！

あとは認知負荷の話。マイクロサービスアーキテクチャも詳しく理解しているわけではないけど、認知負荷の軽減を目的にしているはずなので、その辺にも繋がりそう。PART1はコンウェイの法則の話とチームの認知負荷を制限し、チーム間のインタラクションを促進したほうがいい、という話だった。全員がすべての人とコミュニケーションする必要はないというのも印象的。チームは小さく長続きさせることで信頼感を生むことが大事。

PART2 フローを機能させるチームトポロジー

まず考え抜こうという話。現在のコンテキストに合っていないその場しのぎになってしまいアンチパターンを踏んでしまう。うん。

有名な4つの基本的なチームの話。

ストリームアラインドチーム
イネイブリングチーム
コンプリケイテッド・サブシステムチーム
プラットフォームチーム

運用チームは存在しない。運用もサポートもストリームに沿って実施して、別のチームに引き継ぐことはしないと。ストリームアラインドチームがDevOpsをまるっと体現するチームなのか。

ストリームアラインドチーム

根幹のチームで、その他チームは負荷を減らす役割。you build it, you run it （自分で作ったら自分で運用する）。SREチームはストリームアラインドチームの一種なのか。プラットフォームチームかと思ってたけど違った。

「ストリーム」は継続的なフローであることを強調してる。開発の中心で継続的にDevOpsをやっていくチーム。他チームへの引き継ぎも理想はゼロということでまぁ全部をやるチームということか。サービスが大きくなるとドメインを分割して認知負荷を上げないor下げるようにクロスファンクショナルなチームを複数作っていくイメージかなー。

イネイブリングチーム

テクニカルドメインのスペシャリストから成るチームでストリームアラインドチームの能力を補う。テクニカルコンサルチームとも。

ストリームアラインドチームのニーズを探索する、新しい技術について先んじる、組織内の情報共有を促すなど。目的は新しい技術、アプローチなどの能力を高めるために存在する。のかー。

育成みたいな言葉は出てこなかった。

コンプリケイテッド・サブシステムチーム

ほとんどのチームメンバーがその分野のスペシリストでなければ構成が難しいチーム。ストリームアラインドチームの認知負荷を減らす役割。

プラットフォームチーム

ストリームアラインドチームが自律的に仕事を届けられるようにする役割。下位のサービスを開発する必要性をなくして認知負荷を下げる。

サイロ化を防ぐ
「運用」チームは不適切
職能横断型チーム
認知負荷の低減

ほとんどのチームをストリームアラインドチームに
インフラチームをプラットフォームチームに
コンポーネントチーム(職能チーム)は解散して別のチームに
アーキテクトはイネイブリングとして、あくまで実装チームが手動する

Part3 イノベーションと高速なデリバリーのためにチームインタラクションを進化させる

コラボレーションモード(インタラクションモード)
- コラボレーション
- X-as-a-Service
- ファシリテーション
チームのインタラクションの責任の不明瞭な定義が軋轢や非効率の原因になっている
責任を明確にしつつチーム同士をうまくコラボレートさせる

コラボレーション

他のチームと協力して密接に働く
長時間使用することは最善の選択ではないかもしれない
コンプリケイテッド・サブシステムチームとストリームアラインドチームの共同作業など

X-as-a-Service

最小限のコラボレーションで何かを利用または提供すること
責任が明確だが優れたプロダクトマネジメントが必要
サービス境界が正しく選択され、優れたサービスマネジメントを実践している場合にうまく機能する

ファシリテーション

能力のギャップを感知し縮小する
ファシリテーションまたはコーチしてもらう
イネイブリングチームの主な職務遂行モード

最適なチームインタラクションモードを選択する

組織的センシング

コラボレーションにはコストがかかる、価値があるものにしよう
チームトポロジーは探索し進化させていく
チームの目的や状況に合わせて各所それぞれのタイミングで進化させよ

まとめ

とても良い本だった。こちらを参考にして自社でも Enabling チームを作って活動してみたし、他社でもチームトポロジーを参考にチーム編成されていっている事例もよく見るようになった。組織を作る方々で読み合わせて共通言語を作ったりするのに活用できるなと思った。ただ、論理と実装はかけ離れているので、守破離を大事にまずは型に当てはめてチーム編成し、探索しながら進化させていくというのがよいのだろうなと思った。

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計