Scaled Agile Framework とは（SAFe）

コアバリュー

SAFe のコアバリューは、フレームワークを効果的に使用するためにリーダーシップが育成すべき文化と、その文化の中で人々がどのように振る舞うべきかを表しています。

位置の調整

SAFe は、企業が組織のあらゆるレベルで計画と熟考の期間を設けることを求めています。これらを実施することで、ビジネスの現状、ゴール、そしてそのゴールを達成するために皆がどのように協力すべきかを理解できるようになります。

スタッフとアクティビティを定期的に同期することで、ポートフォリオのあらゆるレベルで足並みを揃えることができます。従来のトップダウン型の指揮統制構造とは異なり、情報は適時に上向きと下向きの両方に流れます。

組み込みの品質

SAFe フレームワークでは、アジリティによって品質が犠牲になるようなことがあってはなりません。SAFe は、すべてのレベルのチームに、各タスクまたはプロジェクトの「完了」の意味を定義し、すべての作業契約に品質開発プラクティスを組み込むことを要求しています。SAFe によると、組み込みの品質には、フロー、アーキテクチャおよび設計の品質、コードの品質、システムの品質、リリースの品質の 5 つの主要なディメンションがあります。

透明性

SAFe は、問題をより早く表面化できる小さなバッチ・サイズでの作業計画、レベル全体のバックログの進捗をリアルタイムで可視化できる機能の導入、検査と適合の手順など、信頼を構築する行動を奨励しています。

プログラムの実行

プログラムの実行は SAFe の中核であり、フレームワーク全体の原動力となります。チームとプログラムは、品質、実用的なソフトウェア、ビジネス価値を定期的に提供する必要があります。

リーダー

リーダーのみがシステムを変更し、すべてのコアバリューを受け入れるために必要な環境を作成できることから、SAFe ではリーンアジャイルリーダーシップの行動が求められます。

SAFe の原則

Scaled Agile Framework の原則は、機能および組織の境界を越えてリーン・アジャイルの意思決定を促すことにより、企業全体を改善することを目的としています。この原則は、リーダーやマネージャーだけでなく、組織内の全員の意思決定に影響を与えることを意図しています。

その目的は、従来のウォーターフォール思考から、リーン ポートフォリオ管理などの慣行が適用されるリーン・アジャイル思考に移行するように思考方法を調整することです。

原則 1 経済的な視点を持つ

Donald Reinertsen のベスト セラー本にある製品開発フローに関する理論に基づくと、持続可能な最短のリードタイムを実現するには、意思決定チェーンにおける各個人が遅延の経済的影響を理解する必要があります。

デリバリーを早期かつ頻繁に行うだけでは必ずしも十分ではありません。SAFe によると、最大限の利益を得るための仕事の順序付け、経済的トレードオフの理解、および無駄のない予算内での運用は、いずれも組織全体で共有する必要がある責任です。

コンセプトとツールの多くは、製品開発フローに関する Reinertsen の理論に基づいています。

原則 2 システム思考を適用する

SAFe は、フレームワークを使用して、ソリューションそのもの、システムを構築する企業、バリュー・ストリームの 3 つの主要な領域にシステム思考を適用するよう促します。ソリューションとは、企業の内部または外部にかかわらず、顧客に提供される製品、サービス、システムのことを指します。

大規模なソリューションには相互接続された多くのコンポーネント・パーツがあるため、チーム・メンバーは、全体像に対する自分のパーツの位置付けを俯瞰できる視点を持つ必要があります。システムを構築する企業について考える場合、SAFe に準拠するときは、組織のスタッフ、管理、プロセスを考慮する必要があります。

そのため、組織がスタッフの作業方法を最適化しようとする場合、サイロの排除、部門横断型への移行、サプライヤーや顧客との新しい労働協約の締結が必要になることがあります。最後に、企業は、ソリューション開発のバリューストリームにおいて、価値が概念から現金にどのように流れるかを明確に定義する必要があります。

リーダーと経営陣は、機能と組織の境界を越えて価値の流れを最大化する必要があります。

原則 3 変動を想定し、選択肢を用意しておく

デフォルトでは、システムとソフトウェアの設計には不確実性が伴います。この原則では、セットベースの設計の概念を取り入れることで不確実性に対処します。そのためには、長期にわたる開発サイクルにおいて、複数の要件と設計のオプションを保持することが求められます。

また、セットベースの設計では、経験的なデータを使用しながら、対象となる最終的な設計オプションをさらに絞り込みます。

セットベースの設計は、戦略オプションのように、オプションと意図した成果が特定されるため、不確実性のある段階で意思決定を伝えるのに便利です。セットベースの設計には、意思決定の期限を示す「学習のマイルストーン」の統合が役に立ちます。時間の経過とともに学習するチームが増えれば増えるほど、排除される選択肢が増えます。

排除される選択肢が増えるほど、進むべき最善の方向性をより簡単に特定し、顧客に可能な限り最適な成果をもたらすことができるようになります。

原則 4 統合された高速な学習サイクルを使用してインクリメンタルに構築する

原則 3 と同様に、この原則では学習のマイルストーンを通じて、リスクと不確実性に対処します。現在選択している設計の実現可能性を評価するには、システムの各コンポーネント部分が機能することを証明するだけでは不十分であり、システム全体を考慮する必要があります。

学習サイクルを加速する場合は、統合ポイントを定期的に計画する必要があります。これらの統合ポイントは、継続的な品質改善のフレームワークであり、開発の変動性を制御するためのメカニズムである、Walter A Shewhart の Plan-Do-Check-Adjust サイクルに範をとっています。

Shewhart の研究や彼がインスピレーションを与えた研究の多くは、SAFe に採用されています。

原則 5 作業システムの客観的な評価の基礎となるマイルストーン

実際の作業システムのデモンストレーションを行えば、要件ドキュメントや成功についてのその他の表面的な評価よりも、意思決定のための優れた基盤を提供できます。また、早い段階で実現可能性の決定に関係者を参加させることにより、信頼の構築や体系的な思考もより促されます。

原則 6 WIP（進行中の作業）を視覚化して制限し、バッチ・サイズを減らし、キューの長さを管理する

進行中の作業を制限すると、関係者が作業の進捗状況を正確に把握できるようになります。

この原則の 3 つの要素は、スループットを最大化し、価値デリバリーを加速させる、つまり「フロー」を実装するための主要な方法を表しています。まさに「象を一頭食べるにも、一口ずつ」という格言の示すとおりです。

これをソフトウェア開発に適用すると、重複する作業の量、各作業項目の複雑さ、特定の時間に取り組む総作業量を制限するということになります。バッチ・サイズが小さければ、作業が正しい方向に向かっていることを常に検証できます。さらに、キューの長さの管理も同様です。

この原則は、最適な成果を得るための最適化のガイダンスを提供することを目標としています。

原則 7 期間を適用し、複数ドメインの計画と同期する

アジャイル チームでは、スプリントまたはイテレーションを通じて期間が自然に適用されます。考え得るすべての問題の期間を作成しておけば、複雑さが軽減され、不確実性に対処でき、身体で期間を覚えることができ、品質を強化し、コラボレーションを促進することができます。

これらの期間を同期すれば、スタッフとアクティビティが車輪の歯車のように動くようになり、学習した情報を意思決定と段階的な計画に活用できるようになります。

原則 8 知識労働者の内在的なモチベーションを解き放つ

影響力のある経営コンサルタントのピーター・ドラッカーと作家のダニエル・ピンクに触発されたこの原則は、我々が特に気に入っている原則の 1 つです。チームのポテンシャルを解き放ち、チームを指揮統制するのではなくコーチングして奉仕するという視点をリーダーシップチームが持つことができるようになる原則です。

原則 9 意思決定を分散化する

意思決定を分散化することによって待ち時間を短縮し、経済的なアプローチをとれば、仕事を遂行するために必要な自律性がチームに備わります。リーダーは、戦略的に重要なトピックに関する意思決定権限を保持し、他のトピックはすべてチームが情報に基づいた選択を行えるようにする必要があります。

SAFe を実装する準備ができている組織とは、通常、エグゼクティブレベルのスポンサーシップ、変更のための強い目的意識、スクラムの基盤が備わった組織のことです。

Scaled Agile, Inc. からは SAFe 実装ロードマップが提供されています。これには、さまざまなポートフォリオに広く導入されるための組織の立ち上げと設定のための詳細な手順が記載されています。SAFe の実装は、次の 12 の手順で構成されます。

1. 転換点へ到達する

2. リーン・アジャイル変革エージェントをトレーニングする

3. エグゼクティブ、マネージャー、リーダーをトレーニングする

4. リーンアジャイルのセンターオブエクセレンスを作成する

5. バリュー・ストリームと ART（アジャイル・リリース・トレイン）を特定する

6. 導入計画を作成する

7. ART のローンチに向けて準備する

8. チームをトレーニングし、ART をローンチする

9. ART 実行のコーチングを行う

10. その他の ART とバリュー・ストリームをローンチする

11. ポートフォリオへ拡張する

12. 持続し改善する

Scaled Agile Framework®（SAFe®）は、大規模なソフトウェア開発チームを持つ企業で広く採用されていますが、他の拡張アジャイル・フレームワークも徐々に台頭してきています。アジャイルの拡張のためのフレームワークはすべて、アジャイル・マニフェストの 12 の原則の活用、期間、同期、スクラム、品質開発のプラクティスという 5 つの主要コンポーネントを共有しています。他のフレームワークの起源、基本的な違い、適用を成功させるための条件を理解すれば、組織のニーズに合わせたフレームワークを的確に選択できます。

人気の Scaled Agile Framework の背景について詳細を知りたい場合は、アジャイル コーチの大規模アジャイルの概要ページをご確認ください。

SAFe と Scrum@Scale

Scrum@Scale (S@S) では、誰もが交換可能なスクラムチームの一員となります。目標に応じて、スクラムチームのネットワークが集まってエコシステムを形成します。S@S の目的は、「スケールフリーアーキテクチャ」を通じてスクラムチームのネットワークを作成することです。つまり、基本的なスクラムの役割とイベントは、新しいプロセスダイナミクスを導入せずに直線的にスケーリングされます。たとえば、25 のスクラムチームがある非常に複雑な製品には 1 つの Scrum of Scrums (SoS) では不十分な場合があるため、Scrum of Scrums マスターのスクラム (SoSM) を有する Scrum of Scrums のスクラム (SoSoS) が必要になる場合があります。

S@S がルールとされることはあまりありませんが、組織がスケーリングの準備ができているかどうかを判断するための 1 つの指針となる質問を提供します。システムにスタッフを追加すると、パフォーマンスは指数関数的に増加しますか、それとも生産性が低下しますか、という質問です。

SAFe と同様に、S@S は、人気が高まっている Scrum@Scale の詳細なガイドを含むリファレンス・コンテンツをオンラインで提供しています。

S@S が最適なケース

• テクノロジースタックがオブジェクト指向である (縦方向のユーザーストーリーは 2 週間で提供可能)

• 組織の機能チームには T 字型スキル、製品中心の価値があり、煩雑な手続きは最小化されている

• 実践が日常化されるまでは、アジャイルまたは ALM（アジャイル・ライフサイクル管理）ツールは必要ない

• エグゼクティブ・チームが、スクラムを実践し、組織の障害を取り除くことを望んでいる

SAFe と Large-Scale Scrum (LeSS)

Large-Scale Scrum（LeSS）は、役割、構造、アーティファクトに対してミニマル主義的なアプローチをとります。より大規模のチームに対応するために SAFe が 4 つの構成を提供し、ソリューションも複雑さを増しているのに対し、LeSS が提供するのは、2 チームから 8 チーム向けの LeSS と 9 チーム以上向けの LeSS Huge の 2 つです。また、SAFe では民主的なアプローチが奨励されるのに対し、LeSS では製品所有者が完全なコンテンツ権限と戦略的影響力を持つべきであるというスタンスをとるという違いもあります。SAFe の戦略には多くの要因がかかわってきますが、LeSS では購買顧客に焦点を当てた顧客中心のアプローチに重点を置きます。

S@S と同様に、LeSS はスクラム・イベント、アーティファクト、権限から拡張されます。また、SAFe と LeSS はともに、システム思考、リーン思考、それらと同様の基本原則を重視しています。ただし、LeSS は、継続的な改善を目標に、組織全体の無駄の削減に多くの重点を置いています。

LeSS が最適なケース

• スクラムチームがスクラムに熟達している

• リーダーが継続的な再構築と改善のためのチャレンジに好意的である

• 製品の定義に整合性がある

• 完了の定義に整合性がある

• 外部コーチが組織、チーム、技術グループと連携している

• 機能チームの他に T 字型スキルを備えたコンポーネント・チームがある

• 組織がプロジェクト管理のパラダイムを完全に排除したいと考えている

SAFe と DA

記載されている他のフレームワークとは異なり、ディシプリンドアジャイル (DA) は、組織に最適な作業方法を判断するためのツールキットです。スクラムとカンバンに根ざした軽量でアジャイルなガバナンスを提供し、人事と財務、ガバナンス、DevOps、ポートフォリオ管理などの分野で変革のための知識を提供します。DA では、状況に応じて各プロジェクトに異なる規模の拡張が導入され、戦略的な方向性を導くための意思決定に重点が置かれます。

DA が最適なケース

• 組織が独自の拡張アジャイルパスを定義することを望んでいる

• 組織が企業全体の柔軟性を維持することを望んでいる

• 組織がプロセスやフレームワークの選択肢を保持することを望んでいる

SAFe と Spotify

Spotify「モデル」は、アジャイル・チームの調整に適用できる、スタッフ主導の自律的な一連のプラクティスです。モデルやフレームワークにすることを意図したものではありませんが、一部の企業では、そのような目的で採用されています。Spotify は、「分隊」（スクラム・チームに相当）と呼ばれる、自己組織化され、部門横断型で、共同配置されたチームに重点を置いています。それと比較すると、SAFe ではチームのコロケーションについてそのような規定を設けていないため、PI 計画にはこのモデルが推奨されています。

分隊は、「部隊」と呼ばれる大きな単位に編成されます。分隊間の依存関係はほとんどなく、依存関係が発生した場合は Scrum of Scrums によって処理されます。知識の共有は、スキルセットと興味に基づいて編成された非公式のグループである「支部」と「ギルド」によって行われます。

オンライン・リソース、トレーニング・コース、認定資格が利用可能な他の例と比較すると、Spotify モデルのリソースは、公開されているブログ、およびその先駆者とファンによって開発された他のガイドブックしかありません。人気が高まっているため、このモデルについては今後さらに詳しく解説する予定です。

Spotify が最適なケース

• 独自のビジネス・コンテキストでアイデアを適用する

• 学習に焦点を当て、ミスを許容し、リスクを管理する文化を持つ組織

• チームと製品が、依存関係による競合を避けるために「緩やかに結ばれ、緊密に連携」されている

SAFe は、世界中の実践担当者のコミュニティと協力して進化し続けることを中心的な信念としています。先日、Scaled Agile, Inc. は SAFe の 5.0 バージョンをリリースしました。主な変更点は、「価値を中心とした構成」という 10 番目の原則が追加されたことと、ステップ 12 が「持続と改善」から「加速」に変更されたことです。もちろん、その他にも変更が加えられています。詳細については、SAFe 5.0 の新機能と変更点に関するブログ記事をご確認ください。

SAFe や上述のようなフレームワークは、企業が組織でアジャイルを効果的に拡張し、ビジネスの成果を達成するのを支援する実際的な選択肢です。しかし、現行のプラクティスを拡大し、そうしたプラクティスのメリットを完全に実現できるツールを選択することも同様に重要です。アトラシアンの Jira Align は SAFe 向けに構築されたエンタープライズ・アジャイル計画プラットフォームです。Jira Align を使えば、可視性、戦略的整合性、企業の適応性を向上してデジタル変革を加速できます。

詳細を見る