要件定義から運用保守まで、滝の水が上から下へ流れるように工程を一方向に進める——それがウォーターフォール開発です。計画性に優れた伝統的手法ですが、「作ってみないと分からない」AIプロジェクトでは弱点が表面化します。G検定第7章ではアジャイル開発との対比で問われる頻出キーワードです。
📖 ひと言でいうと
ウォーターフォール開発とは、要件定義、設計、実装、テスト、リリース、運用保守といった工程を順序立てて直線的に進める、ソフトウェア開発の伝統的な手法です。前の工程が完了してから次へ進むため、その流れが滝(ウォーターフォール)に例えられます。
身近な例えでいえば、注文住宅の建築に似ています。設計図を確定し、基礎を打ち、骨組みを立て、内装を仕上げる——工程の順序は入れ替えられず、完成間近に「間取りを変えたい」と言えば大規模な手戻りが発生します。この「計画どおりに進めやすいが、後からの変更に弱い」性質がウォーターフォールの本質です。
🖼 1枚でわかるウォーターフォール
📘 公式テキストの説明
ウォーターフォール開発は、ソフトウェア開発における伝統的な手法の一つで、各工程を順序立てて進める特徴を持つ。具体的には、要件定義、設計、実装、テスト、リリース、運用保守といったフェーズを直線的に進行する。各フェーズが完了してから次のフェーズに移行するため、全体の計画が立てやすく、進捗管理も容易である。この手法の利点として、プロジェクトの全体像を初期段階で明確に描ける点が挙げられる。特に、大規模なプロジェクトや要件が安定している場合に適している。各フェーズでの成果物が文書化されるため、関係者間の認識共有がスムーズに行える。一方で、ウォーターフォール開発には柔軟性の欠如という課題も存在する。開発途中で要件の変更が生じた場合、前のフェーズに戻って修正することが難しく、手戻りが大きくなる可能性がある。また、テスト工程が最後に位置するため、問題の発見が遅れ、修正コストが増大するリスクもある。AIプロジェクトにおいては、要件が変動しやすく、試行錯誤が求められる場面が多い。そのため、ウォーターフォール開発のような固定的な手法では対応が難しい場合がある。代わりに、アジャイル開発のような柔軟性の高い手法が適しているとされる。アジャイル開発では、短期間のイテレーションを繰り返し、顧客のフィードバックを迅速に取り入れることで、変化に対応しやすい。しかし、ウォーターフォール開発が全く適さないわけではない。要件が明確で変更の可能性が低いプロジェクトや、規模が大きく計画性が重視される場合には、有効な手法となり得る。また、ウォーターフォールとアジャイルの特性を組み合わせたハイブリッド型開発も存在し、プロジェクトの特性に応じて適切な手法を選択することが重要である。ウォーターフォール開発は、計画性と文書化を重視する手法であり、特定の条件下では効果的である。しかし、AIプロジェクトのように変化が多く柔軟性が求められる場合には、他の開発手法の検討も必要となる。
この説明は「利点→課題→AIとの相性→それでも有効な場面」という公平な構成になっています。単純に「ウォーターフォール=悪、アジャイル=善」ではなく、要件が明確で変更が少ない大規模案件ではウォーターフォールが有効であり、両者を組み合わせたハイブリッド型もある、というバランス感覚まで含めて理解するのが正しい読み方です。
🔍 しっかり理解する
工程は一方向——だから強く、だから弱い
ウォーターフォールの工程を並べると次のとおりです。
各フェーズを完了させてから次へ進むため、全体スケジュールと費用の見積もりが立てやすく、いま何合目にいるかの進捗管理も容易です。フェーズごとに要件定義書や設計書といった成果物が文書として残るので、大人数・多組織が関わるプロジェクトでも認識合わせがスムーズです。
一方、この一方向性は「後戻りのコストが大きい」ことと表裏一体です。実装段階で要件の誤りに気づいても、要件定義からやり直す手戻りは甚大です。さらにテストが最後に位置するため、重大な問題ほど発見が遅れ、修正コストが膨らむ構造的リスクを抱えています。
AIプロジェクトで何が起こるか
ウォーターフォールの大前提は「最初に要件を確定できること」です。ところがAIプロジェクトでは、この前提が成り立ちません。
モデルの精度はデータの量と質に依存するため、「精度95%の検品AI」という要件を最初に確定しても、その数字が達成可能かは学習させてみるまで分かりません。データを見て前処理を変え、モデルを変え、ときには目標自体を修正する——という試行錯誤のループが本質的に必要で、「要件が変動しやすい」のです。固定的な一方向の工程では、この行き来を吸収できません。
そのためAI開発では、PoC(概念実証)で実現可能性を確かめ、アジャイル開発のような短いイテレーション(反復)で試行錯誤を回す進め方が適しているとされます。
それでもウォーターフォールが選ばれる場面
ただし全否定は誤りです。要件が明確で変更の可能性が低いプロジェクトや、規模が大きく計画性・文書化が重視される案件(たとえば基幹システムの更改など)では、いまも有効な手法です。実務では、AIモデルの試行錯誤部分はアジャイルで回し、周辺システムとの結合やリリースは計画的にウォーターフォールで進める、といったハイブリッド型も使われます。プロジェクトの特性に応じた使い分けが結論です。
💡 具体例で考える
ある銀行が「融資審査を支援するAIシステム」をウォーターフォールで開発したと想像してください。半年かけて要件定義と設計を固め、「過去データから審査通過確率を予測し、精度90%以上」と仕様書に明記。ところが実装後のテスト段階で、実データでは精度が75%までしか届かないことが判明します。
原因をたどると、要件定義時に想定していなかったデータの欠損や偏りがあり、前処理と特徴量の設計からやり直しが必要でした。しかし工程はすでにテスト段階。要件定義まで戻る手戻りは予算とスケジュールを直撃します。もし最初に小さなPoCで精度の当たりをつけ、反復的に開発していれば、この問題は初期の数週間で発見できたはずです。「テストが最後」「後戻りが困難」というウォーターフォールの弱点が、要件の不確実なAI案件で顕在化する典型例です。
⚠️ よくある誤解・紛らわしい用語
- 「ウォーターフォール=時代遅れの悪い手法」ではない — 要件が安定した大規模プロジェクトでは、計画性と文書化の強みが今も有効です。試験でも「全く適さないわけではない」という留保まで問われえます。
- アジャイルとの対比 — 「各工程を直線的に進める」=ウォーターフォール、「短期間の反復を繰り返す」=アジャイル。この対応の入れ替えが誤答選択肢の定番です。
- V字モデルなど派生との関係 — ウォーターフォールを基礎に、各開発工程とテスト工程を対応づけたV字モデルなどの派生手法もありますが、G検定ではまず基本形の工程と特徴を押さえれば十分です。
- 「AIプロジェクト=必ずアジャイル」でもない — ハイブリッド型のように、プロジェクトの特性に応じて両者を組み合わせる選択肢があります。
📝 試験でのポイント
- 定義問題では「各工程を順序立てて直線的に進める」「各フェーズ完了後に次へ移行」という表現が正解の目印です。
- 利点(全体像の明確化・進捗管理の容易さ・成果物の文書化)と課題(柔軟性の欠如・手戻りの大きさ・テストが最後で問題発見が遅い)を対で覚えましょう。
- 「AIプロジェクトにウォーターフォールが不向きな理由」として、要件の変動しやすさと試行錯誤の必要性を挙げる選択肢が想定されます。
- アジャイルとの特徴入れ替え問題が最頻出です。ハイブリッド型の存在(適材適所での使い分け)も選択肢に登場しえます。
📚 まとめ
- ウォーターフォール開発は、要件定義→設計→実装→テスト→リリース→運用保守を直線的に進める伝統的手法です。
- 全体計画の立てやすさ・進捗管理の容易さ・文書化による認識共有が利点で、要件が安定した大規模案件に適します。
- 弱点は柔軟性の欠如で、要件変更時の手戻りが大きく、テストが最後のため問題発見が遅れがちです。
- 要件が変動し試行錯誤が必要なAIプロジェクトには不向きな場合が多く、アジャイルやハイブリッド型を含めた使い分けが重要です。
