メインコンテンツまでスキップ

🧩 Team Topologies

✅ このスタイルの概要​

チーム構造とその協働パターンを体系化し、ソフトウェアアーキテクチャと組織設計を結びつけるためのアプローチ。

✅ 解決しようとした問題​

  • チーム境界とシステム境界が一致せず、変更コストが高い
  • コミュニケーション負荷が増大し、開発速度が低下
  • プラットフォームや共通基盤が分散し、運用管理がカオス化
  • 「チームの形」が、アーキテクチャを阻害する構造的問題となる

Team Topologies はこれらに対し、
「チーム構造そのものをアーキテクチャ要素として扱う」
という視点を提供する。

✅ 基本思想・ルール​

● 4 つのチームタイプ​

  1. Stream-aligned Team（プロダクト／ドメイン担当）
    • ビジネス価値のストリームに沿って継続開発
  2. Platform Team
    • 内部開発者向けに“内部プラットフォーム”を提供
  3. Enabling Team
    • 他チームを支援し技術的能力を育てる
  4. Complicated Subsystem Team
    • 特殊な専門領域（最適化／ML／動画処理など）を担当

● 3 つの協働モード​

  • Collaboration：短期的に密に連携
  • X-as-a-Service：サービスとして提供・利用する
  • Facilitating：能力支援・コーチング

● チーム境界とアーキテクチャ境界の一致​

  • コンウェイの法則に基づき、組織構造とシステム構造を合わせる
  • 障害の少ない協調パターンを設計する

✅ 得意なアプリケーション​

  • ドメインの分割が明確なプロダクト
  • マイクロサービスやモジュラーモノリスを採用する組織
  • プラットフォーム／基盤の整備が必要な環境
  • 複数チームで継続開発するサービス

❌ 不向きなケース​

  • 少人数で運用できる小規模プロダクト
  • 組織変更が難しい企業文化（硬直的な組織構造）
  • プラットフォームの成熟が不十分で、サービス提供が負荷になる場合

✅ 歴史（系譜・親スタイル）​

  • DevOps 文脈から進化した組織アーキテクチャ手法
  • コンウェイの法則、SRE、プラットフォームエンジニアリングの影響を受けて体系化
  • 近年、モダン組織設計の標準的フレームワークとして普及している

✅ 関連スタイル​

  • DevOps：開発と運用の境界をなくす文化的・技術的アプローチ
  • SRE / SLO：運用品質の標準化
  • Platform Engineering：プラットフォームチームの実践形
  • Microservices / Modular Monolith：チーム境界とサービス境界の一致

✅ まとめ​

Team Topologies は
「組織構造こそアーキテクチャ」
というメッセージを明確にし、
チーム配置・協働モード・境界設計を通して
開発速度と組織の健全性を両立させるための理論と実践を提供する。