これまで説明してきたように，要求開発はその成果物を後に続くシステム開発で利用することを念頭においている。それなら，質の高い要求開発の成果物はどれくらい，またどのような形でシステム開発に役立つのだろうか。
細かい点を挙げればきりがないが，要求開発がシステム開発にもたらす恩恵は，次の2点に集約されると言ってよいだろう。
(A)ビジネス価値が約束されたシステムを開発できる
(B)システム開発の生産性が向上する
要求開発の目的である「正しいものを正しく作る」に照らし合わせると，(A)が「正しいものを」に対応し，(B)が「正しく作る」に対応する。これまで，(A)については何度か取り上げてきたものの，(B)については触れてこなかったように思う。そこで，今回と次回の2回にわたってこの(B)について考えてみたい。
要求開発の成果物がシステム開発における成果物のベースになる
そもそも，要求開発がシステム開発の生産性向上に寄与すると考える根拠は，要求開発がシステム開発で生み出される成果物の「基礎となる成果物」を作り出すことにある。この「基礎となる成果物」が，システム開発で生み出すべき成果物に近いものであれば，要求開発によってシステム開発で行う作業の一部，場合によっては大部分を省略できることになる。このような成果物の近さ，あるいは遠さのことを，ここでは「距離」と呼ぶ。さて，システム開発段階での成果物と言えば，最初に思い浮かぶのがソースコードだろう。加えて最近は，ソースコードの肩代わりをするような情報も必要とされるようになってきた。デプロイメント・ディスクリプタ（DD）や，OR（オブジェクト・リレーショナル）マッピングのためのXML情報などがその例だ。
要求開発の成果物がこうした実装系の成果物に「近い」ものであれば，要求から実装までの距離は短いことになる。もちろん，いきなり実装系の成果物との距離を考える必要はない。設計段階の成果物との距離を考える方が，もっと現実的で有益だ。いずれにせよ，要求開発の成果物とシステム開発における設計系/実装系の成果物との距離を考えて，それを縮める努力をすることが重要である。
では，要求開発からシステム開発へと受け渡される成果物にはどのようなものがあるだろうか。その代表的なものが，ビジネス・プロセス・モデルと概念モデルである。
ビジネス・プロセス・モデルは，BPMN（Business Process Modeling Notation）や，UMLのアクティビティ図として描くことができる。ごく単純に考えれば，これらの表記法を使って描いたビジネス・プロセス・モデルが，例えばBPM（Business Process Management）ツールの入力となることが期待できそうである。システム開発に入ると同時にプロトタイプが動き出す，などということもあるかもしれない。
概念モデルはどうだろうか。概念モデルは，商品，組織，工程，イベントなど，様々な概念と，それらの関連を表すものだ。UMLのクラス図や，ERD（エンティティ・リレーションシップ図）を使って表現できる。ERDで表せることから分かるように，概念モデルの情報は，データベースの設計情報と直接結びつくのが普通だ。したがって，概念モデルからデータベースのスキーマ情報をツールによって自動生成できる可能性がある。あるいは，概念の中でもビジネス機能に関する情報からは，SOA型システムにおけるサービス定義情報を直接生成できるかもしれない。
開発生産性向上のための2つのポイント
残念ながら，ここまでの説明は話を単純化しすぎており，そのまま成り立つわけではない。この点は，システム開発の経験が豊富な方であれば既にお分かりのことであろう。もしこのような考えの下に始まったプロジェクトがあれば，近づかない方が賢明であるとさえ言える。結局のところ，要求開発の成果物はあくまでもシステム開発の成果物の“ベース”を提供するものに過ぎないのである。では，どんな注意を払えば，冒頭に述べた要求開発の恩恵(B)を受けられるのか。そのポイントを以下に2つ挙げる。
(1)モデルによる工程間連携
同一の形式や同一の対象物を持つモデルであっても，要求開発，システム開発の様々なレベルの設計，さらには保守といったライフサイクルの各工程によって，求められる詳細度，抽象度は異なる。これらの工程ごとに適切な詳細度，抽象度でモデルを作成し，かつそれらを互いに連携させることが大切である。
(2)要求開発フロント・ローディング
フロント・ローディングは，製造業において，開発の上流工程で下流工程の課題を先行して検証し，手戻りを減らす手法である。Openthologyではこれを参考に，システム開発の成果物の品質を要求開発の段階で保証することを「要求開発フロント・ローディング」と呼んでいる。
実は(1)は，MDD（モデル駆動開発）そのものであり，OMG（Object Management Group）が提唱するMDA（モデル駆動アーキテクチャ）や米Microsoftのソフトウエア・ファクトリ構想を要求開発の段階まで拡張することに相当する。工程によってモデルの詳細度，抽象度が異なるのは当たり前に感じられるかもしれないが，現実には抽象度が高い上流工程のモデルをそのまま下流工程で使おうとして破綻する，といった例が後を絶たない。この点を明確に意識しながら各工程の成果物を引き継いでいこう，というのが(1)である。
これに対して，(2)は(1)を利用するための姿勢だと言うことができる。(1)によるモデル連携が問題なく効力を発揮し，しかも手戻りなく，優れた品質を持つシステム成果物が得られるように，あらかじめ下流の情報を上流に注入するのである。これは，ある意味で時間を逆行する行為だ。このような逆行が可能な理由は，注入するのがモデルではなくメタモデルに関する情報だからである。
次回は，モデルによる工程間連携と要求開発フロント・ローディングについて詳しく説明する。
| （依田 智夫＝要求開発アライアンス理事） |
