溜池随想録 #9 「『ウォーターフォールモデルは間違いだ！』」　（2010年2月）

システム開発遅延の原因

　現在、日本における受託ソフトウェア開発の大半は、ウォーターフォール・モデルで行われている。ウォーターフォール・モデルとは、ソフトウェア開発の工程を(1) 要求定義、(2) 設計、(3) コーディング、(4) テスト、(5) 保守のように分けて、それらを順に実施していくという手法である。
最初にきちんとした計画や設計書をつくり、それに従って実行するという方法であり、作業は最初から正しく行った方が、後で修復するより効率的であるという考え方（思想）に基づいている。この手法を採用した場合、前の工程の成果物に従って後の工程を進めることになり、原則として前の工程の戻ることはない。「計画を立ててそのとおり実行する」。実にシンプルで美しい。

　しかし、それは理想的ではあっても、現実に実行可能なのだろうか。うまく行くケースもある。しかし、そうでないケースも少なくない。

　ウォーターフォール・モデルでは、最初に要求定義を行う。この工程では、そのソフトウェアの利用者のニーズを把握し、必要な機能や最適なインタフェースを検討し、それをまとめて要求仕様を作成する。システムの設計は、顧客（発注者）が要求仕様書を承認してから始まる。ベンダーが要求仕様書を作成する場合であっても、顧客からニーズを聴取して仕様書を作成し、さらに顧客から承認を得ているのだから、普通に考えれば、要求仕様に問題があるはずがない。しかし、現実は机上の理論どおりには進まない。要求仕様に間違いがあるケースもあるし、時間の経過によって顧客の要求そのものが変化するケースもある。

　要求仕様に間違いがあった場合、納品直前の顧客による受入テスト段階まで発見されないことが多い。ソフトウェアが完成してから、顧客から「こんなソフトじゃ使えない」「こんなシステムを頼んだ覚えはない」などと言われてしまうのである。

　こうした場合、プロジェクトは最初の工程からやり直しになる。かくして要求仕様に問題があったソフトウェア開発プロジェクトは、スケジュールが大幅に遅延し、大赤字になる。

　では、なぜ要求仕様がトラブルの原因になるのだろう。
　顧客がシステムの仕様を確定できない段階でプロジェクトをスタートしてしまうケースや、一応仕様は確定しているのだが、途中で仕様変更や機能追加を強要するケースがかなりある。また、手順が固まっている業務のシステム化であっても、顧客が自分たちの望んでいることや知っていることを正しく伝えられないケースも少なくない。これらは顧客に重大な責任がある。さらに、厄介なのは、環境や技術の変化によって顧客のニーズが変化するケースが増えていることである。こうした場合、最初に綿密な計画をたてる手法は通用しない。

「ウォーターフォールモデルは間違いだ！」

　ウォーターフォール・モデルは、初期工程で混入した重大な問題の発見が遅れ、その結果、プロジェクトの大幅な遅延を招く危険性が高いという欠陥を持った開発モデルである。この事実は情報分野の専門家にとっては「常識」である。そして、何人かの専門家は、はっきりとウォーターフォール・モデルはソフトウェア開発に適していないと述べている。

　たとえば、ソフトウェア開発プロジェクト管理に関するバイブル『人月の神話　狼人間を撃つ銀の銃弾はない』を書いたフレデリック・P・ブルックス Jr.は、その原著発行20周年記念増訂版で、はっきりと「ウォータフォールモデルは間違いだ！」と述べている 。

　この分野で数多くの書籍を執筆しているエド・ヨードンも、『ピープル・ウェア』で有名なトム・デマルコも、前出のバリー・ベームもウォーターフォール・モデルに批判的である。

　日本では、つくば国際大学の大野侚郎教授が「ソフトウェア工学発展史　ウォーターフォール（落水）モデルの錯覚・誤用・悪用の30年間」というコラムの中で、フィードバックなしのウォーターフォール・モデルによるソフトウェア開発がはびこったために「ほとんどの大規模プロジェクトで、納期の遅延、コストの高騰、機能の欠落、プロジェクトの崩壊をもたらした」と指摘している。

　このように多くの専門家が、ウォーターフォール・モデルの問題を指摘しているにもかかわらず、日本では依然としてソフトウェア開発と言えばウォーターフォール・モデルが一般的である。ソフトウェア開発の入門書に最初に出てくる開発モデルはウォーターフォール・モデルであるし、専門学校でも大学でもウォーターフォール・モデルを教えている。

　これだけ問題が指摘され、実際に多くのトラブルを引き起こしているにもかかわらず、依然としてウォーターフォール・モデルが利用されている理由はどこにあるのだろうか。

　それは、ウォーターフォール・モデルがとてもシンプルで分かりやすいからだろう。しかし、最初に述べたように「計画を立ててそのとおり実行する」という手法は、一見正しいように見えるが間違いである。「間違った方法はいつも、より合理的に見える」のである 。

　次回は、反復型開発プロセスを取り上げる。