DXを加速するアジャイル ～変化を味方にしたチームづくり～
【第12回】 「スクラム」をスケールする方法

「第1回：DXがアジャイルを必要とする理由」はこちら＞
「第2回：アジャイルとの出合いから現在まで」はこちら＞
「第3回：スクラムの原点は、日本発のひとつの論文」はこちら＞
「第4回：アジャイル開発の実際」はこちら＞
「第5回：スクラムによる組織改革事例」はこちら＞
「第6回：心理的安全性と幸福度」はこちら＞
「第7回：1週間のスプリントを繰り返す「スクラム」」はこちら＞
「第8回：「スクラム」の3つの役割」はこちら＞
「第9回：「朝会」と「ふりかえり」を大切に」はこちら＞
「第10回：「場づくり」の5つの原則」はこちら＞
「第11回：オンラインで行う 「スクラム」」はこちら＞

いきなりスケールはNG

これまでお話してきたように、「スクラム」というのは最適人数が5～7人で、僕の経験では12人が最大です。それ以上のサイズになるとチームを大きくするだけでは肝心のコミュニケーションが難しくなり、途端に難易度が上がります。開発する製品やサービスの規模が大きくなった時などには、「スクラム」を拡張するスケールのための技法というものが存在します。

今回はいくつか代表的なスケールの技法を紹介したいと思いますが、最初に言っておきたいのは、スケールはうまくいくとは限らないということ。チームという人間の組織の問題なので、徐々に行うのがよく、いきなり10チームにスケーリングフレームワークを導入するのはリスクが高いということです。最低でも1チームに「スクラム」でうまくいった実績があって、それを2チーム、５チームそして10チームにスケールするというのが理想的です。それは、経験というベースが必要だからです。これを抜きにして10チームでいきなり「スクラム」のフレームワークを導入しても、うまくいかないということは頭に入れておいてください。「スクラム」では、実践的な経験や感覚がそれくらい重要なのです。

LeSS(Large Scrum Scale) フレームワーク

最初に紹介するのは、「スクラム」を素直に拡張するとこうなりますというソフトウェア開発に特化した 「LeSS」というスケールの技法です。ひとつの製品に対して、一緒に作業する複数のチームに「スクラム」を拡張するためのフレームワークです。一人のプロダクトオーナーの元で複数のチームが協調して作業する「LeSS」は、チームが増えても全体のプロダクトバックログは１つ、プロダクトオーナーは一人です。

Nexusフレームワーク

「Nexus」というフレームワークでは、それぞれのスクラムチームの代表が参加して「クロスチームリファインメント」というイベントでどのチームがどの作業を引き受けるのかを決めます。各アイテム間の依存関係などを事前に明確にし、開発の透明性を確保してからスプリントプランニングを行い各チームがスプリントに入ります。「Nexus」の大きな特徴は、スクラムチームからきたメンバーによる「Nexusインテグレーションチーム」が、各スクラムのスプリントで出来上がったものを統合する際の説明責任者となって、開発の透明性を確保する役割を担うというところです。

Scrum@Scale フレームワーク

第5回では、フラクタル構造で「スクラム」をスケールする「Scrum@Scale」を紹介しました。このフレームワークでは、スクラムマスターとプロダクトオーナーという２つの役割が重要で、プロダクトのレイヤー、プロダクト・サービスのレイヤー、事業レベルのレイヤーそれぞれに存在します。プロダクトオーナーは、製品の戦略を考え、スクラムマスターは開発の障害を取り除く。各レイヤーのオーナーは、1週間に1回集まってEMS（エグゼクティブメタスクラム）という製品戦略を議論して何を作ればいいのかを突き詰めていく。一方で各レイヤーのスクラムマスターも、EAT(エグゼクティブアクションチーム)という集まりで開発の障害を取り除く最良の方法を突き詰めていく。ですから最上位の EAT には 取締役や執行役員レベルの人に入ってもらいます。この両輪でスクラムをスケールするのがScrum@Scaleです。導入された企業は、ソフトウェア開発だけではなく「組織のコミュニケーションプロトコル」としてもこれを活用しています。

SAFe、DAなど

他にも、「SAFe」や「DA(Disciplined Agile)」、それ以外のフレームワークが存在します。それぞれ日本でも認知され，SAFeはドキュメントやトレーニングも充実しているし、大企業が取り組みやすいフレームワークだと思います。また、DAは企業の人材管理やビジネス戦略までを包括したもので、PMBOK（Project Management Body Of Knowledge）を提供しているPMI(プロジェクトマネジメント協会)がこの手法を啓蒙しています。

このように「スクラム」のスケールにはさまざまな技法が存在します。企業や作ろうとするもの、規模など目的や条件も同じものはないはずですから、興味がある方はぜひWebやセミナーなどで深掘りしてみてください。

「第13回：ゾンビスクラムにならないために」はこちら＞

平鍋 健児（ひらなべ けんじ）

株式会社 永和システムマネジメント 代表取締役社長、株式会社チェンジビジョン 代表取締役CTO、Scrum Inc.Japan 取締役。1989年東京大学工学部卒業後、UMLエディタastah*の開発などを経て、現在は、アジャイル開発の場、Agile Studio にて顧客と共創の環境づくりを実践する経営者。 初代アジャイルジャパン実行委員長、著書『アジャイル開発とスクラム 第2版』（野中郁次郎、及部敬雄と共著） 他に翻訳書多数。

『アジャイル開発とスクラム　第2版』

著：平鍋健児 野中郁次郎　及部敬雄
発行：翔泳社（2021年）