前回から引き続き，要求開発によってシステム開発の生産性向上を図る際に直面する3つの問題をどう解決するかについて述べていく。3つの問題とは，(1)要求開発モデルに記述するべき情報の基準がない，(2)要求開発モデルを活用するツールがない，(3)完全な要求開発モデルを作成する時間がない，である。
まずは，前回挙げた問題(1)の課題(B)「文字列長のような属性の型情報をどのような方法でモデル化するか」について考えよう。データベース管理システムで，ファイル上にどのような情報が存在するかを示した情報をメタ情報という。それと同じく，モデルにどのような情報が表現されるかを示したモデルをメタモデルという。今やソフトウエア開発における共通言語となっているUML（Unified Modeling Language）は，実はメタモデルの名前である。UMLがメタモデルを定義しているおかげで，われわれはUMLモデルを描けるのである。同様に，あるモデルが「UMLモデルではない」ことを見破れるのも，メタモデルのおかげだ。
残念なことに，標準のUMLはわれわれが実務で使うにはあいまいすぎる。それが問題(1)「要求開発モデルに記述するべき情報の基準がない」の原因である。実務でモデリングを役立てるためには，独自のルールを決めるしかない。UMLを利用しても独自ルールを設定することは可能で，それをUMLではプロファイルと呼ぶ。
あるいは，UMLを使わずにモデルを記述することもできる。例えばMDA（Model Driven Architecture）では，MOF（Meta Object Facility）を使って，自分，自社，あるいは業界専用のメタモデルを定義できる。米Microsoftが提唱したSoftware Factoriesも，専用メタモデルを利用することが標準的なアプローチであり，それぞれの専用メタモデルをDSL（Domain Specific Language）と呼ぶ。
図1[拡大表示]に，メタモデルの例と，そのメタモデルに準拠した書籍クラスモデルの例を示した。このメタモデルは表記がUMLであるものの，UMLとは異なる独自のものである。このメタモデルに準拠することが求められると，前々回の図1に示した3つのモデルはもはや許されなくなる。そして，このメタモデルに準拠したモデルの商品番号情報からは，必ずデータベースのスキーマ情報などに必要な最大文字列長を取得できることが約束されるのである。
 図1 メタモデルの例とそのメタモデルに準拠した書籍クラスモデルの例 メタモデルでは，属性の型や商品識別子の最大文字列長などをモデルに明記するよう規定している。 [画像のクリックで拡大表示] |
2番目の問題「要求開発モデルを活用するツールがない」に対しては，既に答えたようなものだ。MDAやソフトウエア・ファクトリーズ関連のツールは，工程間連携とフロント・ローディングの有力なツールとなり得るのである。
MDAの中核概念はモデル変換だ。つまり，抽象度や詳細度が異なる2つ以上のモデル間での変換を行うことである。もちろん，ここで言うのは「A社の販売管理業務モデル」といった特定のモデルを別のモデルに変換することではない。MDAは，特定のメタモデルに準拠する「任意の」モデルを，別の特定のメタモデルに準拠するモデルに変換できるのである。
MDAでは，そのような変換の標準的な記述形式の仕様としてQVT（Query/View/Transformation）を定めており，今後こうした機能を実装した製品が出荷される予定だ。同様にSoftware Factoriesにおいても，このようなDSL間での変換ツールが利用できるようになるだろう。つまり，これらのツールによって，要求開発モデルとシステム開発モデルを工程間で双方向に連携させればよいわけだ。
残るは3番目の問題「完全な要求開発モデルを作成する時間がない」である。この問題に対する解は，要求開発を反復して完全なモデルを目指すか，あるいは一部の作業をシステム開発の時点で行うことにして先送りすることである。システム開発に先送りするとは，ずいぶんと無責任な考え方に聞こえるかもしれない。しかし，筆者はそれでも大きな問題にはならないと考える。その理由は，要求開発の段階でフロント・ローディングが実施されているからである。
フロント・ローディングが実施されているということは，その時点における要求開発メタモデルが存在することを意味する。つまり，モデリングの基準が決まっており，迷いのないリズミカルな作業ができるということだ。ビジネス・プロセス・モデリング，概念モデリング，ユースケース作成なども非常に進めやすくなっているはずである。このおかげで，システム開発要員が要求開発モデリングをすることが現実的になり，作業の一部をシステム開発へ先送りできるのである。もちろん，システム開発側の作業量がそのぶん増加するのは間違いないので，正しく見積もらなければならない。
以上4回にわたり，要求開発によってシステム開発の生産性を向上させる方法について述べてきた。その方法を一言でまとめれば，「技術基盤としてMDD（Model Driven Development）を採用し，要求開発フロント・ローディングを通じて要求開発とシステム開発を連携させること」と言えるだろう。ただ，これだけでは「単なるMDDとどこが違うのか」と疑問に感じる方もいらっしゃるかもしれない。
MDDは一般性の高いアプローチであり，システム開発の全ライフサイクルを通じてモデル変換によって工程を連携させる。なるべく多くのソフトウエア成果物をなるべく自動的に生成することが目標だ。
対して本記事で説明した方法は，要求開発の本来の目標である，ビジネス価値の約束されたシステムを効率的に開発することを主眼としている。要求開発モデルとシステム開発モデルを連携させるのも，これを目標としてのことである。ソフトウエア生成の自動化を最重要テーマであるとは考えていない。そのため一般的なMDDと違って，要求開発側のモデルをビジネス領域の専門家に理解できるモデルの範囲，つまりビジネス・プロセス・モデルと概念モデルにとどめている。
ただ，このように限定しているにもかかわらず，筆者はこの姿勢が単なるMDDに優る強力なプロジェクト管理の方法論を生み出すと期待している。なぜなら，ビジネス・プロセス・モデルや概念モデルが表現しているユーザーの関心事と，実際に構築される情報システムの接点を確実に維持管理することは，現在の常識的開発方法論の適用だけでは困難であり，それが多くのITプロジェクト失敗の背景にあると考えているからである。この点は，今後要求開発を実プロジェクトに適用する過程で検証していきたい。
| （依田 智夫＝要求開発アライアンス理事） |
