アジャイル開発であっても「チーム人数が増えてきたので分割したい」あるいは「他のチームが作ったプロダクトと連携したい」など、チーム間の調整が必要になることがあります。しかし、チーム数が増えてくると、その調整に時間がかかり、意思決定のスピードが落ちたり、待ち時間が出てしまうことがあります。そんなときに大切なのは「チーム同士のつなぎ方」です。
Scrumにおける代表的な3つのアプローチである、LeSS、SoS、Scrum@Scaleを比較しながら、複数のアジャイルチームをつなぎ、協調して動くための構造について考えていきます。
中央集権でつなぐ（ピラミッド）
従来型のプロジェクトでは、ピラミッド型の組織構造がよく採用されます。これは、上位層で意思決定を行い、その判断を階層的に下ろしていくことで、チーム同士を統制しながらつなぐ方法です。
PM1人では管理しきれないため、PMOや領域ごとにサブPMを設置し、各チームからの進捗を集約するための報告資料を作成させ、定期的に報告会議を実施する、といった運用になります。
全体を中央で管理できるため、ガバナンスを効かせやすく、複雑な業務でも誤差なく遂行しやすいという利点があります。
一方で下層のチームには自律性はなく、チーム同士が調整したくとも、上層に情報が集約され、判断されるまで待つ必要があります。結果として調整のスピードが遅くなります。また、こうした仕組みは、コミュニケーションのためのプロセスや資料作成が多くなり、結果として全体の動きが重くなりがちです。変化への柔軟な対応が難しく、状況に応じた対応を求められる現代のプロダクト開発には不向きです（一般的な会社組織の中に現れるサイロ化も似たような問題を抱えていますが）。
アジャイルチーム同士をつなぐ
一方で、アジャイルチームでは、各チームに自律性をもたせ、エンジニアの創造性を引き出します。アジャイルチーム同士のつながりが増えていくにしても、こうしたチームの自律性や創造性を維持する必要があります。
そこでScrumをスケーリングをするための手法であるLeSS（Large-Scale Scrum）、SoS（Scrum of Scrums） 、Scrum@Scaleについて紹介していきます。これらの手法はScrumの良さを維持しながら、チーム同士をつなぐための構造を持っています。
なお、SAFeについては、 SAFe(Scaled Agile Framework)が、再び「採用を控えるべき技術」に選定される - arclamp という状況なので省きます。
ひとつのゴールに向かってスケールアウト（LeSS）
LeSS（Large-Scale Scrum） は、2005年頃に Craig Larman と Bas Vodde が提唱した手法です。
LeSSは、Scrumの基本的な構造である「1プロダクトオーナー、1プロダクトバックログ」を壊さずにそのまま拡張するのが特徴です。最大8チームまでが同じスプリントのリズムで動きます。チーム同士は、同じプロダクトバックログを共有しながら、イベントを通じてつながる、スケールアウト型のイメージです。
各チームはプロダクトバックログを共有し、スプリント計画・レビュー・ふりかえりといったイベントも共有され、あたかも“大きな1チーム”のように一体的に開発を進めます。スプリント計画やふりかえりなどは階層化され、部分的には代表者だけで運用しますが、全体としての階層化を避けています。
9チーム以上になる場合は、 LeSS Hugeと呼び、要素エリア（Requirement Areas）ごとにPOとチーム群を配置して階層化しますが、それでも2階層までにとどめ、Scrumの原則を保とうとします。
LeSSのシンプルさは、Scrumの仕組みを可能な限り維持しながらスケーリングしようとしていることです。
自律したチームを緩やかにつなぐ（SoS）
Scrum of Scrums（SoS） は、2001年に Jeff Sutherland によって紹介された実践ノウハウです（参考：スクラムオブスクラムズ | Atlassian）。
SoSは「複数スクラムによるスクラム」という名の通り、各チームの代表者が集まった仮想チームを作る、というシンプルな考え方です。組織の中にある、異なるプロダクトや異なるリズムのチームをつなぐことができます。
この仮想チームの運用も、Scrumの仕組みに従います。ただし、かなり緩やかな運用が許容され、チーム同士のコミュニケーションの必要性や目的に応じて、代表者を変えたり、タイミングを変えたり、柔軟にアレンジすることができます。チーム同士が緊密に情報を共有して意思決定することもできれば、相互に関係する話題だけを軽く共有するような場にしても良いでしょう。
SoSは、Scrumチーム間の関係にもScrumの仕組みを再帰的に適用することで、各チームが独立しながらも、協調する状態を目指します。
多様なチームを階層で緩やかにつながる（Scrum@Scale）
Scrum@Scale は、2014年に Jeff Sutherland によって提唱されたフレームワークです。Scrum@Scaleは、組織の中にある複数のScrumをつなぐためのアプローチです。さきほどのSoSは実践ノウハウですが、明確にフレームワーク化されています。
Scrum@Scaleの大きな特徴は、「POサイクル（価値判断）」と「SMサイクル（実行支援）」という2つの役割的な流れを、それぞれ階層的に繋げていく点にあります。
- POサイクルでは、チームのPOたちが上位のメタスクラムに集まる。そのメタスクラムの代表POがエグゼクティブメタスクラムに集まる
- SMサイクルでは、各チームのスクラムマスターがScrum of Scrumsに参加する。そのSoSの代表スクラムマスターがScrum of Scrums of Scrumsに集まる
階層化をするためのグルーピングは、チーム間の関係性によって分割することになります。より近い関係にあるチームは同じメタスクラム（SoS）に所属させるべきでしょう。
組織の中で複数のプロダクトがあるなら、大抵の組織では、このようなグループ化と階層化になるはずです。大事なのは、それぞれのグループや階層がScrumであり、自律性がある点です。上の階層は、下層のチームが成果を出すためにやることであって、中央集権化するためのものではありません。
このようにScrumの仕組みが各レイヤーに“自己相似”の形で現れるフラクタル構造（木の枝や雪の結晶のように、全体と部分が似た形を繰り返す構造をしめす用語）になっています。フラクタルと言われると無限階層化出来そうですが、現実には3階層程度で運用されているようです。
どのアプローチがどんな場面に合うのか？
それぞれのアプローチが、どんな状況に合うのかを以下の表にまとめました。
| 状況 | 参照する手況 | 概要 |
| 1つのプロダクトを複数チームで開発 | LeSS | イベント共有・判断とリズムを統一 |
| チームは独立しているが、ゆるやかにつなぎたい | SoS | 各チーム代表者による仮想チーム |
| 複数プロダクトの組織全体を整合したい | Scrum@Scale | POサイクルとSMサイクルによる階層化 |
整理すると「そらそうやろ」という感じでしょうが、各用語で調べればさらに細かいノウハウが整理されているので、参考になるはずです。
まとめ：チーム同士のつなぎ方は“チーム同士の関係性”で決まる
アジャイルチーム同士のつなぐといっても、様々な状況があり、それによって選択すべき構造も違います。大事なのは、チーム同士の関係性です。
- チーム全員がまったく同じプロダクトを作るなら、判断基準や作業リズムも揃えて進める構造が有効
- 似たような方向性を持ちながらも異なるプロダクトやサービスに関わっている場合では、各チームが個別のリズムで進むことを許容しつつ、全体の方向性や価値判断を上位レベルで整合させるような構造が求められる
アーキテクチャが好きなら密結合と疎結合のことだし、ドメイン設計やコンポーネント設計と同じだね、という印象になると思います。コンウェイの法則は慧眼。
アジャイルチーム同士のつながりが増えていっても、価値の整合性とスピード感を維持するには、チーム間のコミュニケーションを最適化しなくてはなりません。そこではチーム同士の関係性を密にするか、疎にするかというデザインが鍵になります。このチーム間の関係性が見えてくれば、どの手法を参考にするかは、自然と見えてくるはずです。
