フレームワーク活用ガイドひとことで言うと#
50人以上の開発組織でもアジャイルを機能させるために、チームレベル・プログラムレベル・ポートフォリオレベルの3階層でアジャイルの原則を適用するフレームワーク。個々のスクラムチームだけでなく、組織全体の方向性を揃える仕組み。
押さえておきたい用語#
- PI（Program Increment）
- 8〜12週間を1単位とするSAFeの基本リズムのこと。通常5回のイテレーション＋1回のイノベーション期間で構成。
- ART（Agile Release Train）
- 5〜12のスクラムチームをまとめたバーチャルな組織単位のこと。バリューストリームに沿って編成し、共通のリズムで動く。
- PIプランニング（PI Planning）
- 全チームが一堂に会し次のPIで何を達成するかを2日間で計画する大規模イベントのこと。SAFeの心臓部。
- RTE（Release Train Engineer）
- ARTの運営責任者のこと。スクラムマスターのART版として、チーム間の障害除去やプロセス改善を担う。
SAFeの全体像#
こんな悩みに効く#
- スクラムチームは回っているが、チーム間の連携がうまくいかない
- 大規模プロジェクトでアジャイルを導入したいが、どこから手をつけるかわからない
- 経営層とのアラインメントが取れず、現場のアジャイルが空回りしている
基本の使い方#
8〜12週間を1つのPI（プログラム増分）として設定する。
- 通常は5回のイテレーション（スプリント）＋1回のイノベーション&プランニング期間
- このPIがSAFeのリズムの基本単位になる
ポイント: PIは全チームが同じタイミングで回す。共通のリズムがSAFeの生命線。
全チームが一堂に会し、次のPIで何を達成するか計画する大規模イベント。
- 2日間で実施するのが標準
- ビジョンの共有 → チームごとの計画 → 依存関係の調整 → コミットメント
- 参加者はチームメンバー、プロダクトマネージャー、アーキテクトなど
ポイント: 対面（またはオンライン同期）で行うことで、チーム間の依存関係を直接解決できる。
5〜12のスクラムチームをまとめた「アジャイルリリーストレイン」単位で開発を進める。
- 各チームは通常のスクラムで動く
- ARTレベルでSystem DemoやInspect & Adaptを実施
- Release Train Engineer（RTE）がARTを運営
ポイント: ARTは組織図の部門ではなく、**価値の流れ（バリューストリーム）**に沿って編成する。
PI終了時に全体でふりかえりを行い、次のPIに改善を反映する。
- 定量データ（ベロシティ、品質指標など）を確認
- 問題の根本原因を分析
- 改善アクションを次のPIに組み込む
ポイント: チームレベルのレトロスペクティブだけでなく、ART全体での改善がSAFeの強み。
具体例#
背景: 10チーム・100名のシステム開発部門。各チームが個別にスクラムを実践しているが、リリースタイミングがバラバラで統合テストに毎回2ヶ月かかっている。
PIプランニング: 全10チームが2日間のPIプランニングに参加。次の10週間で達成する目標と依存関係を洗い出し。チームAの機能がチームBのAPIに依存していることが判明し、その場でスケジュールを調整。
ART運営: 2週間スプリント×5回のPIを開始。隔週のSystem Demoで統合状態を確認。問題を早期発見し、PI途中で軌道修正。
成果:
| 指標 | SAFe導入前 | SAFe導入後 |
|---|---|---|
| 統合テスト期間 | 2ヶ月 | 2週間 |
| リリース頻度 | 年2回 | 四半期ごと |
| チーム間の依存関係解決 | 平均3週間 | PIプランニングで即日 |
| 経営層への進捗可視化 | 不十分 | PIごとに定量報告 |
結果: 統合テスト期間が2ヶ月から2週間に短縮。リリース頻度が年2回から四半期ごとに改善。経営層にも進捗が見える化された。
背景: 自動車メーカーの車載ソフトウェア開発部門。200名・25チーム。機能安全（ISO 26262）対応が必要で、純粋なアジャイルだけでは規制要件を満たせない。
SAFe構成: 3つのART（パワートレイン/インフォテインメント/ADAS）を編成。各ARTに8〜9チーム。Solution Train Engineerが3 ARTを統括。
工夫:
| 課題 | SAFeでの対応 |
|---|---|
| ISO 26262対応 | DoDに安全分析ドキュメントを含める |
| ハードウェア依存 | PIプランニングにHWチームも参加 |
| 車種間の共通化 | ポートフォリオレベルで共通プラットフォームを管理 |
成果: PIプランニングでHW/SW間の依存関係を直接調整し、車載ソフトの結合テスト工数が従来比45%削減。新車種の開発リードタイムが24ヶ月→18ヶ月に短縮。
結果: 機能安全要件を満たしつつアジリティを獲得。SAFeの階層構造が規制産業との相性の良さを実証した。
背景: 地方銀行のシステム部門40名。これまでウォーターフォールのみ。経営層がDX推進を宣言し、アジャイル導入を決断。SAFeを全レイヤー導入するのはリスクが大きいため、Essential SAFe（最小構成）から開始。
導入ステップ:
| フェーズ | 期間 | 内容 |
|---|---|---|
| 準備 | 2ヶ月 | アジャイルコーチ招聘、SAFe研修（全員参加） |
| パイロット | 3ヶ月 | 5チーム・1 ARTでモバイルバンキング開発 |
| 拡大 | 6ヶ月後〜 | 結果を見てポートフォリオレベルに拡張 |
パイロットPIの結果（3ヶ月・2 PI）:
| 指標 | PI 1 | PI 2 |
|---|---|---|
| PIプランニング完了率 | 70%（不慣れ） | 90% |
| PI目標達成率 | 65% | 82% |
| チーム満足度 | 3.2 | 4.0（5点満点） |
| リリース可能な機能数 | 8機能 | 14機能 |
結果: Essential SAFeから始めたことで導入のハードルを下げ、パイロットの成功体験で組織の信頼を獲得。6ヶ月後にポートフォリオレベルの導入を経営会議で承認。段階的アプローチが金融機関の慎重な文化に合致した。
やりがちな失敗パターン#
- 全レイヤーを一度に導入しようとする — SAFeはEssential・Large Solution・Portfolioと段階がある。まずEssential SAFe（ART1本）から始めるのが鉄則
- PIプランニングを形骸化させる — 準備不足で2日間を消化するだけのイベントになりがち。プロダクトマネージャーが明確なビジョンを持って臨むことが前提
- 従来のマネジメント構造をそのまま残す — SAFeを入れても指揮命令系統が変わらなければ効果は出ない。リーダーシップのマインドセット転換が不可欠
- RTEを兼務にする — RTEはART運営のフルタイム役割。PMと兼務させるとチーム間の障害除去が後回しになり、SAFeの効果が半減する
まとめ#
SAFeは、大規模組織でアジャイルを実現するための包括的なフレームワーク。PIプランニングで全チームの方向性を揃え、ARTという単位で価値を継続的に届ける。導入のハードルは高いが、組織全体のアジリティを本気で高めたいなら検討する価値がある。まずはEssential SAFeから小さく始めよう。