# チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
## 2022/02/17 保田
## 書籍情報
[チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計](https://www.amazon.co.jp/dp/4820729632)
280ページ

## どんな本？
組織設計によってシステム開発・運用のフロー向上を目指すための要点などをパターン化したカタログ本
フロー向上につながる背景やアンチパターンなども含まれている

## 用語
- チームトポロジー
システム開発・運用のフロー向上を実現するための組織設計モデル
無理やり一言で表すのであれば、逆コンウェイのデザインパターン

- バリューストリーム
システム開発・運用によって価値を生み出す流れのこと

- コンウェイの法則(オライリーからコピペ)
システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す

## 章立てと概要
- PART I デリバリーの手段としてのチーム
組織がシステム設計に対して与える制約
チームの定義
- Chapter1 組織図の問題
- Chapter2 コンウェイの法則が重要な理由
- Chapter3 チームファースト思考

- PART II フローを機能させるチームトポロジー
チームのパターン・タイプ
チームタイプごとの配置
- Chapter4 静的なチームトポロジーチームのアンチパターン
- Chapter5 4つの基本的なチームタイプ
- Chapter6 チームファーストな境界を決める

- PART III イノベーションと高速なデリバリーのため にチームインタラクションを進化させる
組織設計を進化させる方法
チーム間のインタラクションモード
- Chapter7 チームインタラクションモード
- Chapter8 組織的センシングでチーム構造を進化させる
- Chapter9 まとめ:次世代デジタル運用モデル

## 参考にすべきトピック

### チームタイプとインタラクションモード
chapter9では下記のチームタイプ・インタラクションモードから外れるものは害や無駄とまで書かれるレベル。

#### 4つのチームタイプ
現代のソフトウェア開発チームを4種類に分類したもの
タイプ毎に期待されるふるまいや成果物が異なる
実状として責務が未分化/混在しているケースなどもある

- ストリームアラインドチーム
要求探索(インサイト)～運用までを実現するチーム
他チームとのコミュニケーションが多くなりやすい
サービス・システム開発のメインにあたるイメージ

- イネイブリングチーム
ストリームアラインドチームが持っていない能力を獲得するのを助けるチーム
ストリームアラインドチームが特定の能力を必要とする前に身に着けている
新しいアプローチやツールの情報共有などを行い、ストリームアラインドチームが自立的に動けるようにする

- コンプリケイテッド・サブシステムチーム
専門知識が必要なサブシステムの開発・保守を行うチーム
全てのストリームアラインドチームに常に配置できないようなスペシャリストのチーム
共有コンポーネントかどうかではなく、他チームが担った場合の認知負荷が高ければ配置されるチーム
数理モデルの作成や顔認識エンジンの開発などのイメージ

- プラットフォームチーム
ストリームアラインドチーム向けに下位レイヤーのラッパーサービスなどを提供するチーム
どこまでをプラットフォームと見るかの範囲は捉え方次第

#### 3つのインタラクションモード
チーム間のコミュニケーション方法
それぞれに強み/弱み/制約があり、場面や状況に応じて使いわけが必要になる
- コラボレーション
他のチームと密接に協力して作業
- 強み
イノベーション・探索が早め
引継ぎが少な目
- 弱み
責任が分散する
チーム間での共有が必要=認知負荷が高まる
コラボレーション中は生産量が下がる
- 制約
コラボレーションは1:1まで

- X as a Service
最小限のコラボレーションで何かを利用/提供
- 強み
- 責任が明確(オーナーシップが明確)
- 認知負荷を制限しやすい
- 弱み
- イノベーションが遅め
- 境界が正しく設定できていないとフロー低下につながる
- 制約
- 複数チーム間で調整しながらコミュニケーションする前提をもつ必要がある

- ファシリテーション
支援する/支援される
- 強み
- 障害の除去によってフロー向上が見込める
- ギャップや不整合のある能力・機能を検出できる
- 弱み
- 実業務に従事しない経験豊富なスタッフが必要になる
- コミュニケーションの形式として馴染みがない/違和感が出る可能性がある
- 制約
- 複数チーム間で調整しながらコミュニケーションする前提をもつ必要がある

## 所感
チームタイプとインタラクションの話がメイン。
初見だとチームタイプの名前が頭に入ってこなかったりするものの、2週目で流し読みするとだいぶ違和感が減る。

## お勧め度（☆☆☆☆☆）
★★★☆☆
当然のことながら、書いてある内容をそのまま実施すればフローが向上するというものではない。

前段として認知負荷の話やモノリシックなシステムを分割する際の注意点(節理面)についてなど、
組織設計以外でも興味深い内容もあったりするので、読んでみてよかったという印象。

## 質疑応答