Openthologyでは，システム開発の前段階としての要求開発における，プロセス＊1とモデリングについて方法論を提示している。今回は，このうちモデリングについて考えてみたい。
要求開発のコンセプトに「ビジネスの見える化（可視化）」があるが，見える化を実現するにはモデリングが必要だ。要求開発アライアンスの前身がビジネスモデリング研究会であったことからも分かるように，ビジネス・レベルでのモデリングは要求開発の重要なテーマの一つである。システム開発に携わったことのある人なら，システム開発においてモデルが大切であることは十分過ぎるほど理解しているだろう。要求開発におけるモデルの重要性もそれと同じである。
こうしたモデルは，1つの図で描けるわけではない。書籍「要求開発」（要求開発アライアンス著，日経BP社発行）では，Openthologyで標準的に利用するモデルとして表1のようなものを挙げている。
|
表1 Openthologyで標準的に利用するモデル 「要求開発」（要求開発アライアンス著，日経BP社発行）に掲載された表を基に作成 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
表1を見ればお分かりの通り，システム開発と同様に要求開発においてもモデルの多くはUMLで記述する。一般に，1つのモデルは多面的ないくつかの視点で示される。例えば概観ビジネスモデルは，ユースケース図，クラス図，業務フロー図といった複数のダイアグラムで表現する。これは，立体を表現する際に，三面図や影など複数の視点の図を利用するのに似ている。表1は，要求開発の各フェーズの成果物においてどのようなモデルを利用するべきか，その指針を示していると言える。
システム開発におけるモデリングの経験がある人なら，表1を参照して必要なモデルを作成していけば済むと思うかもしれない。しかし，それだけでは要求開発におけるモデリングはうまくいかない。モデリングで大切なのは，モデルの「観点」と「粒度」だ。たとえ同じようなモデルを描くにしても，システム開発と要求開発ではこの「観点」と「粒度」が異なるのである。
観点とは，モデルを作成する視点のこと。表1の「ビジョンとゴール」や「サービス構造」などがこれに相当する。重要なのは，これらの視点の前に「業務から見た」という修飾子が付くことだ（ここではその意味もこめて，単なる視点ではなく，観点と呼んでいる）。例えば，ユースケースにおけるアクターとしてシステムの利用者や管理者を設定してしまいがちであるが，ビジネス・ユースケースでは，業務から見たビジネス上の利害関係者である顧客や取引先などがアクターになると考えなくてはいけない。
もう一つの課題は，粒度と詳細度である。システム開発におけるモデルは，システムを設計するうえで，粒度を細かくしてある程度詳細化する必要がある。対して要求開発におけるモデルは，そこまで詳細化する必要性は少ない。詳細過ぎるモデルは全体を見渡しにくくなり，かえって本質を見失うことが多い。どの程度の粒度や詳細度で記述したらよいかは，モデルを見る業務担当者の判断によって異なる。
このように，システム開発におけるモデリングをしたことがある人ほど，自らの経験からシステム寄りのモデルを構築しがちなので注意が必要になる。要求開発のモデリングでは，観点と粒度において実際の業務とのギャップを埋めることが大切なのである。
もっとも，こうした注意をしてもなお，要求開発の現場におけるモデリングには落とし穴があると筆者は感じている。次回はこの落とし穴と対策について，筆者なりの考えを述べてみたい。
| （鈴村 幸太郎＝要求開発アライアンス） |
