チームトポロジーを読んだ感想

はじめに

最近、チームってどんな構成にするのがいいんだろうか？と考えることがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。

どうチームを構成するか？
チーム間のコミュニケーション（インタラクション）をどう設計するか？
定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？

チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。
個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなくても良さそうな印象も受けた。このバランス感を見極めるは大変そうだけど、8章あたりに書かれてるどうチームトポロジーを進化させていくか、を実践するのが良さそう。

いろんな考え方があるけど、つまりそれで何がしたいかというと、デリバリーを早くすること、価値を早く届けることなので、そこを見失わないようにしたい。

チーム構成、チーム間の連携、組織の設計について気になる人におすすめの一冊です。

チームトポロジー - JMAM 日本能率協会マネジメントセンター「人・組織・経営の変化」を支援するJMAMの書籍

https://pub.jmam.co.jp

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

Chapter1 組織図の問題
Chapter2 コンウェイの法則が重要な理由
Chapter3 チームファースト思考

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

Chapter4 静的なチームトポロジーチームのアンチパターン
Chapter5 4つの基本的なチームタイプ
Chapter6 チームファーストな境界を決める

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

Chapter7 チームインタラクションモード
Chapter8 組織的センシングでチーム構造を進化させる
Chapter9 まとめ:次世代デジタル運用モデル

以下、各章ごとの感想とメモです。

Chapter1 組織図の問題

📝 この章に書いてあること

Q. チームトポロジーとは？
- A. ビジネスの速度と安定性を実現する技術組織の適応型設計モデル
- 継続的な設計によるチーム構造のこと
- Q. チームトポロジーのゴールとは？
  - A. コラボレーションが必要な場所やタイミング、実行に集中してコミュニケーションのオーバーヘッドを減らすべき場所やタイミングを動的に見つけられるようなアプローチを提供することだ。
組織図が役立つときはいつか？
- 規制
- コンプライアンスの遵守
組織図が現実的でないときはいつか？
- アウトカムの不確実性が高い
- コラボレーションを重視する
😱 なぜ組織図思考は問題なのか？
- 組織図の構造に基づく意思決定は組織の一部分にのみ最適化されてる
- 公式の組織構造と実際の仕事のやり方に不均衡がある（組織図は現実と一致していない）
  - 現実には、プロダクトとチームを中心に据えるというのが最近の潮流
どうすれば組織図思考から脱却できるのか？
- 組織図のような単一の構造をやめる
- チームの成長やチーム間のインタラクションを考慮に入れた、現在の状況に適応可能なモデルにする
- コンウェイの法則、認知的負荷の制限、チームファーストのアプローチ

💁🏻‍♂️ 感想

組織構造は、実態に合わせて変えていける仕組みが良さそう。実態と乖離してると、コミュニケーションのオーバーヘッドが生じたり、適切なコラボレーションができなくなってしまう。

チームトポロジーはそのあたりの課題を解決するモデルで、継続的な設計によってチーム構造作るアプローチ。チームトポロジーがどんな背景があって登場してきた考え方なのかわかってよかった。

Chapter2 コンウェイの法則が重要な理由

📝 この章に書いてあること

Q. コンウェイの法則とは？
- A. システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまうという法則
- プロダクトのアーキティクチャーはそれが開発された組織の構造を反映する傾向がある
- システムのアーキティクチャと組織のアーキティクチャが対立した場合、組織のアーキティクチャが勝つ
- 😱 コンウェイの法則の軽率な使用パターン
  - ツールの選択がコミュニケーションパターンを推進する
    - コンフェイの法則によるとチーム間のコミュニケーション構造（組織構造）がそのままアーキティクチャーに反映されるので、事前に最適なコミュニケーション構造（組織構造）になるように考慮が必要。特にツールは、チーム間のコミュニケーションに影響があるため、どんなツールを使うべきか考慮する必要がある。
  - たくさんの異なるコンポーネントチーム
    - システムの小さな部品を構築するためのコンポーネントチームをたくさん生み出すと、速いフローを提供できないため、むやみやたらに小さいコンポーネントチームを作るべきではない。（ストリームアラインドチームが理想）
  - 縄張りづくりや人員削減を繰り返す組織再編
    - ソフトウェアのアーキティクチャを無視した再編は認知負荷やコンウェイの法則を無視したものになるのでやめた方が良い
Q. 逆コンウェイ戦略とは？
- A. システムの望ましいアーキティクチャを実現するために、チーム構造と組織構造を変化させること
  - そのため、チームを編成する前に、どんなソフトウェアアーキティクチャーが必要か理解する必要がある
なぜ組織設計には技術的専門知識が必要か？
- コンウェイの法則的には、組織設計とシステム設計はコインの裏表なので、どちらのことも把握する必要があり、アーキティクチャの技術的専門知識が必要
Q. 不必要なコミュニケーションを制限する理由とは？
- A. 速いフローを実現するため無駄なコミュニケーションは制限した方が良い。
  - 😱 無駄なコミュニケーションとは？
    - コンウェイの法則的に、ソフトウェアのアーキティクチャーを踏まえると、論理的にコミュニケーションが必要なパスは決まってくる。例えば、システム上連携しないソフトウェアを管理するそれぞれのチームのコミュニケーションは本来必要ないはずだが、コミュニケーションをとっていたりするとそれは何か問題がある、といったこと。
  - チーム間のコミュニケーションの健全性（無駄なコミュニケーションが発生していないか）を評価するための質問
    - その構造は、チーム間のコミュニケーションパスの数を最小化するような構造になっているか？
    - その一方で、チーム間のコミュニケーションが必要な場合は、それを誘発するような構造になっているか？
Q. なぜコンウェイの法則が重要なのか？
- プロダクトのアーキティクチャーはそれが開発された組織の構造を反映する傾向があるため、適切な組織構造になっていない場合、アーキティクチャもあるべき姿にならない。
- アーキティクチャがあるべき姿にならないと、デリバリーの速度が遅くなったり、不具合解消までの時間がかかったりする。
- コンウェイの法則に則り、組織構造とアーキティクチャを一致させることで、デリバリーの速度や不具合解消までの時間を短縮させることができる。
- そのためのアプローチとして逆コンウェイの戦略が重要。

💁🏻‍♂️ 感想

組織構造とアーキティクチャの構造が一致する法則から、最適なアーキティクチャーを目指すなら、まずどうチームを編成するかから考えないといけなそう。

基本的に１つのプロダクトは単一のチームが管理するという感じで整理すれば、問題なさそうに思ったけど、現実世界はそんなに簡単じゃないかもしれない。（データベースの開発まで分割するのはかなり大変そう）

Chapter3 チームファースト思考

📝 この章に書いてあること

チームファーストとは？
- 効果的にソフトウェアを提供するためには、チームから始めなければいけないという考え方
チームとは？
- 5人から9人メンバーからなる安定したグループで、共有されたゴールのために動く単位
  - メンバー数の上限は7人から9人。ダンバー数が上限。
    - ダンバー数とは？
      - グループの認知と信頼に関する進化上の限界の数
    - ダンバー数を超えると、ソフトウェアの生存可能性が失われる
      - ダンバー数を超えると、信頼関係が失われ、不適切な判断が行われるようになるため
      - ダンバー数を超えたら別の新しいユニットに分割する
小さなチームが信頼を生む
長続きするチームに仕事が流れこむ
- まずはチームを安定させること
チームの認知負荷はどうすれば下がるか？
- Q. 認知負荷とは？
  - A. ワーキングメモリで利用される心理的労力の総量
  - 3種類ある
    - 課題内在性負荷
    - 課題外在性負荷
    - 学習関連負荷
- Q. チームの認知負荷とは？
  - コードベースのサイズと複雑さ
  - 責任範囲
  - 運用するアプリケーションの数
  - 管理しなければいけないツールの数
- Q. なぜチームの認知負荷を下げたいのか？
  - ソフトウェアのオーナーシップを発揮できなくなる
  - ソフトウェアを安全に進化させることができなくなる
- Q. 認知負荷をどうやって下げるか？
  - チームの責任範囲を制限する
  - チームが扱うドメイン数を制限する
    - Q. チームにとって適切なドメインの数、種類は？
      - A. 決定的な答えはない。いくつか経験則がある。
        
        それぞれのドメインを単一のチームに割り当てる。
        １つのチームでシンプルなドメインを２つか３つ扱う。
        複雑なドメインを割り当てるチームはそれ以外のドメインを割り当てない。
  - ソフトウェアの境界のサイズをチームの認知負荷に合わせる
チームAPIとは
- 動的で明確なチーム間コミュニケーションのネットワークを作る手段
- 以下のようなものが含まれる
  - コード
  - バージョンかんり
  - ドキュメンテーション
  - プラックティスと原則
  - コミュニケーション
  - 仕事に関する情報
  - そのほか

💁🏻‍♂️ 感想

認知的負荷を下げたいのは、チームにオーナーシップをもたらすためで、チームにオーナーシップをもたらしたいのは、信頼関係があって長続きするチームを維持したいから。認知的負荷を下げるために、ドメインの境界線でチームを分割するのはいいけど、状況によっては、分割しなくても良い場合もあると思うので、何のために認知的負荷を下げたいのか、チームを分割する以外に認知的負荷を下げるためにどんなアプローチがあるのか、とか考えると良さそう。

Chapter4 静的なチームトポロジーチーム

📝 この章に書いてあること

Q. チームの認知的限界を考慮しつつフローを最大化するためにはどうすればいいか？
- A. チームを意図的に継続的に設計する必要がある。
  - 継続的な設計によるチーム構造をチームトポロジーという。
Q. どう設計すればいいのか？（チームを意図的に継続的に設計するとは？）
- まずはアンチパターンを踏まないこと
  - アンチパターン1. 場当たり的なチーム設計
  - アンチパターン2. チームメンバーの入れ替え
- 変更フローを考慮した設計
- 成功してるチームのパターン
  - フィーチャーチーム + システム全体を横断するロール
  - プロダクトチーム + サポートチーム
  - アプリケーション開発チーム + SREチーム
    - 段階によって関わり方が変わる
- チームトポロジーを考えるときに考慮すること
  - 技術的成熟度と文化的成熟度
  - 組織のサイズ、ソフトウェアの規模、エンジニアリングの成熟度
  - 責任の分割によるサイロの解消
  - チーム間の依存関係と待ち時間
Q. チームが自律的であるのがなぜ良いか？
- ノンブロッキングであり、素早くデリバリーができる。

💁🏻‍♂️ 感想

チームが自律的に動くためにはどうすれば？と考えるところがポイントだと思う。基本的には、アプリケーションを作るチームがあり、そのチームの自律を促すために、サポートするチームを作る。これが成功パターンらしい。全て１チームで自律できればそれに越したことはないけど、複数チームが存在する場合、横断してサポートするチームがあると全体の効率はあがりそう。

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

📝 この章に書いてあること

モダンなソフトウェアシステムの開発と運用に必要なチームは4種類
- ストリームアラインドチーム
  - Q. ストリームとは？
    - A. ビジネスドメインや組織の能力に沿った仕事の継続的な流れのこと
  - Q. ストリームアラインドチームとは？
    - A. 価値のある単一の仕事のストリームに沿って働くチームのこと
    - モダンなソフトウェア組織ではほとんどのチームがストリームアラインドチーム
  - ストリームアラインドチームに必要な能力
    - アプリケーションセキュリティ
    - 事業成長分析と運用継続性分析
    - 設計とアーキティクチャー
    - 開発とコーディング
    - インフラストラクチャーと運用性
    - メトリクスとモニタリング
    - プロダクトマネジメントとオーナーシップ
    - テストとQA
    - ユーザーエクスペリエンス
  - なぜ「プロダクトチーム」や「フィーチャーチーム」ではないのか？
    - 必ずしもプロダクトがフィーチャーが存在するとは限らない。より幅広い状況に対応できるように、ストリームという言葉を使ってる
  - ストリームアラインドチームへの期待値
    - フィーチャーデリバリーのための安定したフロー作成
    - フィードバックに基づいた素早い修正
    - プロダクトの進化に実験的なアプローチを学び、常に適応する
    - 他チームへの引き継ぎを最小限にする
    - 変更フローの安定性とチームと技術の健全性をメトリクスによる評価される
    - 支援を受ける他チームタイプと積極的に連携する
    - 「自立」「熟達」「目的」を達成しようとしているか、達成していると感じる。
- イネーブリングチーム
  - ストリームアラウンドチームを横断的に支援する
  - 特定のテクニカルドメインに関する支援を行う
  - イネイブリングチームとストリームアラインドチームのインタラクション
    - 行わないこと
      - 不適切なプラックティス
      - 優先順位設定の間違い
      - 品質の低コードに起因する問題の解決
    - 行うこと
      - 新しい技術、コンセプト、アプローチについての能力を高めること
- コンプリケイテッド・サブシステムチーム
  - 複雑なサブシステムについてストリームアラインドチームの認知負荷を下げるチーム
  - 考えられるサブシステムの例
    - 動画処理のコーデック
    - 顔認識エンジン
- プラットフォームチーム
  - ストリームアラインドチームが自立的に仕事ができるようにプラットフォームを提供するチーム
  - プラットフォームの例
    - 新しいサーバーインスタンスのプロビジョニング
    - アクセス管理ツール
    - セキュリティ強化のためのツール
  - 期待される振る舞い
    - ストリームアラインドチームのニーズを理解して密接にコラボレーションする
    - ストリームアラインドチームからのフィードバックに素早く対応できる
    - 提供するプラットフォームをプロダクトとして扱い、提供するサービスのユーザビリティと信頼性に強くフォーカスする。

💁感想

基本的な考え方は、ストリームアラインドチームがあり、このチームを支えるために他のチームタイプがいるという考えかたのようだった。

各チームタイプに期待される役割が詳しく書かれていて、実際いま僕が所属してる開発組織の各チームはどんな分類なのかイメージできた。

僕が所属してるチームは、ストリームアラインドチームになるけど、その役割だったり、他チームタイプとどんな感じで関われば、もっと良いコラボレーションになるのか？と考えるきっかけになった。

Chapter6 チームファーストな境界を決める

📝 この章に書いてあること

Q. ソフトウェアシステム内もしくはソフトウェアシステム同士の境界線をどう決めるか？
- A. チームの認知負荷に合わせてソフトウェア境界を選ぶ
- Q. なぜ境界線を決める必要があるのか？
  - A. 境界線がない場合（曖昧な場合）責任範囲が不明瞭になり、ソフトウェアのデリバリーにおける多くの問題が発生するから。
  - 境界線が曖昧な、結合度の高いシステムのことを、モノリスという。
    - モノリスの種類
      - アプリケーションモノリス
      - データベース結合モノリス
      - モノリシックビルド
      - モノリシックリリース
      - モノリシックモデル
  - 結合度の高いモノリスは、責任範囲が曖昧になりがちなので、自律的なチームを作りづらくなる。
    - 自律的なチームを作るために、モノリスを分解して疎結合なソフトウェアを作る必要がある。
      - 疎結合なソフトウェアを作るために、モノリスに境界線を決めないといけない。
      - 疎結合のソフトウェアに改変した後、関係するチームにどう影響を与えるか考慮する必要がある。
  - ストリームアラインドチームは単一のドメインに対して責任を負うべき。
- Q. 境界線を見つける方法は？
  - A. 節理面を探せば、ソフトウェアの境界線を自然に見つけることができる
    - Q. 節理面とは？
      - A. ソフトウェアシステムを簡単に複数に分割できる自然な継ぎ目のこと
      - 通常は、ビジネスドメインの違いが、ソフトウェアの境界線とするのが最善
      - 複数の節理面が必要になることも多い
    - 節理面の候補
      1. ビジネスドメインのコンテキスト境界（境界づけられたコンテキスト）
        
        大きなドメインモデルやシステムモデルを小さなパーツに分割する単位のこと
        境界づけられたコンテキストは、組織にとって自然な変更のストリームに沿ったものになる
      2. 規制遵守
        
        金融や医療業界などの規制が厳しい業界でのソフトウェアでの境界線
      3. 変更のケイデンス
        
        変更の頻度
      4. チームの地理的配置
      5. リスク
        
        規制遵守もリスクの一種。リスクの観点で分ける
      6. パフォーマンスによる分離
        
        パフォーマンスに基づいてサブシステムに分ける
      7. 技術
        
        基本的にはチームの自律性が下がるのでおすすめしない節理面だけど、古い技術が認知負荷になっている場合、そこだけ切り離しオーナーシップをもつ専門のチームを作ることで、古い技術を進化させることができる。
      8. ユーザーペルソナ
        
        例えば、ユーザーの課金の有無で提供する機能が異なる場合に有効

インタラクションとは？
- 他のチームとのやりとり
いつチームのインタラクションを変えるべきか？
なぜインタラクションが重要なのか？
- 自律的だ自己組織化だと言われても、メンバーは自分たちの仕事を完成させるために、他のチームとやりとりをせざる得ない。
- 組織における軋轢や非効率の原因は、チームのインタラクションと責任の不明瞭な定義が原因の場合が多いから。
- ソフトウェアシステムを構築する際にチームがインタラクションする方法を形式化することで、チーム間のインターフェイスを明確に定義でき、ソフトウェアデリバリーにおけるさまざまな側面の有効性が評価しやすくなる
チームがどのようにインタラクションするのか？(主要な３つのインタラクションとは？)
- コラボレーションモード
  - 他のチームと密接に協力して作業すること
  - 新しい技術や手法を調査するときなど、高い適応性や探索が必要とされる場合に適してる
  - ２チームが一定期間密接に作業することで、新しいパターンや手法や制限を発見する。責任は共有され教会は曖昧になるが、問題は素早く解決し、組織はすばやく学習する。
  - 強み
    - 素早いイノベーションと探索
    - 引き継ぎが少ない
  - 弱み
    - チーム間で詳細やコンテキストの共有が必要。これは認知負荷の増大に繋がる。
    - コラボレーションの間は以前より生産性が低くなる可能性
- X-as-a-Serviceモード
  - 最小限のコラボレーションで何かを利用または提供すること
  - 一方のチームが別のチームから「サービスとして」提供されたもの（APIなど）を使用する。責任は明確に定義されており、境界が効果的であれば、利用する側のチームは素早いデリバリーが可能になる。
  - 強み
    - 明確な境界線がある明確なオーナーシップ
    - チーム間の詳細やコンテキストの共有が減ることで認知的負荷が制限される
  - 弱み
    - 境界やAPIのイノベーションが遅め
    - 境界やAPIが効果的でなければイノベーションがよどむおそれ
- ファシリテーションモード
  - 障害を取り除くために他のチームを支援したり、支援を受けたりすること
  - 一方のチームが、別のチームが新しいアプローチを学習したり習得したりするのを一定期間支援する。ファシリテーションを行う側のチームは、相手チームをできるだけ早く独り立ちさせることを目標とし、ファシリテーションされる側のチームは学習に対してオープンな態度を取る。
  - 強み
    - ストリームアラインドチームの障害を取り除きフローを増やす
    - コンポーネントやプラットフォームにおけるギャップ、整合性の取れていない能力や機能の検出
  - 弱み
    - 構築や運用に従事しない経験方法なスタッフが必要
    - ファシリテーションモードのチームの一方または双方にとって、そのインタラクションは馴染みがないか奇妙に思えるかもしれない

設計ルール自体の設計も大事
- 規制やマーケットの状況、顧客からの要望、技術の変化、現代だと急速に変わるので、一度組織を定義したら終わりではない。設計ルールを定めておくことが大事。
- ルールだけじゃなくて、経験則も大事
コラボレーションモードとX-as-a-Serviceモードを行き来するとなぜアジリティが上がるのか？
- コラボレーションモードとX-as-a-Serviceモードを行き来するということは、状況に応じて境界線を動的に定義するということになので、境界線が固定化されず、アジリティも上がる。
どんな時にチームトポロジーを進化させるべきか？
- チームの目的や状況に合わせて進化させるべき
- 例えば
  - １チームで扱うにはソフトウェアが大きくなりすぎてる時
  - デリバリーのリズムが遅くなり始めている時
  - 複数の業務サービスが大量の下位サービスに依存してる時
モダンでハイパフォーマンスな組織になる３つの方法とは？
- システム思考
- フィードバックループ
- 継続的な実験と学習の文化
新規サービスと既存システムを一つのチームに担当させた方が良いのはなぜか？
- 新しい手法はダメージを与えるかもしれないが、分離されている場合、新規サービスチームは気にする理由がほとんどない。選択ミスによるダメージを受けるのは、既存システムチームだから。
- ストリームアラインドチームは構築中の新システムと運用中の旧システムを両方見る必要がある。これによって、ユーザーやシステムの動作について、幅広い学習が可能になり、以前のシステムでの失敗を繰り返さないようになる。

ここまでの総まとめっぽいことが書いてる
チームトポロジーの始め方
1. チームから始める
  1. まずはチームが以下のことをするには何が必要か自問してみる
    1. 効果的なチームのふるまい、活動とは？
    2. ソフトウェアの一部で効果的にオーナーシップを持つには？
    3. ユーザーのニーズにフォーカスするには？
    4. 不要な認知負荷を減らすには？
    5. 他のチームのソフトウェアや情報を利用するには？他のチームにソフトウェアや情報を提供するには？
2. 安定した変更のストリームを特定する
3. 最低限のプラットフォームを特定する
4. チームコーチング、メンタリングで能力ギャップを特定する
5. 異なるインタラクションモードを共有、練習し、新しい仕事のやり方の背後にある原則を説明する

💁🏻‍♂️ 感想

ここまでの章の総括的な内容になってて、チームトポロジーの始め方が書かれてるので、これからチームトポロジーをやっていく時に参考になりそう。

MEGUMI SHIMABUKURO