SAFeとは？スクラムとの違い、フレームワークについて
今回は、アジャイルのフレームワークである「SAFe」に関する記事になります。
日本国内でもセミナーや事例が増え始めている「SAFe」です。以前、私がSAFe Day Japanに参加した記事でも、その注目度の高さをご紹介しました。
なぜ、SAFeが近年ここまでの注目を浴びているのでしょうか。スクラムに代表される一般的なフレームワークとは何が違うのでしょうか。
今回は、SAFeがどういったフレームワークなのか、その注目されている理由が何なのかを紐解いていきます。
「SAFe」とは
SAFeとは、Scaled Agile Frameworkの略称です。
大規模にリーン、アジャイル、DevOpsを導入する際のフレームワークです。ナレッジベースで構成されたフレームワークになります。
ポイントは、「大規模に」という部分です。これは組織としてリーン、アジャイル、DevOpsを導入するということを意味します。
つまり、スケールする際のフレームワークであり、組織がビジネスアジリティを実現するためのフレームワークと言えます。
Scaled Agile, Inc.のHPには以下のように記載されています。
The Scaled Agile Framework® (SAFe®) is a system for implementing Agile, Lean, and DevOps practices at scale. It’s the most popular framework for leading enterprises because it works: it’s trusted, customizable, and sustainable.
「SAFe」が注目を浴びている理由
前述の通り、組織はSAFeによってビジネスアジリティを実現することができます。
変化に迅速に対応できる能力が、今後の企業もしくは組織に求められる能力であり、取り組むべき課題ということです。この認識の高まりが、SAFeの注目度として顕著に現れていると思います。
詳細は後述しますが、SAFeは開発チームだけでなく、組織全体を対象として体系立てられています。ポートフォリオから戦略の策定、エピックの管理、エピックをフィーチャーまで分解していくプロセスなどです。そして組織の規模に応じて使用するツールや役割分担（ロール）、イベントが定義されています。
したがって、開発チームよりもさらに上流の部分（上層部が実施すること）からアプローチできるのがSAFeです。エンタプライズアジャイルというだけあります。
SAFeほどしっかりと体系立てられており、かつ、ナレッジベースである点で事例の多さとドキュメントやコミュニティの充実さは、他のエンタプライズアジャイルのフレームワークと一線を画していると個人的に思います。
これらが、SAFeを注目する理由であるのと同時にSAFeを導入する理由ではないかと考えます。
「SAFe」と「スクラム」の違い
一言でいうとSAFeはスクラムを包含しており、スコープが異なります。
前述のように開発チームを取り巻く環境を管理する方法は、スクラムでは定義されていません。強いていうならビジネスオーナーなどの役割で定義されているくらいですかね。
SAFe上にスクラムが登場しないかというと、そんなことは全くなく、各チームの開発自体はスクラムベースに行われます。
複数のスクラムチームを束ねてどう管理するかというところにフォーカスしているのがSAFeです。そういう意味で冒頭の「包含している」という表現になります。
ディシプリンド・アジャイルの記事でもスクラムとの違いを説明しましたが、同じエンタプライズアジャイルでもSAFeの方がスクラム寄りな気がします。（そもそもディシプリンドアジャイルは、ツールボックスと言われるので比較すること自体アレかもしれません…）
「SAFe」のフレームワーク詳細
SAFeの詳細を以下から順にご紹介します。すべてをご紹介できないので骨子となる部分のみを取り上げます。SAFeの概要が何となく見えてくると思います。
SAFeの全体像
SAFeを１枚の図で表した図があります。SAFeで登場するロールやフレームワークが１枚で表現されています。
この図は、HPから実際に確認することができます。気になる部分をクリックすると詳細ページに遷移します。全体像を把握するのに便利です。
４つのコンフィグレーション
組織の規模や管理内容に応じて構成が４つに分かれています（下に行くほど小さい）。コンフィグレーションに合わせて前述のビッグピクチャーが４つ用意されています。
Full：Large solutionにポートフォリオの観点を取り入れたもの
Large solution：アジャイルリリーストレイン（ART）が複数あるもの
Portfollio：Essentialにポートフォリオの観点を取り入れたもの
Essential：100人くらいの規模
詳しくはこちらから（SAFe 5 for Lean Enterprises by © Scaled Agile, Inc.）
インプリメンテーションロードマップ
SAFeを導入する際の順序を示したロードマップがあります。まずは上層部も含めて教育するというのが”SAFe流”です。SAFeの導入を検討する際には便利ですね。
７つのコンピテンシー
ビジネスアジリティを実現するためのコンピテンシーとして以下の７つが定義されています。このコンピテンシーをもとにSAFeのフレームワークが構成されています。
・Team and Technical Agility (TTA)
・Agile Product Delivery (APD)
・Enterprise Solution Delivery (ESD)
・Lean Portfolio Management (LPM)
・Lean-Agile Leadership (LAL)
・Organizational Agility (OA)
・Continuous Learning Culture (CLC)
詳しくはこちらからご確認ください。
SAFe’s Seven Core Competencies by © Scaled Agile, Inc.
リーン・ポートフォリオ・マネジメント
コアコンピテンシーにも記載があるポートフォリオのマネジメント方法です。以下の流れが大まかなポートフォリオ・マネジメントになります。
１．エンタプライズストラテジーを策定
２．そこに紐づくストラテジックテーマを策定
３．実現するためのエピックを作成
４．エピックをフィーチャーに分解
５．各チームが開発
６．バリューを測定する
※全体通して予算のマネジメント
横文字が並びましたが、エンタプライズストラテジーは、経営戦略などです。ストラテジックテーマは、ビジネス目標（事業計画など）です。エピックは、事業計画に沿ったソリューションです。例えば、ユーザーの入力負荷を減らすAPIを開発するなど。
エピックを生み出し、実装されてクローズされるまでのフローをポートフォリオカンバンで管理します。エピック自体はポートフォリオバックログで管理します。ポートフォリオカンバンのどこか１列にポートフォリオバックログがあるイメージです。
ポートフォリオなので予算が付きます。その予算をどのようにマネジメントするかについても定義されています。詳しくはこちらから（Portfolio SAFe © Scaled Agile, Inc.）
コンティニュアスデリバリーパイプライン
SAFeはDevOpsの概念が取り入れられています。そこで定義されているのが、コンティニュアスデリバリーパイプラインです。このパイプラインがSAFeの底流にあります。
コンティニュアスデリバリーパイプラインは、以下の４つから構成されます。
・コンティニュアスエクスプロレーション
・コンティニュアスインテグレーション
・コンティニュアスデプロイメント
・リリースオンデマンド
ポイントは、最初のコンティニュアスエクスプロレーションでカスタマーのニーズを理解する部分が定義されています。
顧客中心でソリューションを考え、継続して必要なニーズをリサーチすることが組織の機能として必要です。
ARTイベント
SAFeは、複数のアジャイルチームを束ねて進めることを前提としています。複数のアジャイルチームを束ねたものを、Agile Release Train（ART）と呼びます。
単一のアジャイルチームについては、スクラムを実施します。複数のアジャイルチームの足並みを合わせるためにART単位に実施するイベントをARTイベントと呼びます。
【ARTイベント】
・PIプランニング
・スクラム オブ スクラム
・POシンク
・システムデモ
・PIプランニングの準備
・インスペクト＆アダプト
特記すべきは、PIプランニングです。
ARTに関わる人が全員参加し、２日間かけて参加者全員のコミットメントまで実施します。PI（スクラムでいうスプリント）で実施する開発内容および見積などを行います。
最初に経営層やプロダクトマネージャーから背景やバックログの候補について説明があり、各アジャイルチームが見積もりしていくイメージです。スプリントプランニングを大きくしたイメージですかね。以下の図がPIプランニングのアジェンダです。
ARTロール
ARTで登場するロールは以下です。※各ロールはリンクになっており、詳細ページに飛びます。
リリーストレインエンジニアは、ART版スクラムマスターです。
プロダクトマネージャーは、プログラムバックログを所有し、定義し、優先順位をつけます。プロダクトオーナーの上位互換です。ちなみにSAFe内でのプロダクトオーナーはアジャイルチームのバックログを管理します。
システムアーキテクトは、アーキテクチャーなどの技術仕様に責任を負う役割です。大きい組織はこのようなロールが定義されていることが多いようです。
システムチームは、開発ツールやプロセスを提供するチームです。開発チームが効率的に作業できるよう新しいツールなどを提供し、支援するチームになります。
詳しくはこちらから（Critical ART Roles by © Scaled Agile, Inc. ）
”SAFe”の”スクラム”との違い、フレームワークまとめ
今回は、SAFeをご紹介しました。
SAFeは、ビジネスアジリティを実現するナレッジベースのフレームワークでした。リーン、アジャイル、DevOpsのプラクティスから構成されています。
スクラムと異なり、単一の開発チームだけではなく、組織全体を対象としています。ポートフォリオマネジメントやARTがよい例です。
昨今の時代背景と相まって組織全体をビジネスアジリティに導くフレームワークとして注目を浴びているのではないでしょうか。
事例の多さ、ドキュメントやコミュニティの充実さは、他のフレームワークと一線を画しており、検討しやすいというのも理由としてあるかもしれません。
【合わせて読みたい】
ーーーーーーーーーーーーーーーーーー
いかがでしたでしょうか。
ぜひスキとフォローもお願いします！
では、また！
※本記事の内容は個人の見解であり、私が所属する組織とは一切関係ありません。
この記事が気に入ったらサポートをしてみませんか？