今、あらためて問う「BRMS」の真価

　エキスパートシステムは、熟練した職人や特定分野の専門家が何らかの事象を前にしたときにどのように行動するかといったルールを探り、蓄積されたルールをベースに事象へのより適切な対応を推論するシステムのことだ。

　推論の結果を基にして、経験や知識が浅い人でも熟練工や専門家と同等のレベルで正しい意思決定が行えるものと期待され、AI研究から生まれた言語「Prolog」やルールベース言語でシステムに実装する試みが盛んに行われた。

　しかし、一部のシステムには実装されて現在でも地道に使われているものの、現実的には当時のビジネスの世界で主流だったCOBOLを利用したシステムを書き換えていくほどには普及しなかった。

　その一方で生まれたのがBRMSだ。これは、システム開発ツールとしてエキスパートシステムの原理や考え方を取り込む一方で、90年代半ばにデータ分析の理論的研究から生まれたビジネスルールの概念と合わさり、既存プログラムを書き換えるのではなく、その中にハードコーディングされているビジネスロジックを「ルール」として抜き出し、管理可能にするユニークな手法をとるものだった。

ビジネスロジックに含まれる「ルール」とは

　ルールとは、「顧客の購買額が◯円以上であれば次の購入時の販売価格は◯％割り引く」というようなものだ。それは「IF〜THEN〜」という条件式で表せる。例えば、保険の査定を行うといった多くのプロセスのフローを必要とする業務では膨大な数となる。

　プロセスのフローの中で、ある条件に対して複数の選択肢があり、そのどれかに決める「決定」を行う部分を「デシジョンポイント」というが、デシジョンポイント1つずつに、数十から数百程度のルールがあるのだ。

　ルールの総体がビジネスロジックというわけだ。ビジネス環境変化などに業務を合致させるためにロジックを変更しようと思えば、この膨大なルールの中の関連部分を見つけ出して改変しなければならない。

　多くのアプリケーションは、ルールをプログラム内部にハードコーディングしているため、変更すべき場所の発見と改変の仕方、さらに影響範囲を知るために、プログラムを解析しなければならなくなる。

　ごく小規模なシステムならいざ知らず、大規模で複雑なプログラムではビジネスロジックの変更を反映するのは簡単な仕事ではない。特に開発時の技術者が既に現場にいない場合、ドキュメントも十分にはそろっていない場合には、恐ろしく時間と手間がかかることになる。「ビジネスロジックのブラックボックス化」が進んでいるのだ。

BRMSによる課題解決

　この問題を解決するのがBRMSだ。その根幹をなす考え方は、アプリケーションとビジネスルールの分離である。

　BRMSはブラックボックス化したビジネスロジックを、ビジネスルールとして抽出して、体系的、系統的な管理を行う。これを行うことにより、ビジネスロジックは誰にでも理解できる「一覧表」のような形に整理され、追加や削除、変更が、システム作成者などの特定人物だけでなく、新人技術者でも、場合によっては業務部門のエキスパートの手によっても実行できるようになる。

　ビジネスロジックの可視化は仕様の可視化にもつながり、ユーザー、開発者、運用担当者、IT管理者のそれぞれの仕様認識の食い違いを防ぐことにも有利に働く。

　アプリケーションはそれ自体にビジネスロジックを組み込むことなく、必要に応じてBRMSからロジック（＝ルール）をあたかもライブラリを呼び出すようにして利用することができる。業務に精通していない開発者であっても、ビジネスロジックはBRMSの方に任せ、単にその呼び出しなどの制御とGUI、データベースの更新、インフラ構築、運用管理というような専門分野に集中することができるため、開発効率の向上が期待できることになる。

BRMSの3つのメリット

　まとめれば、BRMSには次のような3つの利点があるといえる。

（1）ビジネスロジックがルールの一覧表として可視化される

　体系的に整理して管理されるルール群は、難解な記号ではなく自然な日本語や英語、表などで記述可能なので、専門技術者でなくとも、業務に通じた人が見れば理解でき、修正、追加も容易だ。

（2）ビジネスロジックの変更に追随する柔軟性

　ビジネス環境変化に合わせてロジックを変更したいと思えば、そのルールを書き換えればよい。その書き換えたルールをアプリケーションから呼び出せるので、コーディング修正の手間なく、希望通りのシステム改修を実現できる。

（3）超短期構築に貢献

　アプリケーションのコーディングとは独立してルールが管理可能であり、それはさまざまなアプリケーションで共有して利用できる。アプリケーションごとにルールを記述する必要がなくなる上、アジャイル開発の手法にもなじみやすく、コーディング量削減につながり、メンテナンス工数も大幅に削減可能だ。

BRMSを利用した開発の効率化とは

　BRMSのアーキテクチャは、例えば図1のようなものだ。アプリケーションとBRMSの連携にはWebサービス（REST／SOAP）が利用されているが、BRMSはまさに「ルールサービス」を種々のアプリケーションに提供する仕組みであるといえる。

　どんなアプリケーションでも、その開発言語が何であれ、必要に応じてBRMSのルールサービスを利用することにより、コーディングを簡素化でき、保守性も向上させることができる。

　BRMSを利用した開発と従来の開発のステップの違いを図2に示す。大きく違うのは、ビジネスロジックを実装し、テストを行うタイミングだ。

　従来型の開発の場合は、ユーザーがビジネスロジックの動きを確かめるのは、早くても単体テストが終了して結合テストを行う段階以降になってしまうが、BRMSを利用する場合は設計段階からビジネスロジックの実装とテストが可能になる。

　この段階でユーザーの意見を聞きながら開発ステップを進めることで、大きな手戻りなくリリースまで行きつける可能性が高くなる。計画段階で事前にプロトタイプを開発し、ユーザーの反応を見ながら計画作成や要件定義を進める方法も取りやすくなるのも見逃せない。

　加えて大事なのが、保守フェーズの簡素化だ。ビジネスロジックの変更の必要があっても、ほとんどはBRMS内のルールの見直しで済み、アプリケーションに手を入れる必要が最小限になる。

多くの業界で導入が進むBRMS

　こうした利点を活用し、実際にBRMSを実践した国内企業では次のような成果が出ている。

　適用例としては次のような分野が多い。

　その他、ECや小売でのマーケティングやポイント管理、流通業界でのトラック配車などにも利用されており、変わったところではフィットネスクラブの個人向けトレーニングプログラム作成にも使われた例がある。日本は海外に比べて後れを取っているものの、特に保険業界、金融業界などでの導入が積極的に行われ始めているところだ。

BRMSを実現するツールとは

　BRMSの発端となったのは1990年代後半に登場したILOGのツールだが、これは現在IBMの製品に組み込まれて「Operational Decision Manager」として販売されている。またFICOの「Blaze Advisor」も比較的広く導入され、かつてはこの領域の「2強」と目されていた。

　しかし、近年ではそれぞれ特徴を持ったさまざまな製品が現れ、群雄割拠の様相を呈している。日本で提供されているツールは十数種あるが、主なツールと利用しているアルゴリズムなどを表1に掲げる。

　技術的な詳細は本稿では省略するが、アルゴリズムの違いは一般的な優劣を示すものではない。ビジネスルールの量や複雑さに応じ、目的とする業務領域での効率的な意思決定と運用負荷軽減を図れるように選択するべきだ。

アルゴリズムの違いと適用領域の違い

　エキスパートシステムの技術を踏まえた推論アルゴリズムである「Rete（リート、レテなどと読む）」は多くのBRMSツールにそれぞれ独自に拡張されて組み込まれている。

　簡単にいえば、アプリケーションから複数の条件データ（IF〜の部分）が入力されると、ルールの塊であるデシジョンテーブルの条件との一致をパターンマッチングの手法で判断し、条件データとマッチングしたルールの組をルールインスタンスとして確保しておく。複数の条件のルールインスタンスがそろったところで、決められた優先度のもとに順番を付けて「何をするか（THEN〜の部分）」という内容を実行するという手法だ。

　これは推論エンジンとして働くので、ある判断の結果に対し、さらに適用できる別のルールを探すといった複雑な推論で正しい意思決定を促すのに向いている。

　ただし、推論の機能を持つReteベースのアルゴリズムやDETI（Design-Time-Inferencing）アルゴリズムはメモリ消費が通常よりも大きく、例えばデータの妥当性チェックなどのシンプルな用途のみに利用するのなら、高度な推論機能を持たない「手続き型」のツールでも十分な場合も多い。

　これが「手続き型」のBRMSが存在するゆえんである（※1）。実際、今のところBRMSは日本ではそうしたロジックがあまり複雑でない場面で用いられている例がまだまだ多いようだ。

※1：なお、手続き型のツール「OpenRules」は、足りない推論機能を補完するために、制約プログラミングに根差す「Rule Solver」というツールもラインアップに加えており、適宜使い分けをすることを勧めている。

　ロジックの難易度別に3種類の適用例の特徴を表2に示す。

　なお、ここで取り上げているツールはもっぱらルールの管理を行うものだが、一部のBRMSツールではGUIやデータベースのスキーマなどの自動生成機能を持つものもある。そうしたツールでは、ルールを作ればそのままアプリケーションが出来上がることになり、用途は限られるかもしれないが、工期短縮を主眼に据えた開発では有効に利用できそうだ。

今後有望なBRMSの適用領域

　以上のような特徴を持ったBRMSの適用領域は幅広く考えられるが、特に今後有望なのは、CEP（Complex Event Processing、複合イベント処理）への適用と、BPM（Business Process Management）との連携だ。

　CEPはビッグデータ活用におけるキーワードの1つとして知られているように、大量のデータを高速分析する仕組みのことだ。厳密にいうと、CEPとBRMSとは概念的には違うが、IBMのOperational Decision ManagerやJBossのBRMSでは、CEPの機能も統合して提供しており、CEPをリアルタイムのBRMS、広義のBRMSとして捉えることもできよう。

　CEPの例としては、橋梁の管理では膨大な数の多種センサーの情報を絶えず収集し、そのデータのリアルタイム解析により、異常を発見して早期の修理を行うなどの安全対策がとることが可能になっている。海外の事例だが、そうした橋梁管理システムの中核としてCEPが活用されている例がある。

　設備の故障や部材の老朽化、破損などの事実は、各所のセンサーからのデータの変化パターン、あるいは複数のセンサーのデータの相関関係の変化パターンによって知ることができる。何らかの変化パターンが生じたときにどのようなアクションをとればよいかをルール化し、CEPに格納しておけば、日々のセンサー監視情報から問題発生のアラートを上がることが簡単になる。さらに補修工事や部材交換などの対応策がすぐに分かり、被害が起きる前に対処を行うことができるわけだ。

　また、M2M領域に限らず、例えば金融や証券のリスク管理のように複雑な推論が必要な業務においても、CEPは迅速で確実な判断をリアルタイムで行うのに役立つ。ビッグデータから得られる情報を、具体的な行動につなげるために、CEPは今後大きな役割を果たしそうだ。

BPMとの連携

　BPMは、ビジネスプロセスを可視化し、合理化、効率化していく管理システムで、システム連携や統合を含めて業務プロセスの制御や自動化を行うものだ。導入すれば生産性向上やコスト削減に役立つのだが、問題は複雑な判断業務をプロセスフローとして表してしまうと、フローが複雑になりすぎて取扱いが困難になってしまうことだ。

　プロセスフローの中に判断業務をあらわす幾つかのデシジョンポイントが存在することは上に書いた通りだが、BRMSの援用なしにデシジョンポイントの判断ロジックを記述しようとすると、本来のプロセスフローが判断ロジックのフローに埋没してしまう。

　判断ロジックはBRMS、本来のプロセスフローはBPMで記述することによって、透明性、保守性を確保することができる。またシステム連携の際には、データの前処理や後処理が必要な場合があるが、適切な方法で処理するためにBRMSのルールを適用することも可能だ。

　プロセスとルールとは密接な関係にあり、BPMとBRMSとの連携は、何も今に始まることではない。今後はさらに複雑で緊密な連携により、人間系の判断フローを自動化して合理化するような、洗練されたシステムづくりが期待される。

　また上記の分野以外にも、例えばツールの中に（ビッグ）データの分析機能を持ち、機械学習などを援用しながらルールを抽出し、ビジネス環境に合わせてビジネスルールの不断の改善に努めるというような試みもなされている。実際にそういった思想のBRMSも登場し、米国の先進的なユーザーでは導入を始めているところもある。

　以上、BRMSのあらましを紹介したが、日本では一部の成功例が出てきいるとはいえ、一般的にはまだまだ概念や役割、メリットが浸透しているとはいえない。現実的に現在稼働している業務システムにわざわざBRMSを組み込んで置き換えることは、なかなかイメージできないに違いない。

　しかし、開発の短工期化や保守、運用管理コスト削減の必要性はますます高まるばかりであり、IT部門としても、また業務部門としても何らかの打開策が必要なことは、危機感をもっていることと思う。BRMSは、その課題解決に間違いなく大きな役割を果たすことができる。