プロジェクトの進め方には、さまざまな方法があります。
その中でも代表的なものがウォーターフォールです。
ウォーターフォールは、プロジェクトをいくつかの工程に分け、基本的に上流工程から下流工程へ順番に進めていくプロジェクトの進め方です。
「要件を決める → 設計する → 開発する → テストする」というように、工程を順番に進めることから、滝(Waterfall)のように水が上から下へ流れるイメージで「ウォーターフォール」と呼ばれています。
特に、要件や成果物を事前に明確に定義しやすいシステム開発や、変更を厳格に管理する必要があるプロジェクトなどで利用されます。
一言でいうと
ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。
代表的な流れは、
要件定義 → 設計 → 開発 → テスト → リリース
です。
後工程に進んでから前工程の内容を変更すると、影響範囲が大きくなるため、各工程で成果物を確認し、次の工程へ進むことが重要になります。
ウォーターフォールとは
ウォーターフォールは、プロジェクトを段階的な工程に分け、それぞれの工程を順番に完了させながら進めるアプローチです。
例えばシステム開発であれば、
- 要件定義
- 基本設計
- 詳細設計
- 実装
- テスト
- リリース
という流れで進めます。
もちろん、実際のプロジェクトでは工程の名称や分け方は異なります。
重要なのは、プロジェクトを段階的な工程に分け、計画に基づいて順番に進めるという考え方です。
なぜ「ウォーターフォール」と呼ばれるのか
ウォーターフォール(Waterfall)は、日本語にすると「滝」です。
プロジェクトの工程を上から下へ流れる水に見立てていることから、この名前が付けられています。
例えば、
要件定義
↓
設計
↓
開発
↓
テスト
↓
リリース
というように、工程が順番に進んでいくイメージです。
ウォーターフォールの代表的な工程
ウォーターフォールでよく使われる工程には、次のようなものがあります。
| 工程 | 主な内容 |
|---|---|
| 要件定義 | 何を作るのか、どのような機能が必要なのかを明確にする |
| 設計 | 要件を実現するためのシステムや製品の構造を設計する |
| 開発・製造 | 設計に基づいてシステムや製品を作る |
| テスト | 作成した成果物が要求どおりに動作するか確認する |
| リリース | 完成した成果物を利用可能な状態にする |
プロジェクトによっては、要件定義の前に企画工程があったり、テストを複数の工程に分けたりすることもあります。
したがって、「ウォーターフォール=必ずこの工程で進める」という決まりがあるわけではありません。
ウォーターフォールの特徴
計画を立ててから進める
ウォーターフォールでは、プロジェクトの開始時点で、できるだけ必要な作業や成果物、スケジュールなどを明確にします。
そのため、プロジェクト全体の計画を立てやすいという特徴があります。
工程ごとの成果物を明確にする
各工程では、次の工程につなげるための成果物を作成します。
例えば、要件定義では要件定義書、設計では設計書などを作成します。
こうした成果物を確認しながら、次の工程へ進みます。
変更を管理しやすい
ウォーターフォールでは、計画や要求事項を明確にしたうえで進めるため、変更が発生した場合には、変更管理の手続きを通して影響を確認することが一般的です。
そのため、変更を厳格に管理する必要があるプロジェクトに適しています。
後工程での変更は影響が大きくなりやすい
一方で、プロジェクトが進んだ後に要件を変更すると、設計や開発、テストなど多くの工程に影響する可能性があります。
そのため、ウォーターフォールでは上流工程で要求事項をできるだけ明確にすることが重要です。
ウォーターフォールのメリット
プロジェクト全体を計画しやすい
工程を順番に進めるため、プロジェクト全体のスケジュールや必要な作業を計画しやすくなります。
特に、いつまでに何を完成させるのかを明確にする必要があるプロジェクトでは有効です。
進捗を管理しやすい
工程や成果物が明確になっているため、計画と実績を比較しやすくなります。
例えば、
- 要件定義は完了したか
- 設計は予定どおり進んでいるか
- テストはいつ開始できるか
などを確認できます。
成果物を明確にできる
各工程で作成する成果物を定義しやすいため、レビューや承認などの管理を行いやすくなります。
役割分担がしやすい
工程が明確になっているため、どの組織や担当者がどの工程を担当するのかを整理しやすくなります。
規制や承認が重要なプロジェクトに適している
成果物や承認プロセスを明確にしやすいため、記録や証跡が重視されるプロジェクトでも活用しやすい方法です。
ウォーターフォールのデメリット
変更への対応に時間がかかる
上流工程で決めた内容を後から変更すると、すでに完了した設計や開発、テストなどに影響する可能性があります。
そのため、変更が多いプロジェクトでは、対応に時間やコストがかかる場合があります。
完成した成果物を見るまで時間がかかる
基本的には工程を順番に進めるため、ユーザーが実際に利用できる状態になるまで時間がかかることがあります。
その結果、利用者からのフィードバックを得られるのが遅くなる場合があります。
初期の要求が不明確だと問題が後工程に影響する
上流工程で要求を十分に整理できていないと、その問題が設計や開発、テストなど後工程で発見されることがあります。
後工程で発見されるほど、修正の影響が大きくなる可能性があります。
利用者からのフィードバックが遅くなりやすい
実際に動く成果物が完成するまで時間がかかるため、利用者が「思っていたものと違う」と気付くタイミングが遅くなる可能性があります。
ウォーターフォールに向いているプロジェクト
ウォーターフォールは、すべてのプロジェクトに適しているわけではありません。
特に、次のようなプロジェクトでは適用しやすいと考えられます。
- 要求事項が比較的明確である
- 要求事項の変更が少ない
- 成果物や仕様を事前に定義しやすい
- 工程ごとの承認が必要である
- 規制や契約上の制約が多い
- プロジェクト全体の計画を重視する必要がある
例えば、要件が明確で、設計や承認を厳格に管理する必要がある大規模なシステム開発などでは、ウォーターフォールが適している場合があります。
ウォーターフォールに向いていないプロジェクト
一方、次のようなプロジェクトでは、ウォーターフォールだけでは対応しにくい場合があります。
- 要求事項が頻繁に変わる
- ユーザーのニーズがまだ明確ではない
- 市場環境が大きく変化する
- 早い段階でユーザーからフィードバックを得たい
- 試行錯誤しながら成果物を改善したい
このような場合には、アジャイルなどの反復的・適応的なアプローチが適している可能性があります。
ウォーターフォールとアジャイルの違い
ウォーターフォールと比較されることが多いのがアジャイルです。
| 項目 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程を順番に進める | 短い期間で反復する |
| 要求変更 | 変更の影響が大きくなりやすい | 変更を取り込みやすい |
| 計画 | 全体計画を重視 | 短期的な計画を繰り返す |
| 成果物 | 工程の完了に合わせて作成 | 短いサイクルで価値を提供 |
| フィードバック | 後工程になりやすい | 早い段階から得やすい |
| 適した環境 | 要求が比較的明確 | 要求変更が多い |
ただし、ウォーターフォールとアジャイルのどちらが優れているという話ではありません。
プロジェクトの特性に応じて、適切なアプローチを選択することが重要です。
ウォーターフォールとアジャイルは組み合わせられる?
実際のプロジェクトでは、ウォーターフォールかアジャイルかを完全に二択にする必要はありません。
例えば、全体としては大きな工程やマイルストーンをウォーターフォール型に計画し、個々の開発部分ではアジャイルの反復的な進め方を採用することもできます。
このように、プロジェクトの特性に応じて複数のアプローチを組み合わせることをハイブリッドアプローチと呼びます。
重要なのは、「ウォーターフォールだからこうする」と形式的に決めることではなく、プロジェクトの目的、要求の安定性、リスク、組織の状況などを考慮して、適切な進め方を選択することです。
ウォーターフォールで重要な変更管理
ウォーターフォールでは、プロジェクトの途中で要求や仕様が変更されると、複数の工程に影響する可能性があります。
そのため、変更管理が重要になります。
例えば変更要求が発生した場合には、
- 何を変更するのか
- なぜ変更するのか
- スケジュールへの影響はあるか
- コストへの影響はあるか
- 品質への影響はあるか
- 他の成果物への影響はあるか
などを確認したうえで、変更を承認するかどうかを判断します。
つまり、ウォーターフォールでは「変更しないこと」よりも「変更の影響を評価して適切に管理すること」が重要です。
プロジェクトマネジメントでのウォーターフォール
ウォーターフォール型のプロジェクトでは、プロジェクトマネージャは工程ごとの進捗や成果物、品質、課題、リスクなどを管理します。
例えば、
- スケジュールを作成する
- 工程ごとの成果物を定義する
- レビューや承認を管理する
- 進捗を確認する
- 変更要求を管理する
- リスクを管理する
- 課題を管理する
- ステークホルダーとコミュニケーションする
といった活動が重要になります。
特に、後工程への影響を考慮しながら上流工程で問題を早期に発見することが重要です。
ウォーターフォールで重要なレビュー
ウォーターフォールでは、工程ごとに成果物を作成するため、レビューが重要な役割を持ちます。
例えば、要件定義書をレビューし、要求事項の漏れや矛盾を確認します。
その後、設計書をレビューし、要件を正しく設計に反映できているか確認します。
このように、後工程に問題を持ち越さないために、各工程で成果物の品質を確認することが重要です。
ウォーターフォールで重要なテスト
ウォーターフォールでは、開発した成果物を後工程でまとめてテストすることが一般的です。
そのため、テスト工程で重大な問題が見つかると、修正によってスケジュールに大きな影響が出る可能性があります。
このリスクを抑えるためには、テスト工程だけに品質確認を任せるのではなく、要件定義や設計などの上流工程から品質を作り込むことが重要です。
プロジェクトマネージャ試験ではここが重要
ウォーターフォールについては、単に「順番に工程を進める方法」と覚えるだけでは不十分です。
重要なのは、
- 工程を順番に進める
- 上流工程で要求事項を明確にする
- 工程ごとに成果物を作成する
- レビューや承認を行う
- 変更の影響を管理する
- 後工程への問題の持ち越しを防ぐ
という特徴を理解することです。
また、ウォーターフォールとアジャイルを単純に「どちらが優れているか」で考えないことも重要です。
プロジェクトの特性に応じて、適切な開発・プロジェクトアプローチを選択するという視点が重要になります。
PM道場のワンポイント
ウォーターフォールのポイントは、「後から戻ることが難しいから、上流工程を丁寧に行う」ということです。
ウォーターフォールでは、要件定義の後に設計、設計の後に開発、開発の後にテストという流れで進みます。
そのため、上流工程の問題が後工程に影響しやすいという特徴があります。
例えば、要件定義で漏れがあった場合、
要件漏れ
↓
設計への反映漏れ
↓
実装漏れ
↓
テストで不具合として発見
というように、問題が後工程へ流れていく可能性があります。
だからこそ、ウォーターフォールでは、「後でテストすればよい」ではなく、「前の工程でできるだけ問題を見つける」ことが重要です。
レビューやインスペクションなどを活用し、上流工程で成果物の品質を高めることが、プロジェクト全体の品質やスケジュールを守ることにつながります。
そして、ウォーターフォールを選択すること自体が目的ではありません。
「このプロジェクトでは、なぜウォーターフォールが適しているのか?」
を考えることが、プロジェクトマネージャにとって重要です。
関連用語
- アジャイル
- スクラム
- スプリント
- プロジェクトマネジメント
- プロセス群
- パフォーマンスドメイン
- 要件定義
- 変更管理
- レビュー
- インスペクション
- テスト
- 品質管理
- リスク
- 課題
- ステークホルダーエンゲージメント
まとめ
ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。
代表的な流れは、
要件定義 → 設計 → 開発 → テスト → リリース
です。
ウォーターフォールには、
- プロジェクト全体を計画しやすい
- 進捗を管理しやすい
- 成果物を明確にできる
- 工程ごとのレビューや承認を行いやすい
というメリットがあります。
一方で、
- 後からの変更による影響が大きくなりやすい
- 利用者からのフィードバックが遅くなりやすい
- 上流工程の問題が後工程に影響しやすい
という特徴もあります。
そのため、ウォーターフォールを採用する際には、要求事項の明確化、成果物のレビュー、変更管理、上流工程での品質確保が重要になります。
また、要求事項が頻繁に変化するプロジェクトでは、アジャイルなどの別のアプローチが適している場合があります。
重要なのは、ウォーターフォールかアジャイルかを形式的に選ぶことではありません。
プロジェクトの特性に合わせて、最も適した進め方を選択すること。
これがプロジェクトマネージャに求められる重要な判断の一つです。
関連記事
- アジャイルとは?
- スクラムとは?
- スプリントとは?
- レビューとは?
- インスペクションとは?
- テストとは?
- 品質管理とは?
- 変更管理とは?
- リスクとは?
- 課題とは?
- ステークホルダーエンゲージメントとは?
- パフォーマンスドメインとは?
よくある質問(FAQ)
Q. ウォーターフォールとは何ですか?
A. ウォーターフォールとは、プロジェクトを複数の工程に分け、基本的に上流工程から下流工程へ順番に進めるプロジェクトの進め方です。
Q. ウォーターフォールの代表的な工程は何ですか?
A. 一般的には、要件定義、設計、開発、テスト、リリースなどの工程があります。ただし、工程の名称や分け方はプロジェクトによって異なります。
Q. ウォーターフォールは変更に弱いのですか?
A. 後工程に進んでから上流工程の内容を変更すると、設計、開発、テストなどに影響する可能性があります。そのため、変更の影響が大きくなりやすいという特徴があります。ただし、変更を禁止するのではなく、変更管理によって影響を評価し、適切に管理することが重要です。
Q. ウォーターフォールとアジャイルの違いは何ですか?
A. ウォーターフォールは工程を順番に進めることを基本とするのに対し、アジャイルは短い期間で計画・開発・フィードバックを繰り返しながら成果物を改善していくアプローチです。
Q. ウォーターフォールとアジャイルではどちらが優れていますか?
A. 一概にどちらが優れているとはいえません。要求事項が比較的明確で変更が少ないプロジェクトではウォーターフォールが適する場合があり、要求事項が変化しやすいプロジェクトではアジャイルが適する場合があります。プロジェクトの特性に応じて選択することが重要です。
Q. ウォーターフォールではなぜ上流工程が重要なのですか?
A. 上流工程で発生した問題が、設計、開発、テストなどの後工程に影響する可能性があるためです。要件定義や設計などの段階でレビューを行い、問題を早期に発見することが重要です。
私は令和5年度 IPAプロジェクトマネージャ試験に合格しました。
実際に合格した経験をもとに、勉強方法やおすすめ参考書、最難関といわれる午後Ⅱ論文の対策方法を詳しく解説しています。
「これから勉強を始めたい」「効率よく合格したい」という方は、ぜひこちらの記事もご覧ください。

