【開発手法】ウォーターフォール開発の問題点

【開発手法】ウォーターフォール開発の問題点

ウォーターフォール開発とは、システム全体の開発工程をフェーズ順に進めて後戻りはしないソフトウェア開発手法です。

ソフトウェア開発をフェーズ別に分割し、時系列順にすると、おおまかには以下のような流れとなります。

この流れ自体はどのような開発手法でもあまり変わらないでしょう。アジャイル開発であっても、そのイテレーションで開発する機能についてはこのようなフェーズを踏むことになるはずです。

問題は、前工程に戻ることを許容するか？です。これを許容せず（あるいは多少緩く考えても、最小化することに最大限の努力を払う）のがウォーターフォール開発です。

ウォーターフォール開発への批判

ウォーターフォール方式で開発ができれば、作業は非常に効率的となるでしょう。各ステップの実行者は、前工程の完全な情報を基にして、自身の作業に集中できるからです。

しかし現実的にそんなことは不可能であるとして、ウォーターフォールはしばしば批判されます。

ウォーターフォールの問題点は、やはり各ステップで完璧な成果物を作ることが不可能なことも多いという点にあります。

ウォーターフォール方式では前工程への戻りを許容しないため、もしも実際にソフトウェアが出来上がってきてから何かしらの修正をしたい場合、それを認めません。現実的に絶対に認めないということは難しいので、認める部分もあるでしょうが、やはり当初の想定に寄せる方向に誘因が働くことは多いです。

しかし、修正したいということはビジネス的に価値がないものが実際にはできてしまっているということで、それにも関わらず修正しない・修正を軽微にとどめようとするのなら、結果として出来上がったソフトウェアはビジネスの現場で役に立たないものでしかありません。あるいはウォーターフォールでうまくいくことを前提とした予算・納期を設定しているにもかかわらず手戻りを許容するのであれば、ソフトウェア開発者に負担が寄ることになるでしょう。

つまり、ウォーターフォール方式では、「価値のないソフトウェアが出来上がる」か「価値のためにソフトウェア開発者の負担が単純に増すだけ」という結果になりかねないのです。

それゆえ、各ステップで完璧な成果物を作ることことを前提とした開発観をやめて、プロセスや納期や予算といった観点から手戻りを許容するような開発へ移行するべきだ、と批判がされているのです。

手戻りを許容するウォーターフォール開発？

「ウォーターフォール開発といえど、ある程度は許容する」と言う立場もあります。しかし、そうなると、ウォーターフォール開発と他の開発手法の区別がつかなくなり、そもそもウォーターフォール開発という概念自体が無意味化します。ステップごとに作業を進めるというのは、特にウォーターフォールの専売特許というわけでもなく、多かれ少なかれどの開発手法もそういう側面を持ちます。その手戻りを認めるか？という点にしか、ウォーターフォール開発という概念と他を区別できるポイントはありません。

現実的には「どこまでは許容して、どこまでは許容しないのか」というグラデーションの問題で、その考え方を開発に取り込めているのであれば、それは脱ウォーターフォールできていると考えるべきでしょう。その許容の線引きは正しいのか？という問題は依然残るでしょうが、それは個々のプロジェクトに良し悪しが依存するため、現場で都度判断するしかありません。