2013年5月28日

５．２　プロセスモデルからビジネスルールを抽出する

まず、弊社の公開コースの受付プロセスをご覧ください。

コース管理者は常に各コースの申し込み状況をモニターしています。人気のある（申込者が多い）コースはあまり問題ないのですが、少ないと本当に開催できるか心配です。例えば上記の例では、開催の10日前に、最低人数に達しているかが問題になります。もし最低人数に達していなければ開催をキャンセルし申込者に連絡しなければいけません。同時に教室のキャンセル手続きも必要です（そのプロセスは上図には記載されていませんが）。

　運よく申込みが順調ですと、早目に最低人数に達します。その時点から「受講票」が発行できます。同時に請求書を発行したりビジネスとしては順調な状況になります。ある日、申込み人数が定員をオーバーします。それ以降の申し込みに対しては「キャンセル待ち」を連絡することになります。上図はこのコース受付のプロセスを図示したものです。

続いて、次の図をご覧ください。

全く同じことをルールを別出しにしたプロセスです。ワークフローが簡略化されていることがわかると思います。しかし業務は全く同じものです。これがプロセスからビジネスルールを別出しして作成している例です。

実際の業務はもう少し複雑です。コースの「定員」はコースによってすべて異なります。例えば、演習やロールプレイの多い「失敗しない要求開発」コースの定員は16名（4名x4チーム）、レクチャー中心の「ビジネスアナリシス基礎」の定員は20名プラス（教室が大きければ少し増やせます）です。また、最近スタートした「CBAP試験対策」コースは個人指導に近く、定員（最大）は12名です。おのおのコースの特色を加味した定員が設定されています。

　コース開催の「最低人数」も同様です。教室の費用を考慮すると最低人数もおのずから決まります。赤字を避けるために必要なものです。例えば「最低人数」は4名です。さらに、コースの特色が加味されます。「失敗しない要求開発」はロールプレイや演習を行うために最低限必要な人数があります。クラス構成上2チームを考えると最少人数は6名となります。赤字にならない要素だけではありません。

　このように、ルールを別出ししてもそのルールそのものがかなり複雑で、コース毎に異なりますから、システム化する際にはフローとルールを別出しすることが極めて重要になります。実際のイメージは次の図のようなものです。

こうすれば、新しいコースを開発しても、コース受付のフローは全く同じです。異なるのはビジネスルールだけそのコースに最適なルールを作成すればよいのです。