ウォーターフォールは、「要件定義 → 設計 → 開発 → テスト → リリース」の工程を順番に完了させ、原則として前の工程には戻らない開発の進め方です。滝の水が上から下へ流れるように、一段ずつ進みます。
建物の建設工事に近い流れです。まず設計図を確定し、その設計図どおりに施工し、完成したら検査して、問題がなければ引き渡す。全体の見通しが立てやすく、工程ごとに成果物を確かめやすいのが強みです。ウォーターフォールは「古い、悪い方法」ではなく、条件が合えば今も広く使われています。
向いている仕事
- 要件が最初からはっきり固まっていて、途中で変わりにくいプロジェクト
- 官公庁や大企業のように、承認や文書化の手続きが重視される開発
- 航空や医療など、安全性が重要で、工程ごとの成果物を厳密に確かめる必要があるシステム
- 複数の会社が分担して開発するなど、工程の引き渡しを明確にしておく必要があるとき
こうした仕事では、工程ごとに完了の基準がはっきりしていることが、そのまま強みになります。計画どおりに進まないときも、どの工程で遅れているのかを見つけやすいからです。
途中で「やっぱり変えたい」となったら
一度コンクリートを流し込んで壁を作ってから「ここに窓を増やしたい」となれば、壊して作り直す手間と費用がかかります。ウォーターフォールでも、開発が進んだあとに仕様を変えるには、前の工程まで戻って大きく直す必要があります。
しかも、実際に動くものを見られるのは、たいていテストやリリースの直前です。発注した側と作った側の認識のズレが、プロジェクトの後半になってから見つかりやすいのです。
だから、2つのことを始める前に決めておきます。一つは要件定義の精度で、ここがプロジェクト全体の品質を左右します。もう一つは、それでも変更が出たときの扱いです。誰が承認し、費用と期間をどう見直すのか。変更管理の手続きを合意してから進めれば、後半のズレに慌てずに済みます。
短い区切りで作っては直していくアジャイルとどちらを選ぶかは、優劣ではなくプロジェクトの性質で決まります。ウォーターフォールとアジャイルの違いも参考にしてください。