ウォーターフォール開発モデル（waterfall model）

分類: マネジメント系システム開発技術
出る試験: ITパスポート基本情報応用情報
重要度: ★★★★☆

要件定義から順に工程を進め、前の工程に戻らない前提で組み立てる開発の進め方。要求が固まっている部分に向く。

もう少し詳しい説明

ウォーターフォール開発モデルは、工程を順に進め、前の工程に戻らない前提で組み立てる進め方です。

waterfall（滝）という名前は、水が上から下へ流れて戻らない様子から来ています。

工程の並び

順	工程	決めること・作るもの
1	要件定義	何ができればよいか
2	外部設計（基本設計）	利用者から見える形。画面、帳票、データの項目
3	内部設計（詳細設計）	中の作り。処理の分け方
4	プログラミング	実際のコード
5	単体テスト	部品1つずつの確認
6	結合テスト	部品をつないだ確認
7	システムテスト	全体としての確認
8	運用テスト（受入テスト）	利用者が業務で使えるかの確認

工程の名前は、組織や教科書によって違います。 数も4つから8つ程度まで幅があります。

V字モデル

設計の工程と、テストの工程が対応しています。

設計の工程	対応するテスト
要件定義	運用テスト（受入テスト）
外部設計	システムテスト
内部設計	結合テスト
プログラミング	単体テスト

「何を決めた工程か」と「何を確かめるテストか」が対になります。 要件定義で決めたことは運用テストで確かめる、という形です。

この対応を、左に設計、右にテストを置いて V の形に描いたものをV字モデルと呼びます。

向く場面と向かない場面

向く	向かない
要求が固まっている	要求が決まっていない
法令で決まっている処理	使ってみないと分からないもの
他のシステムと合わせる必要がある	市場の反応を見ながら決めるもの
関わる人が多く、先に決めておく必要がある	少人数で早く試したいもの
受注の形で、範囲と金額を先に決める	範囲が変わり続ける

良い点

良い点	中身
進み方が見えやすい	いまどの工程かで、進捗が示せる
人を割り当てやすい	工程ごとに必要な技能が決まる
文書が残る	工程ごとに成果物があるので、後から追える
見積りを立てやすい	範囲を先に決めるため

難しい点

難しい点	中身
後の工程で見つかった誤りの手当てが重い	要件の誤りを運用テストで見つけると、設計から作り直しになる
要求の変更を受けにくい	工程が進むほど、戻る費用が大きくなる
動くものが見えるのが遅い	利用者が確かめられるのは終盤

誤りを見つける時期が遅いほど、直す費用が大きくなります。 そのため、各工程の終わりに別の人が成果物を見る（レビュー）手順を置きます。

2つを混ぜる形

1つのプロジェクトの中で、部分によって進め方を分けるという作り方があります。

部分	向く進め方
要求が固まっている部分（例：法令で決まった計算、他システムとの連携）	ウォーターフォール
要求が固まっていない部分（例：画面の使い勝手、新しい機能）	アジャイル

このとき、次の点をそろえる必要があります。

そろえること	中身
進捗の見方	一方は工程の完了、一方は残りの量で見る
変更の決め方	一方は変更管理委員会、一方はその場で決める
つなぐ時期	両方が合流して結合テストを行う時期

進捗の単位が違うと、全体の状況が分からなくなります。 金額に直して並べる（EVM）という方法が使われます。

試験ではこう出る

科目A（旧・午前）では、他の進め方との違いが問われます。順に進めて戻らないのがウォーターフォール、繰り返すのがアジャイルです。

V字モデルの対応も頻出です。要件定義と運用テスト、外部設計とシステムテストの対です。

午後や応用情報（プロジェクトマネジメント）では、2つの進め方が混在する場面で出ます。どちらの進め方を使う部分か、進捗をどう見るか、変更をどこで決めるか、という読み取りになります。

ミニクイズ

ウォーターフォール開発モデルの特徴として、最も適切なものはどれか。

正解は 4番：工程を順に進め、前の工程の成果物を確定させてから次へ進む

ウォーターフォール開発モデルは、要件定義、設計、実装、テストという工程を順に進め、前の工程の成果物を確定させてから次に進む形です。短い期間の繰返しはアジャイル開発、試作で要求を固めるのはプロトタイピングです。複数の工程を同時に始めるのは並行して進める別の進め方で、前の工程を確定させる前提とは合いません。

間違えた用語の復習リストを見る →

この分野をまとめて解く → システム開発とユーザーインタフェースのミニテスト（全40問）

最終更新：2026-11-09