冒頭文
**ウォーターフォールモデル（Waterfall Model）**は、システム開発を複数の工程に分け、基本的に上流工程から下流工程へ順番に進める開発モデルです。
イメージは名前のとおり「滝」です。
要件定義
↓
設計
↓
実装
↓
テスト
↓
導入
↓
運用・保守一つの工程で決めた内容を次の工程へ引き渡していくため、計画や成果物を管理しやすい一方、後になって要件の誤りが判明すると、大きな手戻りが発生しやすい特徴があります。
基本情報技術者試験の現行シラバスVer.9.2でも、「大分類4：開発技術」「中分類13：ソフトウェア開発管理技術」の「ソフトウェア開発モデル」において、ウォーターフォールモデルが用語例として明記されています。
結論：ウォーターフォールモデルは「工程を順番に確定しながら進める開発モデル」
試験対策として最初に覚える内容は、次の4点です。
| 覚える項目 | ウォーターフォールモデル |
|---|---|
| 開発の進め方 | 工程を順番に進める |
| 要件 | 開発初期にできるだけ明確にする |
| 管理 | 計画・工程・成果物を管理しやすい |
| 弱点 | 後から変更すると手戻りが大きくなりやすい |
IPAもウォーターフォール開発について、開発対象全体の要件や仕様を確定してから開発を進める考え方として説明しています。一方、アジャイルは開発中の機能追加・変更や優先順位の変更などに柔軟に対応する手法として区別されています。
試験では、
「最初に要件を固め、工程を順番に進める」→ ウォーターフォール
と判断できるようにしておくと理解しやすくなります。
この記事で分かること
この記事では、基本情報技術者試験対策として次の内容を理解できます。
- ウォーターフォールモデルとは何か
- 開発工程の流れ
- 上流工程と下流工程の違い
- ウォーターフォールモデルのメリット
- ウォーターフォールモデルのデメリット
- 「前工程には戻れない」という説明の注意点
- 手戻りが大きくなる理由
- アジャイルとの違い
- プロトタイピングモデルとの違い
- V字モデルとの関係
- 試験問題での見分け方
対象読者・前提環境
この記事は、次のような人を対象としています。
- 基本情報技術者試験を勉強している人
- ITパスポートから基本情報技術者試験へ進みたい人
- システム開発経験がまだ少ない人
- ウォーターフォールとアジャイルの違いが曖昧な人
- 要件定義・基本設計・詳細設計などの工程を整理したい人
2026年8月19日時点では、IPAが掲載している基本情報技術者試験の現行シラバスはVer.9.2です。2027年度開始予定の新制度についてはシラバス案の公開が進められていますが、基本情報技術者試験についてはIPAの2026年7月31日更新ページで「準備中」とされています。
ウォーターフォールモデルとは
ウォーターフォールモデルとは、システム開発を複数の工程へ分割し、上流から下流へ順番に進めていくソフトウェア開発モデルです。
たとえるなら、設計図を完成させてから家を建てる方法に近い考え方です。
家を建てながら、
「やっぱり3階建てにしたい」
「玄関を反対側にしたい」
「柱の位置を全部変えたい」
と変更すると、大きな工事になります。
システム開発でも同じです。
要件定義で決めるべき内容が曖昧なまま実装やテストまで進むと、プログラムだけではなく設計書、データベース、テスト仕様などにも変更が広がる可能性があります。
IPAも、要件定義に抜け・漏れ・曖昧さがある場合、後の設計・開発工程で手戻りコストが大きくなると説明しています。
ウォーターフォールモデルの全体像
代表的な流れを単純化すると、次のようになります。
┌────────────┐
│ 要件定義 │
│ 何を作るか │
└─────┬──────┘
↓
┌────────────┐
│ 設計 │
│ どう作るか │
└─────┬──────┘
↓
┌────────────┐
│ 実装 │
│ コードを書く │
└─────┬──────┘
↓
┌────────────┐
│ テスト │
│ 正しいか確認 │
└─────┬──────┘
↓
┌────────────┐
│ 導入・運用 │
│ 実際に使う │
└────────────┘実際の開発では、さらに細かく分けられる場合があります。
企画
↓
要件定義
↓
基本設計・外部設計
↓
詳細設計・内部設計
↓
実装
↓
単体テスト
↓
結合テスト
↓
システムテスト
↓
受入テスト
↓
リリース
↓
運用・保守IPAも要件定義をプロジェクト初期の工程として位置付け、その後に基本設計が続く流れを説明しています。
上流工程と下流工程とは
ウォーターフォールモデルを理解するときは、上流工程と下流工程も覚えておきましょう。
上流工程
主に「何を作るのか」「どのように作るのか」を決めます。
企画
↓
要件定義
↓
基本設計
↓
詳細設計下流工程
上流工程で決めた内容を実際に作り、正しく動くか確認します。
実装
↓
単体テスト
↓
結合テスト
↓
システムテストIPAのDX SQUAREでも、企画・要件定義・基本設計を上流工程として説明しています。
なぜウォーターフォールでは要件定義が重要なのか
ウォーターフォールモデルでは、後工程が前工程の成果物を前提として進みます。
たとえば次のような要件を考えます。
「利用者はメールアドレスでログインできる」この要件から設計すると、
要件定義
「メールアドレスでログインする」
↓
設計
Userテーブルにメールアドレスを持たせる
↓
実装
認証処理を作る
↓
テスト
メールアドレスでログインできるか確認するという流れになります。
ところがテスト段階で、
「やっぱり社員番号でログインしたい」となるとどうでしょうか。
要件修正
↑
設計修正
↑
DB設計修正
↑
認証処理修正
↑
テスト仕様修正複数の成果物へ影響が広がります。
これが手戻りです。
上流工程の問題ほど後工程への影響範囲が大きくなりやすいため、要件定義や設計段階でレビューすることが重要になります。IPAも、要件定義の抜け・漏れ・曖昧さが後工程の手戻りコストを増加させると説明しています。
ウォーターフォールモデルのメリット
1. 全体計画を立てやすい
最初に要件や工程を整理するため、
- 開発範囲
- 必要な担当者
- スケジュール
- 成果物
- テスト計画
などを比較的整理しやすくなります。
2. 工程ごとの責任範囲を明確にしやすい
たとえば、
要件定義チーム
↓
設計チーム
↓
開発チーム
↓
テストチームというように工程ごとに担当を分けることができます。
大人数が関係するプロジェクトでは、成果物と工程の境界を明確にできることが管理上のメリットになります。
3. ドキュメントを残しやすい
各工程で、
- 要件定義書
- 基本設計書
- 詳細設計書
- テスト仕様書
- テスト結果報告書
などを作成することで、判断や仕様を記録できます。
長期間運用するシステムでは、開発時の担当者が退職・異動した後でも仕様を確認しやすくなります。
4. 要件が安定している開発と相性がよい
最初から必要な機能がある程度明確で、大幅な仕様変更が少ないプロジェクトでは、ウォーターフォール型の計画性を生かしやすくなります。
反対に、開発途中で要求が頻繁に変化するプロダクトでは、変更へ柔軟に対応するアジャイルが候補になります。IPAも、ウォーターフォールと比較してアジャイルでは機能追加・変更、優先順位変更、先行リリース部分の改善などへ柔軟に対応できると説明しています。
ウォーターフォールモデルのデメリット
1. 後から要件を変更すると手戻りが大きくなりやすい
最大の弱点です。
要件の誤り
↓
設計へ影響
↓
実装へ影響
↓
テスト仕様へ影響開発が進んでいるほど、変更対象が増える可能性があります。
2. 実際に動くシステムを見る時期が遅くなりやすい
設計を十分に進めてから実装する場合、利用者が実物を確認できる時期も後ろになります。
その結果、
設計書では問題なさそう
↓
実物を見る
↓
「思っていた画面と違う」という認識差が発覚することがあります。
3. 変化が激しいサービスでは計画が陳腐化する可能性がある
開発開始時に最適だった要件でも、完成時には利用者ニーズや市場環境が変わっている可能性があります。
そのため、
要件変更が少ない
→ ウォーターフォールと相性がよい
要件変更が頻繁
→ アジャイルなども検討という考え方が重要です。
「ウォーターフォールは前工程に絶対戻れない」は誤解
初心者向け教材では、
前の工程が完全に終了してから次へ進み、前工程には戻らない
と説明されることがあります。
試験の特徴を覚えるための単純化としては分かりやすいのですが、「絶対に戻ってはいけない」という意味ではありません。
重大な仕様漏れを見つけても、
ウォーターフォールだから修正禁止とはなりません。
実際には、
問題発見
↓
影響分析
↓
変更申請
↓
承認
↓
要件・設計を修正
↓
実装
↓
再テストといった変更管理を行います。
重要なのは、
ウォーターフォールは「戻れない」のではなく、「後から戻るほど変更の影響が大きくなりやすいため、前工程を十分確認してから次へ進む」
と理解することです。
ウォーターフォールとアジャイルの違い
基本情報技術者試験では、比較問題として理解しておくと強くなります。
| 項目 | ウォーターフォール | アジャイル |
| 開発方法 | 工程を順番に進める | 短い開発サイクルを反復する |
| 要件 | 初期に明確化しやすい | 開発中も変化しやすい |
| リリース | 比較的まとめて行う | 小さく繰り返す場合が多い |
| 変更 | 後半ほど影響が大きくなりやすい | 比較的取り込みやすい |
| 利用者からのフィードバック | 後になりやすい | 短い周期で得やすい |
| 計画 | 全体計画を立てやすい | 状況に合わせて調整する |
IPAの現行FEシラバスVer.9.2では、ウォーターフォールモデル、プロトタイピングモデル、アジャイル、DevOps、MLOpsなどがソフトウェア開発モデルに関する用語例として掲載されています。また、アジャイルについてはスクラム、XP、ユーザーストーリー、TDD、CI、リファクタリングなども学習対象として挙げられています。
ウォーターフォールとプロトタイピングモデルの違い
プロトタイピングモデルは、本格的に開発する前に試作品を作って利用者に確認してもらう考え方です。
要件を聞く
↓
試作品を作る
↓
利用者が確認
↓
要件を修正
↓
本開発たとえばECサイトなら、実際の決済処理まで作る前に画面だけ作り、
「商品検索はこの配置でいいですか？」
と確認できます。
ウォーターフォールの弱点である「完成するまで利用者がイメージしにくい」という問題を軽減する手段としても理解できます。
V字モデルとの関係
V字モデルは、設計側の工程とテスト側の工程の対応関係を整理する考え方です。
要件定義 ───────────── 受入・システムテスト
＼ ／
基本設計 ─────── 結合テスト
＼ ／
詳細設計 ─ 単体テスト
＼ ／
実装ポイントは、
設計した内容
↓
対応するテストで確認という関係です。
ウォーターフォールとV字モデルは対立するものではなく、ウォーターフォール型の工程について設計とテストの対応を分かりやすく表現するためにV字型で整理することがあります。
どのような開発に向いているのか
ウォーターフォールが比較的使いやすい条件は次のようなものです。
要件が明確
＋
変更が少ない
＋
成果物を明確にしたい
＋
計画的に進めたい反対に、
何を作るべきかまだ分からない
＋
利用者の反応を見ながら変えたい
＋
頻繁に小さくリリースしたい場合は、アジャイルやプロトタイピングなどの考え方を組み合わせた方が適切な可能性があります。
開発モデルは「どちらが絶対に優れているか」ではなく、プロジェクトの性質に合わせて選択するものです。
試験での確認方法
問題文に次の表現が出てきたら、ウォーターフォールを疑います。
ウォーターフォールを示しやすいキーワード
- 工程を順番に進める
- 要件を最初に明確にする
- 前工程の成果物を次工程へ引き渡す
- 工程ごとにレビューする
- 設計書などの成果物を重視する
- 後工程で仕様変更すると手戻りが大きい
一方、
短期間の反復
スプリント
プロダクトバックログ
継続的なフィードバックなどがあれば、アジャイルやスクラムを考えます。
練習問題
問題1
ウォーターフォールモデルの特徴として最も適切なものはどれか。
A. 開発期間中は仕様書を作成しない
B. 開発工程を短期間で何度も反復する
C. 工程を順番に進め、各工程の成果物を基に次工程を進める
D. 必ず毎日プログラムをリリースする
正解：C
ウォーターフォールでは、工程を段階的に進めることが重要な特徴です。
問題2
ウォーターフォールモデルの欠点として最も適切なものはどれか。
A. プログラムをテストできない
B. 後工程で要件変更が発生すると手戻りが大きくなりやすい
C. 設計書を作成できない
D. 大規模システムには使用できない
正解：B
上流工程の成果物を基に下流工程が進んでいるため、後から上流工程を変更すると複数の成果物へ影響する可能性があります。
問題3
顧客の要求が頻繁に変化し、完成した機能を短い周期で確認してもらいたい。最も特徴が合う開発方法はどれか。
A. アジャイル
B. ウォーターフォール
C. バックアップ
D. フェールセーフ
正解：A
IPAも、アジャイルは開発途中の機能追加・変更や優先順位変更などへ柔軟に対応できる手法と説明しています。
手戻りを減らすための対処方法
ウォーターフォールを採用する場合でも、手戻りをゼロにはできません。
重要なのは早く問題を発見することです。
1. 要件定義で曖昧な表現を減らす
悪い例：
画面を素早く表示する。この要件では、「素早い」の基準が分かりません。
改善例：
通常負荷時の画面応答時間を95パーセンタイルで2秒以内とする。測定可能な条件にします。
2. 各工程でレビューする
要件定義
↓
レビュー
↓
設計
↓
レビュー
↓
実装
↓
コードレビュー
↓
テスト問題を次工程へ持ち越さないことが重要です。
3. 要件とテストを対応付ける
たとえば、
| 要件 | テスト |
| メールアドレスでログインできる | 正しいメールアドレスで認証 |
| 誤ったパスワードを拒否する | 不正パスワードを入力 |
| 5回失敗したらロックする | 5回連続で認証失敗 |
という形にします。
「要件はあるがテストがない」「テストはあるが対応する要件がない」という状態を発見しやすくなります。
4. 変更管理を行う
仕様変更が発生した場合は、すぐ実装だけを書き換えるのではなく、
変更要求
↓
影響範囲確認
↓
工数・リスク確認
↓
承認
↓
設計変更
↓
実装
↓
回帰テストという形で管理します。
動作確認：理解できているかチェック
次の文章を読んで○か×か判断してください。
「ウォーターフォールでは、一度終了した工程は絶対に修正できない」
×
必要なら変更します。
ただし、後工程まで進んでから上流工程を変更すると影響範囲が広くなりやすいため、手戻りコストが問題になります。
「ウォーターフォールは、要件が比較的安定している開発と相性がよい」
○
初期段階で要件を整理して工程を進める特徴を生かしやすくなります。
「ウォーターフォールは必ずアジャイルより優れている」
×
プロジェクトによります。
重要なのは開発モデルそのものの優劣ではなく、対象システムや要求変化、組織、契約、リリース方法などとの適合性です。
再発防止：上流工程のミスを下流へ流さない
ウォーターフォールで大きな手戻りを防ぐには、次の流れを意識します。
要求を集める
↓
要件を具体化する
↓
関係者で合意する
↓
レビューする
↓
設計へ進む
↓
要件とテストを対応付けるIPAも要件定義について、利用者のニーズや要求を整理し、ステークホルダーと合意して要件へまとめる工程として説明しています。
注意点・よくある誤解
誤解1：ウォーターフォールでは前工程へ戻れない
「戻らないように進める」のと「戻ることが禁止されている」は違います。
実務では問題が見つかれば修正します。
誤解2：ウォーターフォールは古いから使う価値がない
開発方法の適否は、新しいか古いかだけでは判断できません。
要件の安定性、規模、組織構造、契約、規制、品質保証などを考慮して決めます。
誤解3：アジャイルなら要件定義は不要
アジャイルでも目的、ゴール、ビジョン、品質基準などは必要です。
IPAのアジャイル開発向けモデル契約でも、プロジェクトの目的・ゴール、プロダクトビジョン、初期計画、完了基準、品質基準などの確認が示されています。
ウォーターフォールモデルに対する否定的な見方
ウォーターフォールには明確な弱点もあります。
1つ目は、利用者からのフィードバックが遅れやすいことです。
実物を確認できる時期が遅い構成では、UIや業務フローの認識差を後から発見する可能性があります。
2つ目は、変更コストが大きくなりやすいことです。
要件変更が設計、実装、テストへ連鎖すると、大きな手戻りになります。IPAも要件定義の不備が後工程の手戻りコストにつながる点を指摘しています。
3つ目は、ドキュメントや工程完了自体が目的化する危険があることです。
「設計書が完成したから成功」ではありません。最終的な目的は、利用者や事業に必要なシステムを適切な品質で提供することです。
そのため実務では、
ウォーターフォール
+
プロトタイプ
+
自動テスト
+
CI/CDのように、一つの考え方だけへ厳密に固定せず、プロジェクトに合わせて技術やプラクティスを組み合わせることもあります。
基本情報技術者試験で覚えるポイント
試験直前なら、次の5つを覚えてください。
① 工程を順番に進める
② 初期に要件を明確化する
③ 計画・成果物を管理しやすい
④ 後からの変更は手戻りが大きくなりやすい
⑤ アジャイルは短い周期で変化へ対応しやすい特に、
「後工程で仕様変更が発生し、手戻りが大きくなる」
という文章はウォーターフォールの弱点を問う問題で重要です。
現行の基本情報技術者試験シラバスVer.9.2では、ウォーターフォールモデルだけでなく、プロトタイピングモデル、アジャイル、DevOps、MLOps、段階的モデル、進展的モデルなども同じソフトウェア開発モデルの学習対象として示されています。
まとめ
ウォーターフォールモデルは、システム開発の工程を上流から下流へ順番に進める代表的な開発モデルです。
要件定義
↓
設計
↓
実装
↓
テスト
↓
導入・運用計画や成果物を管理しやすいことがメリットです。
一方で、
後工程で問題発見
↓
上流工程を修正
↓
複数工程へ影響
↓
大きな手戻りとなりやすい点が重要な弱点です。
ただし、
「ウォーターフォールでは絶対に前工程へ戻れない」
という理解は避けてください。
実務では必要に応じて変更します。
基本情報技術者試験では、
工程を順番に進める・要件を初期に固める・後からの変更による手戻りが大きい
という3点を軸に覚えれば、アジャイルやプロトタイピングとの比較問題にも対応しやすくなります。
FAQ
Q1. ウォーターフォールモデルとは簡単にいうと何ですか？
要件定義、設計、実装、テストなどの工程を、上流から下流へ順番に進める開発モデルです。
Q2. なぜウォーターフォールという名前なのですか？
開発工程が上流から下流へ進んでいく様子を、上から下へ流れる滝に例えた名称です。
Q3. ウォーターフォールでは前の工程に戻れないのですか？
戻れます。
ただし後工程まで進んだ後で上流工程を変更すると、設計・コード・テストなど複数箇所へ変更が波及する可能性があります。そのため、前工程を十分に確認してから次へ進むことを重視します。
Q4. ウォーターフォールの最大のデメリットは何ですか？
後工程で要件や設計の問題が発覚した場合、手戻りが大きくなりやすいことです。IPAも要件定義の抜けや曖昧さが後工程の手戻りコスト増加につながると説明しています。
Q5. アジャイルとの最大の違いは何ですか？
ウォーターフォールは全体の要件や仕様を初期に整理して段階的に進める考え方です。
アジャイルは短いサイクルで開発・確認を繰り返し、機能や優先順位の変更を取り込みながら進めることを重視します。IPAも両者をこの観点から区別しています。
Q6. 2026年の基本情報技術者試験でも出題範囲ですか？
はい。
2026年8月19日時点でIPAが掲載している基本情報技術者試験シラバスVer.9.2では、「ソフトウェア開発モデル」の用語例としてウォーターフォールモデルが掲載されています。
Q7. 2027年度から試験内容は変わりますか？
IPAは2027年度から新試験制度へ移行する予定です。ただし、2026年7月31日時点の公式ページでは、基本情報技術者試験の新シラバス案は「準備中」です。公開後は最新シラバスを再確認する必要があります。
参考情報
IPA「基本情報技術者試験（レベル2）シラバス Ver.9.2」
現行の基本情報技術者試験シラバスです。「ソフトウェア開発モデル」の用語例としてウォーターフォールモデル、プロトタイピングモデル、アジャイルなどが掲載されています。
URL：
https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kpe-att/syllabus_fe_ver9_2.pdf
IPA「試験要綱・シラバスについて」
基本情報技術者試験を含む現在の公式シラバス一覧を確認できます。2026年8月時点では基本情報技術者試験Ver.9.2が掲載されています。
URL：
https://www.ipa.go.jp/shiken/syllabus/gaiyou.html
IPA「情報システム・モデル取引・契約書（アジャイル開発版）」
ウォーターフォールとアジャイルの要件・仕様変更に対する考え方の違いを確認できます。
IPA 情報システム・モデル取引・契約書（アジャイル開発版）
URL：
https://www.ipa.go.jp/digital/model/agile20200331.html
IPA DX SQUARE「要件定義とは？」
要件定義、上流工程、後工程での手戻りについて確認できます。
URL：
https://dx.ipa.go.jp/youken-teigi
IPA「新試験制度のシラバス案について」
2027年度開始予定の新試験制度に関する公式情報です。2026年7月31日の更新時点では、基本情報技術者試験のシラバス案は準備中です。
URL：
https://www.ipa.go.jp/shiken/syllabus/henkou/2026/20260630.html