Scrum Interaction 2019レポートその1：スクラムの“父”が説くアジャイルの「成功」と「失敗」の分岐点

2019-12-24

Summary

2019年11月8日、Scrum Inc. Japanが主催するワークショップ型カンファレンス「Scrum interaction 2019」が開催され、その基調講演に“スクラムの父”とされるジェフ・サザーランド氏と、“スクラムの祖父”とされる野中郁次郎氏がそれぞれ登場した。まずは、スクラムの父、サザーランド氏の講演内容をダイジェストでお届けする。

アジャイルプロジェクトの半分は失敗しているという現実

アジャイル開発手法として世界で最も普及するスクラムの共同考案者であるジェフ・サザーランド氏。米国陸軍士官学校卒業後、戦闘機のパイロット、がん研究者を経て、11の企業でCTOを歴任したのち、1993年に最初のスクラムチームを率いて、金融、ヘルスケア、高等教育、通信など、あらゆる産業でスクラムの拡大を先導した。そんな経歴を持つスクラムの“父”、サザーランド氏は今回、「Scrum@Scaleでビジネスアジリティを実現する」と題した講演を展開した。

その講演の中で同氏はまず、世の中の変化に敏感であることの重要性を次のように説く。「一定の規模を持った会社で働くビジネスパーソンの中で、“自分の会社は10年後になくなるかもしれない”と本気で考えている人はどのくらいいるでしょうか。おそらく、そうした感覚を持つ方は少数派でしょう。ただし、世の中が変化する近年のスピードは極めて速く、どのような会社であっても、10年後に消滅する可能性があるんです。」同氏によれば、こうした変化の多くはITによるビジネスモデルの変革によってもたらされており、その変化に企業が機敏に対応するには、アジャイル開発の手法を取り入れることが不可欠であるとする。

ただし、調査によると、アジャイル開発プロジェクトの47％は失敗しており、成果物である製品がデリバリーできていない状況にあるようだ。

「これらの失敗は、プロジェクトチームがスクラムを正しく実践していなかったことに原因があります。実際、スクラムの手法は11のコンポーネントから構成されていますが、失敗チームの多くはその3分の1しか実践しておらず、チームの3分の1はまったく実践していませんでした。これではまるでタイヤの両輪がパンクした状態で前に進もうとしているようなものです」

MIT（マサチューセッツ工科大学）ビジネススクールの調査によれば、アジャイルへの転換に失敗した企業の25％は倒産・買収といった壊滅的な打撃を受けているという。「だからこそ、スクラムを正しく実践することが大切なんです」と、サザーランド氏は語気を強める。

「Scrum@Scale」でスクラムをスケールする

サザーランド氏によると、今日における米国国防総省のプロジェクトは、すべてアジャイルで行うことが法的に義務付けられているという。

とはいえ、Standish GroupによるCHAOS Report 2018に基づくと、アジャイルプロジェクトには、およそ半数が成果物のデリバリーに失敗するリスクがある。そのため、米国国防総省の調達要件では、「サプライヤーは全てのスプリントの後に、必ず何かをデリバリーすること」「新機能のリクエストから1カ月以内に全バックログを更新すること」といった事柄が定義され、その要件に沿ってサプライヤーが選定されている。「これらはすべて、“いい加減なアジャイル開発”“デタラメなスクラム”を排除するための工夫です」と、サザーランド氏は説明を加える。

ご存知の方も多いと思うが、サザーランド氏によるスクラムの着想の元となったのは、野中郁次郎氏が発表した論文『The New New Product Development Game（邦題／新製品開発のプロセス）』である。

「この論文は、まさに私がやりたかったことを見事に表現していました。そこで、論文に書かれていた意思決定の方法をスクラムと名づけ、スクラムマスターというチームリーダーの下で開発を推進することを提案したのです」(サザーランド氏)。それから2年後の1995年、サザーランド氏はスクラムを使ったプロダクトのデリバリーに成功し、その経験を基にスクラムを広く展開するために定義やガイドを作成した。それがスクラム拡大の方法論である「Scrum@Scale」のベースとなっている。

「Scrum@Scaleは、開発部門のみならず、企業のさまざまな部門が、予測可能性や俊敏性をもってビジネス成果を生み出すための手法と言えます。例えば、スクラムマスターがソフトウェア開発のサイクルを回すのと同じように、プロダクトオーナーがビジネスの改善サイクルを回していきます」(同氏)。

スプリントを早く終わらせることが成功のキモ

サザーランド氏は今回、Scrum@Scaleの重要な構成要素の1つとして、「スケールフリーなアーキテクチャ」を挙げた。神経回路のような形状の下でチームの集団を組織化し、意思決定を構造化していくことでリニアにスケールしていくことが可能になるという。このアーキテクチャの中では、意思決定は個々のチームに委ねられるが、チームの規模を小さくすることで意思決定の遅れを少なくできる。

また、Scrum@Scaleでは、少人数構成のリーンな「スクラムチーム」のほかに、複数のスクラムマスターで組織される「スクラム・オブ・スクラム(SoS)」、最上位のSoSである「エグゼクティブアクションチーム(EAT)」で構成される。さらに、プロダクトオーナーについても、チーフプロダクトオーナー(CPO)チームやエグゼクテイブメタスクラム(EMS)を構成することになる。

「Scrum@Scaleで重視するのはプロセス効率（作業時間÷カレンダー時間）です。多くの意思決定を下す場合も、素早く現場のスクラムチームに落とし込んで10分以内に意思決定ができるようにするのが理想です。また、SoSは、プロダクトオーナーのチームと一緒になりながら1時間以内に意思決定できるようにします。こうしたアジャイルリーダーシップによって加速度的に生産性を向上させることが可能となり、いつまでたってもプロダクトがデリバリーできないといった失敗も防げるようになるのです」(同氏)。

さらに同氏は今回、従来のウォーターフォール型の開発から、アジャイル開発に切り替える方法についても言及した。

「従来のウォーターフォールとアジャイルの間に『変換レイヤー』を設けます。そして、アジャイルの取り組みを進める中で、このレイヤーを段階的に取り除いていきます。実際の取り組みではプロダクトオーナーが、アジャイルへの切り替えの優先順位をつけ、優先順位が最高のものにチームと予算を割り当てます。優先順位付けされたバックログに沿ってチームが自己を組織化し、デリバリーをスピーディに、頻繁に行っていきます」（同氏）。