工程を上流から下流へ順番に進めるソフトウェア開発モデル。
ウォーターフォールモデルとは、ソフトウェアを作るときに工程を上流から下流へ順番に進めていく開発の進め方のことです。ウォーターフォール(waterfall)は「滝」という意味で、水が滝のように上から下へ流れる様子になぞらえています。
身近な例で考えると、家を建てる工事に似ています。「どんな家にするか決める→設計図を描く→基礎を作る→建てる→完成チェック」という順番を守り、いきなり屋根から作ったりはしませんよね。ソフト開発も同じで、前の工程が終わってから次へ進みます。
上の図解では、各工程が階段のように一段ずつ下へつながっています。原則として前の工程には戻らないのがこのモデルの大きな特徴です。
ウォーターフォールでは、ソフトを作る作業を次のような工程(フェーズ)に分け、上流から下流へ順番に進めます。
・要件定義:利用者が何をしたいかを聞き取り、作るものを決める
・設計:要件を実現する仕組みを図面(設計書)に落とす
・実装(プログラミング):設計書をもとにプログラムを書く
・テスト:作ったものが正しく動くか検証する
・運用・保守:実際に使い始め、不具合の修正や改善を続ける
各工程の終わりには成果物(ドキュメントやプログラム)が作られ、それをチェックして問題なければ次の工程へ進みます。工程の区切りがはっきりしているため、いまどこまで進んだかが分かりやすいモデルです。
利点は次のとおりです。
・進捗が分かりやすい:工程の区切りが明確で、どこまで進んだか把握しやすい
・計画が立てやすい:工程ごとに必要な人や期間を見積もりやすい
・大人数で分担しやすい:成果物(ドキュメント)が残るため引き継ぎがしやすい
一方で欠点もあります。
・手戻りが大きい:後の工程で要件の誤りが見つかると、上流に戻ってやり直す負担が大きい
・柔軟性が低い:途中で仕様を変えにくく、変化の多い開発には向かない
・動くものが遅い:最後のテスト工程まで実際に動くソフトが出てこない
そのため、要件が最初から固まっている大規模な開発に向いています。逆に要件が変わりやすい場合は、後で学ぶスパイラルモデルやアジャイル開発のほうが適しています。
後戻りの負担が大きくなる理由は、各工程が前の工程の成果物(=文書やプログラム)の上に積み重なっているからです。
例えば、テストの段階で「要件の決め方が間違っていた」と気づいた場合、次のすべてをやり直す必要があります。
・要件定義を作り直す
・要件をもとにした設計書を作り直す
・設計をもとに書いたプログラムを作り直す
・そして改めてテストを行う
家の建築に例えると、屋根まで作ってから「間取りが違う」と気づくようなもの。全部壊してやり直すことになります。だからウォーターフォールでは最初の要件定義を丁寧に固めることがとても重要で、「後で変わるかもしれない」要件には向かないのです。
ソフトウェア開発モデルには、このページで学んだウォーターフォールのほか、スパイラルモデル・プロトタイピングモデルがあります。3つの最大の違いは「後戻り・反復ができるかどうか」です。
| モデル | 後戻り | 反復 | リスク対応 | 向く開発 |
|---|---|---|---|---|
| ウォーターフォール | 原則なし | なし | 低い | 要件が固い |
| スパイラル | あり(サイクル内) | あり | 高い | 不確実・大規模 |
| プロトタイピング | あり(試作を繰り返す) | あり | 中程度 | 要件があいまい |
ウォーターフォールは「最初から最後まで一本道」のイメージです。道が決まっているから速く進めるのが強みですが、途中で道を変えるのは難しいです。スパイラルとプロトタイピングはどちらも繰り返しがある点では似ていますが、スパイラルはリスクを見極めながら大きな開発を進めるもの、プロトタイピングは利用者に見せて要件を固めることを目的とする点が違います。