開発方法の適否は、新しいか古いかだけでは判断できません。

要件の安定性、規模、組織構造、契約、規制、品質保証などを考慮して決めます。

誤解3：アジャイルなら要件定義は不要

アジャイルでも目的、ゴール、ビジョン、品質基準などは必要です。

IPAのアジャイル開発向けモデル契約でも、プロジェクトの目的・ゴール、プロダクトビジョン、初期計画、完了基準、品質基準などの確認が示されています。

ウォーターフォールモデルに対する否定的な見方

ウォーターフォールには明確な弱点もあります。

1つ目は、利用者からのフィードバックが遅れやすいことです。
実物を確認できる時期が遅い構成では、UIや業務フローの認識差を後から発見する可能性があります。

2つ目は、変更コストが大きくなりやすいことです。
要件変更が設計、実装、テストへ連鎖すると、大きな手戻りになります。IPAも要件定義の不備が後工程の手戻りコストにつながる点を指摘しています。

3つ目は、ドキュメントや工程完了自体が目的化する危険があることです。
「設計書が完成したから成功」ではありません。最終的な目的は、利用者や事業に必要なシステムを適切な品質で提供することです。

そのため実務では、

ウォーターフォール
       +
プロトタイプ
       +
自動テスト
       +
CI/CD