システム開発でよく使われる開発方法論として、ウォーターフォール開発モデルがあります。開発プロセスをいくつかの工程に分割し、工程毎に完了させていく方法であり、大規模開発でよく利用されます。

ウォーターフォール開発モデルの概要

各工程の概要は下記です。

要件定義工程：システムに求める要求・機能を、経営上・ビジネス上のゴールから導出したり、現場のオペレーション上の課題から導出します。

基本設計工程：要件定義内容をInputとして、必要な要件を機能単位に分割し、各機能が何を実現すべきか定めます。具体的には、システム構成、システムの画面構成、帳票定義、機能の処理概要、データベースのテーブル定義・ER図（エンティティー・リレーショナル図）等を作成します。

詳細設計工程：基本設計内容をInputとして、プログラミングができるレベルに詳細化・具体化する工程です。多様なやり方があります。

開発工程：詳細設計内容にもとづき、開発環境を構築し、実際に動く機能をプログラミング等で作ります。

ここまでを下記図のように、「品質の埋め込みプロセス」と呼ぶこともあります。

その後、は「品質の確認・検証プロセス」となり、下記を実施します。

単体テスト：詳細設計内容の検証
結合テスト：基本設計内容の検証
システムテスト・ユーザーテスト：要件定義内容の検証

ウォーターフォール開発モデルのメリットは、下記です。

・プロジェクト全体の計画が立案しやすい
・計画が立案しやすいため、開発に必要なリソース（予算・人員・設備など）が調達しやすい
・進捗管理が容易で、計画に対して、実績の把握・予実対比がやりやすい

しかし、課題があります。

ウォーターフォール開発モデルの課題

変更時の対応コスト大・変更に時間を要する

下記図の通り、変更があった工程だけでなく、完了済の前工程の成果物も、さかのぼって変更対応・修正対応が必要となり、変更時の対応コストが大きいです。合わせて、変更対応に要する時間も長くなります。

では、変更が発生しないように、前の工程でプロジェクト関係者全員で内容の確認・合意をして、着実に後戻りしないように工程毎で承認しながら進めればいいのでは？という疑問が出てくるかもしれません。しかし、下記理由で、極めて困難です。

1.要件定義、基本設計段階で全関係者で内容合意したとしても、動くものを実際に目で見ると、事前のイメージと異なっていることが多く、変更要求が発生する

2.そもそも、要件定義・基本設計段階で、すべての業務要求を洗い出したり、漏れなく要件を設計することは現実的に難しく、どうしても漏れ・認識齟齬は発生する。

3.企業を取り巻く外部環境は日々変化している。大規模開発プロジェクトだと、開発期間が1年を超えることはよくあり、基本設計完了時点の要件・設計内容が、外部環境の変化によって変更が必要となることがある。

上記ウォーターフォール開発モデルの課題に対応するために、プロトタイピングという、要件定義・基本設計部分に、プロトタイプとして目に見えるモックアップ（試作品）を作る工夫をする、アジャイル開発プロセスを採用する、等の対応が考えられます。次回以降の記事で、記載いたします。