では、よりルールエンジンの動きの特徴が表れている例というとどんな例があげられるでしょうか。思うに、たとえば質問に対して答えていき最後に結果を出すといったコンサルティングというか、レコメンドというか…といったシステムの例はそのひとつではないでしょうか。

この動きをルールエンジンの実行サイクルに合わせて見てみましょう。まずは、

１．システムは利用者に対して最初の質問を投げます。
２．利用者は質問に対する回答を行いその回答はデータとして(短期)記憶領域に書かれます。
３．システムはこの回答に合ったルールを選び出し、次の質問を利用者に投げます。
４．利用者はさらに回答を行い結果は記憶領域に書かれます。
５．システムは今までに出した質問の結果と今回の質問の結果を合わせて条件に合うルールを選び出し、さらに質問を繰り返していきます…。
６．そして最後に十分に絞り込まれた結果が得られそれ以上尋ねる質問がなくなった(マッチするルールがなくなった)ところで利用者に結果を返します。

これだけではあまりに抽象的なので、もう少しかみくだいた例として、たとえば、料理に合うワインをおすすめするといった場合を考えてみましょう(この具体的な実装は、Clipsというツールの例としてあげられています)。

まず質問としては、

１．料理は肉、魚、鳥料理のうちのどれですか？
２．料理にはソースがかかっていますか？
３．ソースは、スパイシー、甘口、クリーム、トマトのうちのどれですか？
４．料理の味は、繊細、ふつう、強めのうちのどれですか？
５．ワインとしてお好きなのは赤と白とどちらですか？
……

といった感じ。これら質問をルールとして保持し、ルールの実行部分で質問の回答を記憶領域に書くようにしておきます。
さて、まず最初に１．の質問のルールが動き、質問に対して「肉」という回答をすると、(短期)記憶領域に

・「料理は肉」

と書かれます。次に２．の質問に、「ソースがかかっていない」という回答をすると、記憶領域に

・「料理にはソースがかかっていない」

という事実が追加されます。
次に３．の質問。これは本来、料理にソースがかかっていなければ意味のない質問です。したがって、３．の質問を行うルールの条件部分には「料理にはソースがかかっている」という前提条件を加えておきます。そうすると、現在の記憶領域の状態

・「料理は肉」
・「料理にはソースがかかっていない」

に３．の質問ルールはマッチしないので、ルールは実行されません。一方、２．でソースがかかっていると回答すると自然に３．のルールもマッチしてきます。

このように、質問を行う各ルールの前提条件をきちんと書いておけば、意味のない質問をすることもなく、効率的に結果を求めることができましょう。

さて、実は上の議論では少々ゴマカシがあるのですが、お気づきでしょうか。上の議論では、１．から順に実行することが前提となっているような書き方になっていますが、ルールエンジンの一般的な動きでは上から順に動くという保証はありません。順番に関して何も指定していない(*1)と、上記のルールのうち１．２．４．５．のどのルールが最初に動くかの保証は何もありません。
まあ、論理的には最初に１．２．４．５．のどの質問から聞いても結果は同じなのですが、ワインの好みに対して聞く４．５．の順番はともかく、１．２．は気持ちとしては、１．の次に２．を聞くのがふつうかと。こんなときには、
A.　２．の前提条件に料理の種類が決まっている条件。
具体的には、「料理は○○」という事実があるという条件を加える。
B.　ルールに優先度をつけて、１．が２．よりも先に動くようにする。
というような解決方法があります。まあ、ルールの一般的なお作法としては、A.のほうが推奨ですが、ケースバイケースで一概にどちらがいいというわけでもありません。
さらに質問のかたまり間で順番をつけたいという場合に、たとえば料理に関する質問のルール、ワインの好みに関する質問のルールといったかたまりの間での順番をつけたいというときには、ルールのかたまりとその順番を定義するという仕組みがたいていのルールエンジンに標準的に装備されています(Droolsでは、アジェンダグループとか、ルールフローとか)。

(*1)　実は、ルールが動く順番は全くのランダムというわけではなく、たいていの場合何らかの規則にしたがって、実行されるルールが選ばれます。この規則を競合解消戦略といって、考え方としては、「最新の情報を優先する」、「一般的な条件のルールと、より特殊な条件のルールと両方にマッチした場合は、特殊な条件のルールを優先する」などといった基準があります。

　それはそうと、おかげさまで最近私もルールエンジンの仕事がだいぶ増えてきてうれしい限り。ただ、まだまだ人口に膾炙するといったところではないようで、ルールエンジンの動き等に関連していろいろ質問されることが多々あります。
たとえば
・ルールエンジンのプログラムって、if-Thenのルールが並んでいるけれども、上から順にやっていくの？？
・(上記に関連して)　通常のプログラムの(単体)テストだと全部のパスを通るようにテストするけれども、　ルールの場合のテストでは、全部のパスを通す…ってどのように考えればよい？
・ルールエンジンのメモリ使用量は何に依存してきまるのでしょうか？　ルール数？
・同じようにルールエンジンの処理速度は何できまる？
などなど。

　私もこのような質問をされるようになって、あらためてネットなどを調べてもみるのですが、ルールエンジンの動きとかアルゴリズムとか結構情報が少なくて、ルールエンジンの代表的なアルゴリズムであるはずのReteアルゴリズムの日本語の解説などは、ちょっと探してみたところネット上にはほとんど皆無状態でした。
　というわけで、これからぼちぼちルールエンジンの動きやアルゴリズムなど気が付いたときに書いていきたいと思います。
　さて、最初というわけでルールエンジンの動きから。以前、本宅の記事(プロダクションシステム(ルールベースシステム)とは)にルールエンジンの動きを書きましたが、もともとはこのルールエンジン、人工知能や認知心理学の研究をルーツとするもので
人間が長期記憶にあたる「ルール」を使って、認識した外界の状況(短期記憶に保持される)に合わせて判断を行うという行動がモデルとなっています。
　これをルールエンジンの動きとして翻訳してみると、
１．データの集合に対して、たくさんあるルールの条件部分をひとつひとつデータとマッチングさせて、マッチしたルールとデータのカップルを列挙しておく。
２．カップルの中からひとつを選んで実行する。
３．実行によってデータが書き換えられる場合もあるので、再度１．のカップリングを行う。
４．１～３を繰り返してマッチするルールがなくなったところで実行が終了する。
となります。
　この動きをみるとわかるように、ルールエンジンでは、すべてのデータに対して、すべてのルールの条件部のマッチングを試し、そののちにルールを実行します。したがってルールの実行順序は必ずしも上から順などといったことではなくて(実はそれなりの実行順の規則はあるのですが)、実行順に過度に依存するようなルールの書き方はむしろお作法に反するものという見方が強いです。
　特に最近ルールエンジンがよく使われている入力データのチェックなどは、(チェックそのものだけでいえば)別に順番などはどうでもよく、条件に合うか合わないかで正しくエラーが出ればそれでよいのであって、上記のようなルールエンジンの動きはこの「チェック」という作業に対して非常になじむもののように思います。

　クリストファー・アレグザンダーと言えば、ご存知の方も多いかと思いますが、GoFデザインパターンの発想の源であるパターンランゲージを着想し創りあげた建築家。そのアレグザンダーとシステム内製がどのようにつながるのか訝る方もおられるかと思いますが、実はアレグザンダーは有名な「時を超えた建設の道」「パターン・ランゲージ」以後にも（私が思うに）重要な著作を発表しているのですね。それらの著作「オレゴン大学の実験」「まちづくりの新しい理論」は、実はシステム開発の上でも非常に示唆的な考え方を含んでいるのではないかと思っているわけです。

　特に「オレゴン大学の実験」は、比較的入りやすいかなあと思いますが、残念ながら今のところ手に入りづらいようなので、そのまま本の目次にもなっている６つの原理を序文から引用しておきましょう。
　アレグザンダーらは、コミュニティでの建設と計画の方法を、以下の次の６つの原理にしたがって遂行することで人々が満足する環境を築けるとしています。

　(以下引用)
　一、有機的秩序の原理 The principle of organic order
　二、参加の原理 The principle of participation
　三、漸進的成長の原理 The principle of piecemeal growth
　四、パターンの原理 The principle of patterns
　五、診断の原理 The principle of diagnosis
　六、調整の原理 The principle of coodination
(「オレゴン大学の実験」鹿島出版会 p14 から引用)

これだけですと、少々わかりにくいので、一、二、だけでも、さらに説明付で引用すると、

　(以下引用)

　一、有機的秩序の原理
　　計画や施工は、全体を個別的な行為から徐々に生み出してゆくようなプロセスによって導かれること。

　二、参加の原理
　　建設内容や建設方法に関するすべての決定は利用者の手に委ねること。

(「オレゴン大学の実験」鹿島出版会 p15 から引用)

となっています。(ちなみにパターンの原理のパターンは、パターンランゲージのパターンです)

　さて、この６つの原理を眺めてみると、なんとなく私が「システム開発の上で示唆的」であると言っていることがわかるような気がしません？　今回、「システム内製」と関連して思い浮かべたのが、二、の「参加の原理」。「システム内製」すなわち「ユーザー主体開発」そのものという気がしませんか？　また、一、の有機的秩序の原理などは、EA(エンタープライズアーキテクチャ)を、前もってきちんと定めて個々の開発をその枠内で進めていく…という行き方と真逆のことを言っているようでちょっと面白かったりします。

　もちろん、都市計画や建築の手法がそのままシステム開発に応用できるとは、万事楽観的な私といえども思ってはいませんが、新たな視点を得るという意味ではなかなか示唆に富むものではないでしょうか。

　システム業界では、クリストファー・アレグザンダーと言えばデザインパターンですが、実はデザインパターン以外にも汲み取るべき考え方はまだまだあるのではないかと思っています。

　アレグザンダー恐るべし！

　保険料は、基本料率 * ○○割増 * 保険金額である。
　　ただし
　…の場合は○○割増は1.03
　…の場合は○○割増は1.05

とかいったような。こんな感じで書いた仕様がそのまま動くとなると、業務に携わる人が直接プログラムを保守するということも現実解として十分考えられるようになってきそうです。

　今のところ日本ではBRMS(ビジネスルール管理システム)を使って、現場で業務に携わる人が直接ルールを直すという事例はまだ聞いたことはありません。ただ、ごく一般的な日本の事務現場のExcelシート、マクロの開発力(!!)などを考えると、BRMSでの現場での修正開発も案外いけるのかもしれないなあと思っている今日この頃。
　というわけで、最近「システム内製を極める」という本を読みました。基本的に日経コンピュータの記事を集めた内容なので比較的さらっと読めるのですが、最後「おわりに」には、システム開発にたずさわるものとしては考えさせられることが書いてあります。それはまた次の機会に。

　さて、この言葉を思い出したのは、最近ある雑誌の記事を読んだからです。日経コンピュータの最新9月29日号の「システムを「作らず」に作った」という記事。今回作ったシステムは、ユーザインタフェース部分でひとつのクラウド、帳票生成サービス用のクラウド、ルールエンジン用のクラウド、３つのクラウドの間で通信しながら処理を行うというまさに　「クラウド間でSOAを実現しちゃいました」　的なちょっとおもしろいシステムです。そこそこのパフォーマンスも出ているようで一昔前なら夢物語だったような世界が手の届くところまで来たということですね。

　もちろんこのブログの趣旨からして強調したいのは、ルールエンジンでして・・・^^;。最近のルールエンジンのひとつの典型的な使い方として、今回の例のように、保険料の計算や整合性チェックなどのビジネスロジックの処理部分を、ルールエンジンを用いて独立したWebサービスとして提供するというのがあります。そして将来的には、このサービスをさまざまなアプリケーションで使いまわすということ…もっとも、日本国内で「さまざまなアプリケーションで使いまわす」というところまで行っているところはさすがにまだ聞いたことがないのですが…。

　今回、ルールエンジンがクラウドにのったということになると、上記のようなことがやりやすくなるだけでなく、(もちろんセキュリティの面など解決しなければならないことは多いですが)ルールエンジンを用いてビジネスロジックの処理をサービスとして提供するような可能性、幅がより拡がってくことになるでしょう。冒頭に述べた「マッシュアップ」は、ウィジェットを組み合わせてユーザインタフェース部分をひとつにまとめる感が強いですが、今回のケースは、もう少しビジネスのロジックに踏み込み、クラウドに散在するWebサービス間で物事を処理していく、いわばインターネットSOA、クラウドtoクラウドSOAが始まりつつあるということではないでしょうか。

　最初はルールエンジンの話を書こうと思っていたのですが、結局最後はSOAの話になってしまいましたね。長くなるのでルールの話はぜひ記事を…。

(2012年1月12日追記)　この日経コンピュータの記事は、日経の電子版の12月28日つけ記事「システムを「作らず」に作った…得られた八つの利点」として読めるようになりました。

　ブログを書かない間、Droolsは5.2が出ているし・・・、「アイログ」と入れてググってみると、アイドルグループ育成ゲームが出てきたりするようになっていたり・・・。それはともかく、本日は本の話。前に Amazon で予約していた本なのですが超多忙な時期に出版・送付されてきたもので本棚に積み上げ状態になっておりました。その本は

Agile Business Rule Development：　process, Architecture, and JRules Examples
　　Jerome Boyer、 Hafedh Mili

　IBM(アイログ) の JRules を例にとってはいますが、方法論としてはツールに依存したものではなく、JRules以外でも使えます。その名のとおり一般的な Agile な開発方法論をベースにしており、ドキュメントよりも動くソフトウェアを重視する、利用者との密なコミュニケーションなどといったAgile方法論の原則に則った反復型の開発方法論。
　まだ読み始めたばかりのこの本ですが、久しぶりに出版されたビジネスルールによる実践的なシステム開発の本と言えましょう。ボリュームはありますが、その割りには読みやすいように思えます。JRulesを使わない方も目を通す価値があるのではないでしょうか。

レッドハット、ビジネスルール管理システムの新版「JBoss Enterprise BRMS 5.1」を提供開始

JBoss Enterprise BRMS

複雑な金融事務を“ルールエンジン”で処理　文書イメージのワークフローで効率化も達成【東京海上日動システムズ】