前回、ルールの重要性を言い、そしてルールといっても人それぞれに違った定義をしているということを話ました。今回はその業務ルールを分類して定義してみようと思います。ただ、ここで注意しなくてはいけないのが、参照情報との境界です。

ルールの前提は、意思決定に直接関与するものであると考えているので、単に参考として見る情報というのはルールではないと考えています。ですから、問題となりそうなものは、規約・契約とか予算などの計画情報でしょう。

こうした情報は確かに意思決定に拘束力を与えるように思えますが、直接的でないのでルールというより参照情報として捉えてほうがよいように思います。これは、それでなくてはいけないというわけではなく、かなり縛られるようならルールとしてもかまわないと思います。

さて、ルールというと、それこそゲームをするのにもルールがありますし、会社のルールがあってそれを破るとクビになったりします。ある世界特有の隠語みたいなものもルールかもしれません。

このように、単にルールといっても様々です。ということは、その性格に応じて少し整理してみる必要があると思います。実はそうして整理してみると、前回提示した「プロセス」「データ」「アクション」にきれいに分類できることがわかります。

すなわち、プロセス、データ、アクションのためのルールの3つに分けて考えると分かりやすいように思います。この区分けで行くと次のようになります。

１） プロセス定義のためのルール
手続きや手順のことで、例えば見積照会ルール、受入検収方法とか、注文書発行手順といったものになります。こうしたルールは、プロセスフローやアクティビティのロールといったものに反映されていきます。プロセス設計の段階で埋め込まれるものです。

２） データ定義のためのルール
データの属性を決めるためのルールで、例えば、無検査認定品とはや、棚卸区分といったように、データの性格付けをするためのルールです。これは、標準的というより各社固有のものになってきます。これらをデータ辞書という形で管理するとよいでしょう。

３） アクション定義のためのルール（オペレーションルール）
アクションを誘導するためのルールで、例えば、与信限度額を超えたら処理しないとか、基準在庫に達したら補充発注するといったように、ある閾値になったらどういうアクションを起こすかを決めることです。これは、動的でオペレーショナルなもので、しかも、実績を積みながら変更を加えていくという不断の改良が大切になります。日々進化させるルールということが言えます。

こうしたルールを設計時、及び運用時に適用して業務システムを効率的なものにすることが非常に大事で、こうした考え方はこれまであまりとられていなかったように思います。開発プロジェクトでそのときだけの一時的で静的な場面でルール適用をするだけで、使いながらシステムを成長させるという意識が乏しかったのではないでしょうか。