unless’s blog

日々のちょっとした技術的なことの羅列

いまさらだけどTeam Topologiesについてまとめてみる

Team Topologies DeveloperProductivity 開発組織

たまたま仕事でTeam Topologiesをまとめる機会があったので、備忘録がてらブログにしておく

Team Topologiesとは

Matthew SkeltonとManuel Paisによる本

https://amzn.asia/d/f0l0NBR

DevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかをまとめてる本

チームをDeliveryの最も重要な単位として(Team first-thinking)、チームのパフォーマンスが最大になるようにチームの人数やその責任の範囲の作り方(Team API)から、基本的なチームタイプ(Fundamental team topology)やそのチーム間のコミュニケーション(Team interaction mode)が紹介されてる

コンウェイの法則

システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう

逆コンウェイ戦略

コンウェイの法則に逆らわず、 理想のアーキテクチャを実現するためにそれにあった組織やチーム構造にする

Team first-thinking

小さく長期的に安定したチームを作ることが非常に重要

小さいチーム

小さくの単位は具体的には5-9人
この根拠はDunbar's number
これは人間が安定的な社会関係を維持できるとされてる人数の認知的な上限
チームの人数が増えるとコミュニケーションのパスの数が増える

Untitled

https://blog.nuclino.com/two-pizza-teams-the-science-behind-jeff-bezos-rule

認知負荷

チームの責任範囲をチームが扱える認知負荷に合わせたものにする
認知負荷を超えたチームは集団志向ではなく個人志向で振る舞うようになる

Ownership

また、チームがOwnershipを持てるようにする
プロダクトの目的の維持とそのための継続的な運用を考えられる
複数のチームが同一のシステムやサブシステムに修正を許すとだれもOwnershipを持たなくなる

Team API

チーム間の良い相互作用を作るためにチームをAPIとして考える
チーム間の依頼のIFをしっかり定義して非同期的な動きができると良い
また、Team APIをしっかりと定義するとよい

テンプレートは下記

github.com

Fundamental Topologies

役割の曖昧な複数のタイプのチームがあると責任の所在がわからなくなる
「Team Topologies」が提唱してるのは下記4つのチームに制限すること

基本的にStream aligned teamが根幹で、それ以外の3つのチームがStream aligned teamの負荷を軽減する

Stream aligned team

  • ビジネスにおいて1番重要なチーム
  • ビジネスドメインに沿った開発を行う

Enabling team

  • 機能開発で時間がないチームに対して新技術やプラクティスの導入を支援していくチーム
  • 複数のStream aligned teamを横断的に支援
    • 適切なツール、プラクティスの調査、提案
    • 実作業でなくガイダンスの提供、短期的な支援
  • 永久にそのチームにいるわけではなく一時的な支援(自立支援)

Complicated sub-system team

  • 専門知識が必要な複雑なサブシステムを開発運用するチーム
    • たとえばクレジットカードのプロセッシング、画像や動画の配信部分、AIや機械学習など
  • 目的はStream aligned teamの認知負荷を下げること

Platform team

  • インフラ周りや共通基盤、ObservabilityやDeliveryを提供するチーム
  • これによりStream aligned teamの認知不可を軽減する
    • Developer Experienceを最重視
    • Stream aligned teamの邪魔にならないように
      • 最低限でシンプルなものにする
      • なんでもかんでも提供すればいいってもんでもない
        • 認知負荷の増大につながる

Team firstな境界

目指すべきは分離が容易な疎結合
チームの認知負荷に合わせてソフトウェア境界を選ぶ
素早いDeliveryを実現されるにはStream aligned teamが単一のドメインにたして責任をもつのが単純で手っ取り早い
疎結合にしていくにはモノリスがあることを認識することが重要だが、モノリスにも種類がある

モノリスの種類

  • アプリケーションモノリス
    • 複数の依存関係をもつ単一で巨大なアプリケーション
  • データベースモノリス
    • 同一DBのスキーマと結合している複数のアプリケーション
  • モノリシックビルド
    • 単一のCIでビルドを行う
    • コードベース全体でのビルド
  • モノリシックリリース
    • すべてのコンポーネントをまとめて同一環境に導入しなくてはいけないリリース
  • モノリシックモデル
    • 単一のドメインや表現を多くのコンテキストで強制する
  • モノリシック思考
    • 単一のスタックやツールを強制
    • Ownershipが保たれずモチベが低下する要因になる
  • モノリシックワークスペース
    • 1人ずつ隔離されたスペース

境界を見つける

節理面をさがす

  • ビジネスドメインのコンテキスト境界
    • 基本はこれ
  • 業界特有の規制に対応特化のチームの組成
    • PCI DSSとか
  • システムの変更頻度による分割
  • などなど

Team Interaction Mode

それぞれのチーム間のインタラクションは下記

  • Collaboration
    • 他のチームと一緒に働く
    • コラボにより摩擦は発生する
  • X-as-a-Service
    • コラボレーションを最小にしてツールやAPIを提供する
    • Stream aligned teamとPlatform team
  • Facilitation
    • 他のチームの補助
    • Stream aligned teamとEnabling team

さいごに

開発生産性を向上させるためにチーム構成を考えることも重要
ただ、組織に正解はないと思うので、自分達にあったものを取捨選択していくことが大事
そのためには先人の知恵を知っておくことも重要

参考情報