『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』マシュー・スケルトン（著）、マニュエル・パイス（著） を読んだので、書籍から得た知見をご紹介します。

背景 逆コンウェイの法則を実現させたい

Ryuzee さんの訳者ということで気になっていた『チームトポロジー』、読了後の評判や感想をネット上で見かけて、逆コンウェイの法則を実現させる上での必読書と感じて、この本を読みました。

以下、印象に残った箇所の引用とメモです。

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

Chapter3 チームファースト思考

適切な境界が認知負荷を下げる

チームの認知負荷に合うように責任範囲を制限する

近年のソフトウェアデリバリーで摩擦を増やす要因のうち最も認知されていないものの1つが、チームが扱うコードベースのサイズと複雑さが増大の一途をたどっていることである。これは、チームに際限のない認知負荷をもたらす。

📝 認知負荷という問題。

チームが扱うドメインの種類を制限する

「チームにとって適切なドメインの数、種類は？」という問いに対する決定的な答えはない。ドメインは固定されたものではなく、チームの認知容量も変わっていく。ただ相対的ドメイン複雑度を用いて推測すれば、チームの責任の協会を決定するのに役立つ。

第1の経験則は、それぞれのドメインを単一のチームに割り当てることだ。ドメインが1チームに対して大きすぎたら、チームの責任範囲をドメインのなかで分割するのではなく、ドメインをサブドメインに分割し、サブドメインごとにチームを割り当てられないか検討しよう。

第2の経験則は、7人から9人という黄金則に則った単一のチームが、シンプルなドメインを2つか3つ扱うことだ。そのようなドメインは、極めて手続き的なことが多く、機械的に反応できるため、ドメイン間のコンテキストスイッチのコストも容認しやすい。

第3の経験則は、複雑なドメインを割り当てられたチームには、それ以外のドメインをたとえシンプルなものであっても割り当てるべきではないということだ。これは仕事のフローを妨害するコストの高さ（複雑な問題解決には時間と集中が必要）と、優先順位付け（シンプルで予測可能な問題はすぐ対応することが多く、結果としてビジネスにとっていちばん重要な複雑な問題に取り組むのが遅れる）のためである。

最後の経験則は、チームに2つの煩雑なドメインを割り当てるのを避けるということだ。

「チームAPI」を設計して、チームインタラクションを促す

「チームAPI」をコード、ドキュメント、ユーザーエクスペリエンスを含めて定義する

安定して長続きするチームが、ソフトウェアシステムの特定の部分のオーナーシップを持つことで、安定したチームAPIを構築できる。チームの周りを囲むAPIだ。
APIとは、プログラムがソフトウェアとやりとりするための方法を記述した仕様のことだ。ここで私たちはチームとのやりとりにAPIのアイデアを拡張することにした。

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

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

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

CASE STUDY Amazonの厳格に独立したサービスチーム

CEO ジェフ・ベゾスの厳命により、Amazon のサービスやアプリケーションを担当するチームは、真に独立していることが求められた。こうすることで、コンウェイの法則によって、チーム群の単位でも独立していることが保証されていた。

📝 コンウェイの法則の成功例

Amazon は、ソフトウェアのチームのサイズをピザ2枚で足りるサイズに制限していることでも知られている。

📝 Two pizza rule 🍕🍕

2002年頃、ジェフ・ベゾスは、Amazon のエンジニアリング部門に、チーム編成について以下のような明確なルールを設定した。

・それぞれのチームは、担当するサービスの開発と運用に完全な責任を負う（サービスは、Amazon.com や AWS 製品の単一または複数の機能とみなすことができる）
・それぞれのサービスは、内部向け外部向けに関わらず API を通じて提供される。チームは、他のチームのサービスやアーキテクチャー、利用技術に干渉してはいけないし、いかなる前提も設定してはいけない

📝 AWSがモデルケース

Amazon の CTO であるワーナー・ヴォゲルスが語ったことで有名になった「you build it, you run it （自分で作ったら、自分で運用する）」の原則に従って、サービスチーム（内部での呼称）は職能横断型で、サービスの管理、仕様決定、設計、開発、テスト、運用（インフラストラクチャーのプロビジョニング、顧客サポートを含む）を自分で行える能力を持っていなければいけない。

ストリームアラインドチームが備える能力

一般的に、ストリームアラインドチームは初期の要求探索の段階から本番運用まで作業を進めるのに必要な能力一式を備えている必要がある。そのような能力には以下のようなものが含まれる（これに限らない）。

・アプリケーションセキュリティ
・事業成長性分析と運用継続性分析
・設計とアーキテクチャー
・開発とコーディング
・インフラストラクチャーと運用性
・メトリクスとモニタリング
・プロダクトマネジメントとオーナーシップ
・テストとQA
・ユーザーエクスペリエンス（UX）

📝 ストリームアラインドチームのスキル一覧

プラットフォームチーム

プラットフォームチームの目的は、ストリームアラインドチームが自律的に仕事を届けられるようにすることである。ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。プラットフォームチームは、内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。

プラットフォームチームの知識は、長大な利用マニュアルではなく、セルフサービスの形でウェブポータルやプログラマブルなAPIとして提供され、ストリームアラインドチームは簡単に活用できる。「利用容易性」は、プラットフォーム適用の基礎となる。また同時に、顧客が外部であるか内部であるかに関わらず、プラットフォームチームは、提供するサービスが目的に一致し、信頼性が高く、使いやすいプロダクトになるように扱う必要があることを示している。

良いプラットフォームは「ちょうどよい大きさ」

■最低限のプラットフォーム

どんな場合でも、最低限のプラットフォーム(TVP) を目指すべきだ。プラットフォームが制約になるのは避けなければいけない。アラン・ケリーは「ソフトウェア開発者はプラットフォームを作るのを好む。プロダクトマネジメントからの確かな情報もなしに、必要以上に大きなプラットフォームを開発してしまう」と言っている。TVPは、プラットフォームを小さく保つことと、プラットフォームが開発チームのソフトウェアデリバリーをシンプルにし加速できることの絶妙なバランスで成り立っている。

※ TVP は Thinnest Viable Platform の頭文字を取ったもの

📝 TVP

■一貫性と説得力を併せ持つ適切なプラットフォーム

プラットフォームの開発で陥ることが極めて多い落とし穴は、チームのニーズと切り離してしまうことだ。プラットフォームチームは、ユーザーエクスペリエンス (UX)、 とりわけデベロッパーエクスペリエンス (DevEx) にフォーカスする必要がある。

📝 UX, DexEx にフォーカス

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

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

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

■X-as-a-Service : 責任が明確でデリバリーは予測可能になるが、優れたプロダクトマネジメントが必要

📝 プラットフォームを構築後、初期導入PJでは、ストリームアラインドチームとこのモードで開発を進めるのがよさそう。

Chapter9 次世代デジタル運用モデル

4つのチームタイプと3つのインタラクションモード

ソフトウェアシステムの開発と運用に必要なのは、4つのチームタイプだけだ。これ以外のチームタイプは、組織にとって大きな害を及ぼす場合がある。
4つの基本的なチームタイプは以下のとおりだ。

・ストリームアラインドチーム : ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ

・プラットフォームチーム : 下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす

・イネイブリングチーム : 転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける

・コンプリケイテッド・サブシステムチーム : 普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される

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

速いフローで効果的なソフトウェアのデリバリーを行うのに必要なのは、これらのチームの組み合わせだけだ。だが、効果的なソフトウェアデリバリーとは何なのかを理解し、それを実現していくには、4つの基本的なチームタイプ間のインタラクションモードも極めて重要である。

・コラボレーションモード : 特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある

・X-as-a-Service モード : あるチームが、別のチームが提供する何かを利用する (API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている

・ファシリテーションモード : あるチーム (通常はイネイブリングチーム) が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする

これらの3つのインタラクションモードから外れるチーム間のインタラクションは無駄であり、チームの責任境界や目的が適切に割り当てられていないことを意味する。

📝 3つのインタラクションモード

以上、チームトポロジーの組織論を実践していきたい、現場からお送りしました。