3秒でわかる
要件定義から順に工程を進め、前の工程へ戻らない前提で組む開発の進め方。成果物と分担が明確になるため、仕様が固まった大規模案件で採られます。
もう少し詳しく
どういうものか
ウォーターフォールは、要件定義、基本設計、詳細設計、実装、テスト、運用という工程を順番に進める開発手法である。各工程の終わりに成果物をレビューして承認し、次へ移る。上流から下流へ水が落ちるように後戻りしない形を想定するのが名前の由来になっている。
テスト工程は設計工程と対応付けられる。詳細設計に単体テスト、基本設計に結合テスト、要件定義にシステムテストと受入テストが対応し、この対応関係を図にしたものを V 字モデルと呼ぶ。
なぜ必要か
作るものが最初から確定していて、関わる人数が多い案件では、工程を区切る方が管理しやすい。何がいつ完成するかを事前に見積もれるので、要員計画も予算も引ける。
契約の形とも噛み合う。請負契約は「何をいくらで作るか」を先に決める必要があり、要件を文書として固めるウォーターフォールの前提と一致する。公共システムや金融の基幹システムで今も採られているのはこの理由が大きい。
具体例
工程と主な成果物の対応は下記のとおりである。
要件定義 ─────────────────────→ 受入テスト
要件定義書
└ 基本設計 ─────────→ システムテスト
外部設計書・画面設計
└ 詳細設計 ──→ 結合テスト・単体テスト
内部設計書
└ 実装
ソースコード左側を下る流れが設計で、右側を上る流れがテストになる。左右で同じ高さにある工程が対応する。
つまずきやすいところ
最大の弱点は、動くものが出てくるのが遅い点にある。テスト工程まで進んで初めて利用者が画面に触るため、要件の読み違いが見つかるのが最も修正コストの高い段階になる。仕様変更が入ると、設計書一式の改訂から作り直しになる。
現実には完全な一方通行では回らないので、前工程へ戻る手順と費用の扱いを契約時に決めておく。工程の一部を反復するスパイラルモデルや、先に試作を作るプロトタイピングを組み合わせる形も採られる。
似た用語との違い
| 手法 | 進め方 | 向く場面 |
|---|---|---|
| ウォーターフォール | 工程を順に 1 度だけ通す | 要件が固い大規模案件 |
| アジャイル | 短い反復で動くものを出し続ける | 要件が動く新規サービス |
| スパイラル | 反復しながらリスクの大きい部分から作る | 技術的な不確実性が高い案件 |
| プロトタイピング | 先に試作を作って仕様を確かめる | 画面の使い勝手が要点の案件 |
基本情報技術者試験や IT パスポートでは、V 字モデルの対応関係とアジャイルとの比較が定番の出題になる。