ルールベース・システム概説　　　　　　　　　2013.01.04

　日経コンピュータ（２０１２年３月１５日号）で「超高速開発が日本を救う」の特集が掲載された。その中で、BRMSを活用したアプリケーション開発・保守の効率化が取り上げられた。奇しくも筆者は１０年前のBRMSの利用経験からシステム開発ツールとしての役割に注目した。すごいスピードでの普及を予想したが、金融業界での利用は停滞している。唯一保険業界では浸透し始めているようである。

　昨今、個人ローン・システムの審査プロセス（含む審査モデル）の見直しの動きを耳にする。そこで、無担保ローン審査への適用イメージを例に取り上げる。

A. ビジネス・ルールとは

　“ルール”とはなにか？世の中の様々な行為・活動は、規則・規制・協定など明確にされたもの、あるいは古くからの生活の知恵・暗黙の了解などによって秩序が保たれている。「緑の信号は進行ＯＫ、赤信号は止まれ」、「ラグビーではボールは前方にパスしてはいけない」、「普通自動車第一種免許は満１８歳にならないと取得できない」、「２１時以降、ピアノは弾かないように」など。『ルールとは特定の行為あるいは活動において、人の行為を管理する明快で理解できる規則または法則の集まりの一つである』と定義される。

　ビジネスの世界についても、『ビジネス・ルールとは、ビジネスのある側面を定義あるいは制約するステートメントであり、しかもビジネスの構造をはっきり示し、ビジネスの振る舞いをコントロールし、影響を与えることを意図したものである』と定義される。（ The Business Rules Group, Defining Business Rules “What Are They Really?”から)

　現実のビジネス環境を見ると、商法を初めとしてビジネスに関連する各種法律、各省庁の省令・通達がある。より身近では企業の作成した業務マニュアル、社内通達にも存在する。“業務手順書、業務規程（業務用語の定義、商品条件，判断基準，コンプライアンスなど）の文書化されたもの、あるいは担当者の実務にいかされている知識、経験則、業務知見など明文化されていないものもある。これがビジネス・ルールである。

　ビジネス・ルールは大きく分けると２種類ある。一つは、業務プロセス（制御）に関するルール、他方は業務ロジックに関するルールである。前者の例を挙げると、“保険支払申請書類をチェックした結果、問題なければ支払処理のために経理部に回す。不審点があれば申請者への問い合わせなど再度申請内容をチェックするため審査部門に差し戻す”など、業務の流れをコントロールするルールである。後者の例は、“前述の支払申請書類が完備しているか、記入内容に不審点はないか、不適切な申請内容ではないか、申請期限は妥当かなど”が該当する。Business Rules Applied　では７分類されている。

（図表１　ビジネス・ルールの分類　参照）

　ビジネス・ルールの特徴は以下の様に整理できる。

• 事実を宣言したものである（例．２０歳以上は個人ローンを申請できる）
• 明確性を持った表現となる（例．「ローン申込者は２０歳以上でなければならない」の表現は良いが、「ローン申込者は大人でなければならない」はあいまいな表現でビジネス・ルールとは言えない）
• 環境変化により何度も変更される可能性がある
• 同一の用語（概念が同じ）であっても異なるビジネス分野では異なる意味（ルール）を持つ事になる（例．同一の「申込者」用語であっても、個人融資／企業融資では「個人」と「企業」と異なる）
• ルールの集合体はビジネス・モデルを表現する（集合体を見るとビジネス・モデルが理解できる。例えば、個人融資／企業融資のそれぞれの審査ルールの集まりから該当商品のビジネスが見える）

B. 市場の要求

　企業にとって環境変化への迅速な対応、内部統制の徹底は重要な課題である。また、前述のビスネス・ルールは、既にシステム化されて来たとは言え、未だに人に頼っている部分が多く残されている。そのため、人手作業に伴う下記の様々な問題の解決も重要な課題である。

• 業務手順書、業務規程の作成・更新、および担当者への徹底に手間がかかる
• マニュアル化されていても業務ルールの解釈が異なるケールが発生する
• 担当者の経験判断が属人化しており、全社的なノウハウの共有化が難しい
• これまでのシステムはどちらかと言えば単なるペーパーレス化が目的で、判断は人に任されている。システムの力を借りて均一な判断ができないか　など

“こうした人的要素の課題を解決し、ビジネス・ルールを効率的・効果的に機能させるIT環境”が求められる。これがルール・ベース・システムという事であり、これからのシステムイメージと考えている。 ビジネス・ルールはユーザー部門の管轄である。ユーザー部門が主導権を握ることのできるシステム化環境があれば解決できる。

1. ビジネス・ルールの開発・保守が容易である（ビジネス・ルールと業務ロジックを分離）
2. ビジネス・ルールを一元的に管理（履歴）できる
3. ユーザー部門自身が理解しやすい定義テンプレートを利用して、業務の言葉でビジネス・ルールを定義・変更できる
4. 定義されたビジネス・ルールは、アプリケーションが意識しなくても自動実行される

　 このようなツールを利用してシステム開発が実施できれば、判断ミスの削減・均一化、業務のスピードアップ（手作業の自動化）、業務コストの削減、ルール変更の迅速化、プログラム修正コストの軽減が実現できると考えられる。

　ルール・ベース・システムを実現するソリューションとして、ビジネス・ルール管理システム（Business Rules Management System ：以下、BRMSと表現する）が出現した。 「ルール・エンジン」と呼ばれることもある。 ２００２年のガートナーレポートでは、“ビジネスに敏捷性が要求されるにつれ、使い易いビジネス・ルール・エンジンがより多く求められるようになっている。現在の市場浸透率は２００７年には２０パーセントから８０パーセントまで上昇するとみられている”と予想されていた。”IDC, Worldwide Business Rules Management Systems 2009-2013 Forecast Update and 2008 Vendor Shares”では、BRMSの世界市場規模は２５０億円を超えると強気である。 筆者の記憶では、海外では２０年前頃から活発に利用され始めたが、国内での利用はやっと１０年前頃からで普及はこれからである。

A. BRMSの機能構成

　BRMSは大別すると下記の３つの機能で構成される。（図表２　BRMS機能概要　参照）

1. ルール・エンジン機能：与えられたデータに対し定義されたビジネス・ルールを自動解釈し実行する中枢機能である。実行可能なビジネス・ルールを“アプリケーション・ロジックのうちルールに関連しない画面処理あるいはDBMSとは分離されたソフトウェア層”で稼働させる。
2. ルール・リポジトリ機能：脳機能を果たす。ビジネスのプロセス、ビジネスの意思決定に関連するビジネス・ルールの意味を認識し、取り込み、一元管理する（含む履歴管理）。
3. ルール・ビルダー機能：BRMSの手足機能をとなる。ビジネス・ルールの登録・変更・テスト検証に活躍し、定義されたビジネス・ルールのライフサイクル管理に利用される。

　BRMS各機能の連携を使用イメージで以下に説明する。

1.  

2. 業務担当者は＜ルール・ビルダー＞を使用してビジネス・ルールを定義する

   　・＜ルール・ビルダー＞の提供するルール記述方式（日本語構文記述，表形式，ツリー形式など）でルールを定義する

   　・ルールの曖昧性、完全性、整合性がチェックされる

   　・ミュレーション機能を利用し定義したルールをテスト＆デバッグする

   
   
3. ルールの登録（更新）によりビジネス・ルールが＜ルール・リポジトリ＞に保存される

   　・＜ルール・リポジトリ＞内で、バージョン管理、履歴管理が行われる

   
   
4. BRMSの実行環境稼働に伴い、＜ルール・リポジトリ＞からルールが＜ルール・エンジン＞下に配付（デプロイ）される

    

5. ＜ルール・エンジン＞は業務アプリケーションからの呼出により、該当ルールを自動解釈・実行し、判断結果を返す。

   　・ルール定義にしたがってデータベースのアクセスを処理する

　B. BRMSの特徴と効果

　BRMSの特徴・効果をサマリーすると、『容易な方法を使って、容易な表現で、ビジネス・ルールを見える化できる』、『ビジネス・ルールをアプリケーションから分離する』、『ビジネス・ルールを一元管理する』と言える。

 ビジネス・ルールを“日本語による構文記述方式で”、“テーブル形式の意思決定表で”、あるいは“意思決定ツリー”と言ったビジネス担当部門が容易に理解できる形式で定義でき、重要情報資産の見える化が実現できる。 加えて、ビジネス・ルールをアプリケーションから分離することで、システム開発においてビジネス担当部門とIT部門の役割分担が可能となる。

 これまでIT技術者が担当していた業務ロジック（ビジネス・ルール）の組み込み・変更をビジネス担当部門が担当する。 その結果、システム開発期間の短縮・保守の負担軽減と迅速化が実現でき更に、一度定義したビジネス・ルールは企業内で一元的に管理できる。

 他システムでの利用、新たな制度の導入・改正への迅速な対応、意思決定の精度向上とミスの削減（排除）による顧客へのサービス品質の向上と一貫性の維持が可能となる。 新商品開発、現商品の市場対応力アップなど戦略・施策実行への対応力強化に繋がる。

 ビジネス・ルールを一元的に統合管理できるということは企業として一貫性のある全社的な基盤が存在するということである。内部監査の観点からも望ましい環境が実現できると言える。

　BRMSの利用は保守フェーズで大きな効果をもたらす。 ビジネス・ルールを変更する場合、ユーザー部門で仕様を決定→ＩＴ部門と変更内容を確認→開発・テストというステップを取る。そのため簡単な変更にも数ヶ月を要する事も珍しくない。“BRMSを利用することによるアプリケーション構造の変革”が負荷軽減に大きく寄与する。 “アプリケーション構造の変革とプログラミング技法の変化”について触れておく。

1. ハード・コーディング方式による一体型：DBアクセス、画面インターフェイス等と一体に業務アプリケーションの中に、IF　THEN　ELSE　ステートメントを駆使してビジネス・ルール（規則・条件）をプログラミングするケースである。修正の洗い出し、修正・確認テストに多大な負荷がかかることは目に見えている。
2. パラメータ・ドリブン方式による一体型：ビジネス・ルール（規則・条件）をプログラムから切り離しテーブル化するケースである。基準値の変更には容易に対応できる。しかし、新たなルール追加では、新ルールの確認のみならず他ルールとの整合性の確認が必要となり大変な負荷がかかる。
3. ビジネス・ルール（規則・条件）のプログラムからの分離型：条件そのものを外部に定義・管理することになるため、プログラム変更なく規則・条件の修正・廃止・復活が容易に可能となる。

　C. BRMS利用分野

　以上のような特徴を持つBRMSの利用事例が様々な業種で増えている。

• 通信サービス業：料金計算（課金）、サービス商品管理、サービス障害分析など
• 製造業：受注処理、製品機能構成リコメンデーション、製造処理制御など
• 小売・流通業：Webショッピング、顧客優待サービス、手当・手数料管理など

公益事業、官公庁の業務でも利用が増えていると聞いている。

　金融業界では、保険業務での利用が先行している。例えば、多種多様な特約を持つ保険商品の管理、顧客のきめ細かい要望に対応する新契約査定業務、一時不払い問題が発生した保険支払業務の合理化への対応、自動車保険申込受付・見積（ネット損保）業務など事例が増えている。 しかし、銀行業界ではWeb上でのSFA（Sales Force Automation）、事務ナビゲーションでの利用を聞いたことがあるが、目立った事例を耳にしない。銀行個人向け貸出の業務に焦点を当てただけでも以下のような利用分野が考えられる。

• 顧客セグメンテーション（高リスク顧客、対象顧客、貸出可能顧客の識別）
• 個客属性／行動特性に合った商品推奨・資産運用の相談、キャンペーン管理
• ローン申込の受付・不備対応、申込審査・限度額判定、信用格付・与信管理
• ナビゲーション（貸出関連の業務、営業店の事務、コールセンター対応、Web申込）
• コンプライアンス管理（AML/ KYCなどの金融犯罪対応など）

  新商品の容易な追加、審査基準の迅速な変更、タイムリーなキャンペーン実施などが可能となる。

　筆者もBRMSを利用して銀行の２種類の業務をＰＣでプロトタイピングした経験がある。 一つは、企業財務データから粉飾を発見するルールをシステム化した。 ある融資案件を複数の審査担当の方に個々人の審査ロジックに従い審査していただき、抽出された審査ノウハウから有効性が高いと検証できたルールを構造化して組み込んだ。 他方は、中小企業に対するマーケティング・プロモーションのためのルールをシステム化した。（中小企業に対してキャンペーン先を抽出するルールを複数組み込んでいる。 キャンペーン内容・時期により複数ルールから最適ルールで企業を抽出する）

　A. BRMS利用によるプロセスの変革

　代表的な利用プロセスとして、マーケティング分野と審査分野が考えられる。

1. 集客のためのマーケティング・プロモーションのプロセス：既存顧客の分析、市場分析などBIによるデータ分析により導き出されたルールを活用し、該当顧客を抽出してプロモーション活動に連携する。
2. 申込案件審査のプロセス：過去の取引データを基に導かれたリスクモデルを使用して算出されるデフォルト確率を根拠に、リスク度合いをシステムで判断する分野、および個人情報（属性，勤務先情報，既存取引状況，返済状況，信用情報）を基に、審査担当者が審査判断していたロジック（ビジネス・ルール）のチェックにITを利用する分野である。
3. 途上与信プロセスも当然対象となる。

　BRMSの利用（ルール・ベース審査システム）は、申込案件審査プロセスおよび審査担当者の機能・役割の変革をもたらす。 従来の標準的プロセスでは、“審査支援システムがスコアリングモデルで算出したリスク数値と銀行判断（ブラック／グレー／ホワイト）を一次判断として審査担当者に表示する。 そのリスク度合いに対して、審査担当者は個信情報／銀行取引状況をチェックし、最終判断をする。審査担当者は審査の担い手である。

 それに対し新たな審査プロセスでは、審査担当者が現在行っているビジネス・ルールの判断作業がシステムでチェックされる。その結果はスコアリングモデルの結果と共に最終判断材料として表示される。 審査担当者はこれらの情報を基に、最終的な銀行判断（条件を含む）、あるいは保証会社選定（プロパー融資／グループ保証会社／外部保証会社など）を行う。 この変革は審査担当者の機能（役割）を高める事を意味する。

B. ビジネス・ルール例

　申込案件審査プロセスのビジネス・ルールは、以下の５グループ構成が考えられる。

1.  

2. 商品条件ルール

   　商品申込条件（年齢，資金使途など）から外れるものをルール化し、自動審査で不適格と判断し謝絶対象とする案件を抽出するルールである。

   ・借入申込者の年齢は、融資時点で満２０歳以上でなければならない

   ・借入申込者は社内注意情報に抵触していないこと　など

    

3. 信用リスクスコアリング・ルール

   　これまでもお馴染みの代表的な手法（ツリー分析注1，ロジステッック回帰分析注２など）を用いて過去の取引データを分析し、大数の法則（スコアリング・ロジック）を見つけ出す。このスコアリング・ロジックがルールである。スコアリングルールは信用リスク量を数値化するため、返済能力を判断するのに適している。

   （注１）ツリー分析の場合は、顧客属性情報、勤務先情報、銀行既存取引情報など様々な情報の組合せにより、顧客のデフォルト状況を判断してセグメント分類を行なう。最終的に分類されたセグメントのリスク度合いを勘案したスコアリングモデルにより数値化する。デフォルト状況を効果的に判断する項目が洗い出され、その項目で一連のルールを構成している。したがって、総合評価の色合いが強く、顧客リスクのベーシックなポジショニングが判断できる。何と言っても、人間の思考経路を表現しており審査担当者にとって納得しやすいルールモデルと言える。

   （注２）ロジスティック回帰分析の場合、リスクスコアを算出するために指数関数を使用することになる。算式に使用される項目、係数、算式そのものがビジネス・ルールである。

    

4. 信用リスク＿個人信用情報を活用したルール

   　個人信用情報を様々な角度からチェックするビジネス・ルールである。個人信用情報の開示も増えて来ることを考えると従来と違った視点での効果的なチェックが可能となる。

   ・担保貸し付けがあるのに住居状況が『持家』ではない（資金の切迫度合い・整合性を把握する）

   ・対給与借入比率が４０％を超えている（資金の切迫度合いを把握する）　など

    

5. 不正リスク＿属性情報を活用したルール

   　ローン申込内容と顧客属性から不正を発見しようとするビジネス・ルールである。

   ・借入申込エリアが自宅住所・勤務先住所からかけ離れている（申込者居住場所との矛盾を把握する）

   ・免許証の紛失回数がｘｘ回以上である（だらしなさ、返済意識のレベルを把握する）

   ・資金使途が医療となっている（収入が途絶える可能性がある、資金の切迫度合いを把握する）

    

6. 不正リスク_取引情報を活用したルール

   　ローン申込内容と過去の取引情報から不正を発見しようとするビジネス・ルールである。

   ・家族が既に申し込みお断りしているのに申し込みがされた（家族の資金の切迫度合いを把握する）

   ・借入申込直前に口座開設している（口座開設が明らかに借入目的、資金の切迫度合いを把握する）

C. ルール・ベース審査システムの特徴・メリット

　今後個人信用情報の開示が増えることを考えると、今までノウハウ面で先行している消費者金融・カード会社での審査時着眼点を加味した内容がルール化できるのではないだろうか。

審査に関するビジネス・ルールを組み込んだルール・ベース審査システムは、以下のような特徴・メリットを持っている。

1. リスク計量化を組み込んだビジネス・ルールにより審査材料を充実できる。その結果、案件のリスク状況に応じた審査プロセスの最適化を図ることで、業務の効率化、コストダウンが可能となる。例えば、案件のリスク状況に応じ、ハイリスク案件にはベテランを、低リスク案件には経験の浅い担当者という差別化を図り、人材の有効活用が可能となる。また、全案件同じ審査プロセスで対応するのではなく、謝絶案件は早い段階で排除、ハイリスク案件へは審査を注力するなど、対応の差別化による業務の効率化も可能となる。
2. 不正リスクルールの採用によりレアなケースを見逃さない様、アラーム機能を備えることができる。
3. 審査プロセスを明確にしておくことで、監督官庁への対応も容易になる。
4. 銀行であれば、保証費用も大きな課題である。案件のリスク状況に基づく保証会社選定基準を明確しておけば最適な保証会社決定を支援できる。その結果、低リスク顧客にはプロパー融資を推奨するなど、保証費用削減に繋げることができる。
5. ルール・ベース審査では、ルールの設定しだいで該当者数が少ないニッチな条件も洗い出すことができる。運用の自由度が高まる（ルールの追加・削除が容易）と言える。
6. リスクスコアリング・ルールを考えなければ、分析用のデータを準備しなくても業務をスタートできる。
7. ルール・ベース審査は審査担当者が経験的に行なっていた考え方と類似しているため、納得性が高いと考えられる。

　ルール・ベース審査システムは、これまで保証会社の審査に頼っていた個人ローンの審査業務を銀行として自行が的確な審査態勢を確立する（金融庁監督指針で求めている）ための重要な要素である）

　A. “ちょっとやってみよう”から

　特定の小規模な業務で試行し、その後、当該業務の周辺機能の拡張、あるいは他業務への展開とのアプローチがお勧めである。

　ビジネス・ルールのIT化は、業務プロセス（フロー）を改革することになる。同時に企業としての各組織の役割（権限）の変更につながる。特に、システム化に関連してみれば、ビジネス担当部門は従前の対象業務の要件定義・仕様の決定に加え、ビジネス・ルールの開発および変更を担当することになる。一方、システム部門は業務ロジック（ビジネス・ルール）の開発を担当しないとはいえ、システム開発における中核的な役割がなくなるわけではない。したがって、ルール・ベース・システムの導入に関しては、最終的には全社的な共通認識が必要となる。しかし、こだわり過ぎると“何もできない（しない）”という、お決まりの悪循環に入ってしまう。そこで、“ちょっとやってみよう“をお勧めする。ルール・ベース審査システムを例にとれば、以下の様に、デモパッケージの利用とプロトタイピングの２つの方法が考えられる。

1. デモパッケージが存在すれば、それに触れて新たな審査プロセスのイメージ[４－１）BRMS利用によるプロセスの変革を参照]を体感できる。この変革を理解し、この審査方式をベースに自社の企業文化になじむプロセスを検討すればよい。限られた単純なルールしか取り込んでいないとはいえ、審査プロセスの変革は体感できる。その後、デモパッケージのルールを自社ルールに置き換え、具体的なルール体系の試行を経て、実務で使用すればよいと考える。
2. デモパッケージがなければ、プロトタイピングをお勧めする。ポイントは２点ある。当該業務における自社としてのビジネス・ルールの体系化を検討する事、およびBRMSの体験・選定である。前者に関しては、自社としての審査イメージを試行（プロトタイピング）して、どのようなルールを採用するのか、ルールをどのような体系にするか、審査プロセスはどのような流れが良いのか、グランドデザインすることになる。後者に関しては、ルール定義ツールに触れて、ユーザー部門でも簡単にルールを登録・変更できる事を検証する。また、変更→確認→リリースのプロセスおよびビジネス・ルール管理体制をどのように設計するかなどを検討する。その中で自社にとって必要な機能と価格を評価し、適切なBRMSを選定すればよい。その後は、本番システムへのチューニングである。

　B. 当該業務の機能拡張

　プロトタイピングシステムをベースにした機能拡張である。ルール・ベース審査システムで言えば、自社取引情報の取り込みをどうするか（他システムとの連携）、審査ルールの実装範囲とリスクランクに関するルールをどうするか、審査プロセスをルールで制御するか（ワークフロー制御）などがポイントとなる。

　C. 他業務への展開

　韓国の実情から察すると、利用して導入効果が体験できれば全社的な拡がりに疑問はない。その前に以下を準備しておく必要がある。全社的な業務ルール管理体制（組織）、業務ルール変更管理体制（プロセス、承認履歴管理）、システム開発・保守体系（プロセス）、業務ルール入力体制・入力規約、BRMS作成文書の管理体系などである。

　市場にはオープンソースを含め、いくつかのBRMSが利用可能である注3。その中から自社のプロジェクトにとって適切な製品を選定し利用したいものである。各製品を評価するに際しては、自社で実現したい内容を明確に定義しておく必要がある。製品により何が実現できれば良いのか（要求）、および各要求の重要性を認識することである。そうすることで、評価プロセスを通じて各要求が実現できるか否かを確認することになる。製品をどの様に評価・選定するかのポイントは当資料では省略する。

　製品の評価後、プロトタイプの前段に機能充足性および性能の評価を目的に、POC（Proof of Concept）の実施をお勧めする（POCの詳細は省略）。要件の実現性を確認するには必要なステップである。

（注３)　市場のBRMS製品一例　

　・米IBM：「IBM　WebSphere Operational Decision Management　（ILOGの改称）

　・米プログレス・ソフトウエア社：「Progress Corticon」

　・米Fair Isaac：「Blaze Advisor」

　・韓国イノルールズ：「innoRules」

　・オープンソース製品：「JBoss Enterprise BRMS」　

上記の他、AML、Credit Origination等の業務特化型、WF／BPM連携のプラットフォームも存在する。

　昨今、システムの内製化が叫ばれている。ルール・ベース・システムは、BRMSを開発ツール（開発技法）と考え試行してみるに値するシステムイメージではないだろうか。また、BRMSの中にはビジネス・ルール定義の曖昧性、完全性を検証する機能を持つ製品もある。要件定義作業に利用することで成果物の品質向上に役立つのではないかと考えている。また、要件定義からルールの定義（登録・変更）はユーザー部門、ルールのディプロイ（稼働環境への移行）はIT部門と言った役割分担も検討に値する。まずは体験してみると価値が理解できるテクノロジーである。

参考資料：

Business Rules Applied by Barbara von Halle

　Published by John Wiley & Sons,Inc.

Principles of the Business Rule Approach by Ronald G.Ross

　Published by Addison-Wesley

The Forrester Wave: Business Rules Platforms, Q2 2008

日経コンピュータ（2012/2/16号）「キーワード」

日経コンピュータ（2012/3/11号）「超高速開発が日本を救う」

BRMS分科会　小川　釀一郎