PR

BRMS(ルールエンジン)がもたらすメリット

2017年1月26日(木)
梅野 昌彦植木 雅幸

こんにちは。SCSKでデリバリーを担当している植木と、レッドハットでプリセールスを担当している梅野です。3回にわたり、今注目を浴びているBRMS(ルールエンジン)について、主に技術的な観点からコラムを書かせていただきます。どうぞよろしくお願いします。

BRMSの特徴

BRMSついてはだいぶ認知されてきたと言えるでしょう。Business Rule Management System、その頭文字がBRMSです。内部構造としてはルールエンジンと、ルールを管理するマネージメント部分に分かれます。ここではそのうちのルールエンジン部分について解説していきたいと思います。

ルールエンジンはアプリケーションから呼び出されて動作する、1つのサービスと位置付けられます。ルールとは、業務で定義される「お約束ごと」です。例えば、

「請求金額は、同じ契約番号であれば提供している複数のサービスをまとめて計算する。」

といったものです。

これは、今までであればデータベースのクエリーとして書いたり、アプリケーション内部でIF-THEN-ELSE構文を使って書いたりするのが一般的でした。しかし、ルールエンジンではパターンマッチングという技術を用いて、データにマッチするルールがある時、ルールを引っ張り出して実行する方式を採ります。そのため、WHEN-THENという構文で記述するのが一般的です。そして、ELSEを書かないのが特徴です。ELSEは、IFにマッチしない時に実行される部分です。ということは、ELSEに書かれている部分は、条件IFの否定として扱うか、デフォルト値として、そう設定しておくかという書き方になります。

WHEN-THENだけで記述されるものが、レッドハットの製品だとDRL(Drools Rule Language)となります。

rule "合計"
ruleflow-group "請求額算出"
salience -100
    when
        i: Inner($契約番号 : 契約番号, $小計: 小計  )
        s: Summary(契約番号 == $契約番号, $請求額 : 請求額 )
    then
		s.set請求額($請求額.add($小計));
		retract(i);
//		System.out.println("Inner Clear");
end
記述ルール例

業務ユーザーがこのルールをいきなり理解するのはなかなか難しいと思います。実際の業務では、このように「似たような」ルールがたくさんできることがあります。これをまとめて意思決定表として表現することで、わかりやすくなります。

RuleTable 値引設定_契約番号
CONDITION CONDITION ACTION DATE-EFFECTIVE DATE-EXPIRES
c : Contract() a : Actual()
契約番号 == "$param" CustomerID == c.CustomerID, 商品コード == "$param" Inner I = new Inner(c.get契約番号(),
c.get社名(), c.getCustomerID(),
a.get商品コード(), a.get利用料(), $param);
insert(I);
契約番号 商品コード 個別料率 有効日 失効日
BA001 A001

80%

2017/1/1 2017/12/31
BA001 A002

80%

2017/1/1 2017/12/31
BA001 A003

80%

2017/1/1 2017/12/31
意思決定表ルール例

BRMSは、この「意思決定表」という表の顔と、「パターンマッチング」という裏の顔をうまく使いこなすことが重要です。意思決定表は、横がAND条件、縦がOR条件になります。このANDとORを整理することで、業務ユーザーが見てわかる形式に工夫する必要があります。横に長すぎる(条件が多すぎる)場合は分割し、縦に長すぎる(ケースが多すぎる)場合はデータとロジックを分離できないか、よく考えてみます。この、「業務ユーザーが見て分かる形式」というのがとても重要で、仕様と実装の距離を縮めることにより、バグの発生率を大きく低減できることになります。

冒頭に「ルールエンジンはアプリケーションから呼び出される」と説明しました。ルールエンジンは自主的に何かを行うサービスではありません。そして、すごく重要なことが、ルールエンジンからデータベースを呼び出してはいけないという点です。これをやってしまうと、アプリのコードがそのままルールとして書かれるだけになり、効果がかなり薄れてしまいます。データベースの役割は、データを格納する、たくさんのデータから目的のデータを抽出することです。その役割だけを担うようにします。SQL内にロジックを書いてはいけません。ロジックは全てルールエンジン側で行うこととし、アプリケーションはデータベースから引き出されたデータをルールエンジンに渡す役割にします。

また、ルール内からマスターのデータベースを参照すると、予期しないタイミングでデータが更新されてしまい、期待値と異なった答えが導き出される可能性もあります。そのような場合、何が原因で期待値と異なったかの追跡が難しくなり、システムの不安定さを招きかねません。このような副作用を減らすためにも、データとルールは分離すべきです。

このような観点で全体を整理することにより、何がデータ、何がルールかが明確になり、プログラム全体がスッキリした構成になります。このアーキテクチャ自体は新しいものではありませんが、これができていないとプログラムがあっという間にスパゲッティ状態になるのです。それならば、ルールエンジンの力を借りてこれをやってみてはいかがでしょうか。

じわじわ浸透してきたBRMS

BRMSを使って効果を上げてきているところはこんなにあります。

メインフレームなどで行っていた基幹業務のリニューアル

メインフレームで古くから使われてきた基幹業務システムの再構築が進んでいます。筆者が経験した地方自治体の事例では、メインフレームの保守期限切れに伴って基幹業務システムのオープン化、具体的にはJavaを用いたWebシステムとして再構築をしました。一般的に、官公庁や地方自治体の基幹業務システムには、以下のような特徴があると言えます。

  • 法律や条例によって、業務の形態や条件、計算方法が変わる
  • ベースとなる法律や条例は、それ自体の変更に加え、特別条項の追加などが頻繁にある
  • 税金のように金銭を取り扱う業務もあり、高い品質が求められる

これらの特徴に対し、BRMSが有用なケースは少なくありません。最も大きいのは、仕様の変更や追加が多いことです。仕様の変更や追加の際、素早く変化に対応することも重要ですが、それ以上に既存の仕様に対する影響範囲の特定も重要な点です。BRMSの場合、前述した意思決定表による記述で仕様の見通しを良くし、また宣言型の考え方により、仕様間を疎結合にすることが可能になります。

また、テストフレームワークを用いたテストやCIにより、回帰テストを実施することも可能ですので、影響範囲の特定がテストによっても実現可能となります。

加えて、保守のしやすさも挙げられます。プログラミング言語と比べ、意思決定表は見通しが良く、記述されている内容が理解しやすい表現です。そのため、保守時の対応工数(=保守開発費用)を削減できる上、保守にかかる人数も削減可能となります。

他にも下記のような事例があります。

BRMS事例 小売業

背景/ビジネス課題 顧客接点を最重要視しており、従来はバッチ処理でのデジタルマーケティングを実施していたが、よりコンバージョン率を上げていくためにリアルタイム性を重視したマーケティング基盤を必要としていた
ソリューション JBoss BRMSと JBoss Data Grid製品を使用した、リアルタイムビッグデータ分析ソリューションを適用
導入効果 1キャンペーンあたり数百万円にのぼる、想定以上の売上効果。既存より10〜15%の売上げアップに貢献

BRMS事例 空運業

背景/ビジネス課題 料金プラン作成において、業務担当者がExcelシートを使って作成していたが、Copy & Pasteを何度も繰り返す際に間違いを起こし、手間がかかっていた
Excelシートの管理ができなくなっており、料金作成のナレッジが属人化していた
ソリューション BRMSにて料金作成のナレッジを明文化し誰でもわかるようにした。データ・ロジック・画面を疎結合化し、メンテナンス性の向上を図った
Excelと同じようなWebのインターフェースを持つアプリを作成し、使い勝手を向上させた
導入効果 ツアーパンフレット作成時間の大幅な短縮(半減)
人工知能的なアプローチによる、人の思い込みロジックの改善

BRMS事例 鉄鋼業

背景/ビジネス課題 元々使用していたCOBOLベースのエキスパートシステムの更改
DBテーブル構造の破綻によるルール化の検討
会社合併に伴う工場システムの統一化刷新
ソリューション 製造工程の指示をチャート図とコーディングで行っていたが、それを意思決定表化してわかりやすく整理するなど
業務ユーザー主体で調整可能なようにBRMSを使用する
導入効果 今まで気づかなかった無駄なロジックが可視化された(ルールの正規化)
全社共通基盤としての採用、全社統合システムでの採用

BRMS事例 製造業

背景/ビジネス課題 トヨタ生産方式で製造をしている部品メーカーは、納期を遵守しなければならない。どの工程でどれだけの製品が製造できているかを常にモニタリング・制御しなければならない
ソリューション 機械からの情報を取得し、アプリケーションで表示・警告などを行う。BRMSを使用し、不要な通知の制御、新規機器の対応などを柔軟に行う
導入効果 6ヶ月の稼働で3.3億円にのぼる投資削減効果
製造効率改善による休日出勤の削減
毎日20時間以上の残業の削減
的確な変化点管理による品質の向上
レッドハット株式会社

テクニカルセールス本部 プリンシパルソリューションアーキテクト

1996年より国内大手会社で安全なインターネット商取引事業の立ち上げに従事。その後インテグレーション・メッセージング技術の外資系企業にてQAテスター・製品サポート・コンサルティング・プリセールス等に従事。その後ルールエンジンを中心としたソリューションのコンサルティング・プリセールスに従事。2011年にレッドハットへ入社。現在は前職から数えて10年間の経験を活かしてBRMSエバンジェリストとして主にプリセールス活動を行う。趣味は写真撮影や音楽。

SCSK株式会社

製造システム事業部門 車載システム事業本部 QINeS製品企画部

組込みシステムやWebシステムの構築経験を経て、形式手法VDMの普及・啓蒙・現場適用に従事。 その後、BRMSの推進とともに、BRMSを現場へ適用するプロジェクトの技術面を担当。 現在は、BRMSの経験も活かしながら車載システム開発のツール企画を担当。

連載記事一覧

Think IT会員サービスのご案内

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスのご案内

関連記事