「第1回：DXがアジャイルを必要とする理由」はこちら＞
「第2回：アジャイルとの出合いから現在まで」はこちら＞
「第3回：スクラムの原点は、日本発のひとつの論文」はこちら＞
「第4回：アジャイル開発の実際」はこちら＞
「第5回：スクラムによる組織改革事例」はこちら＞
「第6回：心理的安全性と幸福度」はこちら＞
ウォーターフォールとアジャイル
ここからはアジャイル開発の中でもっとも普及している「スクラム」について、できるだけ実践で役立つよう具体的に解説していきたいと思います。その前に繰り返しになりますが、もう一度ウォーターフォールとアジャイルについて復習しましょう。
この図は、ウォーターフォールとアジャイルを対比的に描いたものです。私自身はこの2つの方法が対立してるわけではなく、それぞれに得意・不得意があるということだと考えています。
ウォーターフォールでは、スコープと呼ばれる要求が例えば365個あるとすると、それを一度固定します。固定しないと開発に入ることができませんから、その時点での要求を一度固めた上で文書化し、それをもとに全体のシステムを設計し、次に実装して、最後にテストまでもっていく。ウォーターフォールの工程で最初に動くものができるのは1年後になります。
今の僕らが相手にしている世の中で、新しい製品やサービスの開発計画が1年間固定されている状況なんて、到底あり得ません。最初に固めた365の要求を忠実に1年かけて形にできたとして、本当に欲しいものが手に入るでしょうか。できたものを見てびっくり、思っていたのと違う、ということがよく起きます。ソフトウェアは目に見えにくいので、実際に使ってみないと良し悪しが判断できないのです。こんな経験はみなさんよくあるのではないでしょうか。さらに、一年後にできたものがユーザーに新しい価値を与えたり、感動を与えることができるのか。おそらくほど遠いものができてしまい、プロジェクト遂行は「成功」でもビジネスは「失敗」、そんな結果になる可能性が高いでしょう。
アジャイル開発の考え方
アジャイルではどう考えるかというと、いったんは365個の要求は並べるかもしれないけれど、「これは変わっていきます」という宣言をします。そして、1番から365番まで優先順に並び替えてもらいます。そうすると、先頭のほうに優先度が高いものが集まってきますから、最初の1週間で優先度の高い7個をまず作り、実際に動かせるものでテストをし、次の優先順位トップ7をまた決めて翌週はそれを作り、テストを行う。
これを繰り返してある程度まとまった状態になった時に、ユーザーあるいはビジネスオーナーに見てもらいます。仕様書のような紙ではなく実際に動かしてもらうことで、「これは思っていたものと違う」とか、「これができるならこれもできるのでは」とか、「競合はこんな機能を入れてきたから、こちらもあの機能を新しく追加できないか」とか、さまざまな具体的要望が出てくるようになる。そこで残りの要求にもう一度優先順位をつけて並べ替え、優先順位の高い7個をまた1週間で作っていく。このやり方なら、その時点の一番フレッシュな優先順位で開発を進めることが可能になります。
365個の使うかどうかもわからない要求を固めてそれを1年後に出すのではなく、とにかく鮮度が高い要求を動くところまで持っていき、それを動かしたフィードバックをもらってさらに並べ替えることで、もっとも効果的な機能を毎週試しながら改善していく。これがニーズを捉え、ビジネスにインパクトを生み出すための重要なポイントです。つまり最初に立てた計画は、必ずしも正解ではない。正解は、市場（が決めた優先順位）が作り出すものであるというのが、アジャイル開発の考え方です。
「スクラム」の概要
それではその1週間の開発を、実際にどうやって進めればいいのか。そのためのコミュニケーション・ルールが「スクラム」です。手法ですからルールはシンプルですが、実際にやるのはもちろん簡単ではありません。
この図は、スクラムという開発手法の1週間の流れです。まず「スプリント」というのは、例えば、1週間という開発スケジュールの単位です。大型の案件になると、スプリントが1か月という単位になったりします。「プロダクトバックログ」は、製品全体の機能リストです。先ほどの365個の要求のことで、その中から選ばれた「スプリントバックログ」というのが1週間で作る7個の機能リストです。（ここで、365とか7という数は単なる例ですので、注意してください）。「インクリメント」は、1週間で仕上げた実際に動くようになった機能（動くソフトウェア）です。
「スプリントプランニング」は、7個の機能リストを作業単位に分割して、誰がどう進めるのかを決める一週間の計画づくりです。これに基づいて、1週間の作業が進められます。そしてできあがった「インクリメント」をユーザーやプロダクトオーナーに実際に動かしてもらい、フィードバックをもらうのが「スプリントレビュー」です。この1週間の流れであるスプリントを繰り返すことで、ニーズを捉えた俊敏なソフトウェアを開発するのが「スクラム」のプロセスの型です。
そしてこの「スプリント」を回すために重要なのが、「デイリースクラム」です。これは毎朝行われるミーティングのことで、僕は「朝会」と呼んでいます。ここで毎朝15分、チーム全員で今の状況や今日やるべきことを確認します。全員が顔を合わせて情報を共有する。これがチームの情報共有やモチベーション、心理的安全性にとってとても重要です。
そして1週間の節目で行う「ふりかえり」のミーティングを「スプリントレトロスペクティブ」、「レトロ」と言いますが、僕はそのまま「ふりかえり」と言っています。このような流れで透明性の高いコミュニケーションを実現し、ラグビーの「スクラム」のようにチーム全員が一体となって前に進むようにソフトウェア開発を行う。カタカナが多くて戸惑われるかもしれませんが、これが「スクラム」という開発技法のフレームワーク（枠組み）になります。
よく、「ウォーターフォールの中でもアジャイルの手法が使えますか？」という質問を受けます。ぼくは、1日や1週間という時間は人間が感じるちょうどよい長さなので、「毎日の朝会と週一のふりかえりをやるだけでも、チームの透明性が高まり、協力できるムードがでてきますよ」と答えるようにしています。もちろん、外界の変化に対応するのがビジネスに対するアジャイルの大きなアプローチなので、アジャイルの本当のパワーは得られないのですが、チーム内のコミュニケーションの課題解決としては優れた手法と言えます。
Hiranabe’s Point
★ 「スクラム」は優先順位の高い機能を1週間で作り、そのフィードバックに基づいて次の1週間で開発する機能の優先順位を決める。
★ 「スクラム」では計画を固定することはない。
★ 毎日の朝会や毎週のふりかえりのミーティングによって全員に状況が共有され、心理的安全性が高まり、変化に対応できるチーム力が生まれる。
平鍋 健児（ひらなべ けんじ）
株式会社 永和システムマネジメント 代表取締役社長、株式会社チェンジビジョン 代表取締役CTO、Scrum Inc.Japan 取締役。1989年東京大学工学部卒業後、UMLエディタastah*の開発などを経て、現在は、アジャイル開発の場、Agile Studio にて顧客と共創の環境づくりを実践する経営者。 初代アジャイルジャパン実行委員長、著書『アジャイル開発とスクラム 第2版』（野中郁次郎、及部敬雄と共著） 他に翻訳書多数。
『アジャイル開発とスクラム 第2版』
著：平鍋健児 野中郁次郎 及部敬雄
発行：翔泳社（2021年）
PDF形式のファイルをご覧になるには、Adobe Systems Incorporated （アドビシステムズ社）のAdobe Acrobat Readerが必要です。
