前のページ｜1　2　3｜次のページ

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

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

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

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

●要求が高度であいまい

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

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

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

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

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

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

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

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

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

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

■イノベーションから見たウォーターフォール開発

　イノベーティブな開発、つまり新しいアイデアを生かしてビジネスの価値を高めようとする開発は、顧客にとってもITエンジニアにとっても大切なことだ。

　「そんなたいそうな開発なんてやったことがない」と考える人も多いだろうが、実はイノベーティブを意識するのはITエンジニアとして常識だ。

　ビジネス価値を高めるための業務の在り方と、そこに必要とされるITの姿、そしてビジネスの継続性を保つためのメンテナンス可能なアーキテクチャ、これらの姿を想像するには、従来の決まりきった業務・開発パターンを打ち破り、新しい姿を業務レベルで考える力が必要である。

　このような手段を実践することは、ITの価値、要求の価値を高めるものとなる。しかし、要求のリスクで挙げたように、ウォーターフォール開発には、イノベーティブな開発ができないという致命傷がある。

　ビジネスで生きるITの姿は、次の2点によって保証される（図2）。

　1つ目は、何をしたいかというユーザーのWhatを、実現方法（How）と組み合わせてできるだけ早く検証することである。

　2つ目は、Howのアイデアによって、何をしたいかというユーザーのWhatを作り出すということである。

　前者は、Howの手探り（要求のリスクマネジメント）、後者は、Howからの突き上げ（イノベーティブな提案による要求の創出）によって要求が作り上げられている。これらはウォーターフォール開発ではできない。

図2　要求のリスクマネジメントとイノベーション

なぜウォーターフォール開発は捨てられないのか

前のページ｜1　2　3｜次のページ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）