検討会議で要件を詰めていく際は、検討対象となる業務プロセスの漏れに注意を払わなければならない。検討漏れは、大きな要件漏れにつながるからだ。そのため、新業務を業務フロー図などとしてモデリングし、関係者で妥当性を確認するのが一般的である。

 日本ユニシスの福島祐子氏(総合技術研究所 インキュベーションラボ 上席研究員)は、新業務をモデリングする際に、「例外処理の検討漏れを起こしやすい」と指摘する。「配送手配後の注文キャンセル対応」といった例外処理は、業務プロセスごとにいくつも存在する。そのため例外処理をすべて業務フロー図として書くのは難しい上に、数が膨大になるとレビューしきれなくなる。かといって、例外処理を業務フロー図の補足説明として文章で表すと、漏れがあっても気付きにくい。

 そこで、業務の例外処理を漏れなく洗い出すために、日本ユニシスの開発現場では「BMAPROS」と呼ぶ独自の技法を用いている。BMAPROSでは、基本の業務フロー図を書いた上で、例外処理を表形式で洗い出すのが特徴である。

 例えば受注業務であれば、「受注する」「配車する」「受注を締める」「伝票を作成する」といった業務プロセスで構成される基本フロー図を書く。そして業務プロセスごとに、例外処理を確認していく。最初の「受注する」の業務プロセスで、「訂正」「取り消し」という例外処理があることが分かったとする。その場合、他の業務プロセスにも「訂正」「取り消し」の例外処理が存在するかどうかを確かめ、表にまとめる(図3)。

図3●業務の例外処理を整理する
日本ユニシスの現場では、「BMAPROS」という独自の業務分析手法を用いて、業務フローの例外処理を表として洗い出す。例外処理ごとに業務フロー図を書かずに済むのに加え、例外処理の考慮漏れを防げる
[画像のクリックで拡大表示]

 さらに他の業務プロセスについて、「訂正」「取り消し」以外の新たな例外処理があるかどうかを確認する。例外処理があった場合は、上述の表に項目を追加し、各業務プロセスを調べる。

 こうして例外処理を表としてまとめることによって、業務フロー図をいくつも書かずに済む。加えて、例外処理の検討漏れを防げる。また、利用部門の担当者によるレビューが早く終わる利点もあるという。

業務プロセスの同期と並列を明確化

 このほか、業務フローで曖昧になりやすいポイントとして、ヤマトシステム開発の鳥居英明氏(システム技術研究所 研究所長)は、業務プロセスの並列処理を挙げる。業務プロセスを単に矢印で結んだだけの業務フロー図では、一つのプロセスから複数の矢印が出ている場合、並列処理になるのか処理に順番があるのかがはっきりしない。同様に、複数の矢印が一つの業務プロセスを指している場合、先行するプロセスがすべて完了してから実行するのか、先行するプロセスが一つでも完了したら実行するのかが曖昧である。

 そこで鳥居氏は、UMLのアクティビティ図の記号を用いる。並列処理の開始を表す「フォーク」と、並列処理がすべて完了したことを表す「ジョイン」だ。アクティビティ図ではなく利用部門にとって分かりやすい業務フロー図を書く場合でも、フォークとジョインを流用するという。

出典:日経SYSTEMS 2011年10月号 pp.63-64
記事は執筆時の情報に基づいており、現在では異なる場合があります。