ウォーターフォールモデルは、段取りをきちんと踏んだ開発モデルです。前工程に大きなミスがあると、後工程にはより大きな支障を来たしてしまうので、事前にできるだけバグを取り除くことが重要です。

ウォーターフォールモデルとは、その名の通り水が上流から下流へ流れる様子を、そのままシステム開発のモデルに名づけたものです。システムの要件定義から設計、製造、テストまで、各開発フェーズを段階的に進めていく開発モデルを指します。

ウォーターフォール開発では、開発フェーズの完了をもって次のフェーズに着手していきます。そのため、フェーズの移行判定がシステム開発プロジェクトにおいて非常に重要な機能を持ちます。

要件定義書には、顧客がシステム化したいビジネスモデルの全体像を記述します。システム的な仕様は抽象的で問題ありませんが、顧客のビジネスモデルは具体的なイメージにしておく必要があります。システム開発全体の根本的な仕様は、要件定義フェーズで決定され、それ以降の開発フェーズにおいても元を辿ればこの要件定義に基づいた開発を行うからです。そのため、要件定義において顧客企業が求める内容とは真逆の要件を定義してしまった場合、要件定義をゼロからやり直さなければなりません。そして、そのようなミスを許す顧客企業は存在しないでしょう。

各開発フェーズにおいて、一つ手前のフェーズで作成した成果物（アウトプット）が、次フェーズの入力物（インプット）になります。そのため、前のフェーズのアウトプットに不備があった場合に次フェーズを満足に遂行することはできません。必ず前のフェーズに戻って、仕様検討や設計をやり直すことになります。システム開発では、このような後戻りがシステム開発全体のスケジュールを圧迫する一番の要因となっています。

上記の例では、開発が製造まで進んでいる段階で、外部設計レベルの仕様変更が発生した場合を示しています。製造を一旦ストップし、外部設計から詳細設計までの仕様検討と、各フェーズで作成した設計書の修正、プログラムの修正を行います。スケジュールが圧迫されるのは当然ですね。

また、要件定義レベルの仕様変更があった場合にシステム開発全体に多大な影響を及ぼすこともあります。開発側としては、事前に決定された要件（仕様）に基づいて開発を進めているため、根本的な仕様が変わってしまった場合には、開発するものを最初から見直す必要が生じるからです。テストフェーズに進んでいる状況で仕様変更を強いられた場合に、作成したプログラムを全て破棄することもあります。スケジュールやコストの面でのダメージはもちろんのこと、プログラマにとっても精神的な苦痛を伴いますそして、このような仕様変更や後戻りは、実際の開発現場で頻発していることもまた事実なのです。上流工程ほど客先交渉による要件の明確化が厳しく求められ、上流工程の業務ほど高いスキルが求められます。

次項では、システム開発の最初のフェーズである要件定義について解説します。

＞＞　要件定義とは？