アジャイル手法は、ソフトウェア開発に革命をもたらし、世界中のチームにスピード、応答性、顧客中心主義をもたらしました。アジャイル運動の中核には、複雑な製品を開発し維持するための軽量なフレームワークであるScrumがあります。しかし、大企業がアジャイルを導入しようとすると、数百人、あるいは数千人にも及ぶ人々の間の連携、アライメント、ガバナンスに関連する課題に直面することがよくあります。
ここで登場するのが、Scaled Agile Framework (SAFe) のようなフレームワークです。Scrumが単一の小規模チーム向けの設計図を提供するのに対し、SAFeはリーンとアジャイルの原則を企業全体に適用するためのオペレーティングシステムを提供します。この2つのフレームワークの根本的な違いと関係性を理解することは、大規模な変革に着手する組織にとって極めて重要です。
こちらも参照：クロスプラットフォームアプリ 開発とは？Flutter/React Native比較と最新トレンド
Scrumの基本と構成要素
Scrumは意図的にシンプルです。通常10人以下の単一の、クロスファンクショナルで自己管理型のチーム向けに設計された軽量フレームワークです。
Scrumのコアコンポーネント：
- 役割（3つ）： プロダクトオーナー、スクラムマスター、開発者。チームは団結し、単一のスプリントゴールに向かって作業します。
- 作成物（3つ）： プロダクトバックログ（プロダクトゴールに導かれる）、スプリントバックログ（スプリントゴールに導かれる）、インクリメント（完成の定義によって検証される）。
- イベント（5つ）： スプリント、スプリント計画、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ。
Scrumの焦点： チームレベルでのスピード、品質、適応性。Scrumは、チームが（通常2～4週間の）すべてのスプリントで、出荷可能な可能性のあるプロダクトインクリメントを確実に提供することで、価値を最大化します。これは、製品作成を推進するエンジンです。
ギャップ： Scrumは、同じ大規模な製品に取り組む12の異なるチーム間で依存関係を調整したり、共有サービスを管理したり、投資を調整したりするためのメカニズムを本質的に提供しません。この連携の不足こそ、スケーリングフレームワークが解決しようとしているものです。
SAFe：大規模アジャイルフレームワーク
Scaled Agile Framework (SAFe)は、アジャイルのスケーリングにおいて最も広く採用されているフレームワークです。包括的で規範的であり、大企業がリーン・アジャイルプラクティスを実装するための構造化されたアプローチを提供します。SAFeは主に4つの構成レベル（Essential、Large Solution、Portfolio、Full）に基づいて構築されていますが、Essential SAFe構成が基礎構造を提供します。
SAFeの主要な構成要素：
- アジャイルリリース・トレイン（ART）： これはSAFeにおけるコアな運用単位です。ARTは、5～12のアジャイルチーム（Scrumチーム）からなる仮想組織であり、通常合計で50～125人で構成されます。ARTは、一定の周期（ケイデンス）で運用され、共に計画し、コミットし、実行します。
- プログラムインクリメント（PI）： PIは、ARTが価値を提供する期間（通常8～12週間）のタイムボックスです。これは、トレイン全体にとっての「スーパースプリント」として機能します。
- プログラムインクリメント計画（PI計画）： これは、通常2日間にわたる極めて重要なイベントであり、ARTのすべてのチームが今後のPIの作業を協力して計画し、依存関係を特定し、共通の目標でアライメントします。
SAFeの焦点： 大規模なチームグループ間でのアライメント、コラボレーション、ガバナンス。SAFeは、多数のチームが共有された戦略的目標に向かって作業できるようにするために必要な役割（リリース・トレイン・エンジニア、プロダクト・マネジメント、システム・アーキテクトなど）とイベントを提供し、摩擦や依存関係の問題を最小限に抑えます。
ScrumとSAFeの主な違い
ScrumとSAFeは対立するものではなく、補完的なものです。SAFeはScrumをその基本的な実行パターンとして使用します。 Scrumを車（チーム）のオペレーティングシステムと考えると、SAFeはその車のフリート（企業全体）の交通管制システムのようなものです。プログラムインクリメント（PI）の境界内でのコアな開発作業は、引き続きScrumフレームワークを使用して実行されます。
チームでのScrumとPIの連携
SAFe環境では、一般的なアジャイルチームは、より大規模なプログラムインクリメント（PI）の周期に統合するために、Scrumをわずかに適応させて利用します。
- ケイデンスのアライメント： Scrumスプリントは、PIカレンダーと完全に一致する必要があります。PIが10週間の場合、チームは5回の2週間スプリントを実行します。
- ゴールの階層： チームのスプリントゴールは、PI計画で定義された高レベルのPI目標に直接貢献する必要があります。これにより、戦術的なチームゴールが戦略的なプログラムゴールに結び付けられます。
- 役割： チームのスクラムマスターとチームのプロダクトオーナーは、それぞれプログラムレベルの対応者であるリリース・トレイン・エンジニア（RTE）とプロダクト・マネジメントと連携します。チームのスクラムマスターはチームの状態と障害除去に焦点を当てる一方、RTEはチーム間の障害除去とPIイベントの円滑化に焦点を当てます。
周期（ケイデンス）と計画の同期
主な違いは、SAFeが導入する同期レイヤーにあります。
- タイムボックスの差別化： Scrumのスプリントは、実行のための短く適応的なタイムボックスです。SAFeのPIは、計画と統合のための長く予測的なタイムボックスです。
- 計画の範囲： Scrum計画は、次の2週間で何ができるかに焦点を当てます。PI計画は、最初のスプリントが始まる前に、次の8〜12週間でトレイン全体によって何が提供されるべきかに焦点を当て、すべてのチームが同じ方向に向かって進んでいることを保証します。
Scrumの継続的な検査と適応のループ（デイリースクラム、レトロスペクティブ）は、SAFeのイベント（PI終了時の検査と適応ワークショップなど）を介してトレイン全体で同期されます。
| 特徴 | Scrum（チームレベルでの実行） | SAFe（プログラムレベルでの同期） |
|---|---|---|
| 適用規模 | 単一の自己管理チーム（通常3～9人の開発者）。 | 5～12のAgileチームのためのオペレーティングシステム（アジャイルリリース・トレイン）。 |
| 周期の期間 | スプリント（通常2週間）。 | プログラムインクリメント（PI）（通常8～12週間。4～5のスプリントを含む）。 |
| 計画の範囲 | スプリント計画（次の2週間の計画）。 | PI計画（次の8～12週間の計画）。 |
| 目標設定 | スプリントゴール。 | PI目標。戦略的テーマと連携する。 |
| 指導原則 | 経験主義（検査と適応）。 | アライメントと透明性。 |
Scrumのメリットと課題
軽量なフレームワークであるScrumは、現場レベルで価値を最大化するのに優れていますが、そのシンプルさゆえにスケーリングの課題が生じます。
Scrumの利点
- 迅速なフィードバックループ： 短いスプリントと頻繁なスプリントレビューにより、チームはステークホルダーから絶え間ないフィードバックを得ることができ、迅速な軌道修正が可能です。
- 高いチームの自律性： Scrumチームは自己管理型であり、開発者が作業を達成し、技術的な課題を解決するための最良の方法を決定する権限を与えます。
- 経験的プロセス制御： Scrumは経験主義（検査と適応）に基づいており、プロセスと製品品質の継続的な改善につながります。
- 低いオーバーヘッド： フレームワークはシンプルでプロセスのオーバーヘッドが最小限であるため、小規模チームでの採用と実行が迅速です。
Scrumの限界
- スケーリングの課題： 単一の製品に取り組む複数のチーム間での作業、依存関係、またはリリースの調整に関するガイダンスがScrumにはありません。
- 外部圧力に対する脆弱性： 適切な組織のサポートがない場合、Scrumのシンプルさが、外部のステークホルダーや経営陣によるスプリントゴールや開発チームの構造への干渉につながる可能性があります。
- 高い献身度の要求： 役割（特にプロダクトオーナー）は、フルタイムの献身と深いドメイン知識を必要としますが、これは大規模な組織では確保が難しい場合があります。
SAFeのメリットと課題
SAFeは、大規模な企業向けに構造とアライメントを提供することで、純粋なScrumのスケーリングの限界に対処するために特別に設計されています。
SAFeの利点
- 組織的なアライメント： SAFeのポートフォリオレベルと戦略的テーマにより、すべてのチームの努力（すべてのPI目標）が最高レベルのビジネス戦略に直接結び付けられ、チームが単に速く構築するだけでなく、正しいものを構築していることが保証されます。
- 予測可能性と依存関係管理： ARTの同期されたケイデンスとPI計画イベントにより、チーム間の依存関係の特定と解決が事前に強制され、統合リスクが劇的に軽減されます。
- 標準化されたアプローチ： SAFeは、役割、イベント、および作成物の完全で十分に文書化されたセットを提供するため、多くの部門やチーム全体で一貫して実装するのが比較的容易になります。
SAFeの限界
- ヘビーウェイトで規範的： SAFeは非常に詳細であり、多くの新しい役割と会議（例：リリース・トレイン・エンジニア、ソリューション・トレイン・エンジニア、PI計画）を導入するため、官僚的で小規模チームの速度を低下させる可能性があります。
- AINOのリスク： その構造上、一部の組織はリーン・アジャイルの考え方を真に受け入れることなくSAFeの仕組みを採用する可能性があり、**名ばかりのアジャイル（Agile In Name Only：AINO）**に陥る結果となります。
- 高いトレーニングと投資コスト： SAFeの実装には、効果的なアジャイルリリース・トレイン（ART）を立ち上げるために、トレーニング、認定、および内部コーチングにかなりの投資が必要です。
企業がSAFeを選ぶ理由
組織は純粋なScrumから始めるかもしれませんが、次の3つの主な理由から、SAFeのようなスケーリングフレームワークに移行することがよくあります。
- ビジネス戦略とのアライメント： SAFeは、開発努力を高レベルの戦略的テーマと予算配分に直接結び付けるポートフォリオレベルを提供し、チームが単に速く構築するだけでなく、正しいものを構築していることを保証します。
- 依存関係管理： ART内の複数のチームのケイデンスを同期することで、PI計画はチームにチーム間の依存関係を対面で特定して解決することを強制し、サイクルの後半での統合問題を劇的に軽減します。
- 予測可能性と透明性： PIケイデンスと結果として得られるPI目標は、組織全体に予測可能な心拍を作成し、ステークホルダーが次の10〜12週間で何が提供されるかについてより明確な理解を持つことを可能にします。
まとめ
結論として、Scrumは小規模チームが迅速に価値を提供するための最も効果的な方法であり続けます。しかし、組織が複数のチームが共有された製品やシステムで協力する必要があるレベルにまで成長した場合、SAFeのような堅牢なスケーリングフレームワークが不可欠になります。SAFeは、それらの小さく高速なScrumエンジンを、強力でアライメントされたエンタープライズマシンに調整するために必要な構造とガバナンスを提供します。
