開発プロセスモデル
ウォーターフォールモデルとは
代表的な開発プロセスの1つにウォーターフォール・モデルがあります。今回は、このウォーターフォール・モデルに焦点を当て、説明していきます。
ウォーターフォール・モデルは、非常に古くから存在するもので、1970年ごろまでさかのぼると言われています。ウォーターフォールモデルでは、プロジェクトの全体工程を「要件定義」「設計」「実装」「テスト」「運用」等の工程に分割します。そして、これら分割された各工程を、直列に進めていくことで、システムを構築していく開発プロセスです（図1）。各工程を直列に進めていくということで、水が川を流れるかのごとく、上流から下流まで開発を進めていくため、「ウォーターフォール」という名前が付いています。
ウォーターフォール・モデルでは、各工程を直列に進めるため、各工程の開始や終了のタイミングが非常に重要となります。通常は、各工程での成果物が明確に定義されていて、その成果物の作成が終了したら、その工程が終了となり次の工程に進みます。ですので、ある工程においては、前工程の成果物を前提として、前工程の成果物の内容を精緻（せいち）化／実現化する方向で、自工程の成果物を作成することにより、開発は進められます。
よく、「ウォーターフォール・モデルは、後戻りできない」という話を聞きます。前工程の成果物が前提となっているため、後工程に入ったら前工程の変更はしない、という意味合いです。これについては、特に「ウォーターフォール・モデルでは、絶対に後戻りしてはならない」と言う訳ではなく、現実問題として、前工程の変更はしないのが一般的、程度に考えた方が良いでしょう。前工程を変更するかしないかは別問題としても、ウォーターフォール・モデルは基本的に、上流工程で決まったことが正しい、下流工程で後戻りを発生させないように、上流工程できちんと決めておく、というコンセプトになっています。
ウォーターフォールモデルの向き／不向き
上で説明しましたが、ウォーターフォール・モデルでは、前工程の成果物の上に、次の工程の成果物を重ねていきます。つまり、後工程の成果物は、前工程の成果物の品質に左右される、ということです。品質が良ければ後戻りは発生しない、という考え方ですね。
では、後戻りしない開発は、実現可能なのでしょうか。先ほど、ウォーターフォール・モデルは古くからある、と述べましたが、コンピューターが「計算機」だった時代は、ウォーターフォール・モデルは、今よりも現実的な開発プロセスだったと思われます。最近は、ECサイトや企業内ポータル等、さまざまな要件をシステムで実現できる世の中になっていますし、その要件が企業の競争力の源泉になっていることも少なくありません。
そういう意味では、要件変化のスピードはシステム開発のスピードよりも速いのが普通ですから、極端な話、「3ヶ月後に使うシステムの要件を、今決めて変更しないのは無理」というユーザーの声も、ある意味うなずけます。
ウォーターフォール・モデルに限らず、開発プロセスには、向き／不向きがあります。そのため、重要なのは、開発プロセスの持つメリット／デメリットを踏まえた上で「どの開発プロセスを適用するか」を見極めることになります。開発プロジェクトによっては、すでに開発プロセスが決まっていて、開発プロセスの選択肢がない場合もあるでしょう。その場合には、「どのように適用するか」を工夫することになります。では、メリット／デメリットについて見ていきましょう。
ウォーターフォールモデルのメリット
ウォーターフォール・モデルのメリットとしては、次のような点が挙げられます。
・進ちょく管理を行いやすい
開発全体のプロセスを工程に分割して各工程の成果物を明確に定義するため、成果物の完成度合いを持って作業進ちょくとすることができる。また、各工程が直列に進むため、マイルストーンの設定が明白。さらに、成果物を関係者がレビューすることにより、各工程の進ちょくに関して、開発側とユーザー側の意思統一が可能。なお、後工程においては、この成果物レビューでの結果が、開発側にとっての唯一の武器となる（ユーザー側に「仕様です」というための根拠）。
・全体規模を把握しやすい
最初の工程から最後の工程まで、システム全体をスコープとして進めるため、要件定義や設計の工程（いわゆる、上流工程）が終わった段階で、システム全体の仕様を決めることができる。逆に言うと「上流工程が終わった段階で、システム全体の仕様が決まっていなければならない」ということなので、現実問題として、その時点で決められる範囲や粒度が問題になることも少なくない。
・PJを構成しやすい
この業界でよく言われる開発者の役割分担に、SEとかPGとか言う分け方がある。それぞれ「設計をする（できる）人」「実装をする（できる）人」ということだが、すなわち、ウォーターフォール・モデルのPJにおいては、設計工程ではSEを集め、実装工程ではPGを集めれば良い、ということになる。特に大規模PJで、メリットが大きいと言る。
・契約にしやすい
システム開発では、実装工程をほかの会社が担当するなど、下請け構造が根強い。例えば、設計工程での成果物（設計書や仕様書）通りの実装を下請け会社に依頼することが多い。この場合、双方にとって、瑕疵（かし）判断の明確さや見積もりのしやすさ、という観点でメリットが大きい。ただし実態としては、仕様変更（上流工程に対する変更）の頻発により、下流工程を担当する下請け会社がデスマーチに陥ることも少なくない。
ウォーターフォールモデルの考え方
さて、これらのメリット（や、この後説明するデメリット）を生み出す根底として、ウォーターフォール・モデルには次のような考え方があります（図2）。
・事前に予見
開発の早い段階で今後のことを見通し、それに従って開発を進める。見通した内容に対する変更は、基本的に受け付けない。そのため進ちょく管理を行いやすく、全体規模を把握しやすく、また契約にもしやすい、ということになる。
・手続き中心
成果物を作成する手続きを中心として、誰がやっても同じように進められるようなタスクに分解して管理する。そのため進ちょく管理を行いやすく、PJを構成しやすい、ということになる。開発メンバー側からすれば、PJのルールに従って、歯車のように各工程の作業をこなす、というイメージとなる。
これらの考え方から、ウォーターフォール・モデルは、「大規模プロジェクトに向いている」「システムの品質を高めるのに有効」などと言われています。
さて、歴史が古いことや上記のようなメリットもあり、現在では、最も使われている開発プロセスと言って良いウォーターフォール・モデルですが、どこに行ってもいろいろな「悪口」を耳にします。「要件が変わらない訳ない」「どうせ、前工程の責任を後工程が全部かぶるだけ」等々。よく使われているだけあって、それなりの「ダメな点」もいろいろと上がってくるのでしょう。そもそもソフトウエア開発PJの成功率があまり高くない（と言われている）上に、開発プロセスの選択肢がほとんどなく、業界の慣習やウォーターフォール・モデルの運用が原因になっていることも多いのではないでしょうか。
ウォーターフォールモデルのデメリット
では、次に、ウォーターフォール・モデルのデメリットを見ていきたいと思います。デメリットとしては、次のような点が挙げられるでしょう（図3）。
・工程の最初の段階でしか要件を決められない
開発全体の要件を、初期工程（要件定義）の段階で決める必要がある。システムの稼働はまだ先なのに、要件を詰めなければならない。また、一度決めた要件は、基本的に変更しない想定で進めなければならない。
これは、メリット「全体規模を把握しやすい」の裏返しと言えます。ただし、ソフトウエアが実現するシステムの多機能化、スピード感が重要視されるようになってきた昨今の状況においては、メリットよりもデメリットの方が大きいという開発PJが増えてきたため、ウォーターフォール・モデル以外の開発プロセスが熱望される状況が生まれたと言って良いでしょう。
・上流工程に対する変更が困難
前工程の成果物の上に、次の成果物を重ねていくため、後工程の成果物ができているのにもかかわらず、前工程の成果物を変更しなければならない場合には、特に時間やコストの面において、多大な手戻りを発生させる要因となる。
システムは、要件定義から設計を経て、プログラムとして実装されたものが動きます。ですので、思い通りに動かない場合には、実装工程で解決せざるを得ない状況が多いと言ます。例えば、受入テストでダメだった場合、本来、上流工程から見直すべきことを、修正に必要なコストや時間の制約から、実装工程以降で対応することが多いのではないでしょうか。
その結果、上流工程の品質の悪さを下流工程で挽回（ばんかい）しようと頑張り、実装工程以降がデスマーチになる、という図式となってしまいます。もちろん、下流工程の担当者は好きで挽回している訳ではなく、仕方なく挽回している訳です。この辺が、現在のSI業界の大きな問題点と言えるでしょう。このような理不尽なデスマーチによって、現場担当者のモチベーション低下を起こさないようにする考え方も提唱されたりしています。
・実物は工程終盤にできる
通常、ユーザーが実際のシステムを見たり使ったりできるのは、テスト工程に入ってからとなる。その段階で、根本が違うようなことが発覚した場合には、かなり前の工程から見直さなければならないことが少なくなく、リスクが高い。
百聞は一見に如（し）かず。仕様書レビューでは何も指摘してこなかったのに、モノを見せた途端に、細かい指摘を連発するユーザーはどこにでもいるものです。ユーザー側の姿勢改善を促すのも一案ですが、早々にモノを見せればいいんじゃない？という考えが出てくるのは自然な流れというものでしょう。そのような開発プロセスも普及し始めています。
こぼれ話
ここでは、ウォーターフォール・モデルでの良くある落とし穴として、私が携わったPJでの話を披露したいと思います。皆さまも十分注意してください。
・「この画面には、この機能を付けてください」
設計の最終段階のある日、ユーザー側担当者に言われた言葉。あまりにとっぴな機能だったので「この機能は誰がどう使うんですか？」と聞いたところ、きっぱりと「分かりません」。いわく「既存システムにあるから」。それまでの流れを全く無視した、しかも、全く使われないであろう機能を実装する危機に。
ウォーターフォール・モデルでは、工程ごとに成果物をFIXさせなければならないため、心配性のユーザーは、駆け込みで意味不明な機能追加を切望するケースがあります。これは、システム品質を落とす一因となります。この場合、ユーザー側担当者にシステム開発のイロハを理解してもらう必要があります。
・「でも、まだ1回しかレビューしてないですよね」
設計書の最終レビューでの一幕。ユーザー側責任者のNG指摘に対して「前回のAさん（ユーザー側担当者）との打ち合わせで決まりました」と回答したときの、Aさんのお言葉。結局、Aさんからのヒアリング内容がことごとく覆ることに。
ウォーターフォール・モデルでは、現場担当者からのヒアリングを基にドキュメントを作成し、現場責任者にレビューしてもらう、というケースがあります。このとき、現場担当者は仕様決定責任を逃れるため、意味不明な「言い訳」をすることが少なくありません。これは、進ちょくを遅延させる一因となります。この場合、早い段階で「ヒアリングして意味のある人」を見極める必要があります。
