ウォーターフォール・モデルウォーターフォール・モデルの概要

ウォーターフォール開発モデルは、製造業と建設業で生まれたものであり、高度に構造化された物理的環境では、開発プロセスのかなり早い段階で設計変更が非常に高価になることを意味していた。ソフトウェア開発に最初に採用されたとき、知識ベースのクリエイティブな作業に認められた代替案はなかった。^[5]

概要

プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、主として以下のような工程で行われる。

要求定義（要求仕様）
外部設計（概要設計）
内部設計（詳細設計）
開発（プログラミング）
テスト（ソフトウェア）
運用（システム）

上記のように作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を段階的に確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。また、工程を分けることによりスキル別に分業化が進み、結果として低スキル者でも開発に関わりやすくなっている。

ウォーターフォール・モデルの例には、IBMによるADSG（Application Development Standardization Guide、アプリケーション開発標準化ガイド）などがある。

なお「ウォーターフォール・モデルは古く、スパイラルモデルは新しい」と単純化して語られる場合もあるが、大規模開発ではスパイラルモデルだけでは収束せず破綻するケースが大半のため、現在でもウォーターフォール・モデルとスパイラルモデル等は、組み合わされて使用されている。

ウォーターフォール・モデルが採用される裏には、次のようなスパイラルモデルの問題が解決できないという理由もある。

要件を変更したときの見積もりや契約の方法が確立されていない
各工程の頻繁なリリースによるバージョン管理が難しい
テストの自動化に関するノウハウが蓄積されていない

歴史

1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。^[6]

「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味し、W. W.ロイスによって1970年に発表された論文「Managing the Development of Large Software Systems」の内容が元になったとされる。この論文において、「大規模ソフトウェア開発には、製品製造過程のようにいくつかの工程に分けたトップダウンアプローチが必要」と述べている。しかし論文には「ウォーターフォール・モデル」という記述は無く、また、前工程への後戻り（見直し）も提唱されており、元の論文の内容とは異なっている。

初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはロイスだと述べている。

問題点

ウォーターフォール・モデルに対する批判には、次のようなものがある。

「ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない」^[7]
「ウォーターフォール・アプローチは，危険かつ問題をはらんだ，企業における風土病」^[8]
「秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた」^[9]

ウォーターフォール・モデルの問題点は、『前工程に間違いがない』ことを前提または期待していることである。

古くから（現代においても）、要求を事前に詳細に定義することは困難であると言われている。要求をユーザーに徹底的に確認したにもかかわらず、下流工程になって見え始めたシステムを見たユーザーから修正要望が出ることがある。この要望に応えるには、前工程に戻って進捗度を戻さざるをえなくなる。（要望に応えなければ戻さずに済む。）

ウォーターフォール開発プロジェクトが成功するためには、過去に同じようなプロジェクトで一度失敗している必要があると言われている。これは、システム開発の名著『人月の神話』においても批判されていることである。

前工程への後戻りはスケジュールの遅延の原因であると評価されるため、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローすることが求められる。

また大規模開発では、全システムを同じスケジュール（1時点では全システムの設計、1時点では全システムのプログラミング、など）とすると、管理可能な範囲を超える、似たような問題が各所で同時発生する、リソースの平準化がなされないなどの問題があるため、業務上またはシステム的に分割容易な適切なサブシステム単位に分割し、それぞれで局面化する事が一般的である。この場合は共通する仕様の問題は、先行するサブシステムで発見されるため、後続のサブシステムではより早い工程で変更できる。

要求の修正要望が出ないようにするために、「プロトタイプ」と呼ばれる試作プログラムや画面デモ用プログラムを作成することがある。この試作プログラムの開発を要求定義工程とみなせば前工程が完了しないと次工程に進まない原則とつじづまが合うが、開発工程とみなせば原則に違反したとしてプロトタイプを作成しないよう指示されてしまうことが考えられる。テスト駆動開発は着実に進捗を進めることを可能にする開発方法であると言われてるが、これも前工程が完了しないと次工程に進まない原則に違反する。また、テストの自動化に関するノウハウが必要になる。

脚注