SAFe(Scaled Agile Framework、大規模アジャイルフレームワーク)

1. 概要

定義: SAFeは、Dean LeffingwellとScaled Agile, Inc.が2011年に公開した大規模組織向けのアジャイル全社拡張フレームワークであり、リーン(Lean)・アジャイル(Agile)・DevOps・システム思考を組み合わせて、数十〜数百名が参加する多数のチームをアジャイル・リリース・トレイン(ART、Agile Release Train)という価値提供単位に同期させ、チーム(Team)・プログラム(Program/Essential)・大規模ソリューション(Large Solution)・ポートフォリオ(Portfolio)の各階層を一つの運用モデルに整合させることでビジネス・アジリティ(Business Agility)を達成しようとする体系である。

SAFeが登場した背景は、スクラム(Scrum)やエクストリーム・プログラミング(XP)のようなチーム単位のアジャイルが収めた成功を、大企業全体へ拡張する際に生じる構造的な限界にある。 単一のスクラムチームは5〜9名規模で自律的によく機能するが、一つの製品を数十チームで共に作らねばならない金融・通信・製造・公共のような大規模組織では、チーム間の依存、共有アーキテクチャ、リリース日程の調整、予算・ガバナンスといった問題がチームレベルのアジャイルだけでは解決されない。 各チームがそれぞれ異なる速度と優先順位で動くと、統合時点に品質事故と日程遅延が集中し、経営陣が求める予測可能性と投資説明責任(accountability)を確保しにくくなる。

第二の背景は、従来の段階的(ウォーターフォール)・年次予算ベースのポートフォリオ管理とアジャイル提供との断絶である。 現場チームが2週間スプリントで素早く提供する一方で、上位組織が依然として年単位でプロジェクトを承認し固定範囲・固定予算を強制すると、アジャイルの適応性が上層部で消滅してしまう。 SAFeはこの溝を埋めるために、リーン・ポートフォリオ・マネジメント(LPM)、バリューストリーム(Value Stream)ベースの資金調達、四半期単位の計画・検査・適応のリズムを提示し、戦略と実行を一つの流れでつなごうとする。

第三の背景は、人員・日程・ガバナンスの予測可能性に対する経営陣の現実的な要求である。 大規模組織は「いつ何が出るのか」を投資意思決定と市場への約束の根拠とせねばならないため、完全に無計画なアジャイルを受け入れにくい。 SAFeはPI(Program Increment、通常8〜12週)という固定タイムボックスと、その起点のPIプランニング(PI Planning)イベントを通じて、自律性と予測可能性という相反する要求を折衷するという点で、「現実妥協型の大規模アジャイル」との評価を受けている。

2. SAFeの構成体系と4つのコンフィギュレーション

SAFeの核心は、組織の規模と複雑性に応じて4つの構成(Configuration)を選択的に適用するようにした拡張可能(scalable)な参照モデルである点にある。 最も小さいEssential SAFeから出発し、必要に応じて上位階層を追加する構造であるため、組織は自らの文脈に合う最小構成だけを導入できる。 以下の概念図は、4つの構成と各階層(レベル)の包含関係を全体的に示している。

flowchart TB
    subgraph PF["ポートフォリオレベル(Portfolio)"]
        LPM["リーンポートフォリオ管理(LPM)"]
        EPIC["エピック(Epic)・戦略テーマ"]
    end
    subgraph LS["大規模ソリューションレベル(Large Solution)"]
        STE["ソリューショントレイン(Solution Train)"]
        SOLB["ソリューションバックログ"]
    end
    subgraph ES["プログラムレベル(Essential/ART)"]
        ART["アジャイルリリーストレイン(ART)"]
        PIP["PIプランニング・PI実行"]
    end
    subgraph TM["チームレベル(Team)"]
        SCRUM["スクラム・カンバンチーム"]
        XP["XP技術プラクティス"]
    end
    PF --> LS --> ES --> TM
    EPIC --> SOLB --> ART
    LPM -. 資金・ガードレール .-> ART

チームレベル(Team Level)はSAFeの土台であり、各チームはスクラムやカンバンを用い、XPの技術プラクティス(継続的インテグレーション・テスト自動化・リファクタリング)を適用する。 SAFeではチームが単独で動かず、必ず上位のARTに所属して共通のリズム(cadence)と同期点を共有する点が一般的なスクラムと異なる。 チームが自律的にバックログを管理しつつ、チームの成果物がART全体のPI目標に寄与するよう上方に整合されることが核心である。

プログラムレベル(Essential SAFe)の中心はアジャイル・リリース・トレイン(ART)である。 ARTは通常50〜125名(5〜12チーム)で構成される「仮想の組織」であり、一つの共通したビジョン・バックログ・リリース日程を共有し、PI単位で共に計画し共に提供する。 ARTは決まった時刻に出発する「列車」に例えられるが、これは個々のチームが遅れてもトレイン自体は日程どおりに出発するというタイムボックス固定・範囲可変(fixed time, variable scope)の原則を象徴する。

大規模ソリューションレベル(Large Solution)は、航空・国防・大型金融システムのように複数のARTと供給業者が一つの巨大なソリューションを作らねばならないときに追加される。 この階層では、複数のARTを束ねるソリューショントレイン(Solution Train)とソリューションアーキテクト、ソリューションバックログが導入され、ART間のアーキテクチャ・インタフェース・規制遵守を調整する。 ほとんどの組織はこの階層を必要とせず、過度に導入するとかえって官僚性が増す点に留意せねばならない。

ポートフォリオレベル(Portfolio)は、全社戦略と資金を提供実行につなぐ最上位階層である。 ここでは戦略テーマとエピック(Epic)をリーンポートフォリオ管理(LPM)で扱い、プロジェクト単位ではなくバリューストリーム(Value Stream)単位で持続的資金(persistent funding)を配分する。 またガードレール(guardrails)を設定し、分散した意思決定を許容しつつ戦略的一貫性と投資上限を維持する。

3. 中核のリズムと役割: PIプランニングとART運用

SAFeを他の拡張フレームワークと区別づける最も象徴的な仕掛けは、PIプランニング(PI Planning)という同期イベントである。 PIプランニングは、ARTに所属する全チームが一堂に(物理的またはバーチャルに)集まり、次のPI(8〜12週)の目標とチーム間の依存、リスクを2日にわたって共に計画する行事であり、「ARTの心臓の鼓動(heartbeat)」と呼ばれる。 全チームが同時に計画を立てることで依存とボトルネックが計画段階で可視化され、統合時点に集中していたリスクが先制的に管理されることが核心的価値である。 以下の概念図は、PI1周期の典型的なプロセスの流れを詳細に示している。

flowchart LR
    V["ビジョン・ロードマップ準備"] --> PIP["PIプランニング(2日)"]
    PIP --> OBJ["PI目標・チームボード確定"]
    OBJ --> IT1["反復1〜n(2週スプリント)"]
    IT1 --> SD["システムデモ(反復ごと)"]
    SD --> IP["IP反復(Innovation & Planning)"]
    IP --> INSP["検査・適応(Inspect & Adapt)"]
    INSP --> V

PI周期は通常4〜5回の2週反復(iteration)と、最後のIP反復(Innovation and Planning iteration)で構成される。 IP反復は革新・学習・日程緩衝(buffer)・次PI準備のための余裕時間であり、過度な稼働率(utilization)100%がかえって流れを塞ぐというリーンの洞察を制度化した仕掛けである。 各反復の終わりのシステムデモ(System Demo)ではART全体が統合された成果物を実演し「本当に動く増分」を検証し、PIの終わりの検査・適応(Inspect & Adapt)ワークショップで定量指標をもとに振り返り改善バックログを作る。

SAFeは役割も階層別に定義する。 プログラムレベルにはART全体の提供を促進するRTE(Release Train Engineer、主席スクラムマスター格)、製品方向を担うプロダクトマネジメント(Product Management)、技術方向を導くシステムアーキテクト(System Architect)がいる。 チームレベルには既存のスクラムと同じくプロダクトオーナー・スクラムマスター・開発チームが配置され、プログラム役割とチーム役割が上下に連結される。 ポートフォリオレベルにはバリューストリームを担うエピックオーナー(Epic Owner)とエンタープライズアーキテクト(Enterprise Architect)が戦略的方向とアーキテクチャ・ランウェイ(Architectural Runway)を管理する。

実際の適用事例として、グローバル通信社など多数の大企業が数百のチームを数十のARTに束ねてPIリズムに合わせて提供するよう転換しており、公開された事例研究は出荷リードタイム短縮と欠陥減少、従業員エンゲージメント向上といった効果を報告している。 ただしこれらの数値は組織・導入成熟度により偏差が大きいため、特定の数値を一般化するよりも自らの基準線(baseline)に対する改善の有無を測定するアプローチが望ましい。

4. 類似する拡張フレームワークとの比較

大規模アジャイル拡張にはSAFeのほかにもLeSS(Large-Scale Scrum)、Scrum@Scale、Spotifyモデル、Nexusなどが存在し、各アプローチは「規模拡張」を見る哲学が異なる。 単にどれが優れているかの問題ではなく、組織の規模・ガバナンス要求・文化成熟度に応じて適した選択が変わるのが核心である。 SAFeは最も規範的(prescriptive)で役割・イベント・成果物が詳細に規定される一方、LeSSはスクラムの単純さを最大限維持しようと規則を最小化する。

SAFeの規範性の高さは長所であり短所でもある。 詳細な指針のおかげでアジャイル成熟度の低い大規模な伝統組織も「なぞれる地図」を得るが、同時に形式だけ導入して哲学が抜けた「機械的SAFe(mechanical SAFe)」へ転落する危険が大きい。 逆にSpotifyモデルは組織文化と自律性に依存するため、模倣は容易に見えても成功裏に体得するのは非常に難しい。 したがって技術士の観点では、「フレームワーク選択」よりも「組織文脈の診断と漸進的な転換戦略」が成否を左右すると見るべきである。

具体的な比較事例として、単一製品を作る300名規模の組織であれば共通スプリント・単一製品バックログを使うLeSSが依存管理により軽い場合がある一方、複数製品と規制報告・大規模予算ガバナンスが必要な金融持株会社であればLPMと多層構造を備えたSAFeが投資説明責任の面で有利である。 つまりツールの複雑性自体がコストであるため、「必要な最小構成」から出発することが共通の模範事例である。

5. 深化: SAFe 6.0、ビジネス・アジリティ、そして批判的視角

SAFeは継続的に改訂されてきており、2023年に公開されたSAFe 6.0はビジネス・アジリティ(Business Agility)を前面に掲げ、7つのコア・コンピテンシー(Seven Core Competencies)——チーム・技術アジリティ、アジャイル製品提供、エンタープライズソリューション提供、リーンポートフォリオ管理、組織アジリティ、継続的学習文化、リーン・アジャイルリーダーシップ——を測定・改善の軸として提示する。 特に、流れ(flow)を組織の全階層で最適化するための8つのフローアクセラレータ(flow accelerators)と、ITを越えてビジネス全領域へリーン・アジャイルを拡張する方向性が強調された。 最新の流れでは生成AIをバックログ精錬・テスト生成・PIプランニング補助に活用する議論も現れているが、これはまだ標準プラクティスとして確立したと断定しにくい。

SAFeに対する批判も技術士の答案でバランスよく扱わねばならない。 第一に、アジャイルコミュニティの一部はSAFeが中央集権的な計画とトップダウン構造を再導入し、アジャイル宣言の核心価値(個人と相互作用、変化への対応)を弱めると批判する。 第二に、役割・イベント・成果物が多く学習曲線と導入コストが大きく、コンサルティング・認証中心の商業的エコシステムに従属しやすいとの指摘がある。 第三に、組織が見た目だけ導入する「SAFe劇場(SAFe theater)」に陥ると、かえって官僚性が増し提供速度が低下しうる。 したがってSAFeは「銀の弾丸」ではなく、組織状況に合わせて裁断(tailoring)すべき参照モデルとして理解するのが妥当である。

6. 考慮事項および示唆点

SAFe導入を検討する技術士の観点では、次のような戦略的考慮が必要である。

• 最小構成からの漸進的拡張: 最初からFull SAFeを適用するよりも、Essential SAFeの単一ARTで始めて成果を確認した後に上位階層を追加する進化的導入(evolutionary adoption)がリスクを下げる。バリューストリーム識別(Value Stream Identification)を先行し、組織をARTにどう束ねるかをまず設計せねばならない。
• 文化・リーダーシップ転換の並行: フレームワークの形式だけ導入すると「機械的SAFe」で失敗する。リーン・アジャイルリーダーシップ、心理的安全性、測定指標の透明性といった文化基盤が共に転換されねばならず、変化管理(ADKAR等)と教育・コーチングへの投資が必須である。
• 技術プラクティスとDevOpsの整合: PIリズムが機能するには継続的インテグレーション・デプロイ(CI/CD)、テスト自動化、アーキテクチャ・ランウェイへの先行投資が前提となる。技術的負債が積もるとトレインが日程どおり出発できないため、内在する品質(Built-in Quality)とDevOpsパイプラインが成功の先決条件である。
• 指標ベースの検査・適応: フロー効率(flow efficiency)・リードタイム・予測可能性・従業員エンゲージメントなど定量指標を基準線対比で測定し、Inspect & Adaptで持続的に改善せねばならない。導入自体を目的化せず、ビジネス結果(価値提供速度・品質・顧客満足)で効果を検証する。
• トレードオフと代替の検討: 規範性が与える予測可能性と、それによる官僚性・従属性の間のトレードオフを認識し、組織規模が小さいか文化成熟度が高ければLeSS・Scrum@Scaleのような軽量代替や自前の裁断を積極的に検討する。
• 展望と連携技術: ビジネス・アジリティ・バリューストリーム管理(VSM)・プラットフォームエンジニアリング・生成AI補助との連携が拡大する見込みであり、組織設計の面ではチームトポロジー(Team Topologies)と相互補完的に活用し、認知負荷と流れを共に最適化するアプローチが有効である。

参考資料

• Scaled Agile, Inc., "SAFe 6.0 Framework". https://framework.scaledagile.com/
• Scaled Agile, Inc., "Agile Release Train". https://framework.scaledagile.com/agile-release-train
• Scaled Agile, Inc., "PI Planning". https://framework.scaledagile.com/pi-planning
• Dean Leffingwell, "SAFe Distilled: Achieving Business Agility with the Scaled Agile Framework", Addison-Wesley.

一言まとめ: SAFeはリーン・アジャイル・DevOpsを結合して多数のチームをアジャイル・リリース・トレイン(ART)とPIプランニングのリズムで同期させ、チーム・プログラム・ソリューション・ポートフォリオの各階層を整合させる大規模アジャイル拡張フレームワークであり、予測可能性と自律性の均衡を追求するが、文化・技術基盤なしに形式だけ導入すると「機械的SAFe」で失敗するため、最小構成から漸進的に裁断せねばならない。