PR

 Openthologyでは,システム開発の前段階としての要求開発における,プロセス*1とモデリングについて方法論を提示している。今回は,このうちモデリングについて考えてみたい。

 要求開発のコンセプトに「ビジネスの見える化(可視化)」があるが,見える化を実現するにはモデリングが必要だ。要求開発アライアンスの前身がビジネスモデリング研究会であったことからも分かるように,ビジネス・レベルでのモデリングは要求開発の重要なテーマの一つである。システム開発に携わったことのある人なら,システム開発においてモデルが大切であることは十分過ぎるほど理解しているだろう。要求開発におけるモデルの重要性もそれと同じである。

 こうしたモデルは,1つの図で描けるわけではない。書籍「要求開発」(要求開発アライアンス著,日経BP社発行)では,Openthologyで標準的に利用するモデルとして表1のようなものを挙げている。

表1 Openthologyで標準的に利用するモデル
「要求開発」(要求開発アライアンス著,日経BP社発行)に掲載された表を基に作成
モデル名 モデルの観点 表記方法 利用
フェーズ
成果物 ビジネス価値 ビジネス要求 システム要求
BSC戦略マップ ビジョンとゴール BSC戦略マップ 準備 プロジェクト
実施計画書
   
ビジョン分析ツリー ビジョンとゴール 分析ツリー図 準備 プロジェクト
実施計画書
   
立案 概観ビジネス・モデル  
問題分析ツリー ビジョンとゴール 分析ツリー図 準備 プロジェクト
実施計画書
   
立案 概観ビジネス・モデル  
ターゲット分析 ビジョンとゴール 準備 プロジェクト
実施計画書
   
ビジネス・ステークホルダー サービス構造 一覧表 準備 -*  
立案 概観ビジネス・モデル  
ビジネス・ユースケース サービス構造 UML(ユースケース図) 準備 -*   
立案 概観ビジネス・モデル  
概念モデル(概念クラス図) 情報構造 UML(クラス図) 準備 -*  
立案 概観ビジネス・モデル  
デザイン ビジネスToBeモデル
業務フロー プロセス構造 UML(アクティビティ図) 立案 概観ビジネスモデル  
デザイン ビジネスToBeモデル
要求リスト サービス構造 一覧表 立案 ビジネス要求リスト  
デザイン IT基本要求
リスト
シフト IT基本要求
リスト
システム・ユースケース サービス構造 UML(ユースケース図) シフト システムToBeモデル
そのモデルで一番注力すべき要求
そのモデルに関係の強い要求
*「準備教育」に用いるモデル。成果物の対象ではない

 表1を見ればお分かりの通り,システム開発と同様に要求開発においてもモデルの多くはUMLで記述する。一般に,1つのモデルは多面的ないくつかの視点で示される。例えば概観ビジネスモデルは,ユースケース図,クラス図,業務フロー図といった複数のダイアグラムで表現する。これは,立体を表現する際に,三面図や影など複数の視点の図を利用するのに似ている。表1は,要求開発の各フェーズの成果物においてどのようなモデルを利用するべきか,その指針を示していると言える。

 システム開発におけるモデリングの経験がある人なら,表1を参照して必要なモデルを作成していけば済むと思うかもしれない。しかし,それだけでは要求開発におけるモデリングはうまくいかない。モデリングで大切なのは,モデルの「観点」と「粒度」だ。たとえ同じようなモデルを描くにしても,システム開発と要求開発ではこの「観点」と「粒度」が異なるのである。

 観点とは,モデルを作成する視点のこと。表1の「ビジョンとゴール」や「サービス構造」などがこれに相当する。重要なのは,これらの視点の前に「業務から見た」という修飾子が付くことだ(ここではその意味もこめて,単なる視点ではなく,観点と呼んでいる)。例えば,ユースケースにおけるアクターとしてシステムの利用者や管理者を設定してしまいがちであるが,ビジネス・ユースケースでは,業務から見たビジネス上の利害関係者である顧客や取引先などがアクターになると考えなくてはいけない。

 もう一つの課題は,粒度と詳細度である。システム開発におけるモデルは,システムを設計するうえで,粒度を細かくしてある程度詳細化する必要がある。対して要求開発におけるモデルは,そこまで詳細化する必要性は少ない。詳細過ぎるモデルは全体を見渡しにくくなり,かえって本質を見失うことが多い。どの程度の粒度や詳細度で記述したらよいかは,モデルを見る業務担当者の判断によって異なる。

 このように,システム開発におけるモデリングをしたことがある人ほど,自らの経験からシステム寄りのモデルを構築しがちなので注意が必要になる。要求開発のモデリングでは,観点と粒度において実際の業務とのギャップを埋めることが大切なのである。

 もっとも,こうした注意をしてもなお,要求開発の現場におけるモデリングには落とし穴があると筆者は感じている。次回はこの落とし穴と対策について,筆者なりの考えを述べてみたい。

(鈴村 幸太郎=要求開発アライアンス)