次回に引き続き，要求開発やシステム開発の未来の姿について語ります。これは，ビジネスとITの将来像をエンジニアリングの観点で予測するといった内容になります。
現在の要求開発は，図1のように上流は要求開発プロセス，下流はシステム開発と思えるようなオーバビューを示しています。ちなみに，この図中のシステム開発は，反復開発としてRUP（Rational Unified Process）を使った例です。
|
|
| 図1●要求開発とシステム開発（現状） |
図1に示したように，要求開発の重要なメタファであるコタツモデルによって確立された要求開発の成果は，RFPによってシステム開発会社へ引き継がれます。見方によっては，RFPによって両者が切り離されてしまっているようにもとらえることができます。
これは私にとっては，目を覆いたくなる現実です。なぜなら，要求開発段階に，トップ/業務メンバー/開発メンバーで組織するコタツモデルによって確立された，将来のビジネスの姿を提案依頼書（RFP）というドキュメントを通して，開発を請け負うIT企業に提案依頼するというのは，あまりにも非効率的すぎるのです。
本来ならば，コタツモデルの中に開発会社のリーダークラスが参加すべきでしょう。そうすれば，将来ビジネスにおけるITの役割が明確に伝わります。そして彼らはビジネスモデルの意図を理解したうえで，開発メンバーにもその意図や知識を伝達しなければなりません。
フロントローディングを要求開発に投入すると，要求開発プロセス段階で，次のようなIT課題を解決できる可能性が出てきます。現在，私が日々実践している要求開発ビジネスのレベルです（図2）。
・要求の検証/創発 ・技術リスクヘッジ ・ビジネスアーキテクチャ検証確立 ・ビジネス価値の高い個所の開発
|
|
| 図2●要求開発とシステム開発（フロントローディング開発） |
さて，これからはちょっと先の将来の話になります。
近いうちに，フロントローディング開発は，単にリスクヘッジだけを行うものではなく，ビジネス価値が高い個所を早期に開発する目的で，要求開発段階で実施するようなケースが多くなるでしょう（図3）。このような開発についてはアジャイル開発が最適だと私は思っています。
|
|
| 図3●要求開発段階における高付加価値ビジネスの実装 |
このように，ビジネス価値を生み出すために本来あるべき開発の姿を追求していくと，ビジネスとITの実現において，ビジネス的に価値が高いものを優先させて，逐次的に開発を進めていくスタイルに変化していきます。
つまり，要求開発の準備フェーズで明らかにした，ビジネス戦略やIT戦略に基づき，「見える化」「決定されたビジネス改革/改善」を細かな粒度に切り裂き，それに優先度をつけて，優先度の高い順に開発につなげていくやり方です。
今までの縦に切れていた要求開発やシステム開発のフェーズ（工程）を，今度はビジネス価値により横に切るわけです。今まで切れていたフェーズの概念は，デシプリン（作業領域）となってしまいます（図4）。
|
|
| 図4●ビジネス価値を生み出すためにあるべき開発の姿 |
ここからは近未来の話です。
図4で示した「ビジネス価値を生み出すためにあるべき開発の姿」をもっともっと追求していくと，未来のビジネスに利用されるITは，非常に変化の激しい領域が対象となります。そこでは従来の大規模開発は姿を潜め，継続的なビジネス価値創発の連鎖の中にIT開発が組み込まれるだろうと考えています（図5）。
|
|
| 図5●近未来の要求開発 |
すべてのビジネスITがこのような進化を遂げるということではありません。また，未来といってもすでにこのような姿に変化しているビジネスもあり，その中では，図5のような開発が行われているものもあるため，未来というのも不適切かもしれません。
ただ現時点においては，図5のようなビジネスIT開発の姿はまだ稀少です。しかし，近未来においては，このような開発のやり方がメジャーになる可能性があります。
ケペル株式会社のCTO（最高技術責任者）である相馬 純平氏は，このような姿をIT側から提案しています。それが「サービスウエア理論」です。簡単に説明すると，開発には始まりも終わりもなく，ビジネス戦略を具現化するビジネス価値創発の連鎖が，継続的に行われるような開発のことを言います。そこでは，見積もり重視ではなく，価値創出重視で進むということです。
相馬氏の考えは，私の未来の要求開発のイメージにピッタリです。そして，ある領域においては，不確定要素が多いなかで正確に見積もりを行うという行為自体，システム開発における重要な座標軸ではないということを教えられました。なぜなら，開発に始まり，終わりがあるわけではなく，そのときの価値を実現するために，継続的な業務改革/改善とIT化が進むため，ある段階のゴールについて予測し，それを見積もるという行為自体無理，無駄だからです。
見積もりが正確にできない理由として，作ってみないと工数も価値もよくわからないという本質的な問題があります。これが常識化するには，ビジネス的な契約の考え方も変えていく必要性があるでしょう。
しかし，これについては，Web2.0などと同様に，未来型ビジネスへの変化が必然的に行われていくなかで，いつの間にか普通の出来事として，開発や契約のやり方が変化していくものと私は考えています。そうしなければ，未来型ビジネスの変化にIT開発が適切に答えることができないからです。
いきなり要求開発がここまで変化するとは思っていません。しかし，このようなビジネス領域がすでに存在していることも事実なので，要求開発を実践する際にそのようなビジネスに遭遇した場合は，ここで描いているような要求開発とシステム開発の融合されたプロセスを，見える化していく必要があるでしょう。
以上のように，私は要求開発の未来像を頭の中に描いています。皆さんのITの将来像は，どのようなものでしょうか？ どこかでお会いできたときに，このような夢を語り合えるといいですね。そして，私の描いている将来像とどこかに接点があれば，お互いに楽しめることができますね。
| （萩本 順三＝要求開発アライアンス理事） |
