「現状のソフトウェア開発は間違っていないか？」（プロセス編）：ソフトウェア開発の匠（3）（2/3 ページ）

» 2009年01月28日 00時00分公開

ウォーターフォール開発がうまくいかない理由

　1990年代、ウォーターフォール開発は、オープン系の開発においても採用されるようになった。筆者もC言語を使っていたころ、ウォーターフォール型のプロセスでプログラム構築をしていた。しかし、筆者は、以前のウォーターフォール開発のようにうまくいかなくなったことを感覚的に理解していた。

　なぜなら、ウォーターフォール開発は、オープン系の開発では、あまりにも楽観的なプロセスのように思えてしまい、そのままだと怖くて使えないと感じたからだ。だから筆者は、ウォーターフォールを改良したものを使っていた。

　では、どうしてオープン系開発ではウォーターフォール開発はうまくいかないのか？　ウォーターフォール開発は、滝のように上流から下流へ手戻りなく開発を進めることを前提にするため、比較的マネジメントしやすいという特徴がある。しかし、これから説明するオープン系特有のリスクに対するリスクマネジメントが欠落しているのである。では、そのリスクとはどのようなものなのか説明しよう。

●要求が高度であいまい

　旧来のメインフレーム開発は、データをためて、集計・演算などを行い、画面・帳票に出力するようなものがほとんどであった。そのような制約の中からシステム要求を抽出していたので、要求の実現イメージはある程度明確にできていた。

　しかし、現在のオープン系の場合には、要求自体がどんどん複雑化し、とらえづらくなっている。例えば、部門連携・企業連携などでは、既存の業務をIT化するというだけではなく、業務をIT化することで付加価値を創出するという課題を負うことが多くなっている。要求提案当初、このような要求については非常にあいまいな場合が多い。

　なぜなら、業務をIT化した際にどの程度ビジネス的な価値が高まるかは最初からは分からないし、どのようにIT化すればビジネスの付加価値がどの程度高まるのかが分からない。つまり、ビジネスとITが融合された中に、本質的なシステムの要求が存在している。

　ここで問題となるリスクは、ウォーターフォール開発では要求の実現を検証したり、チューニング（注1）したりする方法がないということである。

（注1）筆者は、現代においては、この実現のチューニングこそが、要求の価値を高めているという事実を見過ごしてはならないと考えている。

●さまざまなテクノロジを組み合わせて開発を行う

　オープン系の開発では、開発言語、ソフトウェア部品、開発環境などの選択肢が非常に多い。これらのデファクトスタンダードになっているさまざまなテクノロジを組み合わせて開発を行っていく。

　このような環境では、システムに対する要求の制約を最小限に留めることができ、ビジネスの変化や高度なビジネス要求に迅速に応えることができる。一見すばらしい環境のようだ。

　しかしデメリットもある。さまざまなテクノロジを組み合わせて開発した結果、ビジネス要求（機能的要求、パフォーマンスなどの非機能的要求）を実現できるかどうかは、やってみないと分からないことが多い。しかも、テクノロジは数カ月ごとに進歩している。安定期に入るような気配はまだない。

　だからオープン系開発においては、作ってみないと分からないということが現在も続いている。よって、技術的リスクを早期にヘッジ（回避、低減、対応）するためには、アーキテクチャを早期に検証する必要がある。しかし、ウォーターフォール開発では、アーキテクチャを早期に検証する方法がないのだ。これもリスクマネジメントの欠落といえよう。