ウォーターフォール開発
ウォーターフォール開発とは
ウォーターフォール開発は、ソフトウェア開発の工程を上から下へ順番に進める開発モデルです。滝(waterfall)の水が上から下へ流れるように、前の工程が完了してから次の工程へ進みます。
要件定義 → 設計 → 実装 → テスト → リリース → 運用
最初に [[要件定義]] で「何を作るか」をすべて決め、計画どおりに進めることを重視します。日本の大規模な業務システム開発では今も広く使われています。
各工程でやること
| 工程 | 内容 |
|---|---|
| 要件定義 | 作るものと作らないものを決め、文書化する |
| 設計 | 画面・データベース・処理の構造を決める |
| 実装 | 設計書に従ってプログラムを書く |
| テスト | 設計・要件どおりに動くかを検証する |
| リリース・運用 | 本番環境へ展開し、保守する |
各工程の終わりに成果物(要件定義書・設計書など)をレビューして次へ進むため、ドキュメントが充実しやすいのが特徴です。
アジャイルとの比較
| ウォーターフォール | [[アジャイル開発]] | |
|---|---|---|
| 計画 | 最初に全体を計画 | 短いサイクルで見直す |
| 変更への対応 | 苦手(手戻りが大きい) | 得意 |
| 向いている案件 | 要件が明確・変更が少ない | 要件が変わりやすい |
| 成果の確認 | 最後にまとめて | サイクルごとに動くものを確認 |
ウォーターフォールの弱点は、後工程での変更コストが大きいことです。テスト段階で要件の誤りが見つかると、設計からやり直しになります。逆に、要件が固まっている案件では見積もりや進捗管理がしやすいという強みがあります。
初学者向けポイント
- 「ウォーターフォール=古い、アジャイル=正しい」という単純な話ではありません。案件の性質で使い分けるのが実務の感覚です
- 官公庁や金融など、契約時に成果物と金額を確定させたい案件ではウォーターフォールが選ばれやすいです
- 全体の工数を最初に見積もる必要があるため、[[見積もりとベロシティ]] とは違う「積み上げ型」の見積もりが使われます
- 現場では「基本設計」「詳細設計」など工程がさらに細分化されることもあります
関連技術とのつながり
- [[要件定義]] — ウォーターフォールの最初の工程であり、成否を左右する
- [[アジャイル開発]] — 対比される反復型の開発アプローチ
- [[スクラム]] — アジャイルの代表的な実践フレームワーク
- [[見積もりとベロシティ]] — 開発モデルによって見積もりの考え方が変わる
Q: ウォーターフォール開発の特徴はどれ?
- [x] 前の工程が完了してから次の工程へ順番に進む
- [ ] 1〜4週間のサイクルで開発を繰り返す
- [ ] 計画を立てずにすぐ実装を始める
解説: 滝の水のように、要件定義→設計→実装→テストと工程を上から下へ順に進めるのがウォーターフォールです。
Q: ウォーターフォール開発の弱点はどれ?
- [ ] ドキュメントが作られにくい
- [x] 後工程での変更コストが大きい
- [ ] 進捗管理がしにくい
解説: テスト段階で要件の誤りが見つかると設計からやり直しになるなど、後工程での変更に弱いモデルです。
Q: ウォーターフォールが向いているのはどんな案件?
- [ ] 要件が頻繁に変わる新規サービス開発
- [ ] 何を作るか決まっていない実験的な開発
- [x] 要件が明確で変更が少ない案件
解説: 要件が固まっている案件では、最初に全体を計画するウォーターフォールの強み(見積もり・進捗管理のしやすさ)が活きます。