大規模アジャイル:LeSSとSAFe比べてみた！
こんにちはこんばんは。スクラムマスターの いのもえ です。
先日、「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」という本を読んだのですが、その中で GItLab では開発プロセスに SAFe というフレームワークを採用しているらしいことを知りました。
ちょうど読後、「フルリモートと LeSS は相性が悪すぎるのか？」と疑問に思ったので、 SAFe と LeSS の比較について考えてみました。
本のまとめはこちらの記事です
アジャイル開発とは？基礎知識
LeSS と SAFe を比べる前に、もう少し抽象的なレベルで整理してみます。
アジャイル開発やスクラムに関心がある方は知ってることが多いかもしれないので、その場合は次の章からどうぞ！
アジャイル開発
最近の開発プロセスのトレンドとして、「アジャイル開発」というのがあります。よく対比されるのは「ウォーターフォール開発」です。
ウォーターフォール開発は決まったゴールのために計画を立てて遂行する、「プロジェクト開発」の開発手法です。一方でアジャイル開発は、「プロダクト開発」と表現され、明確なゴールはないために小さく改善を積み重ねていく開発手法です。
近年では、決まった計画に向かって一直線に向かうのではなく、刻々と変化する状況を乗りこなすことが必要だと考えられており、その状況に対応しやすいのが「アジャイル開発」と考えられています。
このあたりの考え方については以下の論文が参考になると思います。
スクラム
アジャイル開発で日本で有名な方法の一つに、「スクラム」があります。
スクラムでは、プロダクトオーナー、開発者、スクラムマスターの 3 つのロールが 1 チームとなって開発に関わることにより、チームが自分たちで状況判断しながらプロダクトを育てられるようになることが期待できます。
（余談）
前段で「アジャイルはプロダクト開発であり、プロジェクト開発ではない」と記載しましたが、スクラムではスクラムイベントを周期的に設けることで開発期間を一定毎に区切っています。この一定に区切られた期間のことを「スプリント」と呼び、各スプリントはプロジェクト開発と同様、初期には計画やゴールを設定し、期間の終わりにはゴールを達成できるようにします。
なんとなく良さそうなスクラムですが、「スクラムチームはプロダクトに対して 1 チームである」という制限があり、ある程度大きな組織には適応しにくいという課題があります。
LeSS や SAFe はこれに対し、複数チームでプロダクトを開発するための方法です。
LeSS
スクラムとあまり形を変えずに、関わる人数を増やすアプローチです。
1 つのプロダクトに対して以下のものを用意します。
1 つのプロダクトバックログ
1 人のプロダクトオーナー
最大 8 つのチーム（プロダクト開発者の集まり）
最大 8 人のスクラムマスター（極力減らす場合 1 人あたり 3 チームをサポートする）
8 チームを超える場合には LeSS Huge に進化し、要求エリア毎にエリアプロダクトオーナーを立てます。 LeSS の中に LeSS があるような感じです。
SAFe
開発にはスクラムの要素をとりいれつつ、組織の概念も取り入れた方法です。開発プロセス以外の部分についてもガイドラインがあるのが特徴だと感じました。
特に比較しやすいポイントは「AGILE RELEASE TRAIN（ART）」の存在です。LeSS Huge と少し似ていますが、プログラムレベル（LeSS Huge の「要求エリア」が近い概念）ごとに ART を組成します。1 つの ART は通常 50 〜125 人で構成されます。
ART の中には複数のアジャイルチーム（LeSS でいう「チーム」）が存在し、各チーム毎に PO や SM が存在しています。ART の中にも ART 内のスクラムマスター的な役割（Release Train Engineer）やシステムアーキテクト、プロダクトマネジメントの役割が定義されています。
また、 LeSS ではチームごとの役割分担は定義していませんが、 SAFe では各チームを 4 つの役割にすることが推奨されます。
SAFe に馴染みが薄い方はこちらの記事がおすすめです！
以降では、 LeSS と SAFe の違いについて見ていきます。
適応のスタンスが違う！
特に違うと感じたのは、適応するに当たってのスタンスです。
LeSS は「顧客に価値を届けるためなら組織も変える。難しくても、それが一番最良だと思うなら目指すべき」というスタンス、 SAFe は「顧客に価値を届けるためなら組織も変えるが、あくまで現実的なところを目指すべき」というスタンスをとっているように感じました。
これらの違いは、主に適応対象となる組織規模に起因するものだと考察しています。
詳しく違いを見ていきます。
LeSS
LeSS の方はシンプルな組織であることを重要視しており、従来の組織でよくあるピラミッド構造を崩していかねばなりません。スタートアップなど小規模な組織であれば比較的取り組みやすいでしょうが、かなり大きな企業になるとこの組織構造の変更だけでかなり大変になると思います。
また、このような組織構造にするにあたっての現実的な課題についてはフレームワークの中では特に触れられていないことが多く、一つ一つメンバー同士で協力・議論しながら解決する必要があります。この大変さは、プロダクト開発におけるたくさんの課題を自分ごと化するための仕掛けであると捉えています。
SAFe
一方 SAFe では、 LeSS に比べてロールが細かく分かれています。組織構造もある程度階層構造になっており、これまでのピラミッド構造を少し変えるだけで近づけることが可能そうだという印象を持ちました。
ただし、各アジャイルチームが自己組織化することは SAFe でも推奨しており、これまでマネージャーを担当していた人たちは振る舞いや考え方を変える訓練が必要になります。
また、導入ロードマップからもわかりますが、組織レベルの要素（どのレイヤーで何を検討すべきか等）についてもフレームワークで考慮されている点があります。こういったところはスクラムにはなく、 SAFe オリジナルな要素です。
比較してみて
大規模な組織に「取り入れやすそう」と思われやすいのは SAFe だと思いました。階層構造の組織なので、開発者にも「開発に集中できそう」と思ってもらえそうです。
一方 LeSS は純粋なアジャイルやリーンを追求しており、非常にシンプルで強力な印象を受けます。導入するのは難しそうですが、 LeSS を取り入れることができればアジャイル開発のメリットを最大限活かせそうです。
また、組織規模による点も考慮が必要だと思います。 SAFe は ART の最低人数が 50 名とのことなので、それより少ない規模への適応は運用負荷の方が高くなったり、余計なセクショナリズムを産んでしまうかもしれません。
Attlasian の説明記事に載っている LeSS と SAFe の比較もそれぞれわかりやすかったので、ご興味ありましたら是非どうぞ！
同じところもある！
それぞれに共通しているのは以下の項目だと思います。
調べてみて、根本的な考え方についてはそれほど大差がないと感じました。
顧客中心に開発を進めることを推奨している
チームだけでなく組織全体の変化が必要になる
自律的に考え行動できる組織になることを奨励している
「スクラムを拡張したフレームワーク」という点ではどちらも同じですので、当然かもしれません。
まとめ・所感
「GitLab で SAFe を採用しているなら、フルリモートの正解は SAFe なのかな？」と思って調べてみましたが、 GitLab で SAFe を採用しているのはフルリモートだからではなく、組織規模が大きいからなのではないかという気持ちが強くなりました。
また、「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」を読んだときには「GitLab では個人に責任をもたせることが多いな」と感じて、 LeSS とリモートワークの相性の悪さをなんとなく感じていたのですが、ここに SAFe は関係なさそうでした。
参考 URL
説明に使った図は以下から引用しました。それぞれの説明も載ってますのでご興味ありましたら是非どうぞ！
1) https://less.works/less/framework/introduction?preferred_lang=jp
2) https://less.works/jp/less/less-huge
3) https://scaledagileframework.com/agile-release-train/
4) https://less.works/less/structure/organizational-structure
5) https://scaledagileframework.com/implementation-roadmap/
よろしければサポートお願いします！いただいたサポートは入浴剤や飲み物など、息抜きに使わせていただきます🤗