仕様変更の疲弊から脱却する「ビジネス・ルール・マネジメント」

今回は、弊社で取り扱いを開始したBRMS製品に関連してBRM分野の概要、検討指針などの基本事項について解説します。BRMS（Business RuleManagement System）は、BRM（Business Rule Management）を支援するソフトウェア製品の総称です。国内BRMS市場の2012年度の売上金額は9億4,000万円^※1と規模はまだ小さく、国内においては比較的新しい製品分野です。

※1　出典：「ITR Market View：システム連携／統合ミドルウェア市場2013」

ビジネス・ルールとは非常に曖昧で抽象的な言葉です。

教科書的には、「ビジネス・ルールは、ビジネスを運用していく際のガイドとなる、あるいはビジネス運用上の判断の基盤となる、あるいはビジネス運用上の決定を行うための基準となるものである」^※2とあります。

以下はビジネス・ルールの一例です。

・部品在庫がある場合の値引き率は、ICタグの色で決まる。
－青：10%
－赤：15%
－黄：20%

システム視点では、ビジネス・ルールは制約やロジックとして実装される業務要件です。業務で発生する事象ごとにチェック、判断分岐、加工処理を施し、正しい業務アクションを支援します。

※2　「ITエンジニアのためのビジネスアナリシス」（ロナルド・G・ロス、グラディス・S・W・ラム著、日経BP社刊：第1章2pより引用）

システム改修の理由の多くがビジネス・ルール変更に起因することから、ソフトウェアの透過性と保守性の向上を目的に、データベース制約やアプリケーション・ロジックに散在するビジネス・ルールを独立させ、一元管理するというコンセプトが生まれました。

これは、かつて情報システム・アーキテクチャのフレームワークでデータとファンクションを分けた変革の状況に似ています。

変更頻度は、データよりもアプリケーションの方が多いため、相対的に安定性の高いデータを独立させたアーキテクチャにすることは保守性の問題を大きく改善し、経営資源であるデータの共有性を高めました。　

ビジネス・ルールが変わることが仕様変更であり、安定性の低いルールをプロセスと分離することは情報システムの保守性向上の観点においても妥当性があります。

しかし、ビジネス・ルールをアプリケーションから独立して管理するというコンセプトには、違和感を覚える向きもあるかもしれません。

非常に乱暴な見解では、BRMは「ソース・コードからIF文を切り出して別管理するだけ」で、開発者側の視点で見ると「ITの管理対象が増える」ため、価値は見い出せないという理由からです。

しかし、システムの企画時に必ず起こる議論、「当社の業務は独特で他とは違う」、「業務変革のスピードが強みだ」、だから「汎用パッケージは当社に合わない。相当なカスタマイズが必至だ」、「現行システムの仕様は、今の業務に合わない」等の根底にある主語は、ビジネス・ルールであり、業務の流れ自体は比較的安定性が高いものです。

弊社でもビジネス・モデリング・サービスを提供していますが、プロセスが構造化モデルで安定しているのに対し、ビジネス・ルールは、わずか2～3 ヵ月の間にも多くの変更が発生します。そのため詳細設計になっても仕様がなかなか確定できないという現実があります。

ビジネス・ルールをアプリケーションから独立して管理するというコンセプトのもとに開発されたのが、BRMS製品です。

ユーザ視点での利点は、ビジネス・ルールをモデル化し管理することで、複雑なルールも高い透明性を持ち、保守も容易となります。ルール変更はBRMS上で行うため、アプリケーションへの改修は不要か、軽微で済みます。

テクノロジー視点での特徴はルール・エンジンです。パターン・マッチングのアルゴリズムをベースに多層複合的な判断ロジックを効率的に処理し、ルールの外出しで危惧される性能面の不安を払拭しました。ルールのカプセル化で共有化を促進するとともに、ビジネス・ルールのモデリングをプログラム設計に先行して行えることで詳細設計と開発、テストを高速化します。

さらには、製品ごとの提供機能として、論理矛盾、ルールの定義モレの検出、シミュレーション、ルール変更時の影響分析などがあり、ビジネス・ルール管理を支援します。

現在のBRMS製品は、Suite化志向とビジネス・ルール特化志向で拡張がされています。

Suite化志向とは、BRMに加えてBPM（Business Process Management）も範囲とし、ビジネス・ルールとビジネス・プロセスを統合管理するものです。

ルールのカプセル化との親和性が高いことから、SOAソリューションとして組み込まれるものもあります。ただ、Suite製品は製品特有の技術制約が足かせとなる面もあります。

一方、ビジネス・ルール特化型製品はビジネス・ルールのみを管理対象として、アプリケーション本体との連携はAPIやWebサービスで行います。企業ごとのシステム基盤の制約にも柔軟に対応できる利点があります。

ビジネス・ルール特化型製品の中にはルールの設計／開発／保守をプログラマからユーザの手に委ねようと、ルールの記述、管理をノンプログラミングで平易なGUIで操作できるよう使い勝手を高めたものもあります。ユーザ自身でルール変更作業ができるようになれば、業務変革のスピードが格段に向上し経営に寄与すると期待されています。

保険業界では、1990年代から業務を取り巻く環境が劇的に変化しました。まず、 1990年代後半の保険業法改定によって保険商品の自由化が始まり、同じ契約条件の保険でも各社の保険料に大きな差が現れるようになりました。

2000年代になると、銀行での保険販売が開始、さらには通販やネットでの販売も現れるようになり、販売チャネルの多様化が進みます。複雑性を増す営業活動とともに顧客ニーズの多様性も増している中で、保険業界は以下の課題に直面したのです。

1）環境の変化／市場ニーズの変化に対して、業務は柔軟かつ俊敏に対応できなければならない。
2）複雑化する業務において、実行されるプロセスやディシジョンは信頼性を担保しなければならない。

これら俊敏性と信頼性の要求に対して、ビジネス・ルールをアプリケーションのソースコードにハードコーディングした状態では対応が困難でした。現実に一部の保険会社で、システムのルール変更対応の不備による保険金不払いという事故も発生しました。情報システムが業務の変更要求に迅速に対応できないことは、競争力の低下に直結する状態だったのです。

BRMコンセプトおよびBRMSの導入が早かった保険業界の当時の状況は前述のとおりですが、他業界においても同様の状況が起こりつつあります。TPPなど国際通商ルールの変更は待ったなしの状況であり、競争環境は今や地球規模の視野で考える必要が出てきたのです。

外的要因の要請（法規制、内部統制、コンプライアンス、地勢リスク）
規制ルールの変化とともに企業に求められる統制能力や法令遵守などは企業価値を大きく左右します。リスク対応という意味でも、業務品質の信頼性、透明性の確保には確実に取り組む必要があります。これまでのような属人的なオペレーション頼みの対応では潜在的なリスクを増大させるだけです。

競争環境から見た必要性（アジャイル経営）
激化する競争環境の中では、俊敏性がなければ生き残ることはできない時代となりました。販売チャネルやバリュー・チェーンの複雑化によって、場当たり的な対応は困難になりました。経営の舵取りに合わせて業務と情報システムが瞬時に反応しなければならない時代に突入したのです。情報システムにとっては、定期改修のサイクルで変化を吸収していては、経営の要請に間に合わず、かと言って恒常的に改修を行えるリソースはありません。となれば、今までのようなアーキテクチャでは対応困難となるのは必至です。

自社でBRMの導入を検討する価値があるかどうかは、基本的にビジネス・ルールの量、ルールの複雑さ、変更頻度によってある程度判断できます。あるいは、ルール変更によるシステム改修のコストと工数も判断指標となり得ます。

BRMSでのルール・モデリングの基本はディシジョン・ツリーとディシジョン・テーブルを使うため、自社のルールがどの程度複雑なのかを検証するには、ディシジョン・ツリーもしくはディシジョン・テーブルでルールを表現してみることも有効でしょう。

自社のビジネス・ルールが複雑に多数入り組んでおり、属人化した判断にミスが多発している。あるいは組み込んだシステムの変更が頻繁で、そのための改修コストが負担になっているのであれば、検討する余地は十分にあるのではないでしょうか。

前述のように保険業界での適用が進んでいますが、筆者としてはBRMSは広い業種で生産性と保守性の向上に寄与すると考えています。IT部門と業務部門が連携して確実に変化に強いシステムを構築するための手段の1つとして、アシストも強力に推進していきたいと考えています。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。