ウォーターフォール開発とは?工程の流れとV字モデル、向く案件・向かない案件を発注者目線で解説【2026年版】

「提案書にウォーターフォールと書いてあったが、いまどきそれでよいのか」——システム開発の発注を検討している方から、こうした相談をよく受けます。アジャイルが主流だと聞くのに、目の前の提案書は要件定義から順に進む計画になっている。工程の名前は知っているが、自社が何を決めて何に承認の判を押すのかは書かれていない。しかも「前工程には戻れない」と言われると、途中で気が変わったら終わりなのかと身構えてしまう。

結論から言うと、ウォーターフォール開発は「前工程の成果物を承認してから次工程に進む」という約束で、品質と進捗を工程単位に管理する手法です。そして「前工程に戻らない」とは、物理的に戻れないという意味ではありません。戻るときは変更管理という公式の手続きを通す、という運用上の約束です。ここを正確に理解しているかどうかで、発注側の身構え方も、プロジェクトの進み方も変わります。

手法に優劣はありません。要件を着手前に確定できるか、関係者と部門が多いか、長期の保守と引き継ぎが要るか。この3点で、自社の案件がウォーターフォールの前提に合うかどうかは判断できます。合うなら選べばよく、合わないなら反復型にすればよい。当社の得意な形に案件を合わせようとすることが、失敗のもとです。

本記事では、ウォーターフォール開発の定義と語源、6工程の流れと各工程で発注者が決めること、開発工程とテスト工程を対応させるV字モデル、手戻りが起きる典型3パターンと変更管理の手順、向く案件・向かない案件と日本で使われ続けている3つの理由、よくある質問の順に解説します。工程一覧とV字モデルの対応表は、そのまま社内説明の資料に使える形にしました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社の主力はラボ型(準委任)で、要件が動く案件を週次の判断で回す形です。それでも、要件が確定していて検収の条件も決まっている案件なら、ウォーターフォールで請負にできる会社を勧めます。この記事を読み終えるころには、自社の案件がどちらの前提に合うのかを、自分の言葉で説明できるはずです。

ウォーターフォール開発とは——「滝」の語源と、前工程に戻らないという前提が意味すること

ウォーターフォール開発は、システム開発の工程を上流から下流へ順番に進め、前の工程が完了してから次の工程に入る開発手法です。名前も進め方も広く知られている一方で、「前工程には戻れない」という説明だけが独り歩きしている印象があります。まずは定義と語源、そして「戻らない」という前提が実務では何を意味するのかを、順に整理します。

定義: 工程を一方向に進め、前工程の成果物を承認してから次に進む開発手法

ウォーターフォールモデルの定義は、開発活動を線形の連続したフェーズに分割し、各フェーズが前のフェーズの成果物に依存する形で進める、というものです。要件定義の成果物である要件定義書がなければ基本設計は始められず、基本設計書がなければ詳細設計は書けません。成果物が次の工程の入力になるという依存関係が、工程の順序を決めています。

この依存関係があるため、原則として前工程が完了しないと次工程に進みません。設計の途中でプログラミングを始めるといった並行作業は行わず、前工程の成果物の品質を段階的に確保しながら下流へ流していきます。進捗はガントチャートなどの線表で管理し、工程の完了をもって「何%まで進んだ」と測ります。この管理のしやすさが、ウォーターフォールが最も評価されている点です。

語源と歴史——1968年のNATO会議、1970年のロイス論文、「ウォーターフォール」という呼称の初出

ウォーターフォール(waterfall)は文字どおり「滝」を意味します。水が上から下へ一方向に落ちるように工程が流れることから、この名前が付きました。歴史をたどると、区切りになるのは1968年、NATOが後援した国際会議です。のちにソフトウェア工学に関する最初の会議と位置づけられ、「いわゆるソフトウェア危機」が中心的な問題として挙げられた場でした。ソフトウェア開発を職人芸から工業製品の製造過程に近づけるため、開発をいくつかの工程に分け、各工程の終了を意味する文書を作って進捗を管理する、という考え方が示されました。

モデルの起源とされるのは、1970年にW.W.ロイスが発表した論文「Managing the Development of Large Software Systems」です。ただし、この論文に「ウォーターフォール」という語は出てきません。この呼び名を広めたのは、1976年のT.E.BellとT.A.Thayerによる論文「Software Requirements: Are They Really a Problem?」だと整理されています。

ここで押さえておきたいのは、ロイス自身は厳密な一方通行のやり方を勧めてはいなかったという点です。学習と改善のために工程を繰り返すことを前提に置いていた、と整理されています。一度も後戻りしない一方通行のモデルは、後から単純化されて広まったイメージであって、原案そのものではありません。

「戻らない」の正確な意味——戻れないのではなく、戻り方を管理する

実務でのウォーターフォールは、「前工程に戻ってはいけない」という禁止ではありません。正確には、次の2つの約束を指します。

1. 前工程の成果物を発注者が承認してから、次工程に進む(承認していないものを下流に流さない)
2. 前工程に戻る必要が出たら、変更管理という公式の手続きを通す(現場の判断で黙って直さない)

前工程への後戻りはスケジュール遅延の原因と評価されるため、前工程の完了要件を徹底して品質を高め、後戻りの発生率を下げる。そのうえで後戻りが発生する場合は、変更管理によって公式に決定し、影響範囲の反映まで確実にフォローする——これがウォーターフォールの標準的な運用です。「戻れない」ではなく「戻り方が決まっている」と理解すると、発注側の身構えはかなり解けるはずです。

この前提が生むもの——工程単位の進捗、責任の分界、引き継げる設計書

工程を区切って承認するという前提は、3つのものを生みます。1つ目は工程単位の進捗で、「基本設計完了」という言葉が関係者全員に同じ意味で伝わります。2つ目は責任の分界で、複数のベンダーや部門が関わる案件でも、どの工程の誰が何に責任を持つかが成果物とともに残ります。3つ目は引き継げる設計書で、担当者が異動しても、5年後に保守を別の会社が引き継いでも、設計の意図を文書からたどれます。

この3つを必要としない案件では、ウォーターフォールの利点はほとんど働きません。逆に、この3つが不可欠な案件では、他の手法で代替するのが難しいというのが実情です。では、その工程は具体的にどう流れ、発注者は各工程で何を決めることになるのか。次章で一覧にします。

ウォーターフォール開発の工程の流れ——6工程と、各工程で発注者が決めること

ウォーターフォール開発の工程は、要件定義から運用・保守まで一方向に流れます。工程の分け方は会社や案件によって5〜9段階と幅がありますが、発注側が押さえるべき骨格は6つです。ここでは各工程で何が作られ、発注者が何を決め、どうなれば「完了」とみなすのかを一覧にします。ベンダーの作業表としてではなく、自社が判を押す場所の地図として読んでください。

工程一覧——各工程の作業・成果物・発注者が決めること・完了の判定

工程の数は絶対ではありません。テストを単体・結合・総合・受入の4つに分けて9工程とする分け方もあれば、設計を1つにまとめて5工程とする分け方もあります。重要なのは段階の数ではなく、どの成果物を誰がいつ承認するかが、着手前に決まっているかという点です。

上流工程(要件定義・基本設計)——発注者の仕事が最も重い区間

ウォーターフォールで発注側の負荷が最も高いのは、要件定義と基本設計です。この2工程で「何を作るか」と「利用者からどう見えるか」が確定し、以降の工程はそれを実現する作業になります。ここで決めきれなかったことは、下流で決めるのではなく、下流で「手戻り」として跳ね返ってきます。

現場でよく起きるのは、要件定義を開発会社に任せきりにしてしまうケースです。業務を知っているのは発注側であり、開発会社は業務要件を代わりに決められません。決める材料(現行の業務フロー、例外処理、繁忙期の運用、既存システムの制約)を出せるのは発注側だけです。要件定義そのものの進め方は「要件定義の進め方」の記事、工程全体での位置づけは「要件定義とは」の記事、基本設計書で何が決まるかは「基本設計とは」の記事で詳しく扱っています。

下流工程(詳細設計・実装・テスト・運用保守)——発注者はレビューと受入に回る

詳細設計から実装までは開発会社が主導する区間で、発注側の作業は進捗の確認と質問への回答が中心になります。ただし「任せきり」とは違います。仕様の解釈で迷った点はこの区間で必ず質問が来るため、回答が遅れると開発が止まります。週次で判断できる担当者を置いておくことが、この区間の隠れた要件です。進捗の測り方と報告の粒度については「進捗管理とは」の記事で整理しています。

テスト工程に入ると、発注側の負荷が再び上がります。受入テストは発注者が主体となって実施し、その合格が検収につながるためです。ここで初めて動くシステムを見ることになるので、テスト工程の前半で想定外に気づく事態を避ける設計が要ります。それが次章で扱うV字モデルです。

工程間のゲート——「承認」が進捗の単位になるということ

ウォーターフォールでは、工程と工程の間にゲート(関門)があります。ゲートを通す条件は「成果物が完成していること」ではなく「成果物が承認されていること」です。ここを曖昧にしたまま次工程に進むと、承認していない前提の上に3か月分の作業が積み上がり、後から覆せなくなります。

逆に言えば、発注側がゲートで止める権限を持っているのがウォーターフォールの利点です。「まだ承認できない」と言える場が、工程の数だけ用意されている。この権限を使わずに進めてしまう発注者が多いことこそ、手戻りの最大の温床ではないでしょうか。

V字モデル——開発工程とテスト工程の対応、受入テストの準備は要件定義から始まる

ウォーターフォールを検索すると必ず出てくるのがV字モデルです。名前は知られている一方で、「ウォーターフォールとは別の手法」と誤解されていることが少なくありません。V字モデルは進め方を定義するものではなく、どの工程で作ったものを、どのテストで検証するのかを対応させる品質管理の考え方です。発注側にとっては、受入テストの準備をいつ始めるかを決める地図になります。

V字モデルとは——工程を折り返して、検証の基準を対応させる考え方

V字モデルは、左側に開発工程(要件定義・基本設計・詳細設計)、底に実装、右側にテスト工程(単体テスト・結合テスト・システムテスト・受入テスト)を配置し、全体をアルファベットのVの字で表した図です。左側の工程を下るにつれて設計は具体化し、右側を上るにつれて検証の範囲は広がります。同じ高さにある左右の工程が、互いに対応します。

この形が整理された背景には、ウォーターフォールの品質課題があります。設計と実装を一通り終えてからテストを始めると、設計の誤りや要件の漏れが後工程で初めて見つかり、修正のコストが跳ね上がる。そこで、左側の各工程を作る時点で「これはどのテストで検証されるのか」を決めておき、品質を計画的に作り込む考え方が求められました。

開発工程とテスト工程の対応関係

対応は一対一を基本としつつ、実務ではプロジェクトの定義によって結合テストとシステムテストの境界が重なることもあります。ただし、テストの基準は必ず左側の成果物にあるという原則は変わりません。基準となる文書がないテストは、仕様を満たしているかの検証ではなく、単なる動作確認で終わります。

発注者がやること——受入テストの観点を要件定義の時点で書き出す

この表を発注側の視点で読み替えると、やるべきことは1つに絞られます。受入テストの観点を、要件定義の時点で書き出しておくことです。要件定義書に「在庫が引き当てられること」と書いただけでは、受入テストで何を確認すればよいか分かりません。「同一商品に対して2件の受注が同時に入った場合、先に確定した受注に引き当て、後続は引当待ちとする」と書けば、そのままテストケースになります。

測れない一文を、判定できる一文に直す。この作業を要件定義でやっておけば、受入テストの準備は工程の終盤ではなく最初から進んでいることになります。ペルソナの例で言えば、「受入テストは御社でお願いします」と言われてから慌てる事態は、これで避けられます。テストをどこまで外部に任せられるかは「テスト 外注」の記事で整理しています。

V字モデルとウォーターフォールは対立しない——進め方と品質管理は別の話

V字モデルとウォーターフォールは、置き換え可能な選択肢ではありません。ウォーターフォールが工程の進め方を定義するのに対し、V字モデルは各工程の成果物に対応する検証を定める役割を持ちます。ウォーターフォールの流れで進めながらV字モデルの考え方を取り入れる、というのが実務での標準的な組み合わせです。

当社が開発を請け負う場合も、考え方は同じです。日本人PMが設計レビューを行い、Gitのプルリクエストによるコードレビューを標準化し、リリース前にダブルチェックを入れる。この3つはV字の右側を厚くするのではなく、左側の成果物と右側の検証を対応させるための仕組みです。テスト工程で品質を作ろうとすると必ず間に合わなくなる——これはウォーターフォールでもそれ以外でも変わらない教訓です。

手戻りが起きる典型3パターンと、ウォーターフォールでも変更に対応する方法

ウォーターフォールの弱点として必ず挙がるのが、仕様変更に弱いことと、手戻りの工数が膨らむことです。ただ、私が約100社の相談を受けてきた経験では、手戻りそのものが問題になった案件はほとんどありません。問題になるのは、変更の扱い方が着手前に決まっていなかった案件です。まず手戻りが起きる典型を3つに整理し、そのうえで変更に対応する手順を示します。

手戻りが起きる典型3パターン

私が受ける手戻りの相談に共通するのは、2番目と3番目です。とくに3番目は影響が大きく、「月末に1,000人が同時に使う」という前提が後から出てくると、設計の根幹をやり直すことになります。1番目は要件定義書のレビューで防げますが、2番目と3番目は文書のレビューだけでは見つかりません。動かして見せるか、数値で書かせるかのどちらかが要ります。

変更管理の4ステップ——変更要求から、ベースラインの更新まで

ウォーターフォールでも仕様は変更できます。できないのではなく、手続きを通す必要があるということです。標準的な流れは次の4ステップです。

1. 変更要求(CR)を文書で出す — 誰が、どの成果物の、どこを、なぜ変えたいのかを1枚に書く。口頭や会議での発言は変更要求になりません
2. 影響分析を行う — 変更が及ぶ成果物(要件定義書・設計書・テスト仕様書・テストケース)、追加工数、スケジュールへの影響を開発会社が算定する
3. 承認する、または見送る — 発注側の責任者が、影響分析の結果を見て採否を決める。見送った要求は次期改修の候補として記録に残す
4. ベースラインを更新する — 承認された変更を、関係するすべての成果物に反映する。設計書だけ直してテスト仕様書を直し忘れる、という抜けが最も多い事故です

この4ステップを契約前に取り決めておけば、変更は事故になりません。逆に、手続きを決めずに「言った・言わない」で進めると、検収の場で揉めます。変更にいくらかかるのか、どこからが追加費用なのかという線引きは「仕様変更 追加費用」の記事で詳しく整理しています。

部分的に反復を混ぜる——プロトタイプ、段階リリース、上流だけ固める組み立て

もう1つの現実的な対応が、ウォーターフォールの中に反復の要素を部分的に入れる方法です。実務でよく使われるのは次の3つです。

• プロトタイプ: 基本設計の段階で画面デモや試作を作り、利用部門に触ってもらう。パターン2の手戻りを設計工程に前倒しできる
• サブシステム分割: 大規模な案件で全システムを同じスケジュールにせず、業務単位で分割して工程を回す。先行するサブシステムで見つかった仕様の問題を、後続では早い工程で直せる
• 上流固定・下流反復(ハイブリッド): 要件定義と基本設計はウォーターフォールで固め、実装以降は短いサイクルで確認しながら進める。要件の一部だけが流動的な案件に合う組み立て方です

反復を混ぜること自体は珍しい話ではありません。ただし、契約と検収の条件が「一括請負・完成物で検収」のままだと、反復の自由度は実質的に使えません。反復の要素を入れるなら、契約形態もあわせて設計する必要があります。契約の選び方は「準委任 請負 違い」の記事と「アジャイル開発 外注」の記事で扱っています。

手戻りを減らす仕掛けは上流にしか置けない

3つのパターンをもう一度見ると、対策はすべて要件定義と基本設計に集まっています。テスト工程を厚くしても、テストで見つかるのは「設計どおりに作られていないこと」であって、「設計そのものが業務に合っていないこと」は見つかりません。ウォーターフォールで手戻りを減らす仕掛けは、上流にしか置けないというのが実情です。

ウォーターフォールが向く案件・向かない案件と、日本で使われ続けている理由——当社の位置づけ

ここまでの内容を、自社の案件に当てはめる段階に入ります。手法に優劣はありません。判断すべきなのは「自社の案件が、工程を区切って承認するという前提に合うか」の一点です。ここでは3つの判断軸で向き不向きを整理し、日本のシステム開発でウォーターフォールが使われ続けている理由と、当社の立ち位置を率直に書きます。

判断軸3つ——要件の確定度、関係者の多さ、保守の長さ

3つのうち2つ以上が左側に当てはまるなら、ウォーターフォールを選んで問題ありません。右側が2つ以上なら、反復型を検討したほうが結果的に早く安く着地します。1対2のように割れる場合は、前章のハイブリッド(上流をウォーターフォールで固め、実装以降を反復にする)が現実的な解になります。

なお、アジャイルとの違いを一覧で比べたい場合は、契約形態・体制・スプリント運用まで含めて整理した「アジャイル開発 外注」の記事をご覧ください。本記事では比較そのものには踏み込みません。

日本のシステム開発で使われ続けている3つの理由

「ウォーターフォールはもう古い」という言説は根強くあります。それでも、当社が約100社の相談を受けてきた範囲では、官公庁・金融・製造業の基幹システムで採用が続いています。そこには手法の優劣とは別の理由があります。

1つ目は責任の分界です。複数のベンダーと部門が関わる案件では、誰がどの成果物に責任を持つかを文書で確定させる必要があり、工程の区切りと承認がその役割を担っています。2つ目は検収と予算の制度です。年度予算で発注し、完成物の検収をもって支払う仕組みは、工程と成果物が事前に定義されていることを前提に組まれています。手法だけを先に変えることはできません。3つ目は長期保守の引き継ぎで、10年以上動く基幹システムでは、当時の担当者がいなくなった後に設計書が唯一の手がかりになります。

この3つは、技術の新しさでは解決しない制度と組織の要請です。だからこそ、ウォーターフォールは「古い手法」ではなく「特定の条件では今も最適な手法」として残っています。

当社の位置づけ——ラボ型(準委任)が主力でも、合う案件にはウォーターフォールを勧める

当社TALENTBASE VIETNAMの主力は、ホーチミンの専属チームを月額で確保するラボ型(準委任)です。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインし、協力会社を介さないため仲介マージンがありません。最小構成は日本人PMフロント+2〜3人月で月額約80万円〜、1名から契約でき、最短2週間で開始できます。公開単価は実務3年目安で1,500USD(約22.5万円/1USD=150円換算目安)、ブリッジSEで3,000USDです。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

この体制は、要件が動く案件に向いています。介護記録SaaS「CareViewer」では、日本語ブリッジSE1名とフルスタックエンジニア2名の体制で、週次の優先順位判断を回しながら継続開発を行い、コストは従来の半分以下になりました。一方で、「要件は確定していて、検収の条件も社内で決まっている」という案件を伺ったときは、ウォーターフォールで請負にできる会社を勧めます。当社の得意な形に案件を合わせようとするのが、失敗のもとだからです。

オフショアでウォーターフォールを回すときの注意——仕様書の粒度と時差

オフショアでウォーターフォールを採用する場合、国内以上に仕様書の粒度が効いてきます。工程を区切る運用は、文書で伝わることが前提だからです。曖昧な日本語表現、暗黙の業務ルール、図と文章の食い違いは、そのまま実装のずれになります。粒度の決め方は「オフショア開発 仕様書 書き方」の記事で具体例つきに整理しています。

時差についてはベトナムは日本の2時間遅れで、午前中から同じ時間帯で作業できます。祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)、2026年のテト(旧正月)休暇は2月14日〜22日で、この期間をまたぐ工程スケジュールは事前に織り込む必要があります。工程を区切る手法ほど、休暇と承認のリードタイムが日程に効いてくる——発注前に確認しておきたい点です。自社の案件はどちらの前提に近いでしょうか。

ウォーターフォール開発に関するよくある質問

ウォーターフォール開発について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での説明にもお使いください。

Q1. ウォーターフォール開発はもう古い手法ですか?

古いかどうかではなく、案件の条件に合うかどうかで判断してください。1970年代に提唱された手法ですが、当社が相談を受ける案件を見るかぎり、官公庁・金融・製造業の基幹システムなど、要件が確定していて関係者が多く、長期の保守を前提にする案件では現在も採用が続いています。逆に、要件が流動的な新規事業では不向きです。

Q2. 工程は何段階に分けるのが一般的ですか?

5〜9段階と幅があり、絶対の正解はありません。発注側が押さえるべき骨格は、要件定義・基本設計・詳細設計・実装・テスト・運用保守の6つです。テストを単体・結合・総合・受入の4つに分ければ9工程になります。段階の数より、どの成果物を誰がいつ承認するかを着手前に決めておくことが実務上の要点です。

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

役割が違います。ウォーターフォールは工程の進め方を定義するもので、V字モデルは各工程の成果物とテストの対応関係を定める品質管理の考え方です。対立する選択肢ではなく、ウォーターフォールの流れで進めながらV字モデルの考え方を取り入れるのが一般的な組み合わせになります。

Q4. 途中で仕様を変えられますか?

変えられます。ただし変更管理の手続き(変更要求の文書化→影響分析→承認→関係する全成果物の更新)を通す必要があり、追加の工数と期間が発生します。着手前に、変更要求の出し方・影響分析の期限・誰が承認するかを契約で決めておいてください。手続きを決めずに進めた案件ほど、検収で揉めます。

Q5. 小規模な開発でもウォーターフォールは使えますか?

使えます。1〜2名の小規模開発でも、要件が固まっていれば工程を区切る進め方は有効です。ただし成果物の作成と承認に相応の工数がかかるため、小規模かつ要件が流動的な案件では、文書作成の負荷が成果に見合わなくなります。当社のように1名から・最短2週間で開始し、増員は約1週間、縮小と交代は1か月単位という体制なら、上流だけ工程を区切り、実装以降は週次で優先順位を見直す組み立ても選択肢。

まとめ: 工程を区切って承認できる案件か——要件の確定度・関係者の多さ・保守の長さで決める

ウォーターフォール開発は、要件定義・基本設計・詳細設計・実装・テスト・運用保守の6工程を一方向に進め、前工程の成果物を承認してから次に進む手法です。「前工程に戻らない」とは戻れないという意味ではなく、戻るときは変更管理という公式の手続きを通す、という運用上の約束を指します。1970年のロイス論文が起源とされますが、その原論文にも前工程への後戻りは書かれていました。

品質を作り込む仕掛けはV字モデルにあります。要件定義は受入テスト、基本設計はシステムテスト、詳細設計は単体テストの基準になるため、受入テストの観点は要件定義の時点で書き出しておくものです。手戻りが起きる典型は、要件の言語化不足・画面を見て初めて出る要望・非機能要件の後出しの3つで、対策はいずれも上流工程にしか置けません。変更管理の4ステップ(変更要求の文書化→影響分析→承認→ベースラインの更新)を着手前に決めておけば、仕様変更は事故になりません。

自社の案件に合うかどうかは、要件を着手前に確定できるか、関係者と部門が多いか、長期の保守と引き継ぎが要るか、の3点で判断できます。2つ以上当てはまるならウォーターフォール、当てはまらないなら反復型、割れるなら上流だけ固めるハイブリッドです。反復型の契約と体制についてはアジャイル開発の外注、工程全体での要件定義の位置づけは要件定義とはもあわせてご覧ください。当社の主力はラボ型(準委任)ですが、要件が確定している案件にはウォーターフォールで請負にできる会社を勧めます。現在の体制と要件をお聞かせいただければ、どちらの前提に合うかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。