開発プロセスモデル

ウォーターフォールモデルのデメリット

　では、次に、ウォーターフォール・モデルのデメリットを見ていきたいと思います。デメリットとしては、次のような点が挙げられるでしょう（図3）。

・工程の最初の段階でしか要件を決められない
　開発全体の要件を、初期工程（要件定義）の段階で決める必要がある。システムの稼働はまだ先なのに、要件を詰めなければならない。また、一度決めた要件は、基本的に変更しない想定で進めなければならない。

　これは、メリット「全体規模を把握しやすい」の裏返しと言えます。ただし、ソフトウエアが実現するシステムの多機能化、スピード感が重要視されるようになってきた昨今の状況においては、メリットよりもデメリットの方が大きいという開発PJが増えてきたため、ウォーターフォール・モデル以外の開発プロセスが熱望される状況が生まれたと言って良いでしょう。

・上流工程に対する変更が困難
　前工程の成果物の上に、次の成果物を重ねていくため、後工程の成果物ができているのにもかかわらず、前工程の成果物を変更しなければならない場合には、特に時間やコストの面において、多大な手戻りを発生させる要因となる。

　システムは、要件定義から設計を経て、プログラムとして実装されたものが動きます。ですので、思い通りに動かない場合には、実装工程で解決せざるを得ない状況が多いと言ます。例えば、受入テストでダメだった場合、本来、上流工程から見直すべきことを、修正に必要なコストや時間の制約から、実装工程以降で対応することが多いのではないでしょうか。

　その結果、上流工程の品質の悪さを下流工程で挽回（ばんかい）しようと頑張り、実装工程以降がデスマーチになる、という図式となってしまいます。もちろん、下流工程の担当者は好きで挽回している訳ではなく、仕方なく挽回している訳です。この辺が、現在のSI業界の大きな問題点と言えるでしょう。このような理不尽なデスマーチによって、現場担当者のモチベーション低下を起こさないようにする考え方も提唱されたりしています。

・実物は工程終盤にできる
　通常、ユーザーが実際のシステムを見たり使ったりできるのは、テスト工程に入ってからとなる。その段階で、根本が違うようなことが発覚した場合には、かなり前の工程から見直さなければならないことが少なくなく、リスクが高い。

　百聞は一見に如（し）かず。仕様書レビューでは何も指摘してこなかったのに、モノを見せた途端に、細かい指摘を連発するユーザーはどこにでもいるものです。ユーザー側の姿勢改善を促すのも一案ですが、早々にモノを見せればいいんじゃない？という考えが出てくるのは自然な流れというものでしょう。そのような開発プロセスも普及し始めています。

こぼれ話

　ここでは、ウォーターフォール・モデルでの良くある落とし穴として、私が携わったPJでの話を披露したいと思います。皆さまも十分注意してください。

・「この画面には、この機能を付けてください」
　設計の最終段階のある日、ユーザー側担当者に言われた言葉。あまりにとっぴな機能だったので「この機能は誰がどう使うんですか？」と聞いたところ、きっぱりと「分かりません」。いわく「既存システムにあるから」。それまでの流れを全く無視した、しかも、全く使われないであろう機能を実装する危機に。

　ウォーターフォール・モデルでは、工程ごとに成果物をFIXさせなければならないため、心配性のユーザーは、駆け込みで意味不明な機能追加を切望するケースがあります。これは、システム品質を落とす一因となります。この場合、ユーザー側担当者にシステム開発のイロハを理解してもらう必要があります。

・「でも、まだ1回しかレビューしてないですよね」
　設計書の最終レビューでの一幕。ユーザー側責任者のNG指摘に対して「前回のAさん（ユーザー側担当者）との打ち合わせで決まりました」と回答したときの、Aさんのお言葉。結局、Aさんからのヒアリング内容がことごとく覆ることに。

　ウォーターフォール・モデルでは、現場担当者からのヒアリングを基にドキュメントを作成し、現場責任者にレビューしてもらう、というケースがあります。このとき、現場担当者は仕様決定責任を逃れるため、意味不明な「言い訳」をすることが少なくありません。これは、進ちょくを遅延させる一因となります。この場合、早い段階で「ヒアリングして意味のある人」を見極める必要があります。