BRMS(ルールエンジン)がもたらすメリット
こんにちは。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時間以上の残業の削減 的確な変化点管理による品質の向上 |
2月17日(金)にBRMSのハンズオンセミナーをSCSK主催にて行います。詳細お申込みはこちらから。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- ルール記述のお約束とBRMSの発展形(Business Resource Planner)
- SIer/クライアント視点から読み解くBRMS導入の効果とは
- 実践! 「TOPSIC SQL CONTEST」の練習問題にチャレンジしよう
- BPMN 2.0エンジンと各社BPMツールの実装
- 米MSが「VS Code」のバージョン1.0を公開、OCIをサポートした「Docker 1.11」が登場、ほか
- ローカル・ディスク上でのファイル操作
- PHPにおける関数:同じような処理をまとめて扱うしくみ
- 注目のOpen Policy Agent、その概要とKubernetesでの活用事例
- Web APIの紹介
- XML-RPCを利用したWeb API