ウォーターフォール型開発モデル

上で説明したように、ソフトの開発工程を各フェイズに分け、それを順番に実行しようという開発スタイルを「ウォーターフォール型開発モデル」と呼びます。ウォーターフォール(滝)のように、上(要求分析)から下(完成)まで流れ落ちるように進めることからこの名前がつきました。

ウォーターフォール型開発モデルの要点は、上で述べたように自動車などと同じようにソフトウェア開発にも工程があることを認識して、各工程をしっかりやりなさい、ということです。その教えをまとめると次のようになります。

各フェイズで成果を形にして残しなさい。
前のフェイズの成果を基にして次の工程をやりなさい。
前のフェイズが全部終わるまで、次のフェイズをやってはいけません。
最後になって「設計がまずかった。最初からやり直し」なんてことにならないように、各フェイズをしっかりとやりなさい。
プログラマが頭の中で「仕様検討」や「設計」をしている時間を除いてみれば、実際のところプログラムを作っている期間なんてわずかなものなのです。開発の進捗は「どの部分までできた」で計るのではなく、「どの段階までできた」で計るべきです。

この教えの意味を考えないで表面だけを見ると、いろいろな勘違いやトラブルに巻き込まれます。

いつまでもモノが出来てこない

ウォーターフォール型開発とごく普通の開発を見比べて、「構想ばかりで肝心のモノがいつまでたっても出来てこない」と不満に思う人がいます。例えば同じ在庫管理ソフトをA社はウォーターフォール型開発モデルで、B社は片っ端からプログラミングで作ったとしましょう。するとおそらくこのようになるでしょう。

この例は完全に架空のものですが、だいたいA社が仕様書を書いている段階でB 社では完成品のプログラムができてしまいます。つまり仕様書を書くという工程はプログラムを作るのと同じくらいの工数が必要だということです。だから、プログラムが問題なく使えるようならウォーターフォール型開発モデルなんてまったく無駄なのです。

問題はプログラムが出来た後に起きます。B社では顧客とほとんど打ち合わせもしないままソフトを作り、それでほとんど完成した気分でいます。「このソフトがトラブルもなく終われば、半分の工期で仕事が終わって儲けもの」とありもしない期待を抱いています。だからその後のクレームがトラブルの元になるのです。本当は「完成してからクレームをつけられた」のではなく「完成するまでクレームをつける機会を与えなかった」のです。

非現実的な期待をするのはやめましょう。ソフトウェアの製作というのは時間がかかるものなのです。そして、ウォーターフォール型開発モデルを取ればモノが出来てからは早いのです。

工程の後戻りをしていいか？

よく「ウォーターフォール型開発では工程の後戻りができないからダメだ」という人を見かけます。こういう人はこれにこう付け加えます。「だって、途中で仕様変更とか設計変更があったらどうするんだ？」と。

これは間違いです。何でも「できない」より「できる」方がいいという考え方で設計の後戻りを肯定してはいけません。ウォーターフォール型開発は「後戻りができない」のではなく、「後戻りをしなくていいようにしっかりやれ」という教えだからです。「途中で仕様変更とか設計変更があったらどうするんだ？」という質問には「そんな事はないようにしましょう」というのが答えです。とはいっても、実際には設計変更はゼロにできるわけではありません。その場合には仕方なく後戻りが入ります。「仕方なく」である点に注意が必要です。積極的にしてはいけないのです。

かと言って、後戻りをしなければいけない場面でしないのもまた問題です。ミスが発見されても「ウォーターフォール型では後戻りは許されないから」とそのまま突き進むのでは、それは奈落の底に向かって進んでいくことになります。どちらも、その意味する所を考えずに形式だけ真似るからこうなるのです。

ウォーターフォール型開発の教えは「後戻りをしなくていいようにそれぞれの工程をしっかりやれ」というものです。そしてしっかりやったにも関らずミスが発覚してしまったら、それは仕方なく後戻りすべきです。

ドキュメントを書くのが大変

現場のプログラマにはこういう感想を持つ人もいます。彼らの多くは文章を書くよりはプログラムを書く方が得意な人達です。そして、いつも報告書やプレゼンを作っているマネージャークラスの人はこういう人を「このパソコンオタクが」と見下した目で見ています。この構図が問題なのです。

現場のプログラマはまず「ドキュメントの重要性」を認識して下さい。「ドキュメントの重要性」とはすなわち「仕様検討の重要性」であり「構造設計の重要性」です。プログラマの仕事のアウトプットはプログラムだけではないのです。ただ、「仕様検討の結果をちゃんと形にして残せ」と言っているだけなのです。逆に結果が形になっていればドキュメントは文書としての体裁にこだわる必要はありません。UML図(後述します)やメモ、ホワイトボードのコピーでかまわないのです。他の人がそれを読んで理解できさえすれば。

残念なことに、「ドキュメント作成が大変」という問題を引き起こす原因の多くはプログラマ側ではなくマネージャ側にあります。現場を知らない「開発工程推進派」マネージャが「仕様書や設計書は大事だからちゃんと書け」と強制するのです。プログラマ側はそれらの文書が何のためにあるのかを理解しないまま、単に上からの強制で文書を書かされます。目的もわからないままただマネージャの満足のために文書を書かされる方はたまったものじゃありません。

教条主義に陥らないようにしましょう。「何のためにドキュメントを書くのか」を考え、それに必要十分なものを作ればいいのです。

まとめ

ウォーターフォール型開発とは要するに「ソフト開発を工程に区分して、それぞれをしっかりやりなさい」という事です。それぞれの工程の意味をよく理解して、それをきちんと達成すればいいのです。それ以上の事は何もありません。