第12章 スクラムチームの構成
本章では、プロダクトの規模が大きくなり、複数のスクラムチームが必要になった際のチーム構成のパターンと、チーム間を同期させるための調整手法について解説します。
12.1 概要
Section titled “12.1 概要”小規模なプロダクトであれば1つの機能横断型チームで十分ですが、規模が拡大すると複数のチームによる共同作業が必要になります。いかにチーム間の依存関係を減らし、価値の提供速度（ベロシティ）を維持するかが焦点となります。
12.2 フィーチャーチームかコンポーネントチームか
Section titled “12.2 フィーチャーチームかコンポーネントチームか”チームを構成する際、技術的なレイヤーで分けるか、顧客価値で分けるかの2つのアプローチがあります。
フィーチャーチーム（推奨）
Section titled “フィーチャーチーム（推奨）”エンドユーザー向けの機能（フィーチャー）を、バックログから取り出して最初から最後まで完成させることができるチームです。
- 特徴: 1つのチーム内にUI、API、DB、テストなどの全スキルが揃っている。
- メリット: チーム間の依存関係が最小限になり、顧客への価値提供が早い。
- 責任: 特定の機能を「出荷判断可能」な状態まで持っていく全責任を負う。
コンポーネントチーム
Section titled “コンポーネントチーム”特定のサブシステムや技術レイヤー（例：データベース層のみ、UIコンポーネントのみ）を担当するチームです。
- 課題: 1つの機能を完成させるのに複数チームの調整が必要になり、待ち時間や「バトンリレー」の失敗が発生しやすい。
- リスク: 各チームが自分の領域（コンポーネント）だけを最適化しようとし、プロダクト全体の価値が二の次になる。
12.3 複数チーム間での調整
Section titled “12.3 複数チーム間での調整”規模が大きくなると、チーム単独では解決できない依存関係が生じます。これらを解消するための仕組みが重要です。
スクラム・オブ・スクラム (SoS)
Section titled “スクラム・オブ・スクラム (SoS)”各チームから選出された代表者が集まり、チーム間の依存関係や障害を調整する場です。
- 目的: 自分のチームで行った作業が他チームにどう影響するかを共有し、ブロックされている問題を解決する。
- 運用: デイリースクラムの直後などに開催され、通常は15分程度のタイムボックスで行われる。
リリーストレイン
Section titled “リリーストレイン”複数のチームが共通の「出発時刻（リリース日）」に合わせて進行するメタ構造です。
- 特徴: 全チームが同じケイデンス（歩調）でスプリントを行い、定期的にシステム全体の統合とテストを行う。
- PSI（潜在的に出荷可能なインクリメント）: 数スプリントごとに、全チームの成果物を統合した大きな区切り（PSI）を設けてリリース判断を行う。
12.4 終わりに
Section titled “12.4 終わりに”理想は全てのチームが「フィーチャーチーム」として独立して動けることですが、現実には専門知識の偏りからコンポーネントチームが必要な場面もあります。重要なのは、チーム間の壁を低くし、常に「エンドユーザーへの価値」を優先する構成を模索し続けることです。