BRMS導入にデメリットはあるのか？10年以上のBRMS導入支援実績をもとに解説

　DXの重要性が広く認知された昨今、ビジネスにおいて、ITシステムは欠かせないものとなっています。特に、ビジネスの要求に対して素早く柔軟に対応できることが、ビジネス成功の鍵となっています。BRMSはビジネスルールの変更に対して容易にかつ迅速に対応できる特徴を備えており、DX時代のシステム開発にマッチしていると注目されています。

　このコラムでは、BRMSの特徴を簡単に説明した後に、一般にあまり語られないBRMS普及を妨げているデメリットと、デメリット克服の方向性を示します。

BRMSとは

　BRMSは、ビジネスルール管理システム（Business Rule Management System）の略称で、システムのなかでビジネスに直結するルール（=ビジネスルール）の管理に特化した製品です。ルールを積み重ねて推論や結論を求める特徴から、ルールベースAIとも呼ばれます。

BRMSの特徴

　BRMSがビジネスに迅速に追随できる理由として、大きな特徴が2つあります。

• ビジネスルールを決定表の形のまま管理する
• システムから、ビジネスルールを切り出して管理する

ビジネスルールを決定表の形のまま管理する

　従来のシステム開発は、業務仕様を整理し、設計書を書き起こし、それをエンジニアがプログラミングで実装するという方法が基本です。
　動作するプログラムコードと、業務仕様や設計書の表現形式が異なるため、読み取るのに時間がかかったり、実は仕様通りに実装されていないなどのバグが埋め込まれていたりする可能性があります。

　BRMSは、実装が日本語の決定表（デシジョンテーブル）形式のため、実装と設計書が同じ内容となります。
　設計書として整理したビジネスルールをそのまま実装に反映できるため、修正が容易であることがメリットです。また、決定表は可読性が高く、実装した決定表を業務ユーザーが確認することもできるため、仕様書や設計書などのドキュメントと実装の乖離を未然に防ぐことができます。

システムから、ビジネスルールを切り出して管理する

　従来のシステムは、判断ロジックとなるビジネスルール、システムで利用されるデータ、振る舞いとして動作するプロセスが、ひとつのアプリケーションのなかで複雑に組み合わさることで成り立っています。そのため、ビジネス的に小さな仕様変更であっても、システム改修の時間とコストが大きいケースがみられます。

　例えば、ビジネスルールに修正が発生すると、データとプロセスを含む変更影響を確認する必要があります（リグレッションテスト）。データ項目の修正も同様で、使わなくなったデータ項目を削除するときは、ビジネスルールとプロセスへの変更影響を確認する必要が生じます。

　このように、業務仕様の変更からシステム反映までの作業量が増えて時間がかかりすぎると、ビジネス環境の変化に追随できなくなります。

　BRMSは、業務仕様でもあるビジネスルールだけを、独立して管理しています。その結果、ビジネスルールの変更による影響範囲を限定でき、迅速に修正することができます。

BRMSのデメリット

　ここまでBRMSが、いかに利用価値が高いかを確認してきました。では、BRMSにデメリットはないのでしょうか。BRMS普及を妨げる要因を探っていきます。

　ここでは、世界的に広く認知され、利用されているOSSのDrools（※）のルールエンジンを使うことを前提とします。

　※Droolsは、世界的シェアを持つIBM Decision Manager Open Edition（旧 Red Hat Decision Manager）でも利用されています

独自言語の学習コストがかかる

　決定表が実装そのものであるBRMSでは、正しく動作させるために、一部にルール言語（Drools Rule Language）を埋め込みます。ルール言語はBRMS特有の開発言語であり、この言語を理解していないとルールのバリエーションを増やすことができません。

動作確認環境が業務ユーザーに向かない

　せっかくBRMSの決定表がわかりやすくても、動作確認するには従来の開発と同様、開発環境の知識が必須です。そのため、動作確認には確認用の操作画面をエンジニアが用意するなど、追加の時間がかかります。
　BRMSの決定表形式で素早くルールを実装しても、その後の動作確認に時間を要するため、開発のスピード感に満足いかない可能性があります。

アプリケーションへの組み込みが大変

　Droolsのルール言語で定義されたルールは、Javaプロジェクトへ組み込むことを前提としていますが、組み込むための環境は、別途用意する必要があります。組み込みには他のOSSの利用やスクラッチ実装が必須となるため、ルール実装と同様、専門知識と技量を要します。

設計の知識が必要

　BRMSに限りませんが、1からルール開発していく際、設計の知見が重要となります。

　決定表がわかりやすいこともあって、業務ルールを決定表にしていくこと自体は困難ではありません。しかし、ルールの切り分け方や決定表の単位が適切でないと、BRMSの効果を充分に発揮できない、運用する上で問題が生じる、などの原因となります。

BRMSのデメリットに対する弊社の解決策

　BRMSは、実現のための学習コストが高い（難易度が高い）ことがわかりました。 しかし、せっかく決定表というわかりやすい表現方法と、ビジネスルールの変更に迅速に対応する仕組みを持っているため、実現の難易度が高いからとBRMSを選択肢から外すのはもったいないです。

　オージス総研では、10年以上のBRMS案件の実績をもとに、システム開発におけるBRMS適用の難しさをいかに解消していくか研究を重ねてきました。その成果として、コンセプト、プロセス、メソッド、そして自社開発したツールをナレッジとした「ルールベース開発メソドロジー」を築きあげました。システム開発のルール適用調査や要件定義から、ルール設計や実装に至るまで、BRMS適用したシステム開発の一連のフェーズを支援します。

　また、日本語だけでルール開発できるyonobi®（ヨウノビ）というBRMS開発支援ツールを自社で開発しました。yonobi®は、ルールを簡単に「作れる、試せる、使える」をコンセプトに、ローコードでBRMSを活用することができます。

BRMS適用事例

　BRMSの決定表は保険の価格表との相性がよく、BRMSは保険業界での活用実績が豊富です。保険料は多くの場合、プラン、保障内容、加入時の年齢などによって価格表が異なりますが、それらをすべてコーディングに落とし込んでいくのは骨が折れます。
　それに対し、BRMSであれば、設計通りの決定表がそのまま動作するため、価格変更にも柔軟に対応可能になります。

　弊社の開発実績として、日新火災海上保険株式会社様の事例がありますのでご参照ください。

まとめ

　本コラムでは、BRMSの特徴とデメリットを紹介しました。

　BRMSは高い可読性を実現する決定表と、ビジネスルールを独立して管理する構成によって、ビジネス要求に迅速に対応するシステムを構築できるメリットがありました。

　開発や設計にはコツが必要ですが、初期開発部分を専門家に相談する、yonobi®などローコードのBRMSツールを利用する、という回避策があります。

　複雑な業務ルール、ブラックボックス化してしまったソースコードにお困りの企業様は、BRMSを導入いただくことで仕様を見える化でき、使われていないルールが多いことに驚かれると思います。DXの一環として、ビジネスルールの仕様変更に迅速に対応するシステムを目指している企業様は、ぜひBRMSを検討ください。

最後に

　オージス総研ではBRMS初期開発のご支援、トレーニングなど多数ご用意しております。
　御社業務がBRMS導入効果を充分に得られるか、簡易的な診断からPoC（実証検証）まで行っておりますので、ぜひ一度ご相談ください。

2022年5月24日

※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。