ウォーターフォール型ソフトウェア開発モデルは、なぜ失敗することがあるのか？ - International Scrum Institute

調査対象となった、失敗したソフトウェアプロジェクトの80%超で、ウォーターフォール手法の使用が主な失敗要因の一つだったという研究結果があります。なぜでしょうか？

原寸大の図を開く

リンク先の資料へ進む

従来のウォーターフォール型ソフトウェア開発モデルの工程

上図のように、ウォーターフォールでは、異なる工程を厳密に順番どおり進めます。前の工程が完了してから、次の工程を始めます。多くの場合、前に戻ることは難しく、費用と時間がかかり、チームの意欲も損ないます。

開始時にプロジェクト全体の日程を計画し、リリース可能なプロダクトを提供するのは最後です。一つの工程が遅れると、その後の工程もすべて遅れます。

その事態を避けるため、ウォーターフォールの利用者は、通常あらゆる可能性を事前に予測しようとします。プロジェクトの早い段階で、要件をできる限り詳細かつ完全に定義しようとするのです。しかし、その時点での要件定義は難しく、進行中に多くの要件が変わりますし、変えるべき場合もあります。大規模で複雑なプロジェクトでは、初期要件の約60%が途中で変更されるという研究結果があります。一方、定義どおりに実装しても実際には顧客が必要としない要件もあり、より価値の高い機能に使えたはずの貴重な時間を消費します。

工程を分けることで、各工程を個別に見積もらざるを得なくなります。しかし実際の活動は独立しておらず、重なり合い、互いに影響することが多いのが問題です。

ウォーターフォールによるソフトウェア開発は、小規模で単純なプロジェクトには利用できます。しかし、より大規模で複雑なものでは、スクラムよりリスクが高く、費用がかかりがちで、全般に効率が劣ると言えます。