ルールエンジンが楽しい理由

私がルールエンジンに出会ったのは、ILOG社に入社した時です。2007年かな？
入社した当時は、「ビジネスルールエンジン担当ね」と言われ、IF-THENに相当するロジックを、業務ユーザ向けの言語で書き直すものだと思っていました。なんでIF-THEN-ELSEで書けるものをわざわざIRL(ILog Rule Language) という特殊なものに書き直さないといけないのか？そりゃ「あたかも自然な日本語」で書くことで、わかりやすくなるけど、そんな手間を掛けるだけのものがあるのか？と思っていました。半年間。

プリセールスとして活動していましたが、先輩方の資料を使ってお客様・パートナー様に説明するも、うまく説明できないのです。何が特徴なのか。単に業務ルールを日本語で書くだけなのか？
で、ある日、先輩に質問（ほとんど噛みついたと言ってもいいくらいｗ）したんです。

「ルールエンジンの何が良いのでしょうか？」

今も強烈に覚えています。先輩はこう言いました。
「いままで封印してきたけど、ちょっと話すわ。」
そこで出してきたのが、ルールエンジンのアルゴリズム、RETEアルゴリズムの説明です。
パターンマッチング。投入するデータ(FACT)からその組み合わせを自動的にエンジン内部で作成し、マッチした組み合わせが実行候補となること（これを評価といいます）、評価が終わったら優先順位に従って実行されること（これをアクションといいます）、アクションが終わった後に、再度評価をする（再評価）ことで、最初に評価した組み合わせではない組み合わせが作成され、また実行されること。

最初聞いたときは、「え？再帰的実行？」と思いましたが、そうではないのです。これが推論なのです。

何が面白いかというと、「壊れたトラックがあれば修理する」というルールと「乗れるトラックがあれば乗車する」という、2つのルールがあるとします。乗れるトラックというのは、修理の必要のないトラックのことです。これを今までの手続き型ロジックで書こうとすると、トラックでループ、部品でループ、人でループ　みたいな、配列を全なめしていくような複数のループや条件文で書く必要があります。
ところが、ルールエンジンではまさにこの2つのルールしか書かないのです。

その後に知ることになったのですが、ロジックを「宣言型」で書くのがルールエンジン、ロジックを「手続き型」で書くのが従来手法、ロジックからDBを参照・更新しないのがルールエンジン、ロジックがDB依存になるのが従来手法など、ルールエンジンを入れるだけでアプリの構造がガラリと変わります。
また、「真のオブジェクト指向」が何かについても深く理解出来ました。ルールを書くにはデータモデルが重要で、データモデルをどう定義するのかが良いのかについても、より深く知ることが出来ました。

それだけではありません。モノの見方まで変わります。色々なお客様の過去のソースコードなどを拝見する機会が多いのですが、何重にもかさなるif文for文の嵐の中、全てのパターンを網羅するテストケースなんて作れないよね？とか、いろいろ無駄が見えて来るようになりました。

アプリケーションのアーキテクチャもモノの作り方も新しくなり、全てが効率よく動かすことができるようになるのがルールエンジンの力なのです。

もちろん全てが薔薇色になるわけではありませんし、多少の努力も必要になりますが、なんか楽しいんですよね。ロジックがあっという間に出来て、バグもあまり出ないプログラミング。もはや、ロジックをどう組み立てるかの次のステップで、「ロジックはどれだけ美しいままでいられるか」です。最終的には機能美まで行きます！

この世界、とんでもなく楽しいのです！ まさにHello World! です。
是非皆さんも、一度はルールエンジンの世界を体験してください！皆さんのスキルを、もう一つ上の層に持っていけること、間違いないです。

ちなみにと、「なぜこれを封印していたのですか？」と聞いたところ、
「ビジネスルールの記述・実行をするツールとして売りたい。そこにこのRETEアルゴリズムの動作という話を入れてしまうと、せっかくの業務ユーザへのアプローチが崩れてしまう。」と、会社の戦略であったことがわかりました...
確かに、業務ユーザにRETEアルゴリズムのアレコレを語ると、「そんな小難しいことはやりたくない」と言われますよね... 笑

ルールエンジンを使ったプログラミング、ホンキで楽しいのです。皆様にも是非一度は試していただきたい技術です。