🙌
チームトポロジーを成功させる実践方法の探求 - Team Topologies Study
概要
2022/03/16に開催された下記勉強会のメモです
こちらに書き起こしの記事もあります（全3部） togetter
書籍
セッション
30分で分かった気になるチームトポロジー
企業のソフトウェア開発に関するパフォーマンスをどう測定するか？
4つのキーメトリクス / LeanとDevOpsの科学
- デリバリーのリードタイム
- デプロイの頻度
- サービス復旧の所要時間(MTTR)
- 変更失敗率
なぜこれが良いか
- スクラムのベロシティなどの生産性・量に関する指標は悪用可能
- たくさん作ろことを目指すとビルドトラップに陥る
- ビルドトラップ→顧客の問題を解決したか？よりも機能の開発やリリースを重視
- チームが忙しく働いたかなどの指標は計画外作業などできなくなる
こちらも参照 LeanとDevOpsの科学
チームトポロジーとは？
- （上記の指標にあるような）素早く安定したフローを実現するためのもの
- 適応型の組織設計モデル（のテンプレートみたいなもの）
チームトポロジーが中心に据えたもの
- コンウェイの法則
- チームファースト
- チームAPI
- 4つのチームタイプ
- 3つのインタラクションモード
- 組織的センシング
- トポロジー進化
コンウェイの法則
「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」
- 組織構造がアーキテクチャに反映される
- システムのアーキテクチャと組織のアーキテクチャが対立する場合、組織のアーキテクチャが勝つ
逆コンウェイ戦略
- 望ましいアーキテクチャを実現するために、それにあった組織やチーム構造にする
- コンウェイの法則に逆らわない
チームファースト
- 組織図やマトリクスに依存した組織構造でなく、権限とスキルを持ったチーム構成が大事
- 引き継ぎや受け渡しを必要とせずに自律的に仕事できるようにする
よくある落とし穴
- チーム間の情報共有を増やす・コミュニケーションを活発にする、が必ずしも良いとは言えない
- 開発に使える時間（価値を生み出す時間）が減る
コミュニケーションの複雑性
- 1チームは10人までが適正
- コミュニケーションのオーバーヘッド（パス）が増大する
The API Mandate
- 元Amazon社員のGoogleエンジニア（当時）によって公開されたジェフ・ベゾスが開発チームに通達したドキュメント
- チーム間の蜜結合や調整をなくすという組織設計
- この文章が公開されたのが2011年、通達自体は2002年頃
こちらに日本語訳があります
タックマンモデル
- チームが機能するまでには段階があり、機能するまでに時間もかかる
- 機能してるチームを長く保つ
チームに仕事が流れ込むようにする
- 安定したチームを優先し、メンバーの入れ替えはゆっくりやる
- チームがソフトウェアのオーナーシップを持つ
- 複数のチームがオーナーシップを持つのを避ける
チームの認知負荷を考慮する
- 人間が扱える情報量には限りがあるので、チームの責任範囲や担当範囲を広くしない
- ストレスが高いと自律的に働けない
認知負荷に合うように責任範囲を制限する
- チームが扱うソフトウェアのサイズを制限したり、ソフトウエア領域を選ぶ
- うまくソフトウェアを分割できるポイントを見つけて分割→お互いに依存しないように
- ビジネスドメインのコンテキスト境界
- 規制遵守
- etc...
チームAPI
- 自分達のコード、ドキュメント、仕事のやり方などをインターフェース（API）として定義する
- ほかのチームとのやりとりにもAPIの考え方を用いる
チームAPIの例
4つのチームタイプ
- ストーリームアラインドチーム
- プラットフォームチーム
- イネイブリングチーム
- コンプリケイテッド・サブシステムチーム
ストーリームアラインドチーム
- ビジネスの主な変更フローに沿って配置する、中心となるチームタイプ
- 他の種類のチームは、ストーリームアラインドチームの負荷を減らすために存在する
プラットフォームチーム
- インフラやツール、共通サービスなどの内部サービスを提供するチーム
- ストーリームアラインドチームが詳細を知らなくても使えるようにする
イネイブリングチーム
- 他のチームが新しい技術やスキルを身につけるのを支援するチーム
- ビルド、継続的デリバリ、TDD、アジャイル、IaC、etc...
- 実作業でなくガイダンスの提供、短期的な支援
コンプリケイテッド・サブシステムチーム
- 複雑なサブシステムやコンポーネントを扱う専門チーム
- 動画処理、数理モデル、機械学習、特殊技術、特殊パッケージ、etc...
- 必要な時だけ構成
- ストーリームアラインドチームがブラックボックスとして扱える（認知負荷が減る）ように
3つのインタラクションモード
4つのチームタイプのチーム間コミュニケーションを以下の3つに定義
- コラボレーション
- X-as-a-Service
- ファシリテーション
コラボレーション
- 2つのチームが探索や学習を目的に協力している状態
- 密にコミュニケーションするので素早く探索や実験が可能
- チーム責任分界点が不明瞭で生産性は落ちる
- わからないことが多い状況（初期フェーズなど）で活用
X-as-a-Service
- 一方のチームが他方のチームが提供するものをサービスとして利用
- ブラックボックスとして扱う
- 責任境界が明確、認知負荷が減る
- 境界やAPIが適切である必要がある
- イノベーションは起こりづらくなる
ファシリテーション
- 一方のチームが他方のチームが新しい技術を身につけたり学習するためにファシリテーションする
- コーチングやティーチングなどの経験豊富な人が必要
組織的センシング
- 環境の変化を感知できなければ、やることは意味をなさない
- あらゆるところをセンサーに次にやることに反映
- 本番環境のソフトウェアの動きから学ぶ→開発と運用
- 他チームとのコミュニケーションから学びや気づきを得る
トポロジー進化
- トポロジーは静的なものでなく動的なもの
- プロダクトやサービスの成長、チームの学習などに合わせて適応していく
- ビックバンで変えてはいけない
チームトポロジーを見直すきっかけ→認知負荷が増大していないか？
- ソフトウェアが大きくなりすぎている
- デリバリーのリズムが遅くなった
- 依存関係が増えた
組織をチームトポロジーで振り返ると、よりよい未来が見えてくる
Q: チームトポロジーの価値をどこに感じているの？
A: チームトポロジーは共通言語
チームの進化の実現はCTOやVPoEなどに閉じた行為でないと考える
共通言語の獲得により全員で組織に向き合えるようになる
※上記リンクに公開されている資料で、どのようにチームトポロジーが進化していったか（と将来的な組織構造の理想）の事例が紹介されています
Discussion