ビジネスマンのためのビジネスルール入門⑮

k. shirai

BRMSに大きな関心をもつ方は確実に増えてきていますが、皆一様にモヤモヤを抱えているようです。私が担当させていただいているBRMS入門というトレーニングを通じて、ほとんどのお客様がする質問や不満があります。それは、①BRMSはどのような業務が実際に適しているのか?、②ツールに実装する前にどのようにルールを整理するのか?、③この2つの質問をBRMSベンダーやシステムインテグレーターに聞いても納得のいく回答が貰えない、の3つです。①については、これまでに少しずつ触れてきましたが、詳細は別の機会に譲るとして、今回のBlogでは、②と③について触れてみたいと思います。

ルールの構造体は?

ルールの構造は設計ではなくビジネス要件で決まる

何らかの判断(意思決定)ロジックは、多くのビジネスルールから構成されていることがあります。私のトレーニングコースを受講される方の多くITエンジニアが中心であるため、「判断ロジックは、いくつかのルールセット(粒々のルールの塊)から構成されていることは承知しているが、どのような基準でルールセットを分けるべきか?何階層にすべきか?」というような質問をされます。この考え方は、それが設計の領域であること暗黙的に前提としています。

 

実はここに落とし穴があります。この質問に対して取り扱うべきものは、設計ではなくてビジネス要件の領域なのです。具体的に言えば、「設計者として、それはどのような構造にすることが賢明だろうか?」ではなくて、「ビジネス要件を引き出した結果として、それはどのような構造になるのか?」を取り扱わなければならないのです。したがって、このフェーズで必要となるスキルは、システム設計者としての技ではなくて、ビジネスユーザーから要求を的確に引き出すファシリテーション能力なのです。BRMS実装に関する問題の1つに、ビジネス要件と設計の領域の区別が非常に曖昧なことが挙げられるかと思います。

 

意思決定要件定義のアプローチ

意思決定であれビジネスルールであれ、BRMSに関するモヤモヤが消えない大きな理由があります。それは、BRMSツールに落とし込む前段階において、ビジネス要件を体系化もしくは可視化するアプローチを誰も教えてくれないからです。たとえば、データ構造に関してはリレーショナルモデル、プロセスに関してはBPMN(ビジネスプロセス・モデリングとその表記法)のようなスタンダードが存在します。残念ながら、意思決定やビジネスルールの構造を体系化するアプローチは紹介されてきませんでした。

 

では、諦めるしかないのでしょうか? もちろんその必要はありません。次回からは、米国において比較的幅広く採用されている考え方や新しいスタンダードについて触れていくことにします。

 

(マーケティング担当:白井)

次のBlog

このブログは、弊社が提供するトレーニングコース「BRMS入門」からの抜粋です。ご関心のある方は、こちらをご覧ください。