ひとことで言うと
ウォーターフォールは、「要件定義→設計→開発→テスト→リリース」という工程を順番に完了させ、原則として前の工程に戻らない開発の進め方です。
建物を建てるように、設計図が固まってから施工を始め、完成してから検査する流れです。 全体の見通しが立てやすく、工程ごとに成果物を確認しやすい反面、途中で仕様が変わると修正コストが大きくなります。
たとえ話でもう少し詳しく
ウォーターフォールは、建物の建設工事に近いです。
- まず設計図を確定する（要件定義・設計）
- 設計図をもとに施工する（開発）
- 完成後に検査・確認する（テスト）
- 問題なければ引き渡す（リリース）
一度コンクリートを流し込んで壁を作ってしまったあとに「やっぱりここに窓を増やしたい」となると、修正の手間と費用が大きくなります。 ウォーターフォールでも同様で、開発が進んだあとに「やっぱり仕様を変えたい」となると、前の工程に戻って大幅な修正が必要になります。
よく出る場面・使いどころ
- 要件が最初から明確に固まっていて、途中で変わりにくいプロジェクト
- 官公庁や大企業など、承認・文書化のプロセスが重視される開発
- 安全性が重要なシステム（航空・医療など）で、各工程の成果物を厳密に確認する必要があるとき
- 複数のベンダーが分担して開発する場合など、工程間の引き渡しを明確にする必要があるとき
似た言葉との違い
- アジャイル
- 小さく作って試し、フィードバックをもとに繰り返し改善していく進め方
- ウォーターフォールは最初に全体を設計してから作る、アジャイルは作りながら変えていく
- CI/CD
- コードのテストとデプロイを自動化する仕組み
- ウォーターフォールでも CI/CD を取り入れてテスト・デプロイを効率化することはある
- デプロイ
- 完成したコードを本番環境へ反映する作業
- ウォーターフォールでは全工程が終わった最後にまとめてデプロイすることが多い
実務で気にするポイント
- 要件定義の精度がプロジェクト全体の品質を左右する
- 途中の仕様変更には変更管理のプロセスが必要になる
- 実際に動くものを見られるのがリリース直前になるため、認識のズレが後半に発覚しやすい
- 計画通りに進まない場合でも、工程の完了基準が明確なため問題の見つけやすさはある
注意: ウォーターフォールは「古い・悪い方法」ではありません。要件が安定している大規模プロジェクトや、厳密な工程管理が求められる分野では今も広く使われています。アジャイルと優劣を比べるのではなく、プロジェクトの性質に合わせて選ぶことが大切です。