システム開発のウォーターフォールモデル

ウォーターフォールモデルとは、その名の通り水が上流から下流へ流れる様子を、そのままシステム開発のモデルに名づけたものである。システムの要件定義から設計、製造、テストまで、各開発フェーズを段階的に進めていく開発モデルを指す。　それに対して、各開発フェーズを行ったり来たりして、仕様の検討と実装（プログラミング）を繰り返しながら開発を進めるモデルを、スパイラルモデルと言う。 　システム開発の流れが次のようであることは、システム開発とは何か（後編）で述べた通りである。

1. 要件定義（要求分析）
2. 外部設計（基本設計）
3. 内部設計（機能設計）
4. 詳細設計（プログラム設計）
5. プログラミング（製造、実装、コーディング）
6. テスト

時系列で表すと、次のようになる。ウォーターフォール開発では、開発フェーズの完了をもって次のフェーズに着手していく。したがって、フェーズ終了判定が非常に重要なPJの変わり目と言える。

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

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

上記の例では、開発が製造まで進んでいる段階で、外部設計レベルの仕様変更が発生した場合を示している。製造を一旦ストップし、外部設計から詳細設計までの仕様検討と、各フェーズで作成した設計書の修正、プログラムの修正を行う。スケジュールが圧迫されるのは当然である。　 　また、要件定義レベルの仕様変更があった場合、システム開発全体に多大な影響を及ぼすこともある。開発側としては、事前に決定された要件（仕様）に基づいて開発を進めているため、根本的な仕様が変わってしまった場合は、開発するものを最初から見直す必要が生じるからである。テストフェーズに進んでいる状況で仕様変更を強いられた場合、作成したプログラムを全て破棄することもあり、スケジュールやコストの面でのダメージは当然ながら、プログラマにとっても精神的な苦痛を伴う。　そして、このような仕様変更や、後戻りは、実際の開発現場で頻発していることも事実である。上流工程ほど、きっちりとした客先交渉と要件の明確化が求められ、上流工程の業務ほどレベルの高い能力が必要とされる。 　次項では、システム開発の最初のフェーズである、要件定義について解説する。