アジャイル開発の代表的なスケーリング方法まとめ

この記事は クラウドワークス Advent Calendar 2019 の10日目の記事です。

昨日は、@tmknom さんによる SREやクラウドエンジニアが読むと良さげな本まとめ でした！

はじめに

こんにちは、 @lemtosh469 （スクラムマスター）です。

みなさまは、アジャイル開発を実践されておりますでしょうか。

弊社でもアジャイル開発を採用しており、クラウドワークスのバリューとして「Be Agile」が採用されるなど、アジャイルな考え方が全社的に活発化する環境に向かいつつあります。

アジャイルやアジャイル開発に関する記事は日本語でもたくさんありますのでそちらに譲るとし、今回は組織規模が大きくなってきたときに採用されることの多い大規模なアジャイル開発のやり方である、

スケーリングアジャイル

の各種手法について調査／整理していこうと思います。

網羅的にスケーリングアジャイルの手法をまとめている国内の記事は見つけられなかったので、こうやってまとめるだけでも価値があるかなと思い書いてみました。

僕自身も勉強中の身ですので、説明の内容などで間違いがありましたらご指摘いただけますと幸いです。

アジャイルレポート

引用元：https://www.stateofagile.com

Annual State Of Agile Report（アジャイルレポート）という世界のアジャイル開発の動向をまとめた調査レポートがあります。2019年5月に発表された 13th Annual State Of Agile Report（アジャイルレポート） によると、アジャイル開発におけるポピュラーなスケーリングアジャイルの手法の採用率は、下記に示す割合となっているようです。

手法名	割合
Scaled Agile Framework® (SAFe®)	30%
Scrum of Scrums	16%
Internally created methods（独自の手法）	8%
Disciplined Agile Delivery (DAD)	7%
Spotify Model	5%
Large Scale Scrum (LeSS)	3%
Enterprise Scrum	3%
Lean Management	3%
Agile Portfolio Management (APM)	3%
Nexus	2%
Recipes for Agile Governance in the Enterprise (RAGE)	1%
Don't know	19%
引用元：13th Annual State Of Agile Reportの12ページ

今回は、上記で挙げられているスケーリングアジャイルの手法を調べてその概要をまとめていきたいと思います。

スケーリングアジャイルを紐解く前に...

そもそも、アジャイル開発の根底には、「アジャイルソフトウェア開発宣言」と呼ばれる考え方があります。

この開発宣言には、17人のソフトウェア開発者によって策定されており、これから説明するスケーリングアジャイルの手法の中でも、この宣言の策定に関わった主要なメンバーが提唱しているスケーリングアジャイルの手法が出てきます。また、昨今のアジャイル開発で採用されることの多いスクラムフレームワークをスクラムガイドとしてを定めた人たちが提唱する手法も登場します。

スケーリングアジャイルの種類

Scaled Agile Framework® (SAFe®)

SAFeの全体像

引用元：https://www.scaledagileframework.com/

概要

SAFeの最大の特徴は、意思決定及び実行の階層として以下の3つを設定しているところにあります。

階層	名称	役割
1	ポートフォリオ	プロダクト等の企画を評価、審査する
2	プログラム	複数チームが連携してプロダクトのリリースを開発する
3	チーム	1つのチームがプロダクトの自チーム担当部分を開発する

（ラージソリューションは、あまり使わないと実践者の方に聞いたことがあるので上記の階層の説明からは一旦抜きました。）

ここでいう、「プログラム」とは複数チームで構成される大規模な開発体制のことを意味します。各階層ごとに管理するバックログがあるため、ひとつの手法の中で粒度の異なる複数のバックログを管理することになります。これらの階層を一枚に図示したものを、SAFeの全体像 (big picture) と呼びます。

SAFeが実現しようとしているの価値は以下の4つになります。

1. ベクトル合わせ

• 3 つのレベルのメンバーが戦略的な目標を共有し、その方向に向かって力を合わせる

1. コード品質

• 技術プラクティスを実践することで大規模で品質のよいプロダクトを実現する

1. プログラムの実行

• 開発メンバーの自律性に基づく自己組織化や自己管理、及び反復のサイクルを自然な形でプログラムレベルにスケールアップすることで、大規模プロジェクトを確約に基づきスケジュール通りに実行する

1. 透明性

• 3つのレベルのメンバーが包み隠さず現状を共有することで、より良い連携をもたらす信頼関係を醸成する

• SAFeのプログラムレベルでは、5-10チーム程度（開発者数が50-100名程度）の規模を想定している。

• 2011年の最初のリリースから5つの主要な更新があり最新版として4.6が公開されている。

• 2019年12月現在は、5系のpreview版が公開されている。

• Scaled Agile, Inc. がサービス展開しているので導入支援を受けることができる。

提唱者

• ディーン・レフィングウェル（Dean Leffingwell）

米国コロラド州ボルダーを拠点とする企業家、著者、そしてソフトウェア開発方法論者です。

所感

「Train Everyone, Launch Trains.」という重要なコンセプトがあり、同じ列車に乗って価値を届けるというような思想があるため、用語としてTrainという言葉が使われています。

経営層の戦略もセットにした組織ぐるみでアジャイルを推進する手法。戦略レベルのバックログから降りてきたモノを、プログラムレベルやチームレベルで砕いて開発を進めます。みんなを巻き込んで開発していきます。

また、このSAFeを始めるときには、小さく始めるのが良いとされており、「エッセンシャルSAFe」という、Fullのセットより、もう少し小さいサイズ（具体的には、プログラム層とチーム層のみのミニマムなフレーム）があります。経営陣のお尻に火を付けるような、セリフ集も用意されていると聞きます。

エッセンシャルSAFe

引用元：https://www.scaledagileframework.com/essential-safe/

適用事例

• Fitbit
• Play Station Network | SONY
• Cisco
• LEGO Digital Solutions

参照したい情報

• 公式：Scaled Agile Framework – SAFe for Lean Enterprises
• SAFe (Scaled Agile Framework) 3.0 入門 (第4回) | オブジェクトの広場

国内コミュニティ

• エンタープライズアジャイル勉強会

Scrum of Scrums

引用元：https://www.scruminc.com/scrum-of-scrums/

概要

• 開発チーム中心ではなく、各チームのスクラムマスターのためにデイリースタンドアップの場を作るための手法（各チームのスクラムマスターが問題を持ち寄って情報共有する場）
• スクラムを大規模なグループ（数十人以上）にスケールアップするときに用いる
• デイリースクラムをスケーリングする手法であるとも言える
• 各チームは1人のメンバーを「アンバサダー」として指定し、スクラムオブスクラムに参加してもらう
  • アンバサダーは状況に応じて、
    • 技術的な貢献者
    • 各チームのスクラムマスター
    • 各チームのマネージャー 　などが参加する
• スクラムマスター同士が情報共有し、スクラムチームを繋ぐための手法であることから「メタスクラム」とも呼ばれる
• 2001年のJeff Sutherlandの記事で最初に説明されている

提唱者

• ジェフサザーランド（Jeff Sutherland）

ジェフサザーランド博士は、スクラムソフトウェア開発宣言の作成者の1人です。 Ken Schwaberとともに、OOPSLA'95で一連のプロセスとしてスクラムを作成しました。サザーランドは2001年にアジャイル宣言を書くのを手伝いました。スクラムガイドを書いたメンバーのひとりでもあります。

所感

開発にフォーカスした手法というよりは、スクラムのフレームワークでいうところのスクラムチームのスクラムマスターが情報共有をするための場を設けることための手法です。そのため、調べていくとデイリースクラムをスケーリングするという話が出てきます。

この手法のおもしろいところは、スクラムガイドを書いたジェフサザーランドが提唱していたり、一見すると良さそうな手法に見えるにも関わらず、なぜかScrum of Scrumに対して批判的な立場の人が一定数いるところがあります。とはいえ、その批判のニュアンスもエディタ戦争のようなノリなのではないでしょうか。

参照したい情報

• Scrum of Scrums | Agile Alliance
• Scrum of Scrums - Scrum Inc
• スクラム・オブ・スクラムにおけるデイリーミーティング | Ryuzee.com
• Scrum of Scrum Ground Rules | Scaling Software Agility
• official-guide/guide-ja-japanese.pdf at master · scrumatscale/official-guide · GitHub

Disciplined Agile Delivery (DAD)

引用元：https://disciplinedagiledelivery.jp/

概要

• 大きくは、リーン・エンタープライズのためのプロセス・ディシジョン・フレームワーク
• Disciplined Agile(DA)ツールキットと呼ばれる原則は、個人やチームが情報に基づいた選択を行い、働き方を改善し、組織がアジャイルを合理化し、より良い意思決定を行うための戦略を活用できるようにする、業界をリードするアプローチとして誕生して今日まで進化を続けてきた
• プロジェクト管理専門職のための世界有数の非営利会員団体であるPMI(ProjectManagementInstitute)が、2019年8月に、Disciplined Agile (DA)を買収を発表した
• Project Management Institute（PMI）は、米国のプロジェクトマネジメント協会を指す

提唱者

• Scott Ambler
• Mark Lines

所感

DADは、スクラムを拡張するハイブリッドアプローチを採用しています。ベースとなるのは、アジャイルモデリング（AM）、エクストリーム・プログラミング（XP）、ユニファイドプロセス（UP）、カンバン、リーンソフトウェア開発、アウトサイドイン開発（OID）その他いくつかの手法から採られた、実証された戦略達です。構築にフォーカスしたスクラムのライフサイクルを拡張し、プロジェクトの立ち上げからエンドユーザにソリューションをデリバリーするまでの完全に、エンドトゥエンドのライフサイクルを扱います。

DADは、ハイブリットフレームワークであることを標榜しており、様々なフレームワークのいいとこ取りをするような形態が取られています。（そのため、初級者には一見するだけだとその中身がわかりにくい。）

引用元：https://disciplinedagiledelivery.jp/introductiontodad/

スクラムの良いところも入れていいし、XPの良いところも入れてもいい、SAFeの良いところも...という感じで、ちょっと盛りだくさんな感じになっているため、かなり難易度の高い手法という印象でした。個人的には、SAFeの手法すらも土台として扱うというのは、大きな構想だなと感じます。

参照したい情報

• ディシプリンド・アジャイル・デリバリー日本語公式サイト
• Disciplined Agile (DA) – A Foundation for Business Agility
• DAD(Disciplined Agile Delivery)概要 - Qiita
• なぜディシプリンド・アジャイルか？ | Disciplined Agile 2.X - Japan

Spotify Model

引用元：https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

概要

• 2011年初頭より徐々に拡大する Spotify の開発組織に適用させるために生まれた手法
• 2013年頃のSpotify社のアジャイル開発体制を指して使われる用語

提唱者

• アンディ・パーク（Andy Park）
• ヘンリック・クニベルグ（Henrik Kniberg）

アンディ・パークとヘンリック・クニベルグは、初期Spotifyの元アジャイルコーチです。
Henrik Kniberg さん突撃インタビュー | オブジェクトの広場

所感

Spotifyには、改善作業の整合性と方向性を作成するための「Agile à la Spotify」という独自のマニフェストが背景にあり、基本的にこのモデルは他社に適用できるものではないと言う 意見 もあります。

また、このモデルはあくまで自社サービスと組織の急成長の中の試行錯誤（実験）によって生まれた成果であって、

「Spotifyモデル」として知られるようになりましたが、実際には汎用のフレームワークまたは「モデル」になることはまったく意図されていませんでした。これは、ある会社の仕組みの例にすぎません。私がこの資料を共有した理由は、Spotifyの同僚が私に励ましてくれたからです。そして、それが私がやっていることだからです。

引用元：https://blog.crisp.se/2015/06/07/henrikkniberg/no-i-didnt-invent-the-spotify-model

と、Spotify初期のアジャイルコーチであるヘンリックによって明言されています。Spotifyの当時の状況に合わせてして進化してきたことが伺えます。そのため、ヘンリックは、アジャイルレポートでこれがスケーリングアジャイルの手法の一つであるように紹介されることを恐れていました。しかし、このモデルを採用した多くの企業にアドバイスを求められて、実際に採用した企業を見て回る中で、いくつかの大きな改善がみられたとも言っています。

部隊・分隊・支部やギルドといったマトリクス型の柔軟な組織構成は、個人的には好きなポイントです。

適用事例

• 1500万人の顧客
• エンジニアチーム300人

参照したい情報

• Henrik Kniberg | Labs
• A Checklist for Using the Spotify Model
• Spotifyのエンジニアカルチャー

Large Scale Scrum (LeSS)

概要

• 基本的には、素直にスクラムを拡張したフレームワークとなっている
• オーバーオールレトロスペクティブというシステムに対するふりかえりを行う
• バックログも一つしかない。ひとつのLeSSに対してひとつのバックログに統一
• 最大8チームまで
  • LeSS： 最大8チーム（各チーム最大8人）
  • 8チーム以上の規模になると、 Area Product Owner という役割を置いて、各拠点のLeSSを拡大していくLeSS Huge という手法にスケールしていく
• 基本的には、LeSSひとつのPO（Product Owner）はひとり
• 優先順位を管理。明確化は、チームがステークホルダーと協業してして行っていく
• スクラムマスターは、組織全体の改善に責務を持つ

提唱者

• ラーマン・C・クレーグ（Craig Larman）

カナダ生まれのコンピューター科学者、著者、および組織開発コンサルタントです。

所感

LeSSはスクラムを素直に拡張する考え方であることと、スクラムに馴染みのある開発をできていれば唐突に新しい概念が増えないので、素直に採用してうまくいくケースは多いのではないかという印象があります。国内でも勉強会が活発であったり、採用事例もチラホラ見つけることができたりして情報のキャッチアップは、ほかの手法に比べると遥かにしやすい印象があります。邦訳された書籍（大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法）があるのも導入のハードルを下げている気がします。

懸念点としては、PO（Product Owner）の責務が大きくなりそうだなという印象があります。POの役割をかなりピュアな状態に保って置かないと、かなり疲弊しそうです。

「LeSS Scrum」で検索すると、ここで詳細を語るまでもなくわかりやすい記事がたくさん出てきます。

（個人的には、システム思考の考え方を取り入れているところはツボです。）

適用事例

• 「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記
• Huawei - Large Scale Scrum (LeSS)
• BMWグループ-大規模スクラム（LeSS）
• 大規模スクラム（LeSS）@ JPモーガン

参照したい情報

• LeSS Framework
• 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
• LeSS (Large-Scale Scrum) の概要 | Ryuzee.com

国内コミュニティ

• Less Study | Doorkeeper

Enterprise Scrum

引用元：https://medium.com/@mikebeedle/enterprise-scrum-introduction-a4987ee690d0

概要

• マイクビードルの開発したエンタープライズ向けのスケーリングスクラムの手法

提唱者

• マイク・ビードル（Mike Beedle）

アメリカの理論物理学者に転向したソフトウェアエンジニアであり、アジャイル宣言の共著者でした。 （2018年に逝去しております。まだご存命であればこの手法はまだまだ活発だったかもしれません。）

所感

ほとんど情報がオープンになっていない雰囲気です。というよりは、手法の開発者自身がお亡くなりになられてしまったためコミュニティ自体がそこまで活発でないのかもしれません。

参照したい情報

• Enterprise Scrum - Business Agility for a better FUTURE
• アジャイルエンタープライズ (Object Oriented SELECTION)
• Enterprise Scrum Introduction - Mike Beedle - Medium
• Enterprise Scrum | Facebookグループ

Lean Management

概要

• トヨタ生産方式が1980年代にアメリカのMIT（マサチューセッツ工科大学）で研究され、その成果を再体系化・一般化された手法
• 生産管理手法の一種

提唱者

• 大野耐一

トヨタ自動車工業の元副社長です。かんばん方式など生産管理のあり方として世界的に有名となった "トヨタ生産方式" を体系化した人物です。

所感

スクラムフレームワークとは別物。スクラム実践時に、Lean Management（リーン生産方式）で扱う「カンバン方式」や「バリューストリームマッピング」などを採用するケースがあるが、本来はLean Managementで定義されるThe Lean Management Toolsの中のやり方です。3つの原理・原則を遵守して、顧客価値全体を向上させる手法として確立されました。

その歴史はさることながら、起源が日本にあることより馴染みが深いのではないかと思います。

3つの原理・原則

1. ムダ（「付加価値のない作品」）
2. ムリ（「表土」）
3. ムラ（「不均一性」）

プロセスの管理を徹底して効率化することで上記の３つを削減して、従来の生産方式と同等以上の品質を保ちながら作業時間や在庫量を大幅に削減ができます。

参照したい情報

• Lean Management - Kanbanchi
• トヨタ生産方式――脱規模の経営をめざして

Agile Portfolio Management (APM)

概要

アジャイルプロセスを実施することで、顧客ニーズへの整合性の向上や、計画目的の透明性の向上、協力や効率の改善を図ることができる。アジャイルの実践には、そのような多くの利点はあるものの、戦略的領域に関して、戦略的コミットメントのアジャイルプラクティスは一貫して存在しない、もしくは不足しているという状況があった。

所感

たしかに、アジャイルのプラクティス然り、スクラムのフレームワーク然り、戦略的な領域についての話はなかなかでてきません。あくまで開発者と顧客しか見えてこないことも多い気がします。

上記にも出てきた、SAFeでは、経営層の戦略レベルまで含めたフレームとなっていますが、LeSSなど適用しやすい軽量フレームワークで、戦略レベルとどのように接続していくかのイメージは湧きにくいということろが正直な感想です。

このARP（アジャイルポートフォリオ管理）は、アジャイルの開発手法と、戦略レベルのポートフォリオ管理の接続を意識した結果生まれた手法なのではないかと考えられます。それは、アジャイルの開発手法が現場が主体的に動けるボトムアップの仕組みであることにも起因するような感じがしてきます。

従来のポートフォリオ管理とスケーリングされたアジャイル開発の統合とも言われているようです。アジャイル開発で採用する「カンバン方式」をポートフォリオレベルでも同じように採用して、プロセスが移動するポートフォリオアイテムのステータスを追跡するというのが手法の一部でもあるようです。

モノリシックをマイクロサービス化に移行する際に、どのようにROIをどのように分析するかは非常に重要な観点と思いますが、このアジャイルポートフォリオマネジメントは、役立ちそうな気配があります。

参照したい情報

• アジャイルポートフォリオ管理：使用中の実践に関する経験的視点
• Portfolio Management as Part of Scaling Agile | Daitan

Nexus

出典：Nexus™ ガイド | 日本語版

概要

• 5〜9人のメンバーで構成される約3〜9のスクラム開発チーム
• すべてのチームで使用される共通の製品バックログが1つある（LeSSと同様にNexusは、1つのプロダクトバックログで作業する）
• Nexusフレームワークは、既存のスクラムアジャイルフレームワークに追加され、オーバーレイされる
• Nexusはスクラムを大規模開発向けに拡張しているので、Nexusを知るためにはスクラムを知る必要がある
• スクラムは3〜10人程度のスクラムチームがイテレーション開発を運営するためのロール、成果物、イベント（やること）で構成されている
• スクラムは単独のスクラムチームの運営を想定している
• Nexusはスクラムを複数チームが連携しながらイテレーション開発を行えるように拡張している

提唱者

• ケン・シュエイバー（Ken Schwaber） と Scrum.org

スクラムガイドを執筆したKen Schwaberが2015年にスクラムガイドとともに発表した大規模スクラム開発の手法で、2018年に更新されました。

所感

日本語のドキュメントが整備されていたり、scrum.orgという企業が提供していたり、採用率は低いものの、比較的手法として安定している印象や、スクラムガイドを執筆したケンシュエイバーが提唱していることもあり、シンプルにスクラムを大きくした手法であることが特徴かもしれません。LeSSと同様にキャッチアップコストの低く、導入しやすいスケーリング手法ではあるのかなぁという印象です。NexusはLeSSの弟みたいな感じと言っている人がいてなんとなくそうなんだぁと感じました。そのくらいには似ています。

LeSSとの違いは、

• チーム数

  • LeSS：2〜8チーム
  • Nexus：3〜9チーム

• 構成

  • LeSS：拠点単位で、Product Ownerをひとりだけ設置
  • Nexus：スクラムチームと統合Nexusチーム（Product Ownerはひとり、ほかメンバーは兼任可）

統合Nexusチームをわかりやすく表現すると、EM（Engineering Manager）が適当なのではないかと感じます。
いずれにせよ、各スクラムチームにPOはいません。（適切な代表者とメンバーとスクラムマスターで構成される）

LeSSなのかNexusのなのかで比較すると、情報を集めていると流行り的には、LeSSを採用するほうが国内では情報が集めやすい印象でした。

参照したい情報

• The Nexus™ Guide | Scrum.org
• Nexus™ ガイド | 日本語版
• Nexus and LeSS #rsgt2016
• NexusとLeSSの違いは何ですか？ | Scrum.org NexusとLeSSの違いは何ですか？

Recipes for Agile Governance in the Enterprise (RAGE)

引用元：https://www.cprime.com/rage/

概要

RAGEは、アジャイルガバナンスのためのCprimeのフレームワーク、または繰り返し可能な意思決定の実践の形式化と実行です。最小限の労力で開発された軽量のアーティファクトに基づいた迅速な意思決定を可能にします。あらゆる企業のプロジェクト、プログラム、ポートフォリオレベルのあらゆるプロセスに適用できます。

引用元：https://www.cprime.com/rage/

所感

SAFeと似た印象がありますが、RAGEのほうがポートフォリオ管理を含んでいたりするので、より包括的な構造な気がします。SAFeで取り込めるのはあくまで戦略との接続と経営層のアジャイルに対する理解促進のような気がします。

参照したい情報

• RAGE | Scaled Agile Transformations | Process
• https://www.cprime.com/wp-content/uploads/woocommerce_uploads/2013/07/RAGE-Final-cPrime1.pdf

おわりに

軽い気持ちでテーマに選んで調べ始めてみましたが、なかなか情報量が多いかつ、日本語の資料がほとんど無かったりで結構調べることがたいへんでした。ただ、これまで全然知らなかった大規模スクラムの手法について、ポピュラーなものはある程度把握できたかなと思います。掲載内容が粗くて申し訳ないです。

アジャイルレポートは読んでみるとなかなか興味深くて、世界的なアジャイルの普及率、採用されているプラクティスの割合や大規模スクラムの成功要因などなど、アジャイル界隈のざっくりとしたトレンドを把握することができます。

アジャイルコミュニティに入っていくと、たくさんの手法があってその全体を把握することがなかなか難しいのですが、例に漏れずスケーリングスクラムの手法も乱立していてなにがなんだかわからなかったので、それを調べる良い機会になりました。

実際に組織や企業に適用した事例は、国内ではまだまだ少ないので、今後大規模の手法の採用事例も増えていくのでしょうか。とても楽しみです。