Ken Schwaber、Jeff Sutherland両氏に聞く - スクラムガイドのアップデートについて

スクラムガイドが更新された。スクラムのあり方がより反映されるとともに、スクラムに対する誤解が解消されている。スクラムはソフトウェア製品開発に使用できるだけでなく、ソフトウェア以外のさまざまな領域にも適用が可能だ。スクラムは経験主義に基づく継続的改善のためのフレームワークである。プロセス全体を通じて、日々の検査と適応をサポートする。各スプリント単位、あるいはさらに高い頻度で出荷可能な製品を用意することが、スクラムの重要な要素だ。

スクラムガイドの新たなアップデートは、スクラムガイドの著者であり、スクラムの開発者でもあるKen Schwaber氏とJeff Surtherland氏の参加したウェビナの中で発表され、議論された。InfoQは氏らにインタビューした。

InfoQ: 主にスクラムガイドのどの部分が変更されたのでしょう？

Ken Schwaber: 主要な変更点は５つあります – スクラムの使用に関する定義の拡大、スクラムマスタの役割定義の明確化、インスペクションの手段としてのデイリースクラムのより明確な理解、タイムボックスの最大長の設定、スプリントレトロスペクティブからのフィードバックを含むようにスプリントバックログを更新したことです。これらの変更はいずれも、スクラムに関する誤解を解消するという同じ目的を持っています。

Jeff Sutherland: 今回のスクラムガイドの変更はすべて、ガイドの表現をより明確化し、スクラムマスタにとってより役に立つものにするという意味で、スクラムコミュニティからの意見を反映したものです。特に私は、“Scrummerfall”の参加者の一部が、スクラムガイドは改善の必要性について述べていない、と言われたことが気になっていました。そのために、ガイドの冒頭の文言を変更して、スクラムが継続的な改善プロセスであることを明確にすると同時に、ガイドの末尾では、レトロスペクティブで少なくともひとつのプロセスの改善を指定して、次のスプリントでの最優先ストーリとしてスプリントバックログに置くことを求めました。

あるスクラムクラスで、リーンのエキスパートのひとりが私に、スクラムを改善するためのスクラムが必要だということを、“必要”という点を強調して指摘しました。レトロスペクティブのミーティングで特定したプロセス改善を実行に移してこそ、レトロスペクティブは有効なのだ、というのです。その指摘を受け入れることで、すぐにベロシティを向上することができました。

InfoQ: スクラムに関する誤解には、どのようなものがあるのでしょう？

Sutherland: アジャイルを自称する人はたくさんいますが、スプリントの終了時、あるいはそれ以上の頻度で、出荷可能な機能のインクリメントの提供を実現できていません。これはスクラムガイドおよびアジャイルマニフェストの第２項に反しています。この検査(inspect)と適応(adapt)の欠如は、リスクの増加と遅延の拡大をもたらします – これを私はScrummerfallと呼んでいます。スクラムを自称してはいますが、ウォーターフォールのすべての症状が現れているのです。2005年に私は、“The Future of Scrum”という論文で、継続的デプロイメントを指向した最初の企業のひとつであるPatientKeeperを取り上げました。継続的デプロイメントはその後、優れた企業にとって例外的ではなく、むしろ標準的なものになりました。しかしながら、スプリントで何もデリバリできなくても問題ではないと考えるチームがまだ存在するのです。

Schwaber: スクラムに関する大きな誤解のひとつは、ソフトウェア機能の開発のみに使用するものだ、ということです。スクラムは多くの人が考えるよりも柔軟で、ソフトウェア開発以外にも、多くの分野に適用することが可能です。スクラムは現在、製品やサービス、PTA組織の管理などに幅広く利用されています。スクラムガイドで“開発”という言葉が使われている場合、あらゆる複雑な作業を指しているのです。

もうひとつの大きな誤解は、システム開発にスクラムを使用するためには、スクラムから何をすべきかを常に知っていなければならない、というものです。私たちは以前、スクラムは複雑な製品を構築するためのフレームワークに過ぎない、と言いました。簡単なことです。スクラムを使ったとしても、複雑な問題を実用的で有用な製品に変えるという作業が、非常に困難であることには変わりありません。複雑なものはやはり複雑なのです。今回のアップデートは、こういった誤解の多くを解決してくれると思います。

InfoQ: 検査と適応はアジャイルの柱のひとつですが、スクラムではどのようにサポートされているのでしょう？

Schwaber: スクラムは、リーン思考と実証的(Empirical)プロセス管理の観点を基盤にしています。実証的プロセス管理は、意思決定を支援する上で、定常的な検査と透過的なアーティファクトの適用に依存しています。1990年代初めからスクラムは、あらゆるイベントとアーティファクトに検査、適応、透過性を組み入れてきました。アジャイルという言葉は、2001年にSnowbirdでアジャイルマニフェストを作成した人たちが考案したものです。その直接的な成果はただひとつ、アジャイルマニフェストの価値と原則です。検査と適応はアジャイルにとって重要かも知れませんが、それがアジャイルであるための唯一の方法ではないのです。

Sutherland: デイリースクラムからスプリントレビュー、レトロスペクティブに至るまで、スクラムのすべてのイベントは検査と適応を目的としています。スプリント終了毎ないしそれ以上の頻度で出荷可能な製品増分を達成できないために、検査と適応が実行不可能な場合には、スクラムは破綻し、重大な機能不全が発生します。

InfoQ: デイリースクラムを検査と適応の手段として使うには、どうすればよいのでしょう？

Sutherland: スクラムは検査と適応そのものです。すべてのイベントが検査と適応なのです。スプリント計画でバックログの先頭を検討して、それがスプリントに相応しいことを確認する、デイリーミーティングで昨日行なったことを確認し、それを今日修正する、スプリントレビューでスプリントの最後に成果物を検査し、ステークホルダからのフィードバックに基づいてバックログを変更する、といった具合です。

Schwaber: デイリースクラムは、開発チームが協力して、スプリントの目標に対する進捗状況を検討し、それに従って計画を調整するための時間です。スクラムガイドに書いてあるとおりです。

開発チームはデイリースクラムを使って、スプリントの目標に対する進捗を検討すると同時に、スプリントバックログで作業が完了するまで、進行状況がどのように変化するかを確認します。スプリント目標を達成する確率を最適化する手段がデイリースクラムなのです。スプリント目標を達成し、スプリントの終わりまでにインクリメントを完成するために、自己組織化チームとしてどのように作業するのかを、開発チームは常に意識していければなりません。

ミーティングの構成は開発チームが設定しますが、スプリント目標への進捗を重視するのであれば、別の方法で実施することも可能です。質問形式で行なっているチームもありますし、議論ベースで運営しているチームもあります。

InfoQ: スクラムで作業しているチームに対して、今回のスクラムガイドの改訂はどのような影響を与えると思いますか？

Schwaber: スクラムフレームワークは20年以上にわたって成果を上げており、ユーザによる素晴らしいサポートコミュニティが構築されています。スクラムの原則や価値観や仕組みを体得し、経験から学んだ人は、他では得られない成功をすでに手にしています – 今回の変更は、そういったユーザにはあまり影響しないでしょう。スクラムの理解を深めようとしている人にとって、望み得る最高のオーバービューを得る上で、今回の変更がより大きく影響します。

Sutherland: チームがスクラムをより良く実践して、より良い結果が得られればと思っています。