📝 はじめに
私はこれまで約4年間、スクラムチームの一員としてアジャイル開発に携わってきました。
ただし、SAFe（Scaled Agile Framework）については実践経験がなく、これまでの知識は主に理論・机上にとどまっています。
そんな中、これからSAFeを採用しているプロジェクトに“開発者として参画”することになりました。
今回はその準備の一環として、SAFeをポジティブな面からではなく、ネガティブな面から調べて深掘りしていきたいと思います。
導入や運用というマネジメント視点ではなく、実際に参加するメンバーとして気になったことを中心に書いています。
📚 SAFeって何？
SAFe（Scaled Agile Framework）は、スクラムのようなアジャイル手法を大規模組織全体でスケールさせるためのフレームワークです。
特徴としては以下のようなものがあります：
- 数百人規模の大規模開発に対応
- PI（Program Increment）という10週間程度の計画サイクル
- 多数のロール（Product Manager、RTE、System Architectなど）
- アジャイルチームの連携を支える「ART（Agile Release Train）」という概念
一方で、これらの構造がアジャイルの本来の良さである変化への柔軟な対応や、現場の自律的な意思決定が失われてしまうのではないかという懸念の声もあります。
🚨 ThoughtWorks Technology Radarでの評価
ThoughtWorks Technology Radar は、グローバルなコンサルティング企業 ThoughtWorks が年に2回発表している、ソフトウェア技術に関するトレンドレポートです。
ThoughtWorks Technology Radar では、SAFeは「Hold」カテゴリに位置付けられています。(2025年度4月版)
| 評価 | 意味 |
|---|---|
| Adopt | We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects. (私たちは、業界としてこれらの項目を採用すべきだと強く感じています。適切なプロジェクトでは使っています。) |
| Trial | Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk. (追求する価値あり。この能力を育てる方法を理解することが重要です。企業は、リスクを許容できるプロジェクトでこの技術を試してみるべきです。) |
| Assess | Worth exploring with the goal of understanding how it will affect your enterprise. (あなたの企業にどのような影響を及ぼすかを理解することを目的に、探る価値がある。) |
| Hold | Proceed with caution. (慎重に進めるべき。) |
✅ 指摘されている主な懸念点
-
過剰な構造化と役割分担
→多くのレイヤーや役職が定義されており、柔軟性やチームの自律性が損なわれやすい。 -
トップダウンの意思決定構造
→管理層主導のため、現場の意見や改善提案が反映されにくくなる。 -
プロセス重視による形式主義
→手順や枠組みを守ることが目的化し、本来のアジャイルの価値が薄れる。
🔍 他にも参考になる批判的な視点
▶ A Short Critique of SAFe
Tom Geraghty氏による記事では、以下のような批判が展開されています：
組織の構造を変えずに“アジャイル導入感”を得るための手段になりがち
現場チームの裁量や自己組織化が機能しにくい
PI計画の硬直性によって変化に対応しづらくなる
▶ Redditなどの現場エンジニアの声
「SAFeはウォーターフォールにアジャイルの皮をかぶせただけ」
「10週間のPIスケジュールを立てても、すぐに無駄になることが多い」
「プロセスが重くて、開発よりも調整の比重が高い」
以上の点を踏まえ自分なりに引っかかった点を整理してみました。
🤔 スクラム経験者として引っかかった点まとめ
| ポイント | 内容 | 気になった理由 |
|---|---|---|
| ロールが多い | SAFeにはPM、PO、RTE、アーキテクトなど多数の役割がある | 「誰に何を聞けばいいのか」がわかりづらく、意思決定が遅くなりそう |
| イベントが多い | PI計画、ART Sync、System Demoなど | 会議が多すぎて、開発時間が削られそう |
| 計画が重すぎる | 10週間のPIスケジュールを前提とする | 変化が早いプロダクトには合わない可能性 |
| 自己組織化しづらい | トップダウンでの方針決定が多く、現場判断がしにくい | スクラムの“現場で最適を決める”文化と逆行している印象 |
| 依存関係のマネジメントが煩雑 | チームが多い分、連携調整が多発 | 調整1つでも時間がとられそう |
💡 何に気をつけるべきか（開発者視点）
- ThoughtWorks Technology Radarが指摘している点を基に何に気をつけるべきなのかを開発者視点で考えてみました。
🧩 ①「過剰な構造化と役割分担」
多く役割やレイヤーが定義されているため、チームが状況に応じて迅速に対応する柔軟性や自律性が失われる可能性があります。
🛠️ 気をつける点
-
定義された役割やレイヤーに縛られすぎない
- 役割分担が明確であることは良いことだが、チームのニーズに応じて柔軟に対応する。
-
チームの自律性を尊重する
- メンバーが自分たちで意思決定を行いやすい環境を作る。
🧩 ②：「トップダウンの意思決定構造」
SAFeでは、RTE（Release Train Engineer）、System Architect、Product Management などの
上位ロールが多く、意思決定の大部分がトップダウンで行われる傾向があります。
これはスクラムの「自己組織化」や「現場の創意工夫」とは相容れません。
🛠️ 気をつける点
-
現場で判断できる範囲を明確にし、積極的に意思決定する
- 例：技術選定はチーム判断でやる、設計の見直しはチームで合意して進めるなど。
-
上位ロールとの信頼関係を築く
- RTEやPMなどとオープンに会話し、チームの裁量権を尊重してもらえるよう対話を試みる。
-
あらゆるプロセスに対して「なぜ？」を持つ文化を作る
- 与えられた手順をただ実行するのではなく、背景や目的を理解することで、形骸化を防ぐ。
🧩 ③ 「プロセス重視による形式主義」
プロセスや手順を厳密に守ることが目的化してしまうと、アジャイルの本来の価値が薄れてしまうことがあります。
またSAFeには多くのイベント（PI Planning、Sprint Planning、Daily Standup、Sprint Review、Retrospectiveなど）があるため、形式的に行われるだけで、実際の目的や価値が失われる可能性があります。
🛠️ 気をつける点
-
スクラムの基本原則を意識して残す努力をする
- 手順や枠組みを守ることが目的化しないように、本来のアジャイルの価値（顧客価値の提供、継続的な改善、適応性）を常に意識する。
-
現場で“小さなアジャイル”を守る
- チーム単位でスクラムイベント（スプリントレビュー・レトロ・デイリースクラム）を形式ではなく意味のあるものにする工夫をする。
🔚 まとめ
- ThoughtWorksや他の指摘は、SAFe自体を否定するではなく、アジャイルの本質的な価値を見失わずに適切に運用する必要性を強調していると理解しました。
- 私は今後、SAFeの現場に開発者として参画する立場なので、「形式に流される」のではなく、「現場でできる工夫」を少しでも実践していきたいと思っています。
🔗 参考リンク
- Technology Radar | SAFe - ThoughtWorks
- A Short Critique of SAFe (Tom Geraghty)
- Reddit: Criticism of SAFe
- Implementing SAFe - Challenges and Recommendations
今後、実際にSAFeの現場に入った後、「どうだったか？」の実録編も書いてみたいと思います。
Discussion