ウォーターフォール開発とは
システム開発を要件定義、設計、実装、テスト、リリースといった工程に分割し、上から順に1回ずつ遂行する進め方です。各工程の成果物を確定させ、発注側が承認してから次の工程に移行します。前の工程のやり直しは想定外の手戻りとみなします。
建物でいえば注文住宅の建て方に近いです。間取りと仕様を設計図で確定させてから着工し、着工後の間取り変更には追加の費用と工期がかかります。
なぜ採用されてきたか
工程を定めずに開発しながら修正していく進め方では、規模が拡大するほど、どこまでできたかと残りにいくらかかるかを把握できなくなります。複数の会社で分担すると、どこまでが誰の責任かの線も引けません。そこで開発を工程に区切り、各工程の成果物を承認してから次へ移行するようにしました。これで費用と納期を事前に見積もれ、工程ごとに成果物を受け渡せます。
国内の受託開発では今も主流の進め方です。IPA（情報処理推進機構）は、IT企業から集めた2016〜2021年度の開発プロジェクトのデータをソフトウェア開発分析データ集2022に収録しています。このデータでは進め方の回答があった約1,400件のうち97%をウォーターフォールが占めます。企業向けの受託開発に偏ったデータで、市場全体の比率は表していません。
効果
- 着手前に範囲と費用、納期を見積もりやすく、予算の承認を得やすい
- 工程ごとに成果物と承認者が確定し、発注側が関与する時期を予定に組み込める
- 設計書と試験記録が保存されるため、監査への対応や、保守を別の会社へ引き継ぐときに活用できる
- 工程の区切りで契約を分割でき、複数の会社が分担する開発でも責任の範囲を区分しやすい
コストとリスク
- 全体を通した試験が後半に来るため、設計の誤りや性能の問題が終盤に発見されると、手戻りの費用と期間が増大する
- 承認済みの工程のやり直しを伴う仕様変更には追加の費用と期間がかかる。変更を避けようとして、使いにくいと分かっている仕様のまま完成させることもある
- 利用者が実際に触れるのは終盤になる。利用してみて初めて分かる不満は、リリース後の改修に回ることが多い
- 複数の会社が階層的に分担すると、要件の解釈の違いが下流の工程まで発見されない
- 発注側にも負担がかかる。要件定義で業務の詳細を決め切る担当者と、受入れテストで業務部門の時間を数週間単位で確保する必要がある
- 設計書を作成し、承認し、更新し続ける手間がかかる。リリース後に設計書の更新が停滞すると、保守を引き継ぐときの価値が低下する
- 設計書の更新と承認を改修ごとに経る運用では、小さな変更でもリリースまでに時間がかかる
