SAFe：Scaled Agile Frameworkをわかりやすく解説

SAFe（Scaled Agile Framework）は、大規模企業にAgileを導入するうえで最も広く採用されているアプローチです。組織内に数百人のエンジニアや数十チームが存在し、複雑な製品ラインを単一のScrumでは対応しきれない場合、SAFeはそれらを一元的に調整しながら、すでに活用しているAgileの原則を捨てずに済む構造的な方法を提供します。

SAFeは万能ではなく、実際に批判も多いフレームワークです。ただ、SAFeが何を目的としたものであるかを正しく理解することが、自組織に合うかどうかを賢く判断するための第一歩になります。

SAFe（Scaled Agile Framework）とは何か？

SAFe（Scaled Agile Framework）は、エンタープライズ規模でAgileプラクティスを実装するための組織的・ワークフロー的なパターン集です。Scaled Agile, Inc.が開発・維持管理しています。Lean、Agile、システム思考のアイデアを組み合わせることで、数百人から数千人規模のチームが、より速く、高い品質で、ビジネス目標に沿った成果物を届けられるよう設計されています。

ScrumやKanbanを使っている小規模チームにSAFeは不要です。しかし、50、100、あるいは500チームが同じ製品ビジョンに向かって同時に出荷しなければならない場合、調整そのものがボトルネックになります。SAFeはそのボトルネックに対して、計画の明確な階層、共通のケイデンス、戦略と実行をつなぐ具体的な役割を定義することで対処します。

主要データ

• SAFeは、スケールでAgileを実践する組織の35%が採用しており、最も人気の高いスケーリングフレームワークです（State of Agile Report, 2023）。
• SAFeを導入した組織では、市場投入までの時間が30〜75%短縮されたと報告されています（Scaled Agile, Inc., 2022のケーススタディより）。
• このフレームワークは2011年の登場以来5つのメジャーバージョンを経て、2023年にSAFe 6.0がリリースされました。

SAFeの4つの構成

SAFeは一律のフレームワークではありません。組織の規模と複雑さに応じて4つの構成が用意されています。

多くの組織はEssential SAFeからスタートします。他の構成はオーバーヘッドを伴うため、その調整レイヤーが本当に必要な場合にのみ採用するのが賢明です。

中核概念：ART、PI Planning、各レベル

Agile Release Train（ART）

Agile Release TrainはSAFeの根幹です。ARTは、共通のミッションに向けて計画し、コミットし、一緒に成果を届ける長期的なAgileチームの集合体（通常50〜125人）です。複数の製品サイクルにわたって継続するバーチャルな組織単位と考えるとわかりやすいでしょう。

ART内のすべてのチームは同じイテレーションケイデンスに従います。通常は2週間のSprintです。全チームが同じ計画イベントに参加し、同一のProgram Increment（PI）タイムラインで動きます。この共通のケイデンスにより、常にトップダウンで指示を出さなくても、数十チームが同期して動けるようになります。

Program Increment（PI）Planning

PI PlanningはSAFeの心臓部です。8〜12週ごとに、ART内のすべてのチームが集まり、2日間の対面（またはオンライン）イベントを通じて次のIncrementの作業を計画します。チームは現在の製品の状態を確認し、ロードマップを見直し、次のPIで達成する具体的な目標にコミットします。

その成果物として、各チームのPI目標、チーム間の依存関係を可視化したARTボード、そしてリスク登録簿が作成されます。PI Planningが「SAFeの秘訣」と呼ばれることが多いのは、常に管理者が介入しなくても、チーム間に真の整合性をもたらすからです。一方で、時間的コストも大きく、そのオーバーヘッドに見合うのかを批判する声もあります。

各レベル

SAFeは作業を3つ（または4つ）のレベルに整理します。

チームレベル。 個々のAgileチームがSprintを実行し、チームのBacklogを管理し、レトロスペクティブやSprintレビューなど標準的なAgileセレモニーに参加します。このレベルのProduct BacklogがプログラムレベルのBacklogに接続されます。

プログラムレベル。 ARTが活動する場所です。チームはPI Planning、プログラムボード（チーム間の依存関係の可視化）、Program Increment Backlog（PI Backlog）と呼ばれる共有Backlogを通じて連携します。このレイヤーをRelease Train Engineer（RTE）がファシリテートします。

Large Solutionレベル（必要な場合）。 複数のARTが単一の大規模システムをともに構築する場合、このレイヤーがそれらを調整します。Solution Train EngineerとSolution Architectがソリューションレベルのバックログを管理し、Solution PI Planningを運営します。

ポートフォリオレベル。 ここで戦略と実行が結びつきます。ビジネスリーダーが投資テーマとバリューストリームを定義し、Lean Portfolio Management（LPM）を使って予算を設定し、ポートフォリオKanbanでフローを監視します。このレベルのエピックがプログラムレベルのフィーチャーに分解され、さらにチームレベルのストーリーへと落とし込まれます。

SAFeの役割

SAFeは各レベルにわたって豊富な役割を定義しています。実務で最もよく接する役割を以下にまとめます。

RTEはよく「トレインのスーパーScrum Master」と表現されます。フルタイムの役割であり、RTEの質がARTの実際の機能レベルを大きく左右します。

SAFeのメリット

スケールでの整合性。 PI Planningにより、エンジニアから経営幹部まで全員が参照できる共有計画が生まれます。各チームは自分たちの仕事が大きな製品ビジョンにどう結びついているかを把握できます。大規模組織でこのような整合性を確保することは希少で、かつ非常に価値があります。

予測可能なデリバリー。 すべてのチームが同じPIケイデンスで動いているため、リーダーシップは合理的な精度で成果物の見通しを立てられます。PIが始まる前に、そのPI内でおおむね何が届くかをあらかじめ把握できます。

フィードバックループの短縮。 SAFeはチームに対して2週間ごとに動くソフトウェアを届けることを求め、各PIの終わりにシステムデモを実施します。多くの企業がいまだに採用している従来のWaterfallリリースサイクルと比べて、フィードバックループが格段に短くなります。

ビジネスアジリティの組み込み。 Portfolio SAFeのLean Portfolio Managementにより、経営幹部は次の年次予算サイクルを待たずにバリューストリーム間で投資を移動させる手段を持てます。真の継続的ファンディングとは言えませんが、典型的な企業計画よりも大幅に柔軟性が高まります。

コミュニティとツールの充実。 SAFeには認定プラクティショナーの大きなコミュニティがあり、Jira Align、Rally、Planviewなどのプラットフォームからも強力なツールサポートが得られます。このエコシステムが導入を加速します。

批判と限界

SAFeには真剣な批判があり、導入を決める前にその指摘を真摯に検討することが重要です。

重厚すぎる。 SAFeは既存のチームの業務に多くの役割、成果物、セレモニーを追加します。「Agileとはシンプルで適応的なものであるべき」と考える組織にとって、SAFeはむしろその逆に感じられることがあります。

設計上トップダウン。 根強い批判の一つは、SAFeがAgileというラベルのもとで従来の管理階層を再現しているというものです。Business OwnersがPI目標を承認し、予算はポートフォリオレベルから流れ下り、チームはビジネスステークホルダーが大きくコントロールするロードマップに沿って計画します。これはAgile Manifestoの根幹にある自己組織型チームとはかけ離れています。

「SAFeはAgileではない」。 Agileコーチや思想的リーダーたちの中には、SAFeの硬直性がAgile的価値観に反すると主張する声があります。Manifesto原署名者の一人であるDave Thomasをはじめとする人々は、SAFeが人よりもプロセスを制度化していると批判しています。Ron JeffriesはSAFeを「余分なステップを加えたDark Scrum」と呼んでいます。激しい言葉ではありますが、根底にある懸念は現実的です。組織がAgileのマインドセットを失ったままSAFeのセレモニーだけを採用するリスクが存在します。

Velocityで誤解が生じる可能性。 SAFeチームがPIレベルでVelocityを計測しながら、その数値がユーザー価値に結びついているかを問わない場合、アウトカムよりもアウトプットを最適化してしまいます。SAFe自体はこれを防ぐ仕組みを持たず、PI目標へのコミットプレッシャーがそれをさらに悪化させることがあります。

認定文化の問題。 SAFeの認定エコシステム（SAFe Agilist、RTE、POPMなど）は、Agileの精神とずれているとする批判もあります。認定がコンピテンシーの証ではなく、チェックボックスになりうるのです。

これらのことはSAFeが自組織に不適切だと意味するわけではありません。しかし、目を開けて導入することで、メリットを享受せずに官僚主義だけを実装してしまうリスクを避けられます。

SAFeの導入方法

Scaled Agile, Inc.は実装ロードマップを公開しています。以下はその平易な日本語版です。

ステップ1：リーダーシップチームをトレーニングする

シニアリーダーが理解し、コミットしていなければSAFeは機能しません。まず経営幹部、Director、シニアマネージャーを対象に2日間の「Leading SAFe」コースを実施します。リーダーがWaterfallのポートフォリオ計画を続けながらチームだけSAFeを走らせようとすれば、フレームワークはその接続部分で崩壊します。リーダーシップの整合性は交渉の余地がありません。

ステップ2：バリューストリームとARTを特定する

自組織が顧客に届ける仕事を、組織図ではなくバリューストリームの観点でマッピングします。バリューストリームとは、顧客が価値を感じる製品やサービスを生み出すための一連のステップです。各バリューストリームがARTの境界になります。2つ目のARTを定義する前に最初のARTを定義してください。5つのARTを同時に立ち上げるよりも、学んで調整してから展開するほうがはるかに容易です。

ステップ3：実装計画を作成する

PIの期間（8週間か12週間か）を決め、最初のPI Planningイベントを計画し、ARTを構成するチームをトレーニングし、役割（RTE、Product Management、System Architect）を設定します。初日からすべての役割を完璧に埋める必要はありませんが、フレームワークを理解した人物が中核的な役割を担うことが必要です。

ステップ4：チームをトレーニングし、ARTを立ち上げる

SAFe for Teamsトレーニングと最初のPI Planningを組み合わせた2日間のART Launchイベントを開催します。すべてのチームメンバーがフレームワークを理解し、最初のPIプランが出来上がります。これが混乱することは予想の範囲内です。最初のPI Planningがスムーズにいくことはほとんどありません。それは正常であり、問題ありません。

ステップ5：実行をコーチする

最初の数PI期間は継続的にコーチを行います。RTEとScrum Masterは、チームがケイデンスを内面化できるよう支援する必要があります。よくある失敗ポイントは、チームがイテレーションレビューをスキップすること、PI目標があいまいすぎて評価できないこと、誰も更新しないプログラムボードでの依存関係トラッキングです。

ステップ6：拡張・改善する

2〜3 PI経過後、何がうまくいき、何がうまくいかなかったかを評価します。各PIの終わりに徹底したInspect and Adapt（I&A）ワークショップを実施し、実行可能な改善策を生み出します。最初のARTが安定してから、2つ目のARTやPortfolio SAFeへの拡張を検討してください。問題を抱えたままプロセスをスケールさせると、問題が大きくなるだけです。

SAFe vs 他のスケーリングアプローチ

チームレベルでScrumbanを検討している場合や、スケーリングアプローチを選ぶ前にAgile vs Scrumの比較を整理したい場合は、まずそれらを確認してください。チームレベルで選ぶプラクティスが、その上でどのスケーリングフレームワークがうまく機能するかに影響します。

よくある質問

SAFeはまだAgileと言えますか？

実装の仕方によります。SAFeはAgile原則を取り入れ、Agileセレモニーを採用していますが、構造化された階層とトップダウンの計画サイクルは一部のAgile的価値観に反します。うまく実装すれば、真に適応力のある組織が生まれます。うまくいかない場合は、古い指揮統制のダイナミクスをそのまま残しながら、アジリティの外観だけを作り出すことになります。

Program Increment（PI）の期間はどのくらいですか？

PIは通常8〜12週間です。多くの組織は5つの2週間イテレーションで構成される10週間PIを使います。最後のイテレーションは通常、クリーンアップ、品質強化、次のPI計画に使われるInnovation and Planning（IP）イテレーションとなります。

SAFeを導入するのに認定が必要ですか？

いいえ。認定はチームがフレームワークをより速く習得する助けになり、RTE認定はコーチングする際の信頼性を与えます。ただし、公式認定を最小限に抑えつつ内部コーチングと実践への投資によって、SAFeを成功させている組織も存在します。認定エコシステムは有用ですが、成功のための必須条件ではありません。

Agile Release Trainは何チームで構成されますか？

ARTは通常5〜12チームで構成され、各チームのメンバーは5〜9人です。したがってARTのサイズは50〜125人になります。125人を超える場合は、2つのARTに分割するか、Large Solution構成に移行することを検討する必要があります。

SAFeにおけるEpicとFeatureの違いは何ですか？

EpicはポートフォリオまたはLarge Solutionレベルで定義される大規模なビジネス的または技術的イニシアティブです。FeatureはEpicの一部を実装するために、プログラムレベルで定義される小規模な成果物です。チームはFeatureをチームBacklogのユーザーストーリーへとさらに分解します。Epic→Feature→Storyの階層が、戦略から日々の実行に至るまで仕事が流れる仕組みです。

SAFeが正しく機能する点と今後の進め方

SAFeは誰にでも合うわけではありません。しかし、調整の問題、ロードマップの不整合、デリバリーの遅さに本当に悩んでいる大規模組織にとっては、具体的なスタート地点を提供してくれます。フレームワーク最大の価値はセレモニーそのものではありません。これまで共通リズムを持たなかったチーム間に共通言語とケイデンスをもたらすことにあります。

小さく始め、誠実にトレーニングし、真のInspect and Adaptセッションを実施してください。SAFeから最大の成果を得る組織は、SAFeを永続的なゴールではなく、スタート地点の構成として扱っています。

デリバリーアプローチをまだ検討中であれば、Extreme ProgrammingはSAFeと並んで検討する価値のある、よりエンジニアリング重視の選択肢を提供しています。

関連記事

• Agile方法論とは？
• Scrumとは？
• AgileとScrum
• Sprint Planning
• Agileセレモニー
• Product Backlog
• Agile Manifesto
• Scrumban