ウォーターフォール開発とは？工程とV字モデル・向く案件を発注者目線で解説

ウォーターフォール開発は、要件定義から運用保守までの工程を上流から下流へ一方向に進める開発手法です。滝が上から下へ落ちるように、前の工程が完了してから次へ移り、原則として後戻りしません。この記事では、5〜7段階の工程と各フェーズの成果物、V字モデルとテストの対応関係、計画のしやすさと仕様変更への弱さというメリット・デメリット、そしてどんなプロジェクトに向き、どんな案件では避けるべきかを、システムを発注する側の視点で整理します。アジャイル開発との使い分けの基準まで、順に確認してください。

まとめ｜ウォーターフォール開発が向く案件と発注前に押さえる要点

ウォーターフォール開発は、①要件定義 ②基本設計（外部設計）③詳細設計（内部設計）④製造（実装）⑤テスト ⑥リリース ⑦運用・保守という工程を、前工程の成果物を確定させながら順に進める手法です。テストを単体・結合・総合・受入に細分するため、数え方によって工程数は5〜7段に幅があります。各工程の節目で生まれる要件定義書・基本設計書・テスト仕様書といった成果物を、発注側がレビューして承認できて初めて次へ進みます。

この手法が力を発揮するのは、作るものが最初にほぼ固まっている案件です。金融の勘定系、官公庁向け、大規模な基幹システムのように、要件が途中で大きく揺れず、品質とスケジュールの説明責任が問われる開発に向きます。逆に、市場の反応を見ながら仕様を練る新規事業やスマホアプリでは、後戻りできない性質が足かせになります。仕様が固まらないうちに着手すると、後半での仕様変更が手戻りとなって工数を押し上げるためです。

発注側がまず決めるべきは、上流工程の要件をどこまで自社で握るかです。工程ごとの成果物と工数比率の目安はシステム開発の工程の記事で詳しく扱っています。手法の選定や進め方に不安があれば、要件定義から運用保守まで一貫して引き受ける業務システム開発への相談を検討してください。

ウォーターフォール開発とは何かと工程が上流から下流へ流れる仕組み

ウォーターフォール開発は、1970年にWinston W. Royce氏が論文で示した工程モデルが源流とされ、日本のシステム開発で長く主流を占めてきた手法です。特徴は、工程を時間軸に沿って一列に並べ、前工程を完了させてから次工程に入る点にあります。設計が終わる前に製造を始めたり、テスト中に要件を足したりはしません。この「一度きりで進める」前提が、後述するメリットとデメリットの両方を生みます。

ウォーターフォール開発の名前の由来と滝のように流れる開発の進め方

ウォーターフォールは英語で「滝」を指します。工程を図にすると、要件定義を最上段に置き、設計・製造・テスト・リリースが階段状に下っていく形になり、水が上段から下段へ落ちる様子に似ています。ここから名付けられました。水が逆流しないのと同じで、完了した工程には戻らないのが基本方針です。もし戻る場合は、前工程の成果物を正式に修正し、影響範囲を洗い直したうえで進めます。思いつきで前に戻るのではなく、変更管理の手続きを踏むわけです。

要件定義から運用保守まで工程を一度きりで順に進める基本の流れ

標準的な流れは、要件定義で「何を作るか」を文書化し、基本設計で画面や機能の外側を、詳細設計で内部のつくりを固めます。そのうえで製造（プログラミング）に入り、テストで品質を確かめ、本番環境へリリースし、運用・保守へと引き継ぎます。各工程の出口にあるのは、成果物という関門です。発注側がここで承認して初めて、次工程への通行証が渡ります。上流の要件が曖昧なまま下流へ流れると、製造やテストの段階で矛盾が噴き出し、手戻りが連鎖します。大切なのは順に進めること自体ではなく、各関門で仕様を確定させる規律のほうです。

ウォーターフォール開発の7工程と各フェーズの成果物・担当範囲

工程は大きく上流と下流の2つに分かれます。上流は発注側の業務判断が必要な範囲で、下流は開発会社が主に手を動かす範囲です。ここでは7工程を上流と下流に分け、それぞれで何が決まり、何が生まれるかを順に押さえます。

上流工程にあたる要件定義と基本設計で発注側が決める業務ルール

要件定義は、業務上やりたいことを機能・非機能の要件へ翻訳する工程です。画面に出す項目、承認の流れ、扱う金額の丸め方といった業務ルールは、発注側にしか決められません。基本設計（外部設計）では、その要件を画面・帳票・データの外形に落とします。利用者が触れる部分の設計であるため、ここも発注側の確認が濃く関わります。基本設計で承認すべき観点は外部設計とはの記事にまとめました。上流の精度が、下流の手戻り量をそのまま決めます。

下流工程の詳細設計から製造・テストまでで品質を固める作業の中身

詳細設計（内部設計）は、基本設計で決めた外形を、内部のクラス構成やデータの持ち方に落とす工程で、ここからは開発会社の領分が中心です。製造では設計書どおりにプログラムを組み、単体テストで部品ごとの動作を確かめます。続く結合・総合テストで、部品をつないだ全体の動きと要件との一致を検証します。発注側がこの段階でやるべきは、進捗と課題の管理状況を定例で確認し、検出された不具合が是正・再テストまで閉じているかを追うことです。

各工程で生まれる主な成果物と発注者がレビューで確認すべき観点

工程の節目には、次工程の入力になる成果物が必ず生まれます。何が出てくるはずかを知らないと、レビューの抜けがそのまま品質の穴になります。下表は7工程の成果物と、発注側が承認時に確認したい観点の対応です。

とくに要件定義書と基本設計書は、後工程で作り直すと影響が広く波及します。この2つの承認には、現場の業務担当を必ず同席させてください。文書の体裁ではなく、実際の業務が回るかどうかで判断するのが承認の勘どころです。

ウォーターフォール開発とV字モデルの対応関係とテストの位置づけ

ウォーターフォールを語るとき、V字モデルは切り離せません。工程を一直線ではなくV字に折り曲げて描き、左側の設計工程と右側のテスト工程を対応づけた図がV字モデルです。競合の解説記事では省かれがちですが、テスト計画をいつ作るべきかを理解するうえで土台になる考え方なので、ここで整理します。

V字モデルがウォーターフォールの各工程とテストを対応させる仕組み

V字モデルは、左肩から谷へ要件定義・基本設計・詳細設計と下り、谷で製造を行い、右肩へ単体・結合・総合・受入テストと上っていく形で描きます。ポイントは、同じ高さにある設計工程とテスト工程が対応する点です。要件定義の内容は受入テストで、基本設計は総合テストで、詳細設計は結合テストで検証します。この対応があるからこそ、設計を終えた時点で対応するテストの計画を先に立てられます。

単体・結合・総合テストがそれぞれ対応する設計工程と品質の担保

各テストが確かめる対象は、対応する設計工程で決めた内容です。下表のように紐づけると、テストの抜け漏れを設計段階で防げます。

この対応を意識すると、「要件定義で決めたのにテスト項目が無い」といった漏れに早く気づけます。設計レビューの場で、対応するテストで何を確認するかまで詰めておくと、後半のテスト工程が短くなります。V字モデルは、テストを最後の作業ではなく設計と同時に組み立てる発想へ切り替える道具です。

ウォーターフォール開発のメリットとデメリットの発注側視点での整理

メリットとデメリットは表裏一体です。「後戻りしない」という同じ性質が、計画の立てやすさという長所と、変更への弱さという短所を同時に生みます。発注側の負担という切り口で、両面を見ていきます。

計画と進捗管理のしやすさというウォーターフォール開発の主な強み

最大の強みは、全体像を最初に固めるため、スケジュール・体制・費用を早い段階で見積もりやすいことです。工程と成果物が明確なので、進捗を「どの工程まで終わったか」という形で測れます。担当者の交代があっても、成果物が文書として残るため引き継ぎが利く点も見逃せません。作業を分担しやすく、要員を計画的に投入できるのも大人数の開発では効いてきます。要件が固い案件ほど、この見通しの良さが投資判断を後押しします。

仕様変更に弱く手戻りの工数が膨らむウォーターフォールの主な弱点

弱点は、開発の後半で仕様変更が起きると、対応コストが跳ね上がる点にあります。製造やテストの段階で要件を変えると、設計まで遡って直し、影響範囲のテストをやり直すことになります。前工程の完了を待つため、動くものを利用者が確認できるのがリリース間際になりがちで、そこで初めて認識のずれが露見する例も珍しくありません。要件を固めきれない案件でこの手法を選ぶと、変更のたびに手戻りが積み上がり、当初の見積もりから大きく膨らみます。弱点の多くは、上流での要件確定の甘さに起因します。

ウォーターフォール開発が向くプロジェクトと避けるべき条件の見極め

ここが発注判断の核心です。ボリュームの大小ではなく、「要件が事前に固められるか」で向き不向きを判断します。玉虫色の結論は避け、採用する条件と見送る条件をはっきり分けます。

仕様が固まり要件が変わりにくい案件でウォーターフォールが向く理由

採用してよいのは、次の条件が揃う案件です。第一に、作るものが着手前にほぼ確定していること。第二に、法令や既存業務によって仕様の枠が決まっており、途中で大きく変わりにくいこと。第三に、品質とスケジュールの説明責任が重く、工程の証跡を残す必要があること。勘定系や会計、公共システム、大規模な業務基幹の刷新はこの典型です。関係者が多く、全体を一度設計してから分担して作るほうが混乱が少ない場面でも、この手法が適しています。

要件が固まらない新規事業でウォーターフォールを避けるべき理由

見送るべきなのは、要件が動くことが前提の案件です。市場の反応を見て仕様を練る新規サービス、利用者の声で画面を練り直すスマホアプリ、作りながら要件が見えてくる社内の試作などが該当します。いずれも後戻りできない性質との相性が悪いケースです。無理にウォーターフォールを当てはめると、リリース時点で「思っていたものと違う」が確定します。要件の不確実性が高いなら、短い反復で軌道修正するアジャイル開発とはの手法が向いており、投資の無駄を減らせます。

丸投げが招く要件定義の失敗とウォーターフォールで炎上する条件

手法の向き不向き以前に、案件が炎上する典型パターンがあります。要件定義を開発会社に丸投げし、上流のレビューを実質スキップする進め方です。ウォーターフォールは上流の確定を前提に成り立つため、そこが甘いと下流のすべてが崩れます。発注側の業務担当が要件定義と基本設計に入らない、成果物を読まずに承認印だけ押す、変更管理のルールを決めずに口頭で仕様を足す——この3つが揃うと、後半で手戻りが連鎖します。避ける条件はシンプルで、上流に自社の当事者を必ず据えることです。工程全体の設計と体制づくりに不安があれば、要件定義から伴走する業務システム開発への相談が近道になります。

ウォーターフォール開発とアジャイル開発の違いと使い分けの基準

両者は優劣ではなく、要件の固さで使い分ける関係です。ここでは進め方の違いを表で押さえ、発注前にどちらを選ぶかの判断軸を示します。スクラムを含めた3手法の詳しい比較は、別記事に譲ります。

ウォーターフォール開発とアジャイル開発の進め方と成果物の違い

もっとも大きな差は、工程を一度きりで通すか、短い反復を繰り返すかです。ウォーターフォールは全体を設計してから作り、アジャイルは小さく作って確かめる作業を回します。成果物の出方も変わります。

この違いは、契約や見積もりの形にも波及します。ウォーターフォールは全体一括の請負に馴染む一方、アジャイルは期間や工数で契約する形が中心です。発注側の関わり方も、前者は節目のレビュー中心、後者は反復ごとの継続関与という差になります。

どちらの開発手法を選ぶか発注する前に判断するための3つの評価軸

選定の軸は3つに絞れます。第一に要件の固さで、着手前に決めきれるならウォーターフォール、動くならアジャイルが基本線です。第二は品質・証跡の要求で、法令や監査で工程の記録が要る案件ではウォーターフォールが向きます。第三は発注側の関与量で、反復ごとに判断できる体制が組めるかどうかが分かれ目です。実務では、上流をウォーターフォールで固め、一部をアジャイルで作る折衷もあります。スクラムを加えた3手法の詳細な比較はウォーターフォール・アジャイル・スクラムの違いで扱っているので、選定に迷う場合はあわせて確認してください。

ウォーターフォール開発の導入検討でよく寄せられる質問への回答

ウォーターフォール開発の検討時に寄せられることの多い質問へ、要点を絞って回答します。

ウォーターフォール開発とアジャイル開発はどちらが優れていますか？

一方が常に優れているわけではなく、案件の性質で使い分ける関係です。要件が着手前に固まり、品質やスケジュールの説明責任が重い大規模開発ではウォーターフォールが向きます。市場の反応を見ながら仕様を練る新規事業ではアジャイルが機能します。判断軸は「要件が固いか動くか」「工程の証跡が要るか」「反復ごとに判断できる体制があるか」の3点です。

ウォーターフォール開発はもう古い手法なのですか？

古いから使えないという評価は実態と合いません。勘定系や公共システム、大規模な基幹刷新など、要件が固く証跡が問われる領域では現在も主流です。1970年代に体系化された手法ですが、上流を固めてから作るという発想は今も有効です。要件が動く案件で無理に当てはめると弱点が出るだけで、適した領域では合理的な選択になります。

小規模なシステム開発でもウォーターフォールは使えますか？

使えます。むしろ要件がはっきりした小規模開発では、反復の仕組みを整えるより一直線に進めたほうが速い場合があります。判断基準は規模ではなく要件の固さです。作るものが決まっているなら、小規模でもウォーターフォールで問題ありません。要件が固まらないうちに始めると、規模が小さくても手戻りは発生します。

V字モデルとウォーターフォールモデルは何が違うのですか？

別の手法ではなく、同じ工程の描き方の違いです。ウォーターフォールは工程を上から下へ一直線に並べます。V字モデルは同じ工程をV字に折り、左の設計工程と右のテスト工程を対応づけて描きます。設計とテストの紐づけを明示できるため、テスト計画を設計と同時に立てやすくなるのがV字モデルの利点です。

ウォーターフォール開発の工程は何段階に分けるのが一般的ですか？

5〜7段階に分けるのが一般的です。要件定義・設計・製造・テスト・リリースの5段階で語ることもあれば、設計を基本設計と詳細設計に、テストを単体・結合・総合・受入に細分して7段階以上で数えることもあります。段数そのものより、各工程の成果物を確定させてから次へ進む規律のほうが実務では効いてきます。

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説：ウォーターフォールの各工程の成果物・体制・工数比率をさらに詳しく確認できます。
• ウォーターフォール・アジャイル・スクラムの違い：3つの開発手法を比較し、案件別の使い分けを整理しています。
• アジャイル開発とは：要件が動く案件で選ばれる反復型の手法を、進め方から解説しています。
• 外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点：基本設計フェーズで発注側が確認すべき点を掘り下げています。
• システム構成図とは？種類と書き方・例、発注者が確認すべき観点：設計工程で作る構成図の読み方と確認観点をまとめています。