ビジネスルールを識別する
ビジネスルールはさまざまなものがありますが、大きく分けると3種類（表1）に分類できます。この分類ごとに適切な表現形式があるので、その形式に従うことで整理しやすくなります。
手続き的なビジネスルール
業務フローのように業務に流れがある場合は、その流れに一連のルールが存在します。その流れを状態の遷移として整理します。例えば販売管理システムを例にとると「受注待ち」「受注済」「引当済」「出荷済」などの状態の変化が考えられます。これらの状態を変化させるのが画面やイベントになります。図5では「受注済」のときに受注登録でキャンセルを行うと「受注待ち」に戻り、在庫引当指示で「引当済」に遷移します。このようにビジネス上とり得る状態に対して画面とイベントを遷移に割り当てることで画面、イベントの抜けを見つけることができ、同時にそれらの役割を確認できます。
ここで扱うのは大まかな流れとしてのビジネスルールです。細かなルールは扱いません。あくまでもシステム全体から見て理解できるレベルの粗いルールです。細かなルールは次期システムの分析時に行います。
構造的なビジネスルール
構造にともなうルールとは情報構造のルールをいいます。例えば1回の注文で扱える商品の数、注文に対して分納が認められるかどうか、分納できるとして「最大何件までか」などです。ER図もしくはテーブルの関係を調べることで、ある程度情報構造上の制約を知ることができます。その制約を元に保守担当者にヒアリングを行います。システム化される前の手処理の段階では情報構造上の制約はないものです。手処理で行っている間は臨機応変になんとでも対応できているからです。従って情報構造上の制約はシステム化をきっかけに発生し、データ構造を設計するときに決まります。
条件付けによるビジネスルール
表などで整理できるものが代表例です。例えば100個以上は3％割引、200個以上は5％割引などです。また、消費税5％など用語として定義できるものも含まれます。このように複雑な構造を伴わない簡単な条件付けで整理できるビジネス上の決まり事を表します。
分類して整理する
ある程度システムの規模が大きくなったときは、パッケージを使ってシステムを分割します。パッケージ間の関係が整理できると、システムの見通しがよくなります。分類は業務上識別されているものや既存システムの分類を活用します。
パッケージ間の関係は粗に保ち、一方向にするのが望ましいですが、既存システムの分析では綺麗に整理しようとしてはいけません。既存のシステムをパッケージに分割し、そのパッケージ間の関係を整理しても、関係が密になり、双方向の関係になるのが一般的です。それを無理に綺麗に表現しても実体に合わなくなってしまいます。業務に関わる画面とデータを手がかりにパッケージを洗い出し、システムの構成と役割が把握できるレベルにとどめます。パッケージの精度をあげるのは次期システムのサブシステム分割の時に行います。
まとめ
このようにプログラムに頼らないでも既存の資料とヒアリングでシステムを分析することができます。大事なことはシステム全体を俯瞰したレベルで分析することです。細かな情報に立ち入りすぎると「木を見て森を見ず」になります。全体視点を失わずに、システムが何を行っているのかを説明できることが重要です。システムの入出力とデータを洗い出し、それらを機能でつなげます。そして、ビジネスルールを整理することで各々のつながりの意味が見えてきます。
前回と今回でシステムの地図の必要性と整理の方法を説明しました。次回以降は具体的な表現方法について説明します。
