ルール・エンジン 「innoRules」


私達は、ここ2年ほど個人ローン関連のソリューションに力を入れています。余り大規模な金融サービス会社ではなく、地域金融機関を主たる対象としています。地域金融機関は住宅ローン一辺倒ですが、金利競争が激しく、少し前のような収益性が期待できなくなりました。次に力を入れているのが本体発行クレジットですが、顧客が既に保有しているメジャー・カードとの差別化が出来ず、これも低迷しています。他に新たな収益トップラインもありませんし、金融庁が推奨していることもあって、個人向けフリーローンの事業開拓が急務となっています。ところが、無担保フリーローンの審査ノウハウが蓄積されていません。怖いので、外部の信用保証会社を使うと年率15%程度の利息収入も半分以上が消えてしまう。どうしても、自前の審査システムが欲しいのですが、当初は扱い件数も少ないので大げさなソリューションは金の無駄、かつ、邪魔なだけです。簡単なスコアリング・システムを作ろうにも実績情報がない。加えて、数年前まで一大ブームとなったオートスコアリングで大きく失敗したことがトラウマになっています。そこで、定性的審査でスコアリングを補強しようとなります。定性的審査に使えるソリューションがルール・エンジンです。コンサルタントが持っているノウハウや経験者を中途採用して、そのノウハウをルール化すれば良い。極端な話、数十のルールをエクセルか何かに書き連ねて、審査担当者の机に貼っておくのでも良い。しかし、セグメント別や商品別にルールを使い分けたり、追加更新する仕組みは欲しい。こうしたことから、海外製、国産合わせて多くのルール・エンジンを見たり、試用したりしてきました。

潟Aーネスト・ビジネス・ソリューション(ebs)が販売する、韓国発ルール・エンジン「innoRules」(イノ・ルールズ)の説明とデモを見てきました。昔、製鉄会社ポスコでエキスパート・システムを担当していた技術者達が独立して作った製品で、韓国では銀行、保険などで幅広く使われているそうです。実務面から必要な機能を一通り揃え、といって、余計な機能は省くか、オプション化しており、大変コンパクトかつ高速なエンジンです。金額も500万円台と安く、PCサーバーで充分です。業務系システムとはAPIで連携して、処理しますが、業務系内部で処理ロジックをJavaで組んだ場合と、さして異ならないレスポンスということです。勿論、システム連携なしのスタンダロンでも構いません。

筆者は、20年程前にエキスパート・システムのチームを担当していたことがあります。シェルという大規模なツールも使いましたが、重い、遅い、習得が大変、維持も大変、業務系との連携には大規模開発が必要等々で、とても実用的とは言えませんでした。こうした大きなツールとなると、どうしてもルール数も増えてしまいます。ある大手カード会社では、3千ルールを搭載したのですが、結局は技術的にも業務的にも使い物になりませんでした。その反省から、プロログを使って、if then elseを書きまくったものです。シェルを使うことの問題は簡単に解決したのですが、業務系に組み込む負荷だけは減りませんでした。それに比べると今日では、PCが数段高性能になったことと、ルール・エンジン技術が随分と進化したものだと痛感します。

innoRulesについては、ebs社のサイトでご確認下さい。

http://www.earnest-business.com/activity/innorules01.htm

4つのコンポネントからできた製品です。@RuleBuilder(ルールの登録・変更・検証・管理)ARuleRepository(ルール保管)BRuleServer(ルール解釈・実行)CRuleAPIです。他のルール・エンジンと比べて充実しているのが、テスト・検証機能とルール管理・モニタリング機能です。ルールは、基本的にユーザー部門が作成するでしょう。放置するととんでもない重複、矛盾が発生しますので、どうしてもルール管理責任者が必要です。データ・モデリングしてもすぐにモデルが崩れてしまうのと同じです。4万ルールもレポジトリィに登録しているユーザーもあるそうですが、とても人間が管理できるものではありません。管理機能の充実が不可欠です。ルールの表現方法も、豊富です。if−else、DecisionTable、FlowChartなど8種類あります。蓄積したルールは簡単に検索・閲覧できますし、簡潔に意味を理解できます。昔の、書いた本人以外には理解が難しい文書化とは全く違います。こうなると、プロシージャ言語を使ってプロセスとルール、テーブルを作り込むことが馬鹿らしくなります。一定の約束事を決めた上で、変化の激しいルールをプロセスから分離するという考えが出てきます。1960年代にシステム/360でプログラムとデータを分離したことに匹敵する位の大きな影響が出ることになります。

今回の説明・デモを拝見しながら思ったことは、金融で使われる代表的なルールやデータを整理し、レポジトリィに搭載して、テンプレートというかユーティリティとして共同開発してしまえば、システムの共同化やアウトソーシング、クラウド化などで外部委託しても、自社の独自性も業務面でのガバナンスも確保できる筈ということでした。この種の蓄積型技術は先行者メリットが大きいことに留意すべきでしょう。