【ウォーターフォール開発】6工程とツール比較5選

約 20 分で読めます

ウォーターフォール開発とは、要件定義から保守までの6工程を、前の工程を完了させてから次へ進める開発手法です。本記事では6工程の中身、アジャイルとの違い、向き不向き、管理ツール5選までを整理します。

1. ウォーターフォール開発とは ｜ 定義と全体像を一文でつかむ

ウォーターフォール開発とは、要件定義 → 外部設計 → 内部設計 → 実装 → テスト → リリース・保守という6つの工程を直列に並べ、前の工程の成果物が承認されてから次の工程に着手するシステム開発手法です。英語では Waterfall model（ウォーターフォール・モデル）と呼ばれ、上流から下流へ水が落ちるように後戻りしない進め方が名前の由来になっています。

この考え方の原型は、半世紀以上前にウィンストン・ロイス氏が大規模ソフトウェア開発について書いた論文にさかのぼります。この論文自体は「一方通行で進めると危ない」という問題提起を含んでいましたが、それでも直列モデルが定着したのは、工程を区切ると見積もり・契約・検収が組み立てやすいという発注側の事情に強く合致したからです。

ここまでは定義の話です。実務で差がつくのは「6工程それぞれで何を作り、どの成果物で次工程へのゴーサインを出すか」と「工程をまたいだ遅延をどう検知するか」の2点です。

2. 開発工程の6ステップ ｜ 各工程の成果物まで押さえる

ウォーターフォール開発では、工程の区切りは「作業が終わったかどうか」ではなく「成果物がレビューを通ったかどうか」で判定します。成果物を先に決めておくと、進捗会議が「だいたい8割です」という曖昧な報告にならずに済みます。

上流工程でつまずくと全部に響く

6工程のうち、後工程への影響が最も大きいのは①と②です。特に要件定義の曖昧さは、設計・実装・テストのすべてに伝播します。「あとで詰めましょう」と保留した項目が、結合テストの段階で仕様の食い違いとして表面化するのが典型的な失敗パターンです。要件の洗い出しの段階で、機能要件だけでなく性能・可用性・セキュリティといった非機能要件まで文書化しておくことが、手戻りを減らす最大の投資になります。

工数配分をあらかじめ決めておく

計画時に工程ごとの工数比率を決めておくと、途中で「設計が長引いている」ことに気づけます。例として、12か月・10名規模の基幹システム更新プロジェクトを想定して配分を考えてみます。

この配分はあくまで想定の目安ですが、比率を先に置いておくと「設計が計画の25%を超えた時点でアラート」という運用ができます。実績値の積み上げ方は工数の管理の考え方が参考になります。工程単位の作業を実行可能な単位まで割るときは、作業分解図の手法で階層化しておくと、後述するガントチャートにそのまま流し込めます。

V字モデルで見るとテストの準備が早くなる

ウォーターフォール開発を語るとき、製造業や組み込み開発の現場でよく出てくるのがV字モデルです。左側に要件定義・外部設計・内部設計を、右側に単体テスト・結合テスト・総合テストを配置し、同じ高さの工程同士を対応づけるという考え方です。

V字モデルの実務的な価値は、「要件定義書を書いた時点で総合テストの観点も書ける」という点にあります。テスト仕様書の作成をテスト工程まで先送りせず、対応する設計工程と同時に着手する。これだけでテスト期間の圧縮と、仕様の抜け漏れ検知の早期化が同時に進みます。

3. アジャイル開発との違い ｜ 比較表で判断軸をそろえる

「ウォーターフォールとアジャイルはどちらが優れているか」という問いは、実務ではあまり意味を持ちません。違いは優劣ではなく、計画優先か、適応優先かという前提の置き方にあります。

なお、アジャイルを選べば安心というわけではありません。アジャイルがうまくいかないケースの多くは、手法そのものではなくプロダクトオーナーが決めきれないことに起因します。要件が曖昧なまま「走りながら考える」を言い訳にすると、スプリントごとに方向が揺れ、結果的にウォーターフォール以上に手戻りが増えます。どちらの手法でも、目標の設定方法を先に固めることは避けて通れません。

4. メリット・デメリット ｜ 現場で何が起きるかで理解する

メリット3つ

① 計画と予算が立てやすい：工程と成果物が事前に確定するため、要員計画と支払いスケジュールを先に組めます。年度予算で動く組織や、稟議に見積根拠が必要な案件では、この一点だけで採用理由になります。

② 進捗管理がしやすい：「詳細設計書が全画面の何%完成したか」のように、進捗を成果物ベースで測れます。曖昧な自己申告が入り込みにくい構造です。具体的な報告フォーマットは進捗の共有の型に沿って整えると、関係者間で解釈がぶれません。

③ 品質を担保しやすい：工程ごとにレビューと承認のゲートがあるため、第三者チェックが必ず入ります。監査対応やトレーサビリティの証跡が求められる領域では、この記録そのものが納品物になります。

デメリット3つ

① 手戻りコストが大きい：テスト工程で要件の誤解が見つかると、設計書・コード・テスト仕様書をすべて改訂することになります。上流に戻るほど修正の波及範囲が広がるのが構造的な弱点です。

② 仕様変更に弱い：変更要求は変更管理プロセスを通す必要があり、承認までのリードタイムが発生します。市場環境が動く前提のプロダクトでは、この遅さが致命的になり得ます。

③ リリースまでの期間が長い：動くものが出てくるのが終盤のため、利用部門がイメージと違うと気づくタイミングも遅れます。プロトタイプ画面を早期に見せる、といった補完策が実務では必須です。

2つの対照的なケースで考える

製造業の基幹システム刷新を想定した場合：会計・在庫・生産の連携仕様は法制度と社内規程で固まっており、要件が動く余地が小さい。複数ベンダーの分担と検収も必要です。この条件ではウォーターフォールが素直に機能します。

新規SaaSのMVP検証を想定した場合：何が価値になるかを市場に聞きながら決める段階で、6か月分の詳細設計を先に書いても、書いた瞬間から陳腐化していきます。ここでウォーターフォールを選ぶと、作り込んだ機能が使われないというコストが発生します。

5. 向き・不向きの判断 ｜ 自分の案件はどちらかを決める

判断に迷ったら、次の観点で自分のプロジェクトを当てはめてみてください。

向いているケース

• 要件が事前に確定している（既存業務の置き換え、システム移行、インフラ更改）
• 金融・医療・公共など、規制対応と監査証跡が求められる
• 複数ベンダーや協力会社に工程を分担させ、契約単位で検収する
• 法改正や会計年度など、外部要因でリリース日が動かせない

向いていないケース

• 要件が流動的な新規事業や、ユーザー行動を検証しながら仕様を決める段階
• ターゲットが定まっていないMVP開発
• 少人数で、企画から開発まで同じチームが担うプロダクト開発

なお、向いているケースであっても、ステークホルダーの整理が甘いと要件定義の承認自体が長期化します。誰が最終的に仕様を決裁するのかを、着手前に一枚の表にしておくことをおすすめします。

6. ツール比較5選 ｜ 進捗と依存関係をどう見せるか

ウォーターフォール開発の成否は、実は工程の理屈より運用ツールの選択に左右されます。理由は3つあります。工程間の依存関係が可視化されないと遅延が連鎖する、成果物（文書）が散在すると承認の証跡を追えない、そして進捗が個人の口頭報告に依存すると数字が信用できなくなる、という点です。

monday.com ｜ ガントと依存関係を1画面で扱う

monday.comは、ボード（表形式のタスク一覧）をそのままガントチャートやカレンダーに切り替えて表示できるプロジェクト管理ツールです。ウォーターフォール開発との相性がいいのは、工程の親子関係と依存関係をそのまま画面に落とせる点にあります。

具体的な組み立て方はこうです。まずグループを「要件定義／外部設計／内部設計／実装／テスト／リリース」の6つに切り、各グループの下に成果物単位のタスクを置きます。「基本設計書（在庫モジュール）」のように成果物名でタスクを作ると、進捗が作業時間ではなく成果物ベースで測れるようになります。

次にタスク間に依存関係（前タスクが終わらないと開始しない設定）を引くと、設計が3日遅れた瞬間に後続の実装・テストの予定日が連動して動きます。工程をまたいだ遅延が、会議を待たずにガント上で見える状態になるわけです。

さらに、ステータスが「レビュー待ち」のまま一定期間動かないタスクを担当者に通知する、といった自動化ルールを設定しておくと、承認の滞留を早期に拾えます。ただし自動化は無料プランでは利用できず、スタンダードプラン以上の機能です。テンプレートも用意されているため、ゼロから列設計をする必要がありません。

弱点も挙げておきます。ガント・タイムラインビューもスタンダードプラン以上の機能で、無料プランは最大2ユーザーまでです。つまり「無料のまま5人でガントを使う」という運用はできません。（それでも構造を確かめるだけなら、monday.comの無料プランは2ユーザーまでクレジットカード不要で試せます。有料機能も14日間の無料トライアルで確認できます。）

1つだけ試すなら、monday.comから始めてください。

そのほかの選択肢を正直に比較する

ClickUp：ClickUpはガントチャート、ドキュメント、タスク管理を1つに詰め込んだツールです。無料のFree Foreverでもタスクを作成して運用できますが、ストレージ容量や一部機能の利用回数に上限があるため、設計書やスクリーンショットを多く扱う開発案件では早めに有料プランの検討が必要になります。有料はUnlimitedが年間払いでUS$7/ユーザー/月、BusinessがUS$12/ユーザー/月。Businessでは自動化を月5,000回まで実行できます。機能量は魅力的ですが、設定項目が多く、非エンジニアを含む混成チームでは初期の学習コストが高くつきます。最新のプラン条件は公式サイトでご確認ください。

Notion：Notionは要件定義書・設計書・議事録といった文書を一元管理したいチームに向きます。タイムラインビューは全プランで利用でき、フリープランはUS$0、プラスがUS$10、ビジネスがUS$20（いずれも年間払い表示）。ただしフリープランは外部ゲスト10名・ファイルアップロード5MB・ページ履歴7日という制限があり、大量の設計書を扱うなら有料前提で考えるべきです。厳密な依存関係管理は苦手なので、文書はNotion、進捗はガント系ツール、という併用が現実的です。

Backlog：Backlogは課題管理とGit・Subversionが統合されており、日本語UIとサポートの安心感があります。国内のシステム開発現場で採用例が多いツールです。料金はスペース単位のプラン制（プランごとにユーザー数上限あり）のため、公式サイトで最新の情報をご確認ください。開発者中心のチームには馴染みますが、経営層向けの俯瞰ビューは弱めです。

Jira：アジャイル開発向けという印象が強いものの、ロードマップ機能を使えば工程単位の計画も管理できます。課題タイプやワークフローを細かく定義できる反面、設定の自由度が高く、運用ルールを決める管理者の負担が大きくなりがちです。開発部門以外のメンバーが日常的に閲覧する用途には向きません。

Redmine：オープンソースのため、自社サーバーに導入すればライセンス費用はかかりません。チケット管理とガントチャートを標準で備えており、ウォーターフォールの工程管理にそのまま使えます。ただしサーバーの構築・バックアップ・プラグイン更新を自前で担う前提になるため、情報システム部門の運用工数を見込んでおく必要があります。

Excel・スプレッドシート：初期費用ゼロで自由度が高い一方、依存関係の自動再計算がなく、遅延が発生するたびに手作業で全行を直すことになります。ファイルが複数バージョンに分裂しやすい点も含め、5人を超えるプロジェクトでは早い段階で限界が来ます。

ツール選定チェックリスト

導入前に、次の5項目を自分の言葉で答えられるか確認してください。

1. チーム規模：協力会社を含めて何人がツールにアクセスするか（ライセンス費用の総額はここで決まります）
2. 予算の出どころ：月額課金を通せる予算区分があるか、年度予算に組み込む必要があるか
3. 既存ツールとの連携：GitやSlack、既存の勤怠・工数システムとつなぐ必要があるか
4. ドキュメント要件：承認履歴を証跡として残す必要があるか（監査対応なら必須要件になります）
5. 導入のしやすさ：非エンジニアのメンバーが説明なしで使えるか

判断の目安としては、文書作成が中心の1〜数名ならNotionの無料プラン、部門をまたいで数人〜十数人で工程の依存関係を追うならmonday.com、開発者中心でスプリント運用も併用するならClickUpかBacklog、十数人以上で複数プロジェクトを横断管理するならmonday.comのプロプラン以上が現実的な選択肢になります。工程単位の管理設計そのものを見直したい場合は、工程の管理方法の考え方も合わせて確認しておくとツール選びの軸がはっきりします。

7. 時代遅れなのか ｜ ハイブリッド開発という第三の答え

「ウォーターフォールは時代遅れ」という言葉をよく見かけますが、実態はもう少し複雑です。規制産業や大規模インフラでは、契約・監査・多ベンダー体制という制約から、依然として直列モデルが主流です。一方でWebサービス領域ではアジャイルが標準になりました。つまり過去のものになったのではなく、適用領域が絞り込まれたというのが正確な表現です。

ハイブリッド開発（Wagile）という現実解

現場で増えているのが、両者を工程単位で使い分けるやり方です。システムインテグレーターが基幹システムを刷新する場面を想定して考えてみます。

要件定義と外部設計は従来どおりウォーターフォールで固め、契約・予算・全体スケジュールの基盤を作ります。その後の実装とテストは2週間スプリントで回し、利用部門に画面を早めに見せながら細部を調整する。この形にすると、「全体計画は動かさないが、画面の使い勝手の指摘は早期に吸収できる」という状態が作れます。

ハイブリッド運用で鍵になるのは、スプリントの区切りと全体スケジュールの節目をずらさないことです。実装がスプリント単位で進んでも、外部に約束したリリース日は動きません。そのためマイルストーン管理を全体計画側で固定し、スプリントの成果をそこへ積み上げていく設計にします。全体の時間軸を俯瞰したいときはタイムライン表示を併用すると、スプリントの粒度と全体計画の粒度を同じ画面で扱えます。

なお、ウォーターフォールとアジャイルの中間には、スパイラル型やプロトタイプ型といった手法も存在します。リスクの高い部分だけを反復的に検証する、という発想はハイブリッド開発とも重なります。

まとめ

ウォーターフォール開発について、押さえておくべき要点を整理します。

• 定義：要件定義・外部設計・内部設計・実装・テスト・リリース／保守の6工程を直列に進める手法。工程の区切りは作業完了ではなく成果物の承認で判定する
• V字モデル：設計工程とテスト工程を対応づけることで、テスト仕様書の作成を前倒しできる。これが手戻り削減に直結する
• アジャイルとの違い：優劣ではなく「計画優先か適応優先か」。要件が確定していて規制対応が必要ならウォーターフォール、探索段階ならアジャイル
• 弱点：手戻りコスト、仕様変更への弱さ、リリースまでの長さ。プロトタイプの早期提示や段階リリースで補完する
• 現在地：時代遅れではなく適用領域が絞られた。上流はウォーターフォール、実装以降は反復というハイブリッドが現実解になりつつある

次の一手として、この記事の工程別成果物の表をそのままツールに移してみてください。表の「工程」列がボードのグループ名に、「成果物」列がタスク名に、「主な作業」列がサブタスクになります。monday.comであれば、その状態からガントビューに切り替えるだけで依存関係を引ける画面になり、設計の遅れがテスト開始日にどう響くかがその場で見えるようになります。まず要件定義と外部設計の2グループだけ作って、依存関係を1本引いてみるところから始めるのが、いちばん失敗しない入り方です。タスクの切り方に迷ったらタスクの粒度の考え方を参考にしてください。

よくある質問

ウォーターフォールとアジャイル開発の違いは何ですか？

ウォーターフォールは工程を直列に進め、前工程の成果物が承認されてから次へ移ります。アジャイルは1〜4週間のスプリントを反復し、動くソフトウェアを段階的にリリースします。違いの本質は「計画を先に固めるか、変化に合わせて適応するか」という前提の置き方です。要件が確定していて監査証跡が必要な案件はウォーターフォール、探索段階のプロダクトはアジャイルが適します。

ウォーターフォール開発の手順は？

要件定義、外部設計（基本設計）、内部設計（詳細設計）、実装、テスト、リリース・保守の6工程が基本形です。各工程の終わりには要件定義書・設計書・テスト仕様書といった成果物があり、そのレビュー承認が次工程への着手条件になります。工程の切り方と成果物の対応は本文の表にまとめています。

ウォーターフォール型の欠点は何ですか？

主な欠点は3つです。第一に、テスト工程で要件の誤解が見つかると設計書・コード・テスト仕様書をすべて改訂することになり、手戻りコストが大きくなります。第二に、仕様変更に変更管理プロセスを通す必要があり対応が遅くなります。第三に、動くものが出るのが終盤のため、利用部門の認識ずれの発見が遅れます。

アジャイル開発が失敗する理由は何ですか？

手法そのものより、意思決定者が仕様を決めきれないことが原因になるケースが多く見られます。プロダクトオーナーが優先順位を確定しないままスプリントを回すと、毎回方向が揺れて手戻りが増えます。また、ドキュメントを最小限にするという原則を「何も書かない」と誤解すると、引き継ぎと保守の段階で情報が失われます。

ウォーターフォール開発は英語で何と言いますか？

Waterfall model（ウォーターフォール・モデル）、または Waterfall development と表記します。上流から下流へ水が流れ落ちる様子になぞらえた呼び方です。設計工程とテスト工程を対応づけたV字モデルは V-Model と表記されます。

ウォーターフォール開発の管理にはどんなツールが向いていますか？

工程間の依存関係を自動で再計算できるガントチャート機能があるツールが向いています。monday.com は6工程をグループに分けて成果物単位でタスクを置き、依存関係を引いておくことで、上流の遅延が後続工程の日程にどう波及するかをその場で確認できます。文書中心の運用なら Notion、開発者中心なら ClickUp や Backlog、自社サーバーで運用したいなら Redmine も選択肢になります。