スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。
スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。
そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。
本記事ではその内容をダイジェストで紹介しましょう。
Scrum@Scale入門
原田と言います。アトラクタという会社でアジャイル会社のコンサルティングやコーチングをしています。
今日はスケーリングの話をするわけですが。まずはちょっと面白いスライドを見ていただきたいと思います。
これは権力の源泉についてのグラフです。昔むかし、農耕時代は土地を持っている人が強かった。ですが産業革命が起きると、今度は資本、お金を持ってる人が強くなる。
そしていまは情報産業の時代。資産も土地も、権力の源泉としての価値は下がります。いまは知的労働力、知識や情報を扱うこと、新しい技術を生みだす人が強い。というのがいまのざっくりとした感触です。
いまこの会場にいる皆さんはITシステムのデベロッパーで、知的労働力で、皆さんみたいな価値のある人をどうやって集めるかが大事になってきています。
エッジへ権限を委譲する時代へ
2000年代に初頭に出た本「パワー トゥ ザ エッジ」（デヴィッド・S. アルバーツ、リチャード・E.ヘイズ著 東京電機大学出版局 2009年）という本が面白くて、これは米軍の組織をどうやって動かすかという話です。
軍の組織の指揮命令系統は、トップが情報が集めてトップが判断をし命令を下すことで、トップの思い通りに組織が動くというのが目標でした。
しかしこの本で言われているのは、現代では実はそんなことをしていたら間に合わない。何かあったときにいちいち司令部に問い合わせていたら間に合わない。だからエッジ、末端の実際に働いているところに判断の権限を委譲しないと、そういう組織を作らないといまの時代に動ける組織はできないよ、ということが書かれています。
これが10年前でした。
この話がこのあとどう動くか。こういう本があります。「米海軍で屈指の潜水艦艦長による『最強組織』の作り方」（L・デビッド・マルケ著 東京経済新報社 2014年）。
著者のデビッド・マルケさんは潜水艦の艦長なのですが、指揮命令をしない艦長です。
そしてここに書かれているのは「インテントベースドリーダーシップ」。意図を伝えることによるリーダーシップ。リーダーにどんな意図があるかを部下に伝えることで、潜水艦員が自律的に動けるようになる。
例えば、艦長が方向を間違えて、海の深い方に行かなくちゃいけないのに間違えて陸の方に向かおうとすると、艦長それは方向を間違ってます、深い方に行きたいなら逆ですと潜水艦員が言える。
いままでの軍隊では考えられない組織ですよね。いままではたとえ上司が間違ってもそれに従うのが常識でした。そういう組織の形が変わりつつあります。
そしてこの本が昨年出ました。「The Age of Agile」（Stephen Denning著 Amacom Books 2018年）、時代はアジャイルだ、という本です。
著者のスティーブ・デニングという人は、世界銀行で働いていたナレッジマネジメントの専門家です。
この本が面白いのは、これがソフトウェア業界の人ではなく、ビジネスサイドにいた、世界銀行で働いていたすごい人が書いたということ。しかも私がメールで質問すると1時間で返事が返ってきました。だいぶアジャイルであることを実現している人です。
彼が言っていることは、いま世界でうまくいっている組織はこの3つがあると。
1つは顧客第一であること。2つ目は小さなチームたち。大きな組織ではなく、小さな独立したチームがそれぞれお客様に価値を届けられるようになっている。3つ目はネットワーク。チームのネットワークや情報のネットワークを使って仕事をしていること。
これがこの本の結論です。翻訳をしたいなと思っているので、興味のある出版社さん、よろしくお願いします。
適切なチームの人数は？
こういう話をするとすぐ出てくるのが、チームの人数の話です。
アジャイルやスクラムをやっている人には、チームの人数は「5人くらいがいいよ」と私は言っています。
この図は何を示しているかというと、コミュニケーションのパスです。5人だとパスの数が10くらいなのですね。これだけのパスを満たせば全員が知っている状態になる。
全員が知っている状態が作りやすいので、たとえ全員が同じ場所にいなくても同じ情報を知っているならだいたい同じ判断が判断が下せるはず。これが意思決定の速さにつながります。
アジャイルチームの最大値は9人ですが、スクラムの場合は9人だとだいぶつらいです。
まあこの図を見ると、5人から多くても7人くらいがいいかなと思います。
スケールの前に良いチームをまず2つ育てろ
ここから「Scrum@Scale」の話をするのですが、スケールさせる前の条件があって、これはジェフ（スクラムの提唱者であるジェフ・サザーランド氏）もよく言っているのですが、スケールする前に、良いチームをまず2つ育てろと。
良いチームができないのにスケールさせると、よくないチームがスケールするんですよ。だから、良いチームが2つできるまではScrum@Scaleはやっちゃだめ、と。
ジェフは、だいたいコンサルで呼ばれて訪問した会社の半分くらいはScrum@Scaleじゃなくてベーシックなスクラムの話をすることになるから、まずはスクラムをちゃんとやろうねと。
Scrum@Scale Frameworkの図としてはこんな形になっています。
通常のスクラムと大きく違うのは、プロダクトオーナーのサイクルです。スクラムはプロダクトオーナーに大分冷たいフレームワークなので、プロダクトオーナーがどうすればいいかはあんまり書いていません。
Scrum@Scaleでは、プロダクトオーナーが何をすればいいか、少し補われています。
図の右側、「Product Owner Cycle」は、何を作ればいいか、役立つものは何か、プロダクトとして何を作るのかを決めます。
反対側（図の左側）の「Scrum Master Cycle」。これはScrum Master Cycleじゃなくてデプロイサイクルなんじゃないの？ という議論はいまスクラムのトレーナー間で議論が進んでいますが、こちら側はいままでどおり、動くソフトウェアをチームで作ってデプロイする、というサイクルです。
この2つのサイクルをぐるぐる回さなくては、というのがScrum@Scaleのフレームワークです。
なぜこのようなScrum@Scaleというフレームワークを作ったのか。
スクラムはそれ自身だけでスケールするフレームワークです。ですけど、最近周りがかまびすしくてですね、「スクラムだけじゃスケールできないから、ほかのスケーリングフレームワークがいる」などと言われてしまった結果、いろんなフレームワークが出てきてしまいました。
なので、スクラムで普通にやればできるということを、どうやら書いておかなくてはいけないらしいと。
というので去年（2018年）2月くらいにScrum@Scaleを定義して提供しようという話になりました。
Scrum@Scaleでは、Scrumガイドに出てくるチームメンバーが、チームになります。チーム同士をどう調整して、チームがチームとして動くためにどうすればいいかが、Scrum@Scaleの課題になります。
スケールフリーアーキテクチャ
Scrum@Scaleの背後にあるのが、スケールフリーアーキテクチャです。
チームの人数が増えるとコミュニケーションパスが幾何級数的に増えるのは、先ほどの図で見たとおりです。しかし人間の神経細胞は何十億とたくさんありますが、手を動かそうと思うとすぐ手が動く。わりとアジャイルです。
この仕掛けとしてニューラルネットワークはスケールフリーアーキテクチャで作られています。
要は複数の階層が重なって、階層構造とフルメッシュのあいだのような構造です。
最小限の官僚主義をいれる
Scrum@Scaleにおけるスケーリングの課題は、チームの外にあります。
チームをスケールフリーのネットワークにつなげば、コミュニケーションパスはできますが、なんとかの承認を待たなくてはならないとか、パス先の反応が遅いとチームがそのスピードに制限される。
マネージャの上にマネージャがいて、その上にマネージャがいて、というのでは遅くなる。
とはいえ、組織としては完全にこれをなくすわけにもいかないので、Scrum@Scaleでは「Minimum Viable Bureaucracy」、官僚主義を最小限に、あった方が役に立つ部分はいれようと。
スケール化デイリースクラム
スクラムをスケールするためにScrum of Scrums（SoS）を使うことで、コミュニケーションパスを増やさずに飽和度をあげられます。
その仕掛けの1つが、Scrum of Scrums Master（SoSM）です。
スクラムマスター同士が集まって、この問題をどう片付けようか、といったことを議論するグループミーティングなんですが、Scrum@ScaleではScrum of Scrumsがまた1つのチームになっています。
ここでの議論は、個々のチームがうまくリリースすることを助ける。そのためにScrum of Scrumsというレベルでの活動をします。
さらにScrum of Scrums of Scrums、スケール化デイリースクラム（SDS）というのをやります。
デイリースクラムをやったあとで、メンバーの代表同士、赤いのがスクラムマスターで、黄色いのがプロダクトオーナーで、デイリースクラムをやったら、次のレベルのデイリースクラムをやります。
そうしてScrum of Scurumsをやって、その次のレベルのScrum of Scrums of Scrumsをやって、それを繰り返したいちばん上にはエグゼクティブアクションチーム（EAT）がいます。
ここには会社の役員レベルに入ってもらいます。
で、EATで何をやるかというと、スクラムマスターがやることをやる。つまりチームの障害を取り除く、ということをやります。
チームレベルのスクラムマスターができることは限られています。そこで対応できないとなると、その上のSoSのレベルで相談しますが、それでもできなければまた上のレベルに問題をあげていきます。
で、三段階くらいあげていくと、EATにくるわけです。
そしてEATのメンバーには役員がいます。役員ですから問題に対してはその場で対応を決めて、その場でメンバーに伝えよ、とする。するとめちゃくちゃ早く問題に対応できます。
スクラムチームがあって、SoSがあって、そのデイリースクラムのなかで課題があがったらすぐエスカレーションされるのです。
戦闘機もScrum@Scaleで作っているSAAB
これをSAAB Technologiesという会社、戦闘機のグリペンの開発でやっています。ゲームの「エースコンバット」をやっている人なら、グリペンは良い機体だっていう人、いますよね？
彼らは製造業なので朝が早いです（笑）
7時30分 SCRUMチームのデイリースクラムがあります。
7時45分 SoSのデイリースクラムがあります。
8時00分 SoSoSのデイリースクラムがあって、
8時15分 SoSoSoSのデイリースクラムがあって、
8時30分 EATがあります。
というわけで、スクラムチームが価値を届けることに困るような課題があれば、1時間後にはトップエグゼクティブの知るところとなって、そのEATでさっさと課題に対応できると。圧倒的に早いですよね。
グリペンは6カ月ごとに1回アップデートされることが決まっていて、いちばんコスト効果が高い戦闘機だと言われています。
ハードウェアの世界で、戦闘機という大変難しい分野でも半年に一回リリースが可能になっているのです。
EATを構成するメンバーとは？
ではEATには誰が必要でしょうか？
ある課題があがってきたときに、対応をこのEATの場で決めたいんですよ。ですからCxOの人は必要ですし、何かお金にかかわるときもあるので財務の責任者、そしてアジャイルなやり方としてそれがいいか悪いかをアドバイスできるアジャイルチャンピオン的な人がほしい。
場合によっては人の異動もあるでしょうから人事担当、そして法律的な面を判断できる法務担当。
こうした人たちがEATに必要でしょう。
≫後編に続きます。後編ではプロダクトオーナーをスケールさせる方法について解説します。
関連記事
スクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏の2011年の講演を、あわせてぜひご覧ください。
あわせて読みたい
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（後編）。Developers Summit 2019
≪前の記事
FileMakerが「Claris」へ社名変更。クラウドサービスとの接続機能「Claris Connect」も発表
