ウォーターフォール型開発
ウォータフォール型開発とは、システムやソフトウェアの伝統的な開発方式です。
「要件定義（計画）」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」の工程に分け、一つの工程が終わったら次の工程に移り、原則的に前の工程に戻らないのが特徴です。
水が上から下に流れるイメージから「ウォーターフォール」と呼ばれています。
人的リソースが多く必要な大規模な開発プロジェクトや、要件が状況によって変化しない基幹系システムの開発に適しています。
ウォーターフォール型開発の長所は、
①設計が全体から詳細、外部から内部の順番で行われるため全体の把握が容易であること、
②作業工程が明確に分割されているため、スケジュールや人員の配置、工数や責任範囲などの明確であることです。
ウォーターフォール型開発の短所は、
①前工程の内容が正確であることを前提として、正確後戻りを基本的に想定していないため、仕様変更による後戻りに弱いこと、
②一つ一つの工程での作業内容をすべて完了させてから次の工程に移るため、システムのリリースまでに比較的時間がかかることです。
近年では、伝統的なウォーターフォール型開発だけではなくアジャイル型開発も増えてきています。
目次
よくある質問
ウォーターフォール型が適しているプロジェクトは？
ウォーターフォール型は、開発の全体像や要件が初めから明確で、仕様変更が少ないプロジェクトに非常に向いているとされています。
たとえば、銀行の基幹系システムや組込機器開発のように、高い品質と安全性が求められるケースでは、設計からテストまで順を追って進めるウォーターフォール型が適しています。
開発規模が大きく複数人で進める際も、進捗や人員の管理が容易になるためです。
また、企業の勤怠管理や経理システムなど、仕様が確定しており変更の余地がほとんどない業務系システム開発にも向いています。
要件が固まった状態で対応すべき機能や納期が明確なので、その後の設計・テストをスムーズに行うことが可能です。
反対に、途中で仕様変更や追加要望が発生しやすいWebサービスやスタートアップ案件などには、アジャイル開発のほうが適しているケースもあります。
ウォーターフォール型開発では、発注者側からの要求変更への対応はどのように行いますか？
ウォーターフォール型開発では、基本的に各工程を上から順番に進めていくため、要件や仕様の変更には慎重な対応が求められます。
設計や開発が進んでからの変更は、前の工程に戻って修正を行う必要があるため、スケジュールやコストに大きな影響を及ぼす可能性があります。
そのため、変更が発生した場合は、まず「変更管理プロセス」に則って、変更内容の影響範囲や対応に必要な工数、コスト、納期への影響などを関係者全体で評価します。
評価の結果、変更の必要性と妥当性が確認されれば、正式な手続きを経て仕様書や設計書を更新し、以降の工程にも反映させます。
こうした変更対応には時間と手間がかかるため、ウォーターフォール型開発では、要件定義の段階で要件をできるだけ明確に固めておくことが非常に重要です。
また、発注者と開発者の間で共通認識を持ち、仕様の追加や変更が発生しないよう十分なコミュニケーションと事前調整が求められます。
ただし、公共システムや基幹業務のように、堅牢な設計と文書管理が重視されるプロジェクトでは、このような厳密な変更手続きが信頼性やトレーサビリティの確保につながるというメリットもあります。
最近のシステム開発でもウォーターフォール型は使われていますか？
ウォーターフォール型は現在でも多くのプロジェクトで採用されています。
特に要件が明確で変更が少ない、または品質と安全性を重視する大規模開発においては、今もなお有効な手法です。
たとえば、日本の2023から2024年の時点においては、多くの企業がウォーターフォール型を主に利用しており、IPAの調査では約97％ものプロジェクトが何らかの形でこの方式を採用しているとの報告があります。
また、大規模システムや公共案件、組込系などでは、手順とドキュメントに基づいた管理が必要であることから、ウォーターフォール型が選ばれ続けています 。
もちろん、アジャイルやDevOpsの導入が進む現在では、ウォーターフォールだけに頼るのではなく、状況に応じたハイブリッド的な手法を採用する企業も増えてきています。
この記事の編集者
柳元 華奈
北京大学日中通訳専門修士卒。日本経済の活性化を目指し、日本のIT変革やアジアとの架け橋となるべく、（株）グローバル・パートナーズ・テクノロジーに新卒入社。 主に民間企業のシステム刷新プロジェクトに従事し、同社のPR・マーケティング全般の業務やIT調達ナビの運営業務にも携わる。
