アジャイルのスケーリングはいつ必要になるのか？

はじめに

今年（訳注: 2019年）の初めに開催した「Influential Agile Leader」のワークショップで、スケーリングとそれについてどのように考えるべきかについてのセッションを担当しました。

私は、このトピックについて紹介しつつ、「スケーリングは、答えにならないかもしれない」と説明しました。

大規模フレームワークの副作用

経験上、大規模な取り組みにおいてフレームワークを用いると、以下のような予期せぬ副作用を経験することになります：

• フレームワークでの活動は、他の人たちの行動を制御するために、よりマネージャータイプの人員が必要となることがよくある
• フレームワークが生み出すスループットは少なく、それ以上にはならない

ある参加者が質問してきました：

ある参加者「でも、スケールしないといけない場合はどうでしょうか？」

私は質問に質問を重ねました：

Johanna「そうしなければなりませんか？」

ある参加者は答えました：

ある参加者「うちのマネージャーは、今の問題から抜け出すにはそれしかないと思っているんです。」

いいでしょう。このマネージャーが、仕組み全体を考慮するのではなく、その問題に対する1つの解決策だけを定義したことに注目してください。

私は、その参加者に尋ねました：

Johanna「マネージャーは、スケーリングの決断をする前に、レトロスペクティブ（ふりかえり）をしたり、根本原因を調査したりしましたか？」

その参加者は言いました：

ある参加者「確信はないですが、たぶんしていないでしょう。」

私はさらに尋ねました：

Johanna「チームレベルで、アジャイルなアプローチで成功したチームがありますか？」

ある参加者「いいえ、そんなチームはありませんでした。」

私のはじめてのスケーリング体験

私が学校を卒業後に最初に就職したのは、国防総省 (DoD) の超大型通信システムの開発の開発職でした。私たちは、ワイヤレス、放送、ウェビナーのようなもの、あらゆるものを実装しました。それは、1977年の頃です。

私がプログラミングを始めた頃は、数百人規模のプログラムを開発していました。私たちは、10〜12人年しか遅れていませんでした。

仕事を始めて1〜2ヶ月の頃、ある時、私の上司に尋ねました。

「今、この人たちを雇いましょう。そして、彼らが役に立つときには、それまでの時間を補うことができるのではないでしょうか」

上司は、言いました。

「既に試しましたよ。だからあなたたち新卒がみんなここにいるのですよ。」

半年後に、私は、以下の提案をしていました：

「150人をこのプログラムから外しましょう。私がしていることは、彼らの間違っていた仕事を元に戻しているだけなのです。彼らは、彼らが必要なときに必要な情報を持ち得ていないのです。私がチームを選ぶ（10人ほどの人を指名して）ことができれば、遥かに速くできるようになります。私たちは一人で仕事をしています。」

上司は、椅子にもたれかかりながら言いました：

「他の人たちはどうしますか？」

私は答えました：

「かまいません。仕事にこないようにお金を払えばいいです。その方が私たちは速く仕事できるようになります。」

私の上司はそれを好みませんでした。多少の遅れがでても、彼はそれを好みませんでした。

私はまだ、遅延コストやフロー効率の考え方がわかっていませんでした。また、私は、サイクルタイムをどのようにマッピングすればいいのかも知りませんでした。ただ、引継ぎをしなければもっと速くなることはわかっていました。

1977年にもかかわらず、私たちは、フィーチャーセットによって仕事に取り組んでいました。そうです、バーティカル・スライスです。私たちは、進めながら統合しました（訳注: 継続的インテグレーションと思われます）。私たちは、進捗していました。そして、私がそこにいた18ヶ月間の終わりには、30人月の遅れになっていました。

そこには、スケーリングに伴う、引継ぎとサイクルタイムの遅延があったのです。確かに、当時は要件の管理に紙を使っていましたが、それでも情報を最新の状態に保つことはできませんでした。

スケーリングの問題点（今わかっているもの）

多くの場合、マネジメントは、「より少ない労力でなるべく多くの成果をだしたい」より少ない時間でと望むので、スケーリングが必要であると意思決定しようとします。あるいは、マネジメントがこのプロジェクトの開始を遅らせてしまったので、「時間を取り戻そう」としたのかもしれません。

スケーリングを用いなくてもこれらの問題をやりくりする簡単な方法があります。1つか2つの小さなチームを作って、優先順位付けられたバックログから作業を行うのです。バックログは、どれくらいあるかといった量ではなく、「どれくらい少なくできるか」で考えるようにしましょう。

「時間がかかりすぎる」というのは、多くの場合、マネジメントのタイマンの結果です。または、遅れをみていないことに依ります。

次に、実際に大規模な作業量の問題があります。私たちは、12人だけではあの通信システムは開発できなかったでしょう。当時では難しかったです。今でもそうかもしれません。12人が十分なドメイン知識を持っていませんでした。しかし、おそらく50〜60人に人数を制限しておけば、もっと早く終えることができたのでしょう。

しかしながら、チームが小さく、管理者が少なく、管理するポイントが少なければ、大規模なプログラムでも仕事ができています。

アジャイルなアプローチでもそうでなくても、私がみてきたスケーリングでの問題点についての答えは以下です。

メンバーは以下の条件下で、自分たちを組織化（自己組織化）することができます：

• チームがドメインを理解している
• チームが顧客の課題を理解している
• チームが自分たちでデプロイやリリースを行うことができる
• チーム（または、顧客ニーズを理解している人）が作業の優先順位付けができる

これらのチームは、スモールワールドネットワークのアプローチで仕事を管理でき、提供できます。その方法については、「Agile and Lean Program Management」で解説しています。

私は、同僚たちにこれらのアイデアを提案しました。同僚の一人は言いました。

「マネジメントはこれをしたくないだろうね。マネジメントはまだなんでも管理したいだろうから。」

アジャイルのスケーリングは誰の問題に対する答えなのか？

スケーリングのフレームワークと聞くと、「誰が顧客なのでしょうか」と思います。アジャイルなアプローチで結果を出したいマネージャーにとっては、フレームワークが答えになり得るのは間違いないでしょう。しかしながら、このようなマネージャーは、自分自身を変えようとはあまりしません。アジャイルなアプローチのために文化を変えようとはしないことが多いでしょう。

管理者と管理ポイントが増えても、アジャイルな文化は生まれません。あるいは、多くの場合、マネジメントが求めるプロダクトが結果としてでてきます。

「私たちは、スケーリングをしなければならない」と聞くと、その「私たち」とは一体誰なのだろうかと考えてしまいます。スケールすることに何を求めているのでしょうか。

アジャイルの「スケーリング」が組織の問題への答えになることはほとんどありません。多くの場合、それはディスケーリングです。マネージャーにサイクルタイムが見えるようにしてあげるのが、最初の一歩かもしれません。

少し前にアジャイルのスケーリングについてのシリーズ記事を執筆しました。読んでみるといいかもしれません。