大規模アジャイルフレームワークの紹介

みなさんこんにちは。@ryuzeeです。
12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。

スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。

そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。紹介しますが、最初に大事なことをお伝えしてから紹介します。

そんなにたくさん作っても使わない

2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。

まったく使わない: 24%
ほとんど使わない: 56%
よく使う: 8%
いつも使う: 12%

つまり80%の機能はほとんど、もしくは、まったく使われないということになります。たくさんの人を集めて、たくさんの機能を作るのは、ムダである可能性が高いと言えます。

「いや、全部必要なんだけど」という場合は、ウォーターフォールでやってください。最初から全部必要なものが分かっている自信があるなら、フィードバックサイクルのオーバーヘッドのあるやり方でやる必要はありません（その自信は単なる妄想かもしれませんが）。

そもそも大規模は手法に関係なく難しい

言うまでもないような気もしますが、開発の手法に関係なく、基本的に規模が大きければ大きいほど、プロジェクトの難易度は上がります。

スタンディッシュグループが2015年に発表したデータによると、小規模ではアジャイルの成功率が58%、ウォーターフォールでの成功率が44%ある一方で、大規模になると、それぞれ18%と3%に低下しています。「成功の定義」が適切なのか？というのは常に議論の余地がありますが、単純に数字だけを見ても大規模は大変であることがわかります。

たくさんの人の足並みを揃えるコストはとても高い

コミュニケーションコストは、チーム内の人数が増えれば増えるほど加速度的に高くなります。また、1つのプロジェクトやプロダクトのなかのチームでも、同期的に動かなければいけなくなればなるほど、調整のコストが高くなったり、待ち時間の影響を受けたりしやすくなります。

階層構造型にした場合、意思決定や問題解決までのホップ数が増え、1つの意思決定や問題が影響を及ぼす範囲が広いため、全体に与える影響も必然的に大きくなります。

身も蓋もない成功のコツ

以上から、「成功したければ、規模を小さくするのが鉄則」で、以下がポイントになります。

いかに不要なものを作らないようにするか
いかにプロダクトを分割して、それぞれを独立、疎結合にするか
いかに情報の流れやコミュニケーションを整流化し、適切な権限を移譲するか

つまり、大規模アジャイルの検討をする前に、スコープを減らしたり、ドメインを分割したりして、1チーム（10人以内くらいのサイズ）でやる方法がないのか？を考え抜く必要があります。規模が大きいというのを変えられない制約と見なすべきではありません。

このとき、現在の状況も踏まえて考えましょう。

これから開発を始めるような初期段階から大規模で始めようとするのは、そもそも重たすぎる（そして、みんな余計な仕事ばかりすることになる）
すでにプロダクトが成長段階にある場合は、規模が大きくなっていくこと自体は自然だが、できる限りシンプルな構造にした方が楽。そして成長に応じて構造を適応させていく（『チームトポロジー』を参照）

考え抜いた結果、それでも大規模アジャイルが必要だという方のために、フレームワークを紹介します。なお、単一チームでの成功体験がないうちに大規模に手を出すのは無謀なので、その点も理解した上で先に進んでください。

大規模アジャイルフレームワーク

以下では主なフレームワークを紹介します。なお画像は公式サイトや公式のガイドのものを引用しています。

LeSS

公式サイト: https://less.works/jp
認定スクラムトレーナーのクレイグ・ラーマンとバス・ボッデらが作った大規模スクラムのフレームワーク
8チームまで用のものと、それ以上の規模用の2つが用意されている
プロダクトバックログは1つで、それぞれのスプリントでインクリメントを作るという点も単一チームのものと違いはない
スプリントバックログは開発チームの作業計画なので、各チームごとに作る
全チームは同じ日にイベントを開始し、スプリント期間も同じ
プロダクトオーナーは1人、スクラムマスターは1人で1〜3チームの面倒を見る
完成の定義は全チームで共通となる
その他細かいルールは、https://less.works/jp/less/rules/indexを参照
全体として、スクラムのルールに沿った形の大規模実装となっており、LeSSを使っていてもスクラムガイドには反しないようになっている
日本語翻訳書籍あり: https://www.amazon.co.jp/dp/B07RFVB7KG/
スクラム実践者の間で利用例が多い。日本でもよく見かける

Nexus

公式サイト: https://www.scrum.org/resources/nexus-guide
スクラムの父の1人、ケン・シュエイバーらが作った大規模スクラムのフレームワーク
公式定義: Nexus Guide https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-03/2018-Nexus-Guide-Japanese.pdf
少なくともスプリントで1つは各チームの成果を統合したインクリメントをデリバリーするように定めている
通常のスクラムに加えて、「Nexus統合チーム」と呼ばれるロールが追加されている。Nexusの適用とスクラムの運用の調整・コーチ・監督を担当する。Nexus統合チームは、プロダクトオーナー、スクラムマスター、Nexus統合チームメンバーで構成されている
Nexus統合チームメンバーは、ツールやプラクティス、エンジニアリングプラクティスに精通していて、各チームを支援するとともに、各チームの成果を統合する役目も担う
プロダクトバックログは全体で1本である

Scrum@Scale

公式サイト: https://www.scrumatscale.com/
公式定義: Scrum@Scale Guide https://scruminc.jp/scrum-at-scale/guide/
ジェフ・サザーランドが中心となって作られたスクラムを使った組織運営のフレームワーク。プロダクトそのものよりも、組織にフォーカスしている
プロダクトオーナー用のサイクルと、スクラムマスター用のサイクルがある
- スクラムマスターサイクルでは、スクラムオブスクラムの形で、個々のスクラムチームでの課題を1段上のレイヤーで収集し、組織的に解決（解決できない場合はさらに1段上のレイヤーのスクラムにエスカレーション）する。最上位のチームをEAT（エグゼクティブアクションチーム）と呼ぶ
- プロダクトオーナーサイクルでは、複数チームのプロダクトオーナーが集まってプロダクトオーナーチームを形成し、それを司るCPO（チーフプロダクトオーナー）がいる

SAFe

公式サイト: https://www.scaledagile.com/jp/
もともとRational Unified Processを作っていたディーン・レフィングウェルを中心に作られた大規模アジャイルのフレームワーク
リーンプロダクト開発、アジャイル開発、システム思考の原則に基づいて、企業や事業部レベルでリーンとアジャイルを実現する際のプラクティス集
組織全体での取り組みとして、ポートフォリオ管理という概念が追加されている
スクラム、XP（eXtreme Programming）、デザイン思考、DevOpsなどさまざまな概念を取り込んでおり、非常に非常に重厚長大
アジャイル界隈の重鎮たちは、SAFeに対してはアジリティを損なうものとして懐疑的な意見が多い
- スクラムの父の1人、ケン・シュエイバーのブログ記事: https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/
- 米国空軍でも、SAFeはまったく推奨しないとしている: https://software.af.mil/dsop/documents/
世界でも日本でも大企業が採用している例を見かけることはある

Disciplined Agile (旧: DAD)

公式サイト: https://www.pmi.org/disciplined-agile
Rationalのスコット・アンブラーが中心となって作られたアジャイルフレームワークで、もともとはIBMで使われていた
近年PMPのアジャイル実装に取り入れられた
以下の特徴を持つとされている
- ピープルファースト
- 学習指向のハイブリッドアジャイル/リーンアプローチ
- リスクと価値のデリバリーライフサイクル
- ゴール駆動
- エンタープライズ対応
- チームレベルでの戦術的スケーラビリティ
- エンタープライズ全体に対する戦略的スケーラビリティ
Disciplined Agileが作られた目的は、スクラムがカバーしていない範囲を埋めるため、とされている
それが故に、SAFeと同様多くの概念が取り込まれて大きなフレームワークになっている
日本で利用している人はあまりいない

それでは。