Day 24: 1チームじゃ無理だ！巨大プロジェクトで複数のスクラムチームはどう協業すべきか？（LeSS, SAFe入門）
📝 TL;DR（3行で要約）
- 単一のスクラムチームは強力ですが、プロダクトが大規模化すると、複数チーム間の依存関係や方向性のズレといった新たな課題が噴出します。
- スケールドアジャイルフレームワーク（LeSSやSAFeなど）は、これらの課題を解決し、多数のチームが同じ目標に向かって連携（アラインメント）し、一つの大きな価値を生み出すための「交通整理の仕組み」です。
- LeSSはスクラムの原則をシンプルに拡張することを目指し、SAFeは企業全体のビジネス戦略と開発を連携させるための、より包括的で構造化されたアプローチを提供します。
🚀 1. スポーツカーから航空母艦へ：チームの成長がもたらす新たな「痛み」
皆さん、こんにちは！あなたのアジャイル・スプリント専門家です！これまで私たちは、一つのスクラムチームがいかにして俊敏に、そして効果的に価値を生み出していくかを探求してきました。一つのスクラムチームは、まるで高性能なスポーツカーです。小回りが利き、素早く加速し、変化の激しい道を巧みに走り抜けることができます。
しかし、あなたのプロダクトが大成功を収め、事業が拡大し、たった一つのチーム（スポーツカー）では運びきれないほどの大きな荷物（＝巨大なプロダクトバックログ）を運ぶ必要が出てきたらどうでしょう？スポーツカーを5台、10台と並べても、それぞれがバラバラの方向に走っていては、目的地にたどり着くどころか、互いに衝突して大事故を起こしかねません。
「人を追加することで、遅れているソフトウェアプロジェクトをさらに遅らせることができる」 — ブルックスの法則
この有名な法則が示すように、単純にチームの数を増やすだけでは、問題は解決しません。むしろ、コミュニケーションの経路が爆発的に増え、調整コストが指数関数的に増大し、開発はさらにカオスに陥ります。私たちが次に必要とするのは、スポーツカーの集団ではなく、一つの司令塔のもと、多数の戦闘機や支援部隊が連携して一つの任務を遂行する「航空母艦」のような、巨大で、かつ統率の取れた仕組みなのです。
この「複数チームの連携」という、スクラムが次に直面する大きな壁。これを乗り越えるために生み出されたのが、「スケールドアジャイル（Scaled Agile）」という考え方と、その具体的な実践フレームワークです。今回の記事では、なぜこの「スケール（規模拡大）」が必要になるのか、その際に発生する「痛み」の正体を明らかにし、代表的な解決策であるLeSSとSAFeという2つのフレームワークの世界を、皆さんと一緒に探検してみたいと思います！
🌪️ 2. 「ただチームを増やすだけ」が引き起こす、避けられない4つのカオス
1チームから5チーム、10チームへと組織が拡大する過程で、ほぼすべての組織が経験する「成長痛」があります。これらを放置すると、組織全体のアジリティを蝕む深刻な病へと発展します。
🚧 カオス①：悪夢の「依存関係地獄（Dependency Hell）」
- どんな状況？
- チームAの作業が完了しないと、チームBの作業が始められない。
- チームCが作ったコンポーネントにバグがあり、チームDとEの作業が完全にストップする。
- 「どのチームが先にやるか」の調整だけで、スプリント計画に丸一日かかってしまう。
- なぜ起こる？ 巨大なプロダクトは、本質的に多くの機能やコンポーネントが複雑に絡み合っています。各チームがプロダクトの一部分だけを担当するようになると、チーム間の境界線をまたぐ作業（依存関係）が必然的に発生します。これらの依存関係を可視化し、計画的に管理する仕組みがないと、チームはお互いの作業を待ち合うだけの「アイドル時間」だらけになり、全体の生産性は劇的に低下します。
🤷♂️ カオス②：「私たちはどこへ向かうのか？」ビジョンと優先順位の崩壊
- どんな状況？
- チームAは「パフォーマンス改善」が最優先だと信じ、チームBは「新規の顧客向け機能」が最優先だと考えている。
- 各チームがスプリントレビューで見せる成果物が、全く別の方向を向いており、一つのプロダクトとして統合性がない。
- それぞれのチームに異なるステークホルダーが別々の要求を出し、現場が大混乱に陥る。
- なぜ起こる？ チームが5つあれば、プロダクトオーナー（的な役割の人）も5人…という安易な構造は、プロダクト全体のビジョンを崩壊させます。各チームが自分の担当領域の最適化だけを考えると、プロダクト全体としての整合性や、「今、ビジネスとして本当に最も価値のあることは何か？」という問いに対する答えがバラバラになってしまうのです。
🧩 カオス③：「合体させたら動きません…」インテグレーションの悪夢
- どんな状況？
- 各チームがそれぞれのスプリントで「完成」させた機能を、スプリントの最後に結合しようとしたら、全く動作しない。
- インテグレーション（統合）のための作業だけで、数週間を要する「インテグレーション・スプリント」が常態化している。
- どのチームの変更が問題を引き起こしたのか、原因究明に膨大な時間がかかる。
- なぜ起こる？ スクラムの原則は、スプリントの終わりに「潜在的にリリース可能なインクリメント（Potentially Shippable Increment）」を生み出すことです。しかし、複数チームが協業する場合、この「インクリメント」は、全チームの成果物が統合された状態でなければなりません。継続的なインテグレーション（CI）の仕組みや、頻繁に同期を取るイベントがないと、各チームの「完成」はただの「部分的な完成」に過ぎず、最後の最後で巨大な手戻りが発生します。
🗣️ カオス④：「隣のチームが何をしているか誰も知らない」コミュニケーションの断絶
- どんな状況？
- チームAとチームBが、同じような機能を重複して開発していたことが後から発覚する。
- チームCが発見した重要な技術的知見が、他のチームに共有されず、チームDが同じ問題で時間を無駄にする。
- チーム横断でのアーキテクチャ設計や技術標準化の議論が行われず、プロダクト全体が技術的にバラバラ（サイロ化）になる。
- なぜ起こる？ チームの数が増えると、非公式なコミュニケーションだけでは情報が全体に行き渡らなくなります。チーム内のコミュニケーションは密でも、チーム間のコミュニケーションが希薄になると、組織全体として学習し、最適化していく能力が失われてしまいます。
これらの「カオス」は、スクラムが悪いのではなく、スクラムが本来想定していなかった「規模」の問題に直面しているサインなのです。この問題を解決するために、スクラムの原則を尊重しつつ、多人数・多チームでの協業を可能にするための「追加のOS」が必要になります。それがスケールドアジャイルフレームワークです。
🗺️ 3. カオスを乗りこなすための航海図：スケールドアジャイルフレームワークとは？
スケールドアジャイルフレームワークとは、前述のような大規模開発特有の課題を解決するために考案された、思考様式、役割、イベント、そして実践（プラクティス）の集合体です。
これは、スクラムを否定し、置き換えるものではありません。むしろ、スクラムという強力なエンジンを複数搭載した巨大な船を、どうやってうまく操縦し、港（＝ビジネスゴール）へと導くか、そのための「航海図」や「操船マニュアル」のようなものだと考えてください。
世の中には様々なスケールドアジャイルフレームワークが存在しますが、今回はその中でも特に有名で、対照的な思想を持つ2つのフレームワーク、LeSSとSAFeに焦点を当てて、その世界を覗いてみましょう。
🌱 4. LeSS (Large-Scale Scrum): スクラムを、もっと。スクラムの原則でスケールする
LeSSは、その名の通り、大規模スクラムを実践するためのフレームワークです。「More with LeSS（より少ないもので、より多くを）」というキャッチフレーズが示すように、その哲学は非常にシンプルです。
LeSSの核心思想：「スクラムで解決できない規模の問題は存在しない。解決策は、ルールを追加することではなく、スクラムの原則（透明性、検査、適応）を、より大規模に、より徹底的に適用することである。」
LeSSは、新しい役割や複雑なプロセスを導入することを極力避け、スクラムガイドに書かれているルールを、複数チームの状況にどう適用するか、という観点から構築されています。
🧭 LeSSの基本構造（LeSS: 2〜8チームの場合）
- 👑 1人のプロダクトオーナー (One Product Owner): これがLeSSの最も重要で、かつラディカルな特徴です。たとえチームが8つあっても、プロダクトオーナーはただ一人。これにより、プロダクト全体のビジョンと優先順位が単一の源泉から提供され、前述の「優先順位の崩壊」を防ぎます。プロダクトオーナーは全チームを率いる「プロダクトのCEO」として振る舞います。
- 📚 1つのプロダクトバックログ (One Product Backlog): プロダクトオーナーが一人なので、当然プロダクトバックログも一つです。全チームが、この単一のバックログから作業を取得します。これにより、全チームが常に「プロダクト全体にとって最も価値の高いこと」に取り組むことが保証されます。
- 🤝 複数のフィーチャーチーム (Multiple Feature Teams): LeSSでは、特定のコンポーネント（例：DBチーム、UIチーム）ごとではなく、顧客に価値を届ける機能（フィーチャー）を端から端まで開発できる「フィーチャーチーム」で構成することが強く推奨されます。これにより、チーム間の依存関係を最小限に抑えることができます。
- 🔄 共通の「完成の定義」とスプリント (One Definition of Done & One Sprint): 全チームが同じスプリントケイデンス（例：2週間）で活動し、スプリントの終わりには、全チームの成果物が統合された、単一の「潜在的にリリース可能なインクリメント」を生み出します。これを保証するために、全チーム共通の、より厳格な「完成の定義」が必要になります。
🎉 LeSSのイベント：スクラムを複数チーム向けにアレンジ
LeSSのイベントは、基本的にはスクラムと同じですが、複数チームが参加するためにいくつかの工夫が凝らされています。
- スプリントプランニング:
- Part 1: 全チームの代表者が集まり、プロダクトオーナーと共に、このスプリントでどのアイテムに取り組むかを決定します。
- Part 2: 各チームに戻り、自分たちが担当するアイテムをどのように完成させるか、詳細なタスク分割と計画を立てます。
- デイリースクラム: これは各チームで通常通り行います。チーム間の調整が必要な場合は、代表者が集まるScrum of Scrumsのような場を設けることもあります。
- スプリントレビュー: 全チームが参加し、統合されたインクリメントをステークホルダーにデモします。まるで、様々な出店が集まる賑やかな「バザール」のように、各チームが自分たちの成果を披露し、フィードバックを求めます。
- レトロスペクティブ:
- 各チームのレトロスペクティブ: まずはチーム内で振り返りを行います。
- オーバーオール・レトロスペクティブ (Overall Retrospective): 各チームの代表者、プロダクトオーナー、スクラムマスターが集まり、チーム間の連携や組織全体の問題について話し合い、改善策を決定します。
👍 LeSSが向いている組織
- 既に強力なスクラム文化が根付いており、自己組織化能力の高いチームが存在する組織。
- トップダウンの指示よりも、現場の自律性を重んじる文化を持つ組織。
- プロダクト中心の組織構造改革（フィーチャーチーム化など）に踏み切る覚悟がある組織。
LeSSは、スクラムの本質を愛し、その力を信じる人々のための、ミニマリスティックでパワフルなフレームワークと言えるでしょう。
🏢 5. SAFe (Scaled Agile Framework): 全社でアジャイルを。ビジネスと開発を繋ぐ巨大な羅針盤
一方、SAFeは、LeSSとは対照的に、より構造的で、包括的で、そして規定的なフレームワークです。その目的は、単に開発チームをスケールさせるだけでなく、企業のビジネス戦略、予算編成、ポートフォリオ管理といった上位のレイヤーと、現場の開発チームを完全に連携させることにあります。
SAFeの核心思想：「アジャイルな開発チームだけが俊敏に動いても、企業の意思決定や予算プロセスが旧態依然のままでは、真のビジネスアジリティは達成できない。組織の全部門が同じリズムで連携するための、共通のOSが必要である。」
SAFeは、何百人、何千人という規模の巨大な組織で、予測可能性と統制を保ちながらアジャイル開発を導入するための、詳細なブループリントを提供します。
🚂 SAFeの心臓部：「アジャイルリリーストレイン（ART）」
SAFeを理解する上で最も重要なコンセプトが、アジャイルリリーストレイン（Agile Release Train, ART）です。これは、5〜12チーム（約50〜125人）から構成される、長期間存続する「チームのチーム」です。ARTは、共通のビジネスミッションとビジョンに向かって、同じリズム（ケイデンス）で走り続ける列車に例えられます。
- 共通のケイデンス: ARTに所属する全チームは、プログラムインクリメント（Program Increment, PI）と呼ばれる、通常8〜12週間の共通のタイムボックスで活動します。PIは、複数のスプリント（通常4〜5回）で構成されます。
- 同期: 全チームのスプリントは、同じ日に始まり、同じ日に終わります。これにより、計画、デモ、学習のサイクルが組織全体で同期します。
✨ SAFeで最も重要なイベント：「PIプランニング」
PIプランニングは、ARTの全メンバーが一同に会して（あるいはバーチャルで）、次のPI（8〜12週間）の計画を立てる、2日間の巨大なワークショップです。これはSAFeの鼓動であり、魂とも言えるイベントです。
- 何が起こる？
- ビジネスオーナーやプロダクトマネジメントが、今後PIで達成したいビジネス目標（ビジョン）と、優先順位付けされたフィーチャーを提示します。
- 各チームは、それらのフィーチャーを自分たちのチームでどう実現するかを議論し、ストーリーに分割し、見積もり、チーム間の依存関係を特定します。
- 特定された依存関係は、「プログラムボード」と呼ばれる巨大なボード上で可視化され、チーム間で直接交渉し、解決策を見つけ出します。
- 最終的に、各チームは「PI目標（PI Objectives）」、つまり「このPIで私たちはこれらのビジネス価値を提供することを約束します（あるいは目指します）」という形で、自分たちの計画を発表します。
このPIプランニングを通じて、ARTの全メンバーが顔を合わせ、共通の目標を理解し、互いの計画を調整することで、強力なアラインメント（方向性の合致）が生まれます。
🎭 SAFeの新たな役割
SAFeは、ARTを円滑に運営するために、スクラムの役割に加えて、いくつかの新たな役割を定義しています。
- リリーストレインエンジニア (Release Train Engineer, RTE): ARTの「チーフスクラムマスター」とも言える存在。PIプランニングなどのイベントをファシリテートし、ARTレベルでの障害を取り除き、全体のプロセス改善をリードする、サーバントリーダーです。
- プロダクトマネジメント (Product Management): ARTレベルの「チーフプロダクトオーナー」のような役割。顧客やビジネスサイドと対話し、ARTが取り組むべきフィーチャーを定義し、優先順位を決定します。
- システムアーキテクト／エンジニア (System Architect/Engineering): ART全体の技術的なビジョンを示し、各チームが従うべきアーキテクチャのガイドラインや技術標準を定義します。
👍 SAFeが向いている組織
- 何百人、何千人規模の大企業で、トップダウンでのアジャイル変革を目指している組織。
- 規制の厳しい業界（金融、医療、航空宇宙など）で、高いレベルの予測可能性やガバナンスが求められる組織。
- 開発だけでなく、マーケティング、営業、法務といったビジネス部門も含めた、組織全体の連携を強化したいと考えている組織。
SAFeは、その包括性と規定的な性質から学習コストが高いという側面もありますが、巨大組織にアジャイルという新しいOSをインストールするための、非常に強力で実績のあるフレームワークです。
⚖️ 6. LeSS vs. SAFe：私たちの組織にはどちらが合う？
LeSSとSAFeは、どちらも素晴らしいフレームワークですが、その哲学とアプローチは大きく異なります。どちらを選ぶかは、あなたの組織の文化、規模、そしてアジャイル変革の目的によって決まります。
| 観点 | 🍃 LeSS (Large-Scale Scrum) | 🏢 SAFe (Scaled Agile Framework) |
|---|---|---|
| 哲学 | ミニマリズム。スクラムの原則をシンプルに拡張する。「経験主義」を重視。 | マキシマリズム。包括的で規定的なブループリントを提供する。「計画と連携」を重視。 |
| アプローチ | ボトムアップ型。強いチームが自律的にスケールしていくことを支援する。 | トップダウン型。経営層のリーダーシップのもと、組織全体に変革を導入する。 |
| 複雑さ | 低い。ルールや役割が少なく、理解しやすい。 | 高い。多くの役割、イベント、階層があり、学習コストが高い。 |
| 焦点 | プロダクト開発のスケールに焦点を当てる。 | 企業全体。ポートフォリオ管理、予算編成、ビジネス戦略との連携に焦点を当てる。 |
| 主な対象 | 2〜8チーム（LeSS）から数十チーム（LeSS Huge） | 数十〜数百チーム。大企業、エンタープライズ向け。 |
究極的には、「現場の自己組織化能力を信じて、ミニマムなルールでスケールしたい」ならLeSSが、「組織全体の足並みを揃え、予測可能性を担保するための詳細な地図が欲しい」ならSAFeが、より良い出発点になるかもしれません。
✨ 結論
スクラムチームが一つから複数へと成長する旅は、エキサイティングであると同時に、多くの困難を伴うものです。単に人を増やし、チームを増やすだけでは、生産性が上がるどころか、カオスが増大するだけという「ブルックスの法則」の罠が待ち構えています。
この罠を乗り越え、多数のチームが同じ心臓の鼓動を共有し、一つの大きな価値を生み出す生命体へと進化するために、スケールドアジャイルフレームワークは、私たちに強力な羅針盤を与えてくれます。
どちらの道を選ぶにせよ、最も重要なことは、これらのフレームワークが「銀の弾丸」ではないと理解することです。これらはあくまでも「地図」であり、旅をするのは私たち自身です。その根底に、透明性、検査、適応というアジャイルの原則と、顧客に価値を届けたいという情熱、そして互いへのリスペクトがなければ、どんな立派な地図も宝の持ち腐れになってしまいます。
あなたの組織という船は、今、どの海を航海していますか？そして、次に目指すべき港はどこですか？今日の話が、あなたの船に最適な航海図を見つけるための一助となれば、これほど嬉しいことはありません。
