Team Topologies の輪読会用の備忘録

はじめに

Team Topologies 輪読会前の頭の整理＆備忘録

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

チームトポロジーの分解図

Chapter 1 : 組織の問題

チームトポロジーを考える必要性についてが述べられている

• チームトポロジーとは何か？
  • 人、技術、ビジネスの変化に継続的に対処できるようチームを進化させるためのガイド
  • チーム構造は、ソフトウェアデリバリーの安定化に影響を与えるものであることの理解を促すもの
• 最終的なゴール
  • 顧客ニーズにあうソフトウェアをチームがより簡単に構築、実行でき、オーナーシップを持てるようにすること
• 意識すべきもの
  • コンウェイの法則
    • チームの構成がプロダクトの設計に影響する（ex. モノリス、マイクロサービス）
    • 重要なのは、要求されているソフトウェアとチーム構造は一致していないといけない（コンウェイの法則への対抗はNG）
      • 例えば、モノリスなアーキテクチャに対してチームが複数ある状態は不適切な設計を生み易い
        • モノリスがNG、マイクロサービスがOKという話ではない。チームの認知負荷を考慮した設計であることが重要という話
  • 認知負荷の制限
    • 認知負荷の主語は チーム
      • チームファーストの障害として認知負荷がある
    • 人間の脳に留められる情報量には限界がある
      • 個人だけじゃなくチームも同じであることを認識すること
      • 個人の認知負荷は個々で判断できそうだが、チームの認知負荷はどうやって判定すればよいのだろうか？
        • 認知負荷を問う質問をしてみる（Chapter 3）
    • ドメインを複数持つことはチームの認知負荷が上がるわかりやすい例
      • 責任範囲の拡大 -> コンテキストスイッチの発生 -> 業務熟練度の遅れ -> 品質の低下 -> モチベーションの低下
    • 他チームとのコラボレーション
      • 他チームと関わることで必然的にコミュニケーションが発生しその中で認知負荷は高まる
      • 3つのアプローチのどれが適切かの判断が重要（Chapter 7）

Chapter 2 : コンウェイの法則が重要な理由

• 組織構造やチーム間のコミュニケーションパスが、結果的に 構築されるシステムのアーキテクチャになってしまう
  • チームの設計とソフトウェアの設計を別の活動にすることはできないというシンプルな法則
• ではコンウェイの法則が避けられてないとしたら何を注意しないといけないか？
  • チーム間のコミュニケーションを制限することで、早いデリバリーができるように促す
    • チーム間のコミュニケーションのパターンがある（Chapter 7）
      • チームに持っていない知識や技術を借りる場合
      • 他チーム向けの自チームの知識をAPI化する場合
    • コミュニケーションが多い方が良いと考えがちだがそれは違う
      • 必要とされるのは特定のチーム間における集中的なコミュニケーション
    • チーム間でのやり取りに利用するツールは共通のものを使うこと
      • 別々の課題管理ツールを使うと上手くいかないよ
• アーキテクチャを再設計したい場合はどうしたら良いか？
  • 最適なアーキテクチャを設計し、その設計に合わせたチーム設計を行っていく（逆コンウェイ戦略）
  • 理想はチームを編成する前に最適なアーキテクチャを理解し設計することだが、スタートアップでそれは難しい気がする
• コンウェイの法則によればこのチーム設計が最も自然に望ましいソフトウェアアーキテクチャを生み出す
  注意すべきは、コンポーネントの高い凝集性を意識するあまり、コンプリケイテッドチーム単位で分割しないこと
  ストリームアラインドチーム単位 での凝集性を意識すること
  

Chapter 3 : チームファースト思考

• チームファースト思考はなぜ必要か？
  • モダンなソフトウェア開発における情報の量と質を適切に扱うには個人では継続不可能だから
  • チームのパフォーマンスが高ければ効率的にソフトウェアを提供できるから
    • パフォーマンスにおいては、 誰がいるか？ ではなく、チームとしての力学の方が重要だというGoogleの研究結果
      • 個人志向のメンバーがチームに与える影響力より、集団志向のメンバーの方がチームのパフォーマンスを上げる可能性が高い
  • チームの責任範囲をチームが扱える認知負荷に合わせたものにする
    • 認知負荷を超えたチームは集団志向ではなく個人志向で振る舞うようになる
    • 運用するアプリケーション数
      • チームの認知負荷を超えるサブシステムを許容しない
    • 管理しなければならないツールの数を減らすために自動化を考える
  • 多様なバックグラウンドを持つチームの方がバイアスが掛からないので新しい発想で解決策を打てる可能性が高い
  • 注意！
    • 継続的デリバリーやテストファーストの開発などの基本的なエンジニアリングスキルがあってこそのチームファーストアプローチ
      • エンジニアリングの基礎が定まってない段階でチームファーストに投資しても意味がない
• チームについて
  • 5~9人の共通のゴールのために働く単位
  • 長続きする小さなチームを標準とする
    • 理想は人が年1回チームを離れてもチームのパフォーマンスに影響を与えないチーム
      • チームがハイパフォーマンスを維持するためには、チーム力学を育てなくてはならない、故にタックマンモデルの混乱期は続く
    • 長続きするための要因は 信頼
      • 2週間〜3ヶ月でやっとチームの形ができる
        • 6ヶ月のプロジェクトを完了してパフォーマンスが向上してきたところでメンバーを他チームにアサインするのは価値がない
    • 新しい人を追加してもすぐパフォーマンス増えない（ブルックスの法則）
  • チームの最適人数についての参考
    • 7人が人類力学的に信頼関係を結べる限界（ダンバー数）
    • two pizzaルール（By Amazon）
• 1つのチーム がソフトウェアのオーナーになることの重要性
  • オーナーシップを持つことでプロダクトの目的の維持とそのための継続的な運用を考えられるようになる
    • オーナーシップが個人の縄張り争い争いにならないようにする（この部分は自分のコードの占有者にならないように）
      • チームはコードの世話役であるというスタンスが大事
  • 複数のチームが同一のシステムやサブシステムに修正を許すと混乱する。そしてその変更に対して誰もオーナーシップを発揮しなくなる
    • 他チームからのPRは作れるようにしても、その変更に対する責任はチームであるべき
• メンバーにチームファーストのマインドセットの育成が必要
  • 個人のニーズよりもチームのニーズを優先しなくてはならい（具体例として以下）
    1. スタンドアップやMTGに遅れない
    2. 議論や調査を脱線させない
    3. 自分の新たな仕事を始める前に他のメンバーの障害を取り除くのを助けること
    4. 新しく参加したメンバー、経験の少ないメンバーをメンタリングすること
    5. 議論に勝敗をつけようとするのをやめ、良い代替案の模索に合意すること
• チームの認知負荷を測るために中立的立場から以下の質問をすると良い
  • 「チームは、頼まれた仕事に対して、効果的にタイムリーな仕事ができていると思うか？」
    • なぜ問いなのか？（モジュール、クラスやメソッド数などで認知負荷を測ることはできなかったというレポート有り）
• 認知負荷を下げるには、ドメインの種類と数をチームで定義する
  • チームで扱うドメインとは何を指すものなのか？
    • インフラチームを作るべきなのか？テストチームを作るべきなのか？プロダクトで分けるべきなのか？
  • コレという定義はないので、責任を担うチームがどう感じているか？ という点議論していく
• 認知負荷軽減の経験則
  • 経験則１
    • ドメインをサブドメインに分割し、それに応じてチームも分けるパターン
  • 経験則２
    • シンプルなドメインを２〜３扱う7〜９人のチーム
      • シンプルが故にモチベーション低下リスク有り
  • 経験則３
    • 複雑なドメインを割り当てられたチームはそれ以外のドメインをたとえシンプルなものであっても割り当てるべきではない
    • チームに２つの煩雑なドメインが割当てられると、実際にはそれぞれのドメインを担当する２チームに分割されたように振る舞う
      • 分割された割には全員が両方のドメインに関する知識を要求され認知負荷や調整コストが上がる罠がある
• 分割したとして、チーム間の良い相互作用を作るには？
  • チーム自信をAPIとしてみることで見えてくるものがある（以下例）
    • コミュニケーションツールはSlackで、メンションしてくれれば反応します
    • 依頼はTrelloからお願いします
    • 他チームのPRは週１でチームで検討する場があります
    • 現在開発しているプロダクトと中長期的な展望はWikiにまとめてあります

Chapter 4 : 静的なチームトポロジーチームのアンチパターン

• トポロジーは変化し続けるのが前提であること、現時点での関心事において機能するトポロジーを都度選ぶことができる体制を構築しておくことが重要
  • マーケットからの新たの要求を受け行き当たりばったりでチーム編成するのは意図しない認知負荷を生む
  • 一方で、考え抜いて選択したトポロジーであれば実現できただろうスピードが手に入らない
• ある時点での組織の特定の関心事に適したチームトポロジーのパターンがあるのでそれをチームで学んでおくこと
• 自分たちどのチームタイプであるかを質問することで参考にするトポロジーが見えてくる
  • 自分たちのスキル、制約、文化とエンジニアリング成熟度、望ましいソフトウェアアーキテクチャ、ビジネスゴールを踏まえると、素早く安全に成果を出すにはどのチームタイプが役立つか？
  • 主な変更フローにおいて、チーム間の引き継ぎをなくしたり、減らしたりするにはどうしたらよいか？
  • システムを実行可能に維持しつつ、早いフローを促進する上で、ソフトウェアシステムの境界をどこに設定すべきか？（チームはどう合わせて行けばよいか？）
• 【アンチパターン】
  • 場当たり的なチーム設計
    • DBの扱いが壊れた後に作られたDB管理チーム
    • 大きくなりすぎてコミュニケーションのオーバーヘッドで壊れてしまったチーム
  • 非常に不安定なチームを急増しプロジェクトが終わったら解散
    • チーム立ち上げコストや、頻繁に発生するコンテキストスイッチを見込んでいないのがあるある
• 【変更フローを考慮した計パターン】ストリームアラインド（Chapter 5）
  • 同一チーム内で設計・開発・テスト・デプロイ・運用を行うためのすべてのスキルを備えるパターン
    • 俗に言うDevOps
    • スキル毎にチームを分けるとでチーム間でコミュニケーション摩擦が起き、問題の発見からの改善が遅くなる
    • フィーチャーチームの上位概念のイメージ（ストリームというビジネスや組織の仕事を継続的に行うという単位での見方。機能やプロダクトを包含している）
      • フィーチャーチームやプロダクトチームはストリームアラインドができる前の概念
• 【フィーチャーチーム】
  • 他チームを待つこと無く自給自足でPDCAを回せす
    • 職能横断かつコンポーネント横断で動くので複数のコードベースを触る機会がある
    • そのため、エンジニアリングにおいて高い成熟度と信頼を必要とする
• 【プロダクトチーム】
  • フィーチャーチームの下位互換のイメージ
  • 自分たちの弱い部分を他チームに払い出す（テスト環境の払い出しやデプロイパイプラインの作成・監視など）
    • フィーチャーチームに比べて他チームのブロッキングを受けるデメリットがあるが、弱点を払い出すことで認知負荷を軽減できるメリット
• 【クラウドチーム】
  • 従来のインフラストラクチャーチームが名前を変えただけのチーム
  • プロダクトチームが作ったインフラの雛形を引き継ぎ、本番で実運用に耐えるように昇華させる
• 【SREチーム】
  • SREは必須でなくオプション
  • SREチームの関わり方イメージ
    
• トポロジーを選択する場合に考慮すべきこと
  • 責任が明確であること
    • 責任の分割によるサイロの解消
      • 責任を分割することで、チームへの依存関係が減らせる（除去できる）
  • 独立して作業することが可能であること
    • 自分たちのことは自分たちでできるようにする
      • 自動デプロイやテストをDevOpsチームに依存してずっと切り出すのは良くない（一時的なフォローをしてもらいいずれ自立する意識が大事）
  • フローに最適化されていること
    • チーム間の依存関係を明確にすることで、デプロイまでの待ちを可視化する
    • 依存関係マトリックスを作ることが推奨されている

Chapter 5 : 4つの基本的なチームタイプ

4つのチームタイプのインタラクションの全体像は以下（詳細なインタラクションについてはChapter 7）

ストリームアラインドは組織の根幹。それ以外の3つはストリームアラインドの負荷を軽減するのが役割

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

• ストリームとは、ビジネスドメインや組織の能力に沿った継続的な仕事の流れ
  • 機能一式のことでもあるし、仕事やサービスのことでもあるし、ユーザーエクスペリエンスのことでもある
• 備えているべき能力（個人ではなくチームで）
  • アプリケーションセキュリティ
  • 事業成長性分析と運用継続性分析
  • 設計とアーキテクチャ
  • インフラストラクチャーと運用性
  • メトリクスとモニタリング
  • プロダクトマネージメントとオーナーシップ
  • テストとQA
  • ユーザーエクスペリエンス

イネイブリングチーム

• ストリームアラインドチームが欠けている能力を素早く獲得するのを助ける
  • チーム単位でのサーバントリーダーシップの発揮が求められる
  • 複数のストリームアラインドチームを横断的に支援
    • 適切なツール、プラクティスの調査、提案など
  • 特定のテクニカルドメインのスペシャリストチームになる
  • 継続的な支援を受けないように注意（あくまで自立支援）

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

• システムの中でスペシャリストの知識が必要となるパーツの開発と保守に責任を持つ
  • 目的はストリームアラインドチームの認知負荷を下げること
    • 顔認証エンジンや金融サービスのトランザクションレポートシステムなど
• チーム組成の判断基準は、チームの認知負荷と特別な専門知識の有無

プラットフォームチーム

• プロビジョニング、監視、デプロイなどを引き取り、使いやすいサービスを提供することでストリームアラインドの認知負荷を減らすこと
• チーム特性上、プラットフォームチームの顧客はストリームアラインドチームになる
  • デベロッパーエクスペリエンスを重視する
  • 開発チームの開発の邪魔にならないようにする
    • それ故最低限のシンプルなものにするのが好ましい（認知負荷軽減にもつながる）

以下単一職能チームにしがちなもの（サイロを避けることで変更フローに強くなるため）

• テストやQA
• UX
• データベース管理
• ETL処理

サポートチームはストリームアラインドとペアを作ると良い

• 障害がそのストリームに閉じているものであればペアチームなので適切に処置
• 他チームに及ぶ場合は他のサポートチームを巻き込み対応
  • スウォーミングのメリットが効きやすい分野でもある

Chapter 6 : チームファーストな境界を決める

素早いデリバリーを実現するためには、ストリームアラインドチームが単一のドメインに対して責任を負うのが最も単純で話が早い

既存のシステムに対して以下の観点での分割が可能かどうかを自問してみるのが良い

• モノリシックなシステムの中で複数のドメインが隠れている場合があるか？
• 複数のビジネス領域を跨いだ機能を提供するために技術的な選択でドメインが決められているか？
• 分割後それぞれが独立してオーナ湿布を持ち継続的に進化できるかどうか？
  • マイクロサービス化すれば必ずしも解決するとは限らない。E2Eテストが別のシステムがないと完結しないのであれば、それは分散型モノリスになっているだけ
  • 分割後のパーツ間での一貫性が失われ、整合性が低下する危険性があるので要注意

モノリスを認識することが境界の判断に重要だが、そもそもモノリスも種類が複数あるのでその理解から始めると良い

• アプリケーションモノリス
  • 複数の依存関係をもつ単一で巨大なアプリケーション
    • リリースしている最中はすべてのサービスが使えない
• データベースモノリス
  • 同一DBのスキーマと結合している複数のアプリケーションからなるもの
    • それぞれ別々に変更、テスト、デプロイが難しくなっているもの
• モノリシックビルド（すべてをリビルド）
  • 単一の巨大なCIでビルドを行う（アプリケーションモノリスのビルドはこれに該当する）
• モノリシックリリース（すべてをまとめてリリース）
  • 全コンポーネントの最新バージョンをまとめて同一環境に導入しなくてはいけないリリース
• モノリシックモデル（画一的な視点）
  • 単一のドメインや表現を多くのコンテキストで強制する
    • 小さなチームで共通認識がしっかりしていればOKだが、大きくなってくると管理しきれないため意図しない不具合を生む種となる
• モノリシック思考（なんでも標準化）
  • 単一のスタックやツールを強制してしまう
  • チームの選択の自由を奪うとモチベーション低下（エンジニアは学習したがる生き物）
• モノリシックワークスペース（オープンプランオフィス）
  • 1人ずつ隔離されたスペース、机の間に仕切りがない
    • 悪影響を及ぼす可能性あり（対面でのやり取りが減少し電子的なやり取りが増加するため）
    • 物理的に同じ空間にいるメリットを活かせない
      • いる場所を同じにするのではない、目的を同じにするために物理的な空間に共存する

節理面の探し方

ビジネスドメインの違いとソフトウェアの境界が一致しているのが分かりやすいが、実際には節理面は複数のパターンがある

現状どのパターンに帰属しいるのかで打ち手に影響するので意識をしておく必要あり

• ビジネスドメインとソフトウェア境界を一致させる（基本パターン）
  • 一方で境界を判定するには、ビジネス的知識と技術的な知見が必要になり、最初は間違いやすい（DDDの概念が役に立つ）
• 業界特有の規制に対応特化のチームの組成
  • 医療や金融業界は特定の基準を強制してくる（外部からの要件によって全体への影響を最小限に留めるにはどうしたら良いか？の考え方）
  • PCI DSSなどが良い例。規制の対象のシステムをサブチーム化することで、PCI DSSへの対応が発生した時に、社内のコンプライアンスメンバーと素早い対応ができるイメージは湧く
• システムの変更頻度による分割
• チームメンバーのタイムゾーン
  • メンバーがリモートかつタイムゾーンが異なる場合にはコミュニケーションの難しさが表面化しやすい
    • コミュニケーションツールの利用で改善しない場合はタイムゾーンを元にしたチームとして分割
• リスク
  • システムには複数のリスクが内在している。そのリスクの大小で分ける
    • 例）無償ユーザーに対する変更は、潜在的な有償ユーザーの獲得に直結するので高リスク
• パフォーマンス
  • システムの中で使われる機能に差はある。特に使われる機能群に特化したチームを作ることで、上のリスクの軽減にも繋がる
• 技術
  • 技術主導の分割（フロントエンド、バックエンド、データ層）は制約を生み、全体視点での不透明度が増し、早い変更の妨げとなる
    • 特定の条件下（技術が古い、自動化できない）ではハマるが、現代においては、非推奨なパターンであはある
• ユーザーペルソナ
  • 一例として収益構造ペルソナでチームを分ける
  • 一般に課金ユーザーは、使える機能も多く、システムに対しての習熟度も高く、収益への貢献度も高い
  • そのユーザーに対するフォローを手厚くすることで高い顧客満足度&収益維持することは理にかなっている

一方、ソフトウェアはビジネスドメイン観点以外でも節理面候補があるのでそこを意識しておく必要がある

Chapter 7 : チームインタラクションモード

責任境界を持つチーム定義するだけでは不十分。実際にはチーム間でインタラクションが発生するため。よってこの章で学ぶべきはインタラクションのパターンで、分類すると3つある。

つまり、4つのチームパターン x 3つのインタラクション の組み合わせが基本戦略になる
一方で、チームとインタラクションのパターンの基本形は以下のようになる

コラボレーション

• チーム間が一時的に密結合する
  • コラボで摩擦（認知負荷やコミュニケーションコスト）は発生する
  • 1つの目的が共有され互いの専門性が発揮することで、新しい手法や発見を生む可能性あり
    • 責任は共有されて、境界は曖昧になる
    • 問題が素早く解決し、組織が素早く学習できるメリット
• 推奨トレーニング
  • ペアプロ
  • モブプロ
  • ホワイトボードでのスケッチ

X-as-a-Service

• 一方のチームが他チームに対してAPIなどを提供するイメージ
• 責任は明確に分離できるし、利用する側は素早いデリバリーが可能になる
  • 他チームから提供されるものを信頼し、自分たちのタスクに集中できる
  • 互いのチームがオーナーシップを明確化できる
• 予測可能な答えるある課題に対しての選択肢
• 推奨トレーニング
  • UXとDevExのプラクティスに関する勉強会

ファシリテーション

• 一方のチームが別チームに新しいアプローチの学習・習得するための支援（障害を取り除くための支援）
  • イネイブリングチームの主な仕事
• 目的はチームの独り立ちなので、一定期間という期限付き

Chapter 8 : 組織的センシングでチーム構造を進化させる

• チーム構造の進化はなぜ重要なのか？
  • 最初の設計がずっと正しい訳がない（プロダクトは成長するので）
  • プロダクトの設計は進化すべき
    • プロダクトを進化させるためにはチーム構造を変化していく必要がある（コンウェイの法則）
      • チーム構造の変化は一筋縄ではいかないが以下の認識を持つことで柔軟性が伝わりやすい
        • チームとアーキテクチャはそもそも疎結合であるべきもの
• チームトポロジーの進化例
  • コラボとX-as-a-Serviceを行き来できる組織はアジリティが非常に高い
    
• 組織におけるチームトポロジーは、数カ月に渡ってゆっくりと変化する
  • 数ヶ月かけてインタラクションモードに変化を促し、それに付随してソフトウェアアーキテクチャーにも変化が起こる

進化のきっかけになるポイント

• 1チームで扱うにはソフトウェアが大きくなりすぎている
  • プロダクトチーム全員が等しくコードベースで理解するのが難しくなっている（人の認知容量の限界）
• 今最も優先すべき仕事は何か？ではなく わかっているのは誰か？ に計画が左右されている時
• デリバリーのリズムが遅くなり始めている
  • 定性的にリリースに時間がかかる様になった
  • 1年前にくらべてベロシティが低下している
  • 別チームのアクションを待つ変更が増え、仕掛りが多くなっている
  • 結合するサブシステムの数と複雑さにより、円滑で早いデリバリーが達成できない

保守作業の重要性と取り扱い方

• 保守チームを作ってはいけない
  • プロダクトとはユーザーとの継続的な対話だから
    • 対話をするには開発チーム自信が保守や運用作業にアンテナを張り開発活動に取り込むフィードバックループが重要
    • DevとOpsをチーム分離するのではなく、DevOpsがチーム内で完結しているトポロジー
  • 開発チームと保守チームをわけた時に陥る罠
    • 開発チームは新しいものを導入するのが好きで抵抗ない、保守チームは新しいものを導入されてその不具合対応をやらされ、大きな不満のもととなる

Chapter 9 : まとめ:次世代デジタル運用モデル

これまでの各章で学んできたことをまとめた図

チームトポロジーの始め方

1. チームから始めるために以下の質問をチームに投げかける
   1. 効果的なチームとしての振る舞いや活動とは？
   2. オーナーシップを持てているか？持つために必要なこととは？
   3. ユーザーのニーズを満たすことにフォーカスするには？
   4. 不要な認知負荷を減らすには？
   5. 他のチームのリソースを利用するには？提供してもらうには？
2. 安定したストリームの特定
   • チームで扱うストリームの定義についての目線合わせ
     • ストリームは業種や組織によっても捉え方が異なるため
3. 最低限のプラットフォームの特定
   • 最低限のプラットフォームで早い変更にフォーカスできる
4. 能力のギャップの特定と解消（コーチング、メンタリング）
   • 実際ちゃんとできる人材は希少
5. 練習（異なるインタラクションモードやその背景にある原則の理解）
   • インタラクションモードの種類とデモ
   • コンウェイの法則の説明
   • チーム間コミュニケーションの適切な距離が自分たちの最適な時間の確保につながり、ソフトウェアを改善できることの理解
   • 認知負荷のあぶり出し