スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（後編）。Developers Summit 2019
アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。
スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。
そのために開発されたのが「Scrum@Scale」フレームワークです。
本記事は「スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019」の続きです。
プロダクトオーナーをスケールする
ここまではスクラムマスター側をスケールさせる話をしてきました。
その反対側のプロダクトオーナー側はどうでしょう。
Scrum@Scaleがほかのフレームワークとちょっと違うのは、チームには必ず一人のプロダクトオーナーをアサインしてね、と言っていることです。
一人のプロダクトオーナーが複数チームを見てもかまわないのですが、そうするとどうしてもチームの中でプロダクトオーナーがボトルネックになりやすいので、複数チームを掛け持ちするときには、掛け持ちする人をチーフプロダクトオーナーとして、できるだけチーム内のプロダクトオーナーに権限委譲できるようにしてねと。
この場合、プロダクトオーナーの上位がチーフプロダクトオーナー、その上はチーフチーフプロダクトオーナーになります。
ちなみにスクラムマスター側の最上位にはEATという名前が付いていますけど、プロダクトオーナーの方はそうなってなくて、チーフチーフチーフチーフプロダクトオーナーとか言いたくないので（笑）、いい名前があったら教えてください。
プロダクトオーナーもグループを作って、それぞれのチームにどんなアサインをしたらいいか、といった調整をします。これを「メタスクラム」といいます。
ちなみにこれも「メタスクラム」「メタメタスクラム」「メタメタメタスクラム」とレイヤが上がっていって、いちばん上が「エグゼクティブメタスクラム」です。
メタスクラム、エグゼクティブメタスクラムはEATと違ってプロダクトの方針、ビジョンを考える役割なので、必ずしもマネージャである必要はありません。
メタスクラムもスクラムチームなので、それぞれのチームでレビューをして、うまくいったかを確認します。
スクラムマスターとプロダクトオーナーのやり方の違い
スクラムマスターとプロダクトオーナーではスケールの仕方が違っていて、スクラムマスターはチームの問題を解決する、取り除く。
チームの問題はみんなの問題なので、そのためにScrum of Scrumsでみんなでよってたかって協力して問題を取り除く方法を考える。
一方、プロダクトオーナーは意志決定が勝負なので、プロダクトオーナーにとって上のレイヤの判断は絶対です。プロダクトオーナーが迷ったらチーフプロダクトオーナーに相談、あるいはチーフプロダクトオーナーが決める、という構造をしています。
最近、スクラムチームのコーチとしてお客様のところへいって、プロダクトオーナー側を支援することもあるのですが、最近したプロダクトオーナーに対するアドバイスは、もうちょっと時間をかけて調査する、というのは許されず、いま間違えろと。次のスプリントで作って、もしそれが間違いだったらそこで分かるので、その方が早い。調査するのを待っていると知らない状態でチームが進むので、スピードが遅くなると。
ただ、それでチームが失敗ばかりしてしまうのはどうしましょうか、というのは、まあプロダクトオーナーの責任なのですが、それでもまず間違えろ、早く間違えろと。その方が自分もチームも学ぶんです。まあ、それはつらいんですけどね。
Scrum@Scaleの利用方法
このようにプロダクトオーナー側では役に立つものを見つけにかかるサイクルと、スクラムマスター側ではプロダクトを実際に提供して実験して計測するサイクル。
これを両側でぐるぐる回す仕組みを作るのがScrum@Scaleの目標とするところです。
これは、従来のスクラムではプロダクトオーナー側が何をやったらいいかが分からない、という反省にたって少し改善されています。
Scrum@Scaleはフレームワークなので、どうやって組織に取り入れるか、どうやって詰めていくかは書いていません。
ターゲットによって導入方法は異なります。
これは代表的な事例です。左は伝統的大企業って書いてありますが、このマークでなんとなく分かるかと。
それぞれにスケーリングに対する課題が違います。伝統的大企業は、すでに作り上げてきた複雑なハードやソフトがあって、それを扱うためにはいきなりアジャイルだ、とはいかない。だからユーザーに近いところからプロジェクトごとに、アジャイルを入れていったりする。
中企業はきっかけが企業買収だったりします。ある企業を買収してみたらその企業がスクラムを使っていた。そのノリに合わせないと製品を統合できない、というのでじゃあスクラムを覚えるか、ということが多かったりします。
Autodeskなんて、紙の図面をCADで置き換えた会社なので破壊的イノベーターだったのですが、それがだんだん大きくなっていくときに、まさにスケールする仕方を模索していたと。
いちばん右は、そもそも会社を作ったときからアジャイルを取り入れているんだけど、顧客の規模が大きくなってくると開発組織を大きくしなくちゃいけなくて、既存のアジャイルだけでは回らなくなってきた。
といった形で、導入の方向性はいっぱいあります。
実はスクラムも一緒です。大きな会社でスクラムをやりましょうといわれて、行って説明すると、「そんないいかげんなやり方でソフトウェアを作って大丈夫なのか？」と言われます。で、「デモするから大丈夫です」っていうと、「いや、レビューぐらい誰でもするだろ」と言われて。
逆もちろんあって、ベンチャーが製品を出したら当たっちゃってユーザーが急に増えて機能要求がたくさんくるようになって、だんだん回らなくなってどうしようと。
そこにスクラムを教えに行って、「バックログを作って一列に並べるんです」って言うと、「ソフトウェアを作るのにそんな面倒くさいことしなくちゃいけないんですか？」って言われる（笑）。
同じようにScrum@Scaleっていうやり方があるよって言っても、会社ごとに見え方がずいぶん違う。だから会社ごとに合ったやり方で、どの辺からいれるといいかは違います。
でもScrum@Scaleをやるのであれば、最終的には全部にいれてねと。いきなり全部は無理ですからじわじわと。どのコンポーネントから入れるか、どの組織から、どの事業所からいれるか、それはEATで考えてください。
そのときには、例えば組織図がこんな風になります。階層っぽく見ますが、となり同士が見ているので情報共有はものすごく早いです。ここでは五角形で書かれていますが、必ずしも5である必要はありません。
チームに必ずプロダクトオーナーとスクラムマスターがいるのは狙いがあって、チームごと異動できるんですね。プロダクトオーナーとスクラムマスターがいるとチームごと動かせるんですね。
Scrum@Scaleでは、チームを壊さないでくれと言うことをいつもいっています。ニーズが増えたところにチームごと異動できて、移動先にはすでに別のチームが横にいて、うまく行くチームを育てるのには時間がかかりますし、新たにチームを立ち上げるよりもプロダクトを扱えるようになる時間が圧倒的に短くなるんです。
エンジニアの知見を使ってマネジメントに参画できる
いくつかやってみての私見です。
EATもスクラムチームなんですよ、なのでバックログがいります。作業を見積もらなくてはいけません。デモもしなくちゃいけません。
で、EATは何がいいかというと、アジャイルをやったことのないマネージャに透明性とタイムボックスの練習ができます。そしてスプリントごとに、EATがこんな課題を解消しましたっていうデモしてもらいます。
で、皆さんはステークホルダーなのでみんなでデモを見に行きます。
いいですか？ ステークホルダーはプロダクトオーナーに優しくするんですよ（笑）
あと、Scrum@Scaleでは、エンジニア経験を持ったマネージャがエンジニアの知見を十分に使ってマネジメントに参画できます。デベロッパーってマネージャになるのをいやがるじゃないですか。ねえ。
でもいまからのマネージャって仕事のやり方が大分違うはずです。イノベーティブな企業ってだいたいエンジニアドリブンな企業が多いので、それはエンジニアが分かったマネージャの方がいいですよね。
でも残念ながらエンジニアだけではある程度以上の規模の組織は回せないですよね。
だからマネージャになってください。ただ、皆さんが知っているようなマネージャになる必要はなくて、要は同じようにスクラムの仕掛けを使って、透明性やメトリクスやチームビルドを使って、たぶん扱う対象がコードじゃなくなるだけで、スキルはエンジニアにすごく近いと思います。
まあMinimum Viable Bureaucracy、最低限の官僚主義、というのにはもう少し良い名前を付けたいですが、そのあたりを手伝っていける仕掛けとしてScrum@Scaleはいいのではないでしょうか。
Scrum@Scaleガイド、日本語版もありますが、まだ訳がこなれていなかったりするところもあるので、ぜひフィードバックをいただければと思います。
最後、マネージャで大事なのは、チームの邪魔をしないこと。マネージャの仕事って妨害を取り除くことじゃないですか、あなたが妨害になってどうするんですかと、チームが早く動けるようにちょっとどいてくださいと、そうすればチームが早く動けるようになります。
ありがとうございました。
公開されているスライド「Scrum@Scale入門」
関連記事
スクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏の2011年の講演を、あわせてぜひご覧ください。
あわせて読みたい
CircleCI、Windows対応を正式リリース。Windows Server 2019の仮想マシンでビルドやテストが実行可能に
≪前の記事
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
