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

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

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

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

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

発注前に押さえておきたい要点を、先に4つへ絞ります。

• 工程数の多少より、各工程の出口で成果物を確定させる規律が効きます。承認の場には現場の業務担当を必ず入れてください。
• V字モデルで設計工程とテスト工程を対応づけると、テスト計画を設計と同時に立てられます。受入テストの観点は要件定義の段階で書き出せます。
• 契約と見積もりは工程ごとに姿が変わります。要件定義は準委任、仕様確定後の設計・製造は請負という段階的な締結が、実務で選ばれやすい形です。
• アジャイル開発との違いは進め方だけではありません。発注側が割く体制・意思決定の頻度・受入の作法まで変わります。

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

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

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

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

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

Royceの原論文が示した原案と後から広まった呼称の成り立ち

出典をたどると、通説とは少しずれた事実が見えてきます。源流とされるRoyce氏の1970年の論文「Managing the Development of Large Software Systems」には、「ウォーターフォール」という語そのものが出てきません。この呼び名が広まったのは、1976年のBell氏とThayer氏による論文以降と整理されています。しかも同論文は、工程を一度きり流す形をそのまま勧めてはおらず、前工程へ戻すフィードバックや試作の必要を説いていました。つまり「絶対に後戻りしない手法」という理解は、後年の運用側による単純化です。実務で効くのは、戻らない規律ではなく、戻るときの手続きを先に決めておくことのほうでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

受入テストの準備をV字モデルの左側から始める発注側の具体的段取り

V字モデルの実利は、発注側の準備を前倒しできる点にあります。受入テストは要件定義と対応するため、要件を文書化した時点で「合格の条件」を書き出せます。業務の代表シナリオ、判定に使うデータの実物、合否を決める担当者、テストに充てられる期間。この4つを要件定義の承認と同じタイミングで決めておくと、後半の日程が楽になります。逆に製造の終盤まで放置すると、受入テストが日程の谷間に押し込まれ、現場が触らないまま検収印だけが押される事態になりがちです。各テストの範囲と流れはシステム開発のテスト工程の記事で掘り下げています。

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

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

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

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

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

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

ウォーターフォール開発の契約形態と見積もりが工程ごとに変わる理由

手法の話は、そのまま契約と金額の話につながります。工程を分けて進める以上、契約の型と見積もりの精度も工程ごとに変わるからです。ここを曖昧にしたまま一括で発注すると、後半の変更が有償か無償かで揉めます。

工程ごとに契約を分ける段階的な締結と請負・準委任の判断と使い分け

参照しやすい一次情報として、IPAが公開している「情報システム・モデル取引・契約書」があります。第二版は2020年12月22日に公開され、共通フレーム2013の工程定義に沿って、企画・要件定義・システム開発・運用・保守の各プロセスを分けて契約する形を示しています。アジャイル開発版はこれとは別に2020年3月31日付で公開されており、反復型には反復型のひな形が用意されている形です（いずれも2026年8月時点）。

実務での使い分けは、成果物を着手時点で確定できるかどうかで決まります。要件定義のように、何が出来上がるかを事前に書き切れない工程は準委任が選ばれやすく、仕様が固まった後の設計・製造は請負に馴染みます。両者の責任範囲の違いは準委任契約とはの記事で詳しく比べました。全工程を一括の請負にすると、要件が曖昧なまま金額だけが固定され、しわ寄せが後半に集まります。

概算から確定へ精度が上がる見積もりと変更管理のルールの決め方

見積もりの精度は、上流の確定度と連動します。要件定義前に出せるのは幅を持った概算で、要件定義書と基本設計書が固まって初めて確定見積もりの水準になります。下表が工程と契約・見積もりの対応です。

あわせて決めておきたいのが変更管理のルールです。変更要求を受け付ける窓口、影響調査にかける工数の扱い、承認する人、追加費用の算定方法。この4点を契約書と議事録に残しておくと、後半の仕様変更が「言った言わない」に落ちません。見積書そのものの読み方はシステム開発の見積もりの記事で解説しています。

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

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

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

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

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

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

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

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

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

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

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

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

この違いは、契約や見積もりの形にも波及します。ウォーターフォールは全体一括の請負に馴染む一方、アジャイルは期間や工数で契約する形が中心です。用語の面では、PMIの「PMBOKガイド」が開発アプローチを予測型・ハイブリッド・適応型という連続体で並べる整理を第7版（2021年）で示し、2026年に切り替わった第8版でもこの並列の扱いを引き継いでいます（2026年8月時点）。ウォーターフォールは予測型、アジャイルは適応型に当たると読み替えると、社内での説明が通りやすくなります。

発注側の体制と受入の作法に表れるアジャイル開発との実務上の違い

比較表に出てこない差が、発注側の手間です。ウォーターフォールで求められるのは、節目のレビューに人を出し、成果物を読み込んで承認する働き方。アジャイルで求められるのは、反復ごとに優先順位を決め、その場で仕様を判断できる担当者を継続して張り付ける働き方です。下表に、日々の運用で効いてくる差を並べます。

ここを読み違えると、手法だけ入れ替えて失敗しかねません。反復ごとに判断できる担当者を出せない組織がアジャイルを選ぶと、決裁待ちで反復が止まります。逆に、要件が動く案件でウォーターフォールを選ぶと、変更のたびに契約変更の手続きが要ります。自社が出せる関与量から手法を逆算するのが、現実的な順序でしょう。

上流を固めて一部だけ反復で作るハイブリッド型の実務での組み立て方

二者択一に見えて、実務では折衷が広く使われています。要件定義と基本設計をウォーターフォールで固め、画面や一部機能だけを反復で作る形です。境界の引き方には目安があります。法令や既存の基幹システムと接続する部分、データの持ち方や権限設計のように後から変えにくい部分は、先に固める側へ。利用者の反応で変わる画面や、優先順位が動く追加機能は、反復側へ寄せます。

落とし穴は、契約と進捗の物差しが二本立てになることです。固める側は請負で工程完了率、反復側は準委任で機能の消化量、というように測り方が分かれます。着手前に、どの機能がどちらの側かを一覧にし、リリースの単位と受入の方法まで決めてください。反復側で要件をどう扱うかはアジャイル開発の要件定義の記事が参考になります。

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

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

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

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

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

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

ウォーターフォール開発とアジャイル開発の違いはどこに出ますか？

差は3層に分かれます。第一が進め方で、工程を一度きり通すか、短い反復を繰り返すか。第二が成果物の出方で、終盤にまとめて動くものが出るか、反復ごとに動く形が出るかという違いです。第三が発注側の負担で、節目のレビュー中心か、反復ごとの継続関与かが分かれます。契約も前者は請負、後者は準委任が中心になりやすく、費用の見え方まで変わってきます。

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

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

ウォーターフォール開発の契約は請負と準委任のどちらですか？

工程によって分けるのが実務の基本形です。要件定義のように成果物を着手時点で書き切れない工程は準委任、仕様が固まった後の設計・製造は請負に馴染む傾向です。IPAの「情報システム・モデル取引・契約書（第二版）」も、工程ごとに契約を分けて締結する形を示しています。全工程を一括の請負にすると、要件が曖昧なまま金額が固定され、後半の変更で条件がこじれます。

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

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

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

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

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

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

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説：ウォーターフォールの各工程の成果物・体制・工数比率をさらに詳しく確認できます。
• ウォーターフォール・アジャイル・スクラムの違い：3つの開発手法を比較し、案件別の使い分けを整理しています。
• アジャイル開発とは：要件が動く案件で選ばれる反復型の手法を、進め方から解説しています。
• アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い：反復型で要件をどう扱うかを段階別にまとめています。
• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：上流工程で決める範囲と発注側の作業分担を確認できます。
• 外部設計とは？内部設計との違いと成果物、発注者が承認すべき観点：基本設計フェーズで発注側が確認すべき点を掘り下げています。
• システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸：各テストの範囲と受入の進め方を詳しく扱っています。
• 準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説：工程ごとの契約の型と責任範囲を比較しています。
• システム開発の見積もりとは？見積書の見方・依頼方法・相見積もりの比較：見積書の内訳と妥当性の見抜き方をまとめています。
• システム構成図とは？種類と書き方・例、発注者が確認すべき観点：設計工程で作る構成図の読み方と確認観点をまとめています。