ビジネスIT・エンジニアリングの未来(1)

開発プロセスの本質・要求開発のフロントローディング開発

2007.01.18

　今回は，ちょっと大げさなタイトルで，驚かれた方もいることでしょう。でも，そんなに大げさなことではありません。要求開発からIT開発につなげていくための流れが，今後，ビジネス環境の変化とともに，どのように変わっていくのかについて私が考えていることを2回に分けて書いてみたいと思います。

　まず今回は，最近のシステム開発における開発プロセスの変化について説明し，最後に要求開発におけるフロントローディング開発の必要性へとつなげます。そして次回は，要求開発とシステム開発が今後どのように変化するのかという点について書いてみたいと思っています。

開発プロセスの本質

　オープン系におけるシステム開発プロセスは，ウォータフォール・モデルから反復開発やアジャイル開発へ徐々にシフトしています。

　ウォータフォール・モデルは，滝のように上流から下流へ流れるように開発を行うもので，手戻りがないことを前提に開発を進めるため，比較的にマネジメントしやすいという特徴があります。しかし，ウォータフォール・モデルでは，オープン系の開発には対応できません。その理由は，リスクマネジメントが欠落しているからです。そのリスクとは，オープン系特有のリスクと考えるべき下記のようなものです。

1. 要求が高度であいまい

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

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

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

2. 様々なテクノロジを組み合わせて開発を行う

　オープン系の開発においては，開発言語，ソフトウエア部品，開発環境などについて選択肢が非常に多く，デファクト・スタンダードとなっている様々なテクノロジを組み合わせて開発を行っていきます。このような環境では，システムに対する要求の制約を最小限に留めることができ，ビジネスの変化や高度なビジネス要求に答えられる環境が用意されているので，一見素晴らしい開発環境が提供されているように見受けられるでしょう。

　しかしデメリットもあるのです。それは，様々なテクノロジを組み合わせて開発した結果，はたしてビジネス要求を実現できるかのかどうか，ちょっとやってみないとわからないということです。しかも，それぞれのテクノロジは数カ月ごとに進歩しており，まだ安定期に入るような気配がありません。

　だからオープン系開発においては，作ってみないとわからないということが，いまになっても続いているのです。これがオープン系特有の第二のリスクとなります。

　これらのリスクをできるだけ早期にヘッジするために，反復開発やアジャイル開発といったものが必要とされていると筆者は考えています。つまり，下記の2点を解消することで，ビジネスに要求されるIT化のゴールを慎重かつ確実に達成させようとしているわけです。

　(1)要求を早期に検証する
　(2)技術的リスクを早期にヘッジする

　反復開発やアジャイル開発において，これらの早期リスクヘッジのやり方は，まさに「石橋を叩いて渡る」的であり，一見すると高リスクな開発のように見えるかもしれません。しかし，作ってもメリットがない/実現できないことを実現しようとするリスクを避けることで，無駄な部分に手を染めないことが，効率的かつ価値のある開発を行うことにつながるわけです。

　このように(1)と(2)は，ウォータフォール型開発から反復開発やアジャイル開発に移行すべき根拠となります。オープン化において「要求の検証」と「技術リスクのヘッジ」は，リスクマネジメントの観点で非常に重要なものとなるわけです。

　ウォータフォール型開発は，そういう意味で，リスクマネジメント的に致命的な欠点があります。しかし，オープン系開発でウォータフォール型開発を行っている企業はいまだに存在しています。

　実は，そのようにオープン系開発でウォータフォール型開発を行っている企業では，かならずと言ってよいほど，隠れプロセスがあります。(1)はユーザービリティ検証プロトタイプで，(2)は方式検証プロトタイプでリスクヘッジが行われているのです。

　このような隠れプロセスの存在で，影ながらリスクヘッジすることにより，ウォータフォール型開発でも対応可能になっているのでしょう。しかし，これはもうウォータフォール型開発ではなくなっており，一種の反復開発プロセスととらえることもできます。

　反復開発プロセスは，この隠れプロセスを明示的なプロセスとして示していると言えます。つまり，アジャイル開発のプロセスや反復開発プロセスは，オープン系開発におけるリスクマネジメントを導入したプロセスのリファレンスモデル（参考として参照するためのプロセス例）として理解すべきです。本質的には，いかにして上記(1)と(2)のリスクヘッジを行うかということに注意しつつ，開発プロセスをカスタマイズ（テーラリング）しなければならないわけです。