ざっくり感想
慣習的なチーム構造での経験が大半を占める自分にとっては目からウロコな内容だった。慣習的なチーム構造とは、大きな1つのチームがあり、複数の案件に担当者をアサインするというもの。往々にして案件は兼務になっていて、1人あたり2~4の異なるコンテキストを日々行き来する。チームトポロジーはこうしたチーム構造へのアンチテーゼになっている。
チームトポロジーというと、ストリームアラインドやら X-as-a-Service といった概念が先行してしまいがちだったが、もっと普遍的で汎用的なチーム設計の考え方を学べる1冊となっている。
以下に要約と個人的補足を書く。
チームトポロジーとは
典型的な組織図に縛られない「新しいチームの構造」であり、ソフトウェアを構築・運用する上での効果的なアプローチとされている。
4つのチームタイプと3つのインタラクションモードを定義している。
- チームタイプ
- ストリームアラインドチーム (*1)
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
- プラットフォームチーム
- インタラクションモード
- コラボレーション
- X-as-a-Service
- ファシリテーション
役割の異なる4つチームタイプを、3つのインタラクションモードで接続するというコンセプトである。API やシステムの設計と考え方が似ているため、エンジニアにとってイメージしやすいものになっている。
(*1) ストリームとは、ビジネスドメインとして独立可能な業務の流れ（開発、リリース、フィードバック）を指している。
何を解決するのか
本書ではチームトポロジーの最終ゴールをこう述べている。
最終的なゴールは、顧客のニーズに合うソフトウェアをチームがより簡単に構築、実行し、オーナーシップをもてるようにすることである。
チームトポロジーに順じた組織設計により、チームの責任境界が明確になり、認知負荷が軽減され、フローを邪魔する調整やコンテキストスイッチも少なくなる。結果として、ソフトウェアデリバリーを高速化し品質も向上できる。
チームトポロジーを支える思想
チームトポロジーの土台となる思想が2つある。「逆コンウェイ戦略」と「チームファースト思考」である。
逆コンウェイ戦略
チームトポロジーはコンウェイの法則を確たる土台として設計される。
コンウェイの法則:
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう。
コンウェイの法則によれば、組織が先にあるとそれにソフトウェアの構造が依存する。結果として得られるアーキテクチャは本来あるべき姿とは異なっている可能性がある。
この法則を逆手に取ったのが逆コンウェイ戦略である。
あるべきソフトウェアアーキテクチャの青写真を先に描き、それに一致する構造のチームを組織する。すると、コンウェイの法則によって「自然と」望ましいソフトウェアアーキテクチャが得られる。
チームファースト思考
チームファースト思考は、個人プレーよりチームプレーを尊重し、チームとしていかに効果的に働くかを考える。中心的な関心事には、サイズ、寿命、認知負荷などがある。
- チームのサイズ
- 効果的に働けるチームの最大サイズ: 7~9人
- いわゆる Two-pizza チーム
- チームの寿命
- 立ち上げから一体的に働けるようになるまで3ヶ月かかる
- メンバーのアサインし直しは無価値
- チームを長く安定させ仕事が流れ込むようにする
- チームの認知負荷
- チームが扱える認知負荷には限度がある
- 限度を超えるとチームは「ただの個人の集まり」のように振る舞う
- チームが扱うシステムや作業範囲を制約する必要がある
チームトポロジーへの帰着
逆コンウェイ戦略によって、あるべきソフトウェアのアーキテクチャに合わせてチームの構造を決定することで自然な力学のもとで両者のアーキテクチャが一致するようになる。
そうしてチーム構造を決定するときに、チームファースト思考を取り入れながら、チームのサイズ、認知負荷は適切なものかケアしなければならない。
読んでいる最中はチームタイプやインタラクションモードなどキャッチーな概念に目が行っていたが、こうして振り返ると、この2つの考え方こそが普遍的かつ汎用的で、どの時代どの組織でも役立つ「チーム設計の指針」になるのかもしれない。
