最近、エンタープライズアーキテクチャグループ内の一部の戦略的な人たちから、ルールをもっと自分たちの組織に関連付けたいと依頼があった。ルールをどう いう時に中間レイヤに組み込み、どういう時にサービス内にカプセル化するのかということから、理想的な利用事例と参照実装まで、彼らの関心は多岐にわたっ ていた。そして、ルールを BPM および BI と結びつけることに特に興味を抱いていた。従来の IT の考え方は BPM の乱用をまねく手続き型のコーディングに偏っていると Paul 氏は述べている。彼は、よりバランスのとれた視点をもつために理解しなければならない基本的な項目として次の2つを挙げている。
- どのような抽象的アクティビティにルール技術がよく適しているか
- どういう時に、そしてどういう理由で、ルール技術が使い慣れた選択肢よりもすぐれているのか
現在の BPM 製品は、いずれもルールを組み入れるための何らかのメカニズムをもっているが、Paul 氏は現在の実装がルール技術の本当の能力を抑えこんでいると主張している。
ロジックをプロセスから切り離して外部に出すことによる柔軟性、アジャイル性、アクセシビリティ上のメリットや開発のための時間を、ユーザが知らず知らずのうちに犠牲にしてしまっていることがあまりに多すぎる。
重要なのは BPM がビジネスルールのより広範な利用を押し進めているわけではないということだ。BPM ベンダはむしろ、「自分たちにはプロセスの中で意思決定を行う必要があり、そしてコードやフローチャートよりもルールのほうが意思決定の管理に適してい る」ということを理解している人たちに応じているだけである。
では、BPM に縛られたお決まりの利用事例を越えてルール技術を活用するにはどうすればよいだろうか？ Paul 氏は次のようにいくつかの「ルールの青写真」を提供している。
どういう時にルールが高い確実性で効果を発揮するかについては、明白な経験則がある。以下に例を示すが、適用が望ましい場面のいくつかは意思決定やコンプライアンスのようにタスク中心である。
- 適格（または失格）であると判断するための多くの評価基準や理由がある場合
- 問題（例えば予想外のハプニングやコンプライアンスの欠如など）を知らせる多くの例外がある場合
最初のケースでは、決定は二つの互いに排他的な選択肢の間で行われる。これはビジネスルールにとって最も簡単なケースである。このケースにおけるルール技術の活用は、次のような場合に更に効果的になる。
- 評価基準の数が増加するとき
- 一連の評価基準がより動的になるとき
- 評価基準がより複雑になるとき
ルール技術の利用が適している典型的な領域として、ビジネスにおいて発生する例外の識別と、コンプライアンスの強制が挙げられる。Paul 氏は次のように書いている。
例外はコンプライアンスアプリケーションにおいてごく一般的なものである。ほとんどの規則は要求として表現される。それらは、すべきではないことについて 述べられていることが多い。そのような要求はどれも、演繹的な規則か、アクションを実行するオペレータに変換されなくてはならない。通常そのような変換で は「must」「may」「shall」「will」を取り替えて「if」か「unless」を導入することになる。
要求からビジネスルールへの分析的な変換が一対一以上であったり、複数のクラスやタスクやプロセスに影響したりするなら、明らかにルール技術の利用が望ましい。
ポリシーが要求として表現されることも多いかもしれないが、それらが頻繁に規則としても表現されることに注意してほしい。だから、ビジネス要求と規則に加えて、ポリシーもまた例外を使って実行されるか、変換を必要とするかもしれない。ルールとしての例外ロジックを整備することで、ビジネスプロセス全体を通じて、例外を認識し、コンプライアンスを強制することが可能だ。それも、要求や規 則やポリシーがどのようにチェックされる（あるいは、されるべき）かを冗長に、そして明確に表現する必要なしにである。要するに、フローチャートから要求 （規則の大部分とポリシーの一部を含む）を取り除くことで、生産性やアジャイル性を劇的に向上させることができるのである。
同様に、評価アルゴリズムにおいてルールは有用なコンポーネントとなる可能性がある。
...対象となる評価業務の専門家が経験則に気付いた場合や、リスクや収益性やその他の主要な成績指標との間に相関関係が見つかった場合、ルールを利用すればスケーラブルな評価アーキテクチャの実現が容易になる。
また Paul 氏は、プロセスがごく平凡なものである場合など、ルール技術が適さないケースを判別するいくつかの指標について論じている。
以下の両方に該当するケースではルールを使うべきではない。
- フローチャートに分岐点が少ない
- ロジックが完全に把握されており、将来的な変更が見込まれない
ルールをサービスとしてカプセル化するという観点では、Paul 氏は次のようなアドバイスを提供している。
ルールなどのビジネスロジックをオブジェクトやサービスの内部にカプセル化することについてよく議論されるが、サービスはビジネスプロセスによって統合された意思決定とコンプライアンスにとって有用である。そして、続けて次のように述べている。
要求や規則やポリシーあるいはルールが、モデル内の多くのクラスとプロセス内の多くのタスクにわたる場合、ルールの外出しが強く望まれる。記事の結びとして、 Paul 氏は BPM と BPM 製品との間の統合が現時点で十分ではない点を重要視し、次のように述べている。
BPM ベンダが夢中になっているビジネスルール機能には、ずっとそれに専念していたルールベンダが早くから言及していたアクセシビリティ・管理容易性・機能性・ 性能が欠けており、そして、最上層の BPM ベンダとルールベンダとの間のパートナーシップは十分ではない。それが現在の市場の現実だ。Paul 氏は、BPM ソリューションにルール技術を導入するために現在利用可能で潜在的にベストな統合技術として、以前 InfoQ でも触れた(参考記事) JBoss Drools(source)を強く推している。...
統合能力の制限は、BPM プラットフォームにルールの使用を加えるかどうかという判断に影響を及ぼす。あるベンダの能力がルール技術に専念しているベンダと比較して劣っている場合 でも、そのベンダが内部に有している能力がもっとも実行可能な選択肢となるかもしれない。しかしそれは、ベンダの関心事を内側に閉じ込めてしまうという悪 影響をもたらすことになる。
原文はこちらです：http://www.infoq.com/news/2007/12/haley