アジャイル＆ウォーターフォール⑤ ～「手法として共に良い」の間違い～

はじめに

ソフトウェア開発の現場では「状況に応じてウォーターフォールとアジャイルのプラクティスを使い分ける」という考え方が広く見られます。しかし、この考え方はアジャイルのプラクティスが持つ本質的な意図を見落としています。本稿では、ウォーターフォール開発で発生する具体的な問題とそれに対するアジャイルプラクティスの解決策を検証することで、両者の関係性について考察します。

ウォーターフォールプラクティスの課題

ウォーターフォール開発では、計画段階での想定と実態の乖離により、開発中にスコープの変更が必要となることが一般的です。しかし、スケジュールやコストは顧客のビジネス都合から変更が困難であるため、スコープ変更の都度、変更管理帳票の作成や承認プロセス、場合によっては契約の再締結が必要となります。この煩雑な手続きを避けるため、現場担当者が非公式に作業を追加してしまう事態が頻発し、これがスコープクリープの主要な原因となっています。

アジャイルプラクティスによる解決

アジャイルのプラクティスは、これらウォーターフォールの課題に対する具体的な解決策として設計されています。例えば、開発チームが新たな要件や課題を発見した場合、プロダクトバックログに記録するだけでよく、その優先順位付けは定期的なリファインメントの中で権限者により実施されます。この仕組みにより、スコープの変更を正式なプロセスとして管理でき、スコープクリープを防ぐことができます。

プラクティスの本質的な違い

このように、アジャイルのプラクティスは、ウォーターフォール開発で発生する具体的な問題点への対応として設計されています。プロダクトバックログやリファインメントといった仕組みは、変更管理の硬直性やスコープクリープといったウォーターフォールの課題を解決するために考案されました。したがって、これらを単なる「異なるアプローチ」として扱うことは、アジャイルプラクティスが持つ問題解決としての本質を見落としていることになります。

まとめ

アジャイルのプラクティスは、ウォーターフォール開発で生じる実務上の問題、特にスコープクリープや変更管理の硬直性に対する具体的な解決策として設計されました。したがって、これらを「状況に応じて使い分ける別々の手法」として評価することは、アジャイルプラクティスの本質的な意図を正しく理解していない評価だと言えます。アジャルのプラクティスを考案した人々にとって、ウォーターフォールの具体的な問題を解決するために生まれたアジャイルの価値を、単なる選択肢の一つとして扱うような評価は、本質を見誤った見方なのです。