Team Topologies for Delivery
A focused chapter on team topologies for delivery, with practical delivery concerns, trade-offs, and the operational questions behind CI/CD work.
チーム構造がデリバリ速度を決める理由
チーム構造がCI/CDのデリバリ速度に与える影響を解説。コミュニケーションのボトルネック、チーム間依存関係、不明確な所有権がもたらす問題と、改善のためのチェックリストを提供。
チームが全行程を所有する：ストリームアラインドチームとデリバリー
チームが価値ストリーム全体を所有するストリームアラインドチームの概念を解説。CI/CDパイプラインへの影響、コミュニケーションボトルネックの解消、実践的な移行チェックリストを提供。
全チームが独自パイプラインを構築すると逆効果になる理由
各チームが個別にCI/CDパイプラインを構築すると、セキュリティパッチの遅延やナレッジ移行の非効率が発生。プラットフォームチームによる標準化とセルフサービスが鍵。
チームを依存体質にせずに成長させる支援チームの役割
ストリームアラインドチームがセキュリティスキャンなど未熟な領域に直面したとき、代わりに作業するのではなく知識を移転して自立を促す「イネーブリングチーム」の実践ガイド。CI/CD文脈での具体例と成功の測定基準を解説。
フィーチャーチームがコードに触れるべきでない時：複雑サブシステムチームの必要性
フィーチャーチームが扱うにはリスクが高く、専門知識が必要な複雑サブシステムに特化したチーム構成のメリットと実践方法を解説。ペイメントエンジンや課金システムなどの具体例を通じて、X-as-a-Service型のインターフェース設計とボトルネック回避のポイントを紹介。
ボトルネックを生まない3つのチーム連携パターン
プラットフォームチームが優れたCI/CDパイプラインを構築しても、ストリームアラインドチームが使いこなせなければ意味がありません。本記事では、チーム間の依存関係を減らし、スムーズなデリバリーを実現する3つのインタラクションパターン（コラボレーション、X-as-a-Service、ファシリテーション）を解説します。
チームモデルがデリバリーの妨げになるとき
3つのフィーチャーチームがそれぞれ独自のパイプラインと環境を持ち、デプロイが遅延し、調整が難航する——そんな状況から脱却するためのチームモデル再評価の実践的ガイド。