第2回：ウォーターフォールに対するアンチテーゼとしての反復型開発とアジャイル - (page 2)

　「ウォーターフォール」という用語は、その後1976年にT. E. Bell氏とT. A. Thayer氏によって初めて用いられ、さらにその後B. Boehm氏が「ウォーターフォールモデルの提唱者はRoyce氏である」とその著書で述べた、とされていますが、ほぼ半世紀が経過していることもあり、真相は藪の中です（注2）。ウォーターフォール開発方式は、ソフトウェア開発活動のQCDを可視化し、コントロールすることに主眼を置き、その点で一定の効果をもたらしましたが、その一方で、「『前工程に間違いがないこと』を前提もしくは期待」しており、「秩序正しく、予測が可能で、説明がつきやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想を与える」という大きな課題も残しました。

（注2）出所：「ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く」　小椋俊秀　2013　（https://cir.nii.ac.jp/crid/1050001201674393472などから入手可能）

ウォーターフォール開発が抱える課題とアンチテーゼとしてのアジャイル開発

　ウォーターフォール開発手法の特徴の1つは、「要求」「分析」「設計」など、上流工程の活動に多くの工数を投入して、しっかりとアーキテクチャー設計を行い、その結果を精緻にドキュメント化し、ステークホルダーによる評価を通じて完全性を高め、結果としてQCDを担保しようとする考え方で、これは俗に「Big Design Up Front（BDUF）」とも呼ばれています。

　確かに、以前に一度作ったことがあるものとほぼ同様のものをもう一度作るのであれば、その教訓（Lessons & Learned）を生かし、BDUFのアプローチを採るのは有効でしょう。ただし、多くのITシステムのように、1点モノのカスタム開発において、それは現実的なアプローチといえるでしょうか。例えば、世界的なスポーツイベントのチケット予約サイトなど、短期間に膨大なアクセス数が集中することが想定されるシステムにおいては、設計通りの性能が出るのかどうかを早期に確かめることが重要です。あるいは、技術の進化のスピードが早まっている現在、これまで実績がない新たなテクノロジーを採用するケースにおいては、それが想定通りのふるまいをするかを早期に確かめる必要があります。

　このようなケースにおいて、ITシステムが設計通りに動く、という確証を得るのに最適な方法は何でしょうか。BDUFで最初にしっかり設計を行い、大量のドキュメントを作成し、それを評価し、精緻化することで達成できるという考えは一見理にかなっているように思えますが、それにより「確証」を得られると考えるのは早計です。最も怖いのは、設計のフィージビリティーに関する有識者の意見の一致や断言により「意見の趨勢」のようなものが形作られて、「本当に動くの？」というまっとうな疑問を差し挟むことがはばかられてしまうようなケースです。

　筆者が過去に実施したインタビュー調査においても、多くの技術者が「不確定要素が多いプロジェクトのごく初期の段階で『○○を作ります』という約束をさせられてしまう」ことを否定的に捉えており、頻出回答の1つでした。確実に動くという「保証」がない設計を基に実装を推し進め、最終的にテストを実施した結果、不幸にして期待通りに動かないことが発覚した場合、プロジェクトのQCD、さらには技術者のモチベーションに与えるネガティブなインパクトは甚大なものとなるでしょう。

　ウォーターフォール開発手法では、このようなリスクを低減するために、「アジャイルの4つの価値宣言」（図4）の左側にある要素「プロセスやツール」「包括的なドキュメント」「契約と交渉」「計画の順守」を重要視しており、それらの重要性は今日も変わるものではありません。ただし、多くの技術者がその限界に気づいており、さらに言えば、発注者側はリスク低減の対価を負担しているのが実情です。

　リスク低減のためには、価値宣言の右側に書かれている「個人＆対話」「動くソフトウェア」「顧客との協調」「変化への対応」、つまり、プロジェクトのなるべく早い段階において、モックアップを用いた性能シミュレーション、あるいは技術、コンセプトの検証などを行い、実際に動くソフトウェアを通じて結果の白黒をはっきりさせることが肝要です。仮に期待通りの結果が得られなかったとしても、初期段階の失敗と、リリース予定時期を目前に控えた段階の失敗と、どちらが挽回可能かは明白でしょう。これがライフサイクル全体で見たときの良好なQCDにつながるのです。この点については、次回以降で詳しく見ていきます。

図4 アジャイルが重視する価値
（「アジャイルソフトウェア価値宣言」を基にKPMG作成）

　さて、ウォーターフォールの生みの親ということになっているRoyce氏は、実際にはウォーターフォール方式を推奨したわけではなく、むしろ発表段階からその構造的な欠陥に警鐘を鳴らしていたわけですが、そこから20年ほどの歳月が流れ1990年代に入ると、Royce氏の実の息子であるWalker Royce氏が反復型プロセスの原型を提唱します。それは父が警鐘を鳴らしたウォーターフォール方式の構造的な問題の解決を試みたものであり、のちの「ラショナル統一プロセス （RUP）」を経て、現在のアジャイル開発プロセスの根底となす概念を提供するものといえます。

　かつて筆者は、Walker Royce氏と一緒に仕事をし、その薫陶を受ける機会に恵まれましたが、最も印象に残っているのは、「一日の仕事を終えて家路につくとき、その日に自分がやったことを思いだしていい気分になれるかどうか、それが一番大切だ」という趣旨の言葉です。ウォーターフォールであれ何であれ、プロセスがこうやりなさい、と言っているからやる（Do things right：正しくやる）のではなく、ソフトウェア開発において、その実践経験から正しいと信じることをやる（Do the right thing：正しいことをやる）ことが大切だと諭し、反復型開発手法の本質の理解の途上にあった筆者に対して「早くこっちの世界へ来い」と言いたかったのだと今にして思います。

　次回は、ウォーターフォール手法に対するアンチテーゼとして生まれたアジャイル開発手法が、ソフトウェア開発活動をどのように変え、どのような成果をもたらしてきたのかを見ていきます。