PR

 前回触れたように,要求開発におけるモデリングにはシステム開発の場合とは違った難しさがある。中でも問題となるのが,モデルを理解すべきユーザー(業務担当者)自身がモデリングの重要性を認識していない場合があることだ。

 こうした場合,いきなりUMLのモデルを業務担当者に示しても,「理解できない」と拒絶される場合が多い。そもそも,業務モデリングでUMLによる表記などの細かい流儀にこだわるのが間違いと言える。前回の表にもあるように,要求やステークホルダを一覧表にまとめたものも立派なモデルなのだ。モデルが必要だからといって,やれUMLだのと肩肘をはる必要はない。普通に分かりやすく書くにはどうするべきかを考えてみるとよいだろう。

 要求開発のモデルは,システム設計とは違い,業務の観点から行うものである。こうした業務レベルのモデルでは,表記方法の正しさや整合性はそれほど重要ではない。それよりもまず,業務担当者にとって分かりやすいことのほうが大切だ。

 業務フローを例に挙げてみてみよう。UMLでは,業務フローはアクティビティ図として描くことになっている。図1は,アクティビティ図で描いた業務フローの例である。


図1 アクティビティ図として描いた業務フローの例

 しかし,UMLを知らない業務担当者にこの図を示したら,どのような反応が返ってくるだろうか? 例えば,

業務担当者:この黒い丸は何かね?
モデラー:はい,これは開始と終了を意味しています。
業務担当者:じゃ,この黒い棒は?
モデラー:これは,フォーク(分岐)とジョイン(結合)を表していて・・・
業務担当者:「注文を受け付ける」だと長いから,「受注」と書けばいいんじゃない?
モデラー:アクションは,目的語と動詞で記述するのが基本なんですよ。

などという会話が始まるかもしれない。

 UMLの基本を忠実に守ろうとすると,「注文」というクラスはアクティビティ図には登場しない(オブジェクト・フローやノートとして記述することはできるかもしれないが)。ルールに忠実にモデルを記述しようとすると,伝えたいことを図に表せないこともあるのだ。

 ではどうすればいいのだろうか。相手と場合によるが,筆者は図2[拡大表示]のような形で業務フローを提示してみることがある。基本はアクティビティ図であるが,視覚的な見やすさを重視している。何よりもまず,業務担当者に内容を見てもらえることが重要だからだ。


図2 業務担当者が理解しやすいように描いた業務フローの例
[画像のクリックで拡大表示]

 例えば,図2を見て,

業務担当者:営業は忙しくて注文を受け付けるのは無理だね。
モデラー:では注文担当が受け付けるということでよいでしょうか?
業務担当者:与信判断のところのOKというマークはどういう意味かね?
モデラー:クレジットの与信や在庫がない場合は別の業務フローになるので,与信や在庫に問題がない場合を表しています。

などという会話になれば,モデルを作ったかいがあったと言えるだろう。最初から正しいモデルである必要はない。モデルを示しながら業務担当者とコミュニケーションできることが重要である。一度モデルをベースにコミュニケーションが始まれば,モデルの有用性に気づいてもらえるはずだ。そうすれば,徐々にUMLの記法を取り入れていくことも可能になる。

 モデルの記述方法には特に決まりはない。ここで示した描き方も常に良いとは限らない。場合によってはアイコンなどを使わずにシンプルに記述したほうがよい場合もあるだろう。

 とはいえ,全く自由に記述してよいというわけでもない。モデリングではポイントを押さえたモデルを描く意識が必要である。例えば図2では,矢印が実線の場合は業務の流れ,点線の場合はデータの流れ,と「業務の流れ」と「データの流れ」を意識して区別している。実際の業務フローを考えてみると,業務の流れとデータの流れが別になっていることが少なくないはずだ。

 もう一つ,図2では顧客担当と販売支援システムの間を太い実線で区切っている。これは,人間系と情報システム系の境目である。情報システム側では,システムの持つ機能と各種情報を表すエンティティなどを記述している。標準のアクティビティ図にエンティティを記述する記法はないが,情報システムの中にデータが蓄積されることを考慮すると,どのような情報が存在しているかを分かりやすく示しておいたほうがよい。図2では,エンティティに加えて,システムの持つ機能やほかのシステムとの関係なども記述している。

 こうしたノウハウは,書籍「要求開発」(日経BP社発行)などで紹介されているLFD(レーン・フロー・ダイアグラム)を参考に,筆者なりのやり方を追加したものである。LFDは,現場の担当者に見てもらえるモデルとは何かを考えた結果,生み出された記述法だ。要求開発におけるモデリングでは,何よりもまず,「ユーザーに見てもらえるように」書くことが大切である。せっかくモデルを作っても,ユーザーに見てもらえなければ何の役にも立たないことを肝に銘じておいていただきたい。

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