1．は じ め に
近年，企業情報システム分野においては，業務（ビ ジネス）ルール管理システム（BRMS：Business Rule Management Systems）と呼ばれる，業務ルール（業 務上の規定や約束事．例えば，交通手段として飛行機 を使うには，片道 500 km 以上でなければならないとい う約束事）を維持管理・実行するための開発環境に関 心が寄せられている [日経 12]．BRMS の核となる技術 は，1980 年代に産業界で普及したエキスパートシステ ム（ES：Expert Systems）と同様なのだが，DSL（Domain Specific Language）[Fowler 12] 入力インタフェース（IF： Interface）により，業務担当者が直接業務ルールを入力 し変更できるようにしたこと，およびプログラム自動生 成機能によりルール変更が，システムエンジニアを介さ ずに，業務基幹システムに直接反映できるようになった ことにより，詳細設計，プログラミング，単体テストな どの情報システム開発工程が大幅に削減され，アジャイ ル開発，アジャイル意思決定を実現できると期待されて いる． これは，入出力 IF を備えた ES が業務システム分野 でリバイバルしたと単純に考えてよいのであろうか？ 本解説の前半では，ES と BRMS の対比と業務ルール 開発工程からこの点について考察し，後半では，オー プンソースの BRMS として，Drools Guvnor（以下， Guvnor）を取り上げ，具体的に BRMS について説明する．2．ES と BRMS
1980年代，多くの ES，および ES の構成要素である RB（Rule Base：ルールベース）が開発されたが，RB の維持が困難であることがしだいに明らかになっていっ た．すなわち，組織では，RB 開発に携わった領域専門 家が 2 ～ 3 年で異動することが多いが，RB の開発背景 や文脈は外在化されていないために，新しく異動してき た領域専門家がその RB の意味を把握できないことから， ESの動作環境が変わって RB を変更維持する作業を実 施することができず，90 年代以降，既存の ES が動かな くなるとともに，新しい ES も開発されなくなった． そのため知識工学の研究分野では，RB や推論エンジ ン（IE：Inference Engine）に仕様を与えるべきという 議論が始まり，モデリングプリミティブの仕様として のオントロジーの研究が開始され [Gruber 93]，セマン ティック Web や LOD（Linked Open Data）研究の基 盤となっている．現在，オントロジーと関連付けた次世 代 ES の研究が進みつつあるが [溝口 12]，オントロジー 構築コストなどの課題があり，産業界に広く普及するに は至っていない． 一方，企業情報システムの分野では，経営と IT の融 合 を 目 指 し て，90 年 代 以 降，BPR（Business Process Reengineering），BPM（Business Process Management）， EA（Enterprise Architecture）など，さまざまな概念 が提唱されてきた．大規模組織では，業務ルールは 1 万 以上，その中で 30 ～ 40％は頻繁に変更されるという 報告があり [ロス 12]，業務ルールが情報システム（ア プリケーション）内にハードコーディングされていれ ば，その維持管理コストは膨大になる．そのような背景 から，業務ルールと情報システムを分離し，RB と推論 エンジンによって業務ルールを独立に管理し，自然言語 入力 IF により業務担当者が直接業務ルールを変更でき， 変更された業務ルールを実行するプログラムを自動生成 して情報システムを自動的に変更維持する出力 IF を備 えた BRMS への関心が高まってきた．ES に自然言語入 力 IF とプログラム自動生成出力 IF を加えた BRMS が， ESが衰退していった 90 年代に登場し，変化の激しいビ ジネス分野の要望と合致して，多くの関心を集めている ことは興味深い．業務ルール管理システムBRMS の現状と動向
Business Rule Management Systems: Current State and Trends
森田 武史
青山学院大学社会情報学部Takeshi Morita School of Social Informatics, Aoyama Gakuin University.
[email protected], http://researchmap.jp/t_morita/
山口 高平
慶應義塾大学理工学部Takahira Yamaguchi Faculty of Science and Technology, Keio University.
[email protected], http://www.yamaguti.comp.ae.keio.ac.jp/
ESと BRMS を比較すると，コア部についてはほぼ 同じであるが，RB 化する知識の性質が異なる．ES は， 領域専門家へのインタビューから獲得した悪構造（ill-structured）ルールを対象としていたのに対して，BRMS では業務ルールを対象とするので，業務担当者が直接入 力編集でき，整構造（well-structured）ルールを対象に しているといえる．ただし，業務ルールより上位に位置 する，業務フロー，業務戦略のような知識が加わってい けば，インタビューにより担当者の考えを明示的にモデ リングする必要があり，前述したオントロジーの導入も 必要となり，より高度な BRMS が必要とされるであろ う． RBへの入力 IF については，ES では，知識エンジニ アが領域専門家にインタビューして専用のルールベース 記述言語を使ってコード化していたが，BRMS では，業 務担当者が DSL を使って，自然言語（に近い構文）で ルールを直接入力する．DSL とは，日本語ではドメイ ン特化言語と呼ばれ，特定のタスク向けに設計されたコ ンピュータ言語である．このように，BRMS では，情報 システム担当者をできるだけ関与させない点が大きな特 色であり，業務ルールのアジャイルな開発・保守を実現 している． RBから情報システムに連携する出力 IF については， 業務ルールからプログラム（Java 言語など）への自動 変換を実現し，統合開発環境との連携も可能にし，業務 アプリケーションのアジャイル開発を実現している．
3．業務ルールの開発工程
本章では，Boyer らが提案している業務ルール開発手 法である，Agile Business Rule Development（ABRD） における業務ルールの開発工程について紹介する [Boyer 11]．ABRD は，BRMS，Business Rule Engine（BRE）， Business Process Expression Language（BPEL）＊ 1，BPMのコンポーネントを業務アプリケーションに配置 するために必要な概念を考慮した，反復型のソフトウェ ア開発プロセスである．ABRD は，アジャイルソフトウェ ア開発の原則[Cockburn 06]に基づいて設計されている． 図 1 に ABRD における業務ルールの開発工程を示す． 業務ルールの開発工程は，発見，分析，設計，作成，検証， 配置から構成され，抽出，プロトタイピング，開発，統合， 強化の五つのサイクルにより，業務ルールが開発される． ABRDでは，開発工程全体を通して，業務担当者のチー ムのみが業務ルールの開発を担当するため，開発コスト の削減が期待されている．また，BRMS におけるルー ル記述支援機能（DSL 入力 IF やルールエディタなど） により，情報システム担当者が業務ルールの開発にほと んど関与しない．一方 ES では，知識エンジニアと業務 担当者が常に密に連携して業務ルールを開発していたた め，大きなコストがかかっていたことが問題であった． 以下では，各工程とサイクルについて説明する． 抽出サイクルは，ルールの発見と分析の繰返しにより 行う．1 日を午前と午後に分け，午前中の 2 ～ 3 時間程 度で，業務プロセス記述，ユースケース記述，領域専門 家（SME：Subject Matter Expert）との面談などから， ルールの発見を行う．午後は，発見したルールの分析と 結果の文書化を行う．ルールの数や複雑さに応じて，本 作業を 2 ～ 5 日程度繰り返す．ここで作成する文書の一 つに Decision Point Table（DPT）がある．DPT は，多 くの業務上の決定が含まれるプロセスにおける要点を記 述したもので，ルールセットの潜在的な候補を表す． 以下では，架空の損害保険会社における請求処理アプ リケーションを例に，業務ルール開発の具体例を示す． この会社は，現状では COBOL＊2で開発された請求処 理アプリケーションを利用しており，このアプリケーシ ョンを BRMS に移行することを考える．図 2 に，請求 処理アプリケーションにおける請求プロセスの一部を示 す．主なプロセスとして，請求の入力，請求の検証，保 険証券の管理，補償範囲の検証があり，これらのプロセ スから作成した DPT の一部を表 1 に示す． プロトタイピングサイクルでは，ルールの設計と作 成を行う．設計を行う際には，抽出サイクルで作成した DPTを開始点として，DPT における決定点（DP:Decision Point）をルールセットに対応付ける．ルールの定義に 必要なデータモデル，どのようにエラーや例外を出力す るか，ルールエンジンにより用いられる各ルールセット の入出力パラメータなどを，設計者は考慮する必要があ る．ルールの作成は通常，統合開発環境を用いて行われ る．問題が発生した場合には，抽出サイクルに戻る． 表 1 に示した DPT における DP：請求の検証につい て記述したルールの一部を表 2 に示す．また，図 3 に ＊1 http://bpel.xml.org/about-bpel ＊2 事務処理用に開発されたプログラミング言語： http://www.cobol.gr.jp 図 1 ABRD における業務ルールの開発工程 図 2 請求処理アプリケーションにおける請求プロセスの一部
請求の検証におけるデータモデルの例として，保険証 券クラスを示す．次の「開発サイクル」において，表 2における VC05 のルールを実行可能な形式で作成す る際には，保険証券クラスにおける保険契約満了日 （expirationDate）フィールドを参照する．BRMS 上での モデル作成例については，4･4 節を参照していただきたい． この段階で，原子レベルのルール（意味を損なうこと なくこれ以上分解できないルール）に変換する必要があ る．原子レベルのルールに変換する理由として，ルール の理解や維持管理を容易にすることやルールの実行効率 を向上させることなどがあげられる．例えば，「費用が 発生して 1 年以上後に請求が提示された場合，または請 求者が過去 1 年以内に海外に 182 日以上滞在していた場 合，保険は海外で発生した医療費を返済しない」という ルールがあった場合，「請求の作成日付が医療費の治療 の日を 1 年以上経過した場合に医療費を拒否」と「請求 者が過去 1 年以内に海外で 182 日以上を過ごした場合に 請求を拒否」の二つの原子レベルのルールに変換する必 要がある．表 2 における VC01 や VC05 は，原子レベル のルールとなっている． 開発サイクルでは，Test-Driven Development（TDD） [Beck 03]アプローチを用いて，実データによるユニッ トテストケースのセットを作成し，実行可能なルールの 作成とその検証を行う．Boyer らの経験上，決定支援シ ステムの開発では，文書上でのルールの定義よりも，実 行可能なルールのほうが重要である．開発サイクルでは， 設計，作成，検証を主に 3 ～ 4 週間程度繰り返す． 実行可能なルールについては，ルール記述言語を用い て記述する．その際，BRMS が提供しているルールエディ タなどを利用する．BRMS 上での実行可能なルール作成 例については，4･5 節を参照していただきたい． 統合サイクルでは，開発中のルールセットをすべて サーバに配置し，テストシナリオに従ってテストを行う． テストシナリオの具体例は以下のようなものである． ジャック・ビーはカリフォルニア在住の架空損害保 険会社の顧客であり，3 年間良好なドライバーであっ た．あるとき，ジャックの友人のマークを車の助手 席に乗せていると，軽い自動車事故に遭い，マーク が首に軽いけがをしたため，ジャックは保険の請求 をした．マークは事故の翌日に病院へ行き，医療提 供者に従っている．病院と医療提供者は，架空損害 保険会社に請求書を送っている．ある医療請求書に は，事故があった日の 6 か月後の治療日での首の マッサージが含まれている．その請求書は却下され るべきである（事故後，保険契約に記載された指定 の期間内に請求書が提出されていないため）． 上記のようなテストシナリオについて，モデルのイン スタンスを用いてファクトを作成し，知識ベースに格納 することで，ルールを適用可能にする．BRMS 上でのテ ストシナリオ作成例については，4･6 節を参照していた だきたい． 図 3 請求の検証におけるデータモデルの例（保険証券クラス） 表 1 請求プロセスから定義した DPT の一部 表 2 請求の検証に関するルール記述の一部 決定点 （DP） 説 明 ルール発見のソース 自動化の現状 ルール所有者 請求の検証 （関連ルールを 表 2 に示す） システムに入力された請求や 医療請求書が有効かどうか検証する 領域専門家へのインタビュー，保険に関する法律文書や保険契約 手動 保険査定部門 補償範囲の 検証 システムに入力された請求に適用する，補償範囲と控除免責金額を検証する 領域専門家へのインタビュー， 保険契約データベース （補償範囲と控除免責金額の種類を記録） 手動 保険査定部門 請求または 医療請求書の検証 請求または医療請求書がシステムに入力された後に要求される 以下のルールのいずれかに違反した場合には，請求は却下される．被保険者は，正確なデータを提供する必 要がある．矛盾したデータの抽出が早くできれば，処理コストを下げることができる． ルール ID ルールの説明 ルールの分類と説明 VC01 請求は事故から 30 営業日以内に開始すべきである． Guidance. この日数は保険契約により決められる． VC05 請求は保険契約満了日より前に発行されなければならない． Constraint.
最後に，強化サイクルでは，ルールセットの完成と調 整を行う．強化サイクルは，ルールの作成，検証，配置 の繰返しにより行われるが，領域専門家との面談も必要 となる．これまでのサイクルは，業務担当者が主に実施 するが，強化サイクルは，業務担当者よりもビジネス指 向である，ルールセットや業務ポリシーの所有者が担当 し，最終的に彼らのペースで，ルールセットを完成させる． 開 発 プ ロ セ ス を 統 合 開 発 環 境 Eclipse＊3上 で 定 義
可 能 な Eclipse プ ラ グ イ ン で あ る Eclipse Process Framework（EPF）＊4を用いて，ABRD はオープンソー スで開発されており，EPF の Web サイト＊5で公開され ている． ABRD以外の業務ルールの開発工程として，ブレイズ・ コンサルティング株式会社が提供している資料 [BLAZE 07]も参考となる．
4．オープンソースの BRMS：Guvnor
4･1 概 要 本章では，代表的なオープンソースの BRMS である Guvnor＊6について紹介する．Guvnor とは，複数人で 共同でルールや知識ベースを管理することが可能な Web アプリケーションである． 3章で紹介した ABRD は，特定の BRMS に依存しな い業務ルールの開発工程を定義している．Guvnor は， 図 1 に示した ABRD の業務ルール開発工程における， 作成，検証，配置で用いることができる． 図 4 に BRMS のアーキテクチャ図を示す．Guvnor は， 図 4 の BRMS アプリケーションに相当する．業務シス テムは，図 4 のユーザアプリケーションに相当する． Guvnorは，Drools＊7と呼ばれるビジネスロジック統 合プラットフォームの一部として提供されており，Rete アルゴリズム [Forgy 82] をベースとするルールエンジ ンを用いて実装されている．Rete アルゴリズムは，効 率的なパターンマッチングを行うことを目的としてつく られたアルゴリズムであり，ES の基盤として利用され てきた．Drools は，JSR-94＊8の Java Rule Engine APIを実装した Java のルールエンジンライブラリも提供し ている．図 4 中の「drools-repository」，「drools-compiler」， 「drools-core」は，Drools が提供する主な Java ライブ ラリを示している．業務システムからこれらの Java ラ イブラリの API を用いることにより，Guvnor を経由し て，データストアに格納された業務ルールの獲得，知識 ベースへのルールの適用とその結果の取得などが可能 となる．以上より，業務ルールと業務システム実装の分 離が可能となる．なお，JBoss Enterprise BRMS＊9は， Droolsを元にレッドハット＊10が製品化したものである． Guvnorは以下のような場合に有効に活用できる． ● ルールのバージョン管理を行いたい場合 ● さまざまなスキルレベルをもつ複数のユーザがルー ルにアクセスし編集する必要がある場合 ● ルール管理に関する既存の基盤がない場合 ● アプリケーションの一部となっている技術的なルー ルではなく，「業務ルール」を多数管理する必要が ある場合 Guvnorの対象ユーザは，業務アナリスト，ルールの エキスパート，開発者，ルール管理者などである． Guvnorは，モデル，DSL，ルール，決定表，テスト シナリオなどをデータストア（リポジトリ）に格納し， バージョン管理することが可能であり，これらをまとめ て「アセット」と呼ぶ． Guvnorの 特 徴 と し て，3 種 類 の ル ー ル エ デ ィ タ （Guided Rule Editor，ルールテンプレート，決定表），
複数のアセットをまとめて一つのパッケージとして管理 する機能，DSL を用いてルールの条件部と結論部を定 義する機能，バージョン管理機能，ルールのテストシナ リオ作成・実行機能，ルールの検証機能，カテゴリー化 機能，デプロイ機能，セキュリティ（ユーザ管理とロ グイン機能），データのインポート・エクスポート機能， 図 4 BRMS のアーキテクチャ図 ＊3 https://www.eclipse.org ＊4 http://www.eclipse.org/epf/ ＊5 http://epf.eclipse.org/wikis/epfpractices/ の左 側にあるメニューの practices > Additional practices > Agile Business Rule Developmentから参照できる．
＊6 http://www.jboss.org/drools/drools-guvnor.html ＊7 http://www.jboss.org/drools/ ＊8 https://jcp.org/en/jsr/detail?id=94 ＊9 http://www.redhat.com/products/ jbossenterprisemiddleware/business-rules/ ＊10 http://jp.redhat.com
アセットの REST API による操作，WebDAV との連携 機能，統合開発環境 Eclipse との連携機能などがあげら れる． 本稿では，紙面の都合より，Guvnor のインストール 方法については，省略する．インストール方法につい ては，関連書籍 [Browne 09] や Guvnor のユーザガイ ド＊11が参考になる．DroolsやGuvnorの詳細については， [Amador 12]が参考になる． 本章で紹介する Guvnor のパッケージをエクスポート したサンプルリポジトリを著者らにより GitHub 上に公 開した＊12．興味のある方は，リポジトリをダウンロー ドし，Guvnor 上にインポートすることにより，アセッ トの確認やテストシナリオの実行が可能である． 4･2 サンプルルール 以下では，科学研究費（科研費）国内出張における日 当（1 日分）を求めるための以下の三つのルールを例と して，Gunvor（ver. 5.5.0）の利用方法を説明する． ● 【科研費国内出張日当 A】職位が教授の場合，日当 は 4,000 円 ● 【科研費国内出張日当 B】職位が准教授または専任 講師の場合，日当は 3,500 円 ● 【科研費国内出張日当 C】職位が助教または助手の 場合，日当は 3,000 円 4･3 Guvnor の画面構成 ログイン後に表示される Guvnor の初期画面を図 5 に示す．「Browse」タブでは，作成者，アセットの種 類，更新日時などからアセットの検索が可能である． 「Knowledge Bases」タブでは，アセットの作成が可能 である．「QA」タブでは，ルールのテストシナリオを参 照可能である．「Package snapshots」タブでは，パッケー ジのスナップショットの作成と参照が可能である．ここ で，パッケージとは複数のアセットをまとめて一つの名 前を付けたものであり，スナップショットとは，ある時 点のパッケージ内容に名前を付けて保存し，参照可能に したものである．「Administration」タブでは，インポー ト・エクスポートやユーザ管理などが可能である．本章 では，「Knowledge Bases」タブを中心に，Guvnor の利 用方法を説明する． 「Knowledge Bases」タブでは，パッケージの作成，デー タ列挙（Enumerations），DSL を用いたルールの条件 部と結論部の定義，モデルの作成，業務ルールの定義， テストシナリオの作成などが可能である． 最初に，複数のアセットを管理するためにパッケー ジを作成する必要がある．業務ルールは，ルールの定義 に必要なデータ構造を規定したモデルを参照するため， ルールを定義する前にモデルを作成する必要がある．ま た，ルール作成者が容易にルールを作成できるようにす るために，適宜，DSL によるルールの条件部と結論部 の定義とその際に参照するデータ列挙を事前に定義する ことができる．次に，作成した業務ルールを検証するた めに，テストシナリオを作成し，ルールの検証を行う． 最後に，パッケージのスナップショットを作成し，デプ ロイを行うことで，統合開発環境 Eclipse を利用して， Javaプログラムより，モデル，ルール，テストシナリ オなどを参照することが可能となる． 4･4 モデルの作成 科研費国内出張における日当を求めるためのルールで は，氏名（name），職位（ jobTitle），日当（dailyAllowance） の三つの属性が必要となる．Guvnor では，オブジェク ト指向におけるクラスのフィールドやデータベースにお けるテーブルと同様に，データ型付きの複数の属性を定 義し，名前を付けてモデルとして管理することが可能で ある．ここでは，氏名と職位を Text 型（文字列型），日 当を BigDecimal 型（任意精度の符号付き小数）として， 「KAKENHIDomesticTripModel（以下，KDTModel）」 を定義する．図 6 に科研費国内出張に関するモデルの作 成画面を示す．図 6 に示すように，GUI によりモデル ＊11 http://docs.jboss.org/drools/release/ 5.5.0.Final/drools-guvnor-docs/html/index.html ＊12 http://t-morita.github.io/GuvnorExamples/ 図 5 Guvnor の初期画面 図 6 科研費国内出張に関するモデルの作成画面
の定義が可能であるが，内部では図 7 に示すような構 文でソースコードが保存されている．データ型について は，Java 言語におけるデータ型と対応付けられており， Guvnorのモデルを Java 言語におけるクラスに変換可 能となっている（Text は Java 言語における java.lang. Stringクラス，BigDecimal は Java 言語における java. math.BigDecimalクラスに対応付けられている）． 4･5 ル ー ル の 作 成
§ 1 概 要
Guvnorで は， ユ ー ザ の 状 況 に 合 わ せ て，Guided Rule Editorのみ，Guided Rule Editor と DSL，決定表 の主に 3 種類の方法を用いて，ルールを作成することが できる．業務担当者が直接ルールを作成可能にするため に，通常，BRMS では Guided Rule Editor と DSL を組 み合わせて利用することが多い．情報システム担当者が ルールを作成する場合には，Guided Rule Editor 単独で 利用することも考えられる．また，複雑な条件判定を伴 うルールを作成したい場合には，決定表の利用が有効で ある．
以下では，各方法を用いて，科研費国内出張における 日当を求めるルールを作成する例を示す．
§ 2 Guided Rule Editor によるルールの作成
「【科研費国内出張日当 A】職位が教授の場合，日当は 4,000円」のルールを Guided Rule Editor を用いて作成 した画面を図 8 に示す．Guided Rule Editor は，条件部 （WHEN 部），結論部（THEN 部），オプションの三つ の部分から構成される． 条件部では，ルールの実行条件をモデルと比較演算子 などを用いて定義する．図 8 の条件部では，KDTModel のインスタンス（tm）を用意し，tm における jobTitle フィールドの値が「教授」と一致（matches）すれば， 結論部を実行するという条件となっている．また，フィー ルドの値については，結論部で参照できるように，変 数を割り当てることが可能となっている．図 8 の条件 部では，変数「jt」に jobTitle フィールドの値を，変数 「n」に name フィールドの値を割り当てている．なお， nameフィールドについては，結論部のコンソール出力 時に参照するためだけに用意されているため，比較演算 子による演算は行っていない． 結論部では，モデルのインスタンスのフィールドに 値をセットしたり，Java プログラムのコードを実行 することなどが可能である．図 8 の結論部では，最初 に，Java のコンソール出力メソッドを利用して，あ る教員の職位と日当を出力している．ログやコンソー ル上にメッセージが出力される．次に，KDTModel の dailyAllowanceフィールドの値に，4 000 をセットし， 「Retract KDTModel[tm]」の部分で，インスタンスに値 を保存している．ここで保存した値については，Java プログラムと Guvnor を連携させた際に，クラスのイン スタンスとして，プログラムから参照可能となる． オプションについては，ルールの重要度（ルールに競 合が発生した場合に重要度の高いルールが優先して実行 される）など，ルールに関するメタデータを設定するた めに用意されている．
§ 3 Guided Rule Editor と DSL によるルールの作成 BRMSの特徴の一つとして，DSL の利用があげられ る．DSL を用いることで，自然言語を用いてルールの 作成が可能となり，システムやルール管理に詳しくない 業務担当者でも，ルールの維持・管理を行うことができ るようになると考えられる．同時に，ルール変更に伴う システムメンテナンスコストの低減が期待できる．以下 では，DSL を用いて「【科研費国内出張日当 A】職位が 教授の場合，日当は 4,000 円」のルールを作成する方法 について説明する． DSLでは，ルールの条件部と結論部について，自然 言語文の中にモデルにおけるフィールドの値や条件式， フィールドの値のセット文などを埋め込むことが可能と なる．その際，データ列挙を同時に用いることができる． 図 10 に科研費国内出張に関する DSL の定義を示す． 図 7 科研費国内出張に関するモデルのソースコード 図 8 科研費国内出張に関するルールの作成画面
ここで，[when] で始まる文は条件部を，[then] で始ま る文は結論部をそれぞれ表している．また，「＝」記号の 左側がルール作成画面で表示される部分を表し．右側に 記述された文がルール実行時に実行される． 図 10 では，DSL を用いた条件部の定義として「[when] 職位が {jobTitle:ENUM:KDTModel.jobTitle} の場合＝ teacher:KDTModel(jobTitle＝＝"{jobTitle}")」が定義さ れ て い る が，「{jobTitle:ENUM:KDTModel.jobTitle}」 の部分は，図 9 の一つ目のデータ列挙により定義され た値を参照している．図 9 の一つ目のデータ列挙では， KDTModelの jobTitle フィールドに対して，教授，准 教授，専任講師，助教，助手の五つの値を列挙している． データ列挙定義後に，DSL を用いた条件部の定義の中で， 「{jobTitle:ENUM:KDTModel.jobTitle}」と記述すること で，列挙したデータを選択可能なプルダウンメニューが 図 11 のルール条件部に表示される．プルダウンメニュー で選択された職位の値は「jobTitle」変数に保存される． 「＝」記号の右側の「teacher:KDTModel（jobTitle＝＝ "{jobTitle}"）」部分は，プルダウンメニューから選択さ れた職位をフィールドの値として持つ KDTModel のイ ンスタンスを，teacher 変数に保存することを意味する． 図 10 では，DSL を用いた結論部の定義として「[then]日 当は {dailyAllowance:ENUM:KDTModel.dailyAllowance} 円＝ teacher.setDailyAllowance({dailyAllowance})」が定 義されているが，「{dailyAllowance:ENUM:KDTModel. dailyAllowance}」の部分は，図 9 の二つ目のデータ列 挙により定義された値を参照している．図 9 の二つ目の データ列挙では，KDTModel の dailyAllowance フィー ルドに対して，4000，3500，3000 の三つの値を列挙し ている．上記の DSL を用いた条件部の定義の説明と同 様に，列挙したデータを選択可能なプルダウンメニュー が図 11 のルール結論部に表示される．プルダウンメ ニューで選択された値は「dailyAllowance」変数に保存 される．「＝」記号の右側の「teacher.setDailyAllowance （{dailyAllowance}）」部分は，プルダウンメニューから 選択された日当（dailyAllowance 変数）の値を，条件 部で作成した teacher インスタンスの dailyAllowance フィールドの値として保存することを意味する． DSLにより定義した条件部と結論部を用いて「【科研 費国内出張日当 A】職位が教授の場合，日当は 4,000 円」 のルールを作成した画面を図 11 に示す．図 8（DSL 利 用なし）と図 11（DSL 利用あり）を比べると，図 11 の ほうには，モデルのフィールドなど，実装に関する記述 が DSL により隠ぺいされているため，業務担当者によ るルールの作成や更新が可能になると考えられる． 図 12 に図 11 に示したルールのソースコードを示す． DSLを用いて定義した条件部と結論部の中で，「＝」記 号の右側に記述された内容がソースコードに反映されて いる．なお，Guvnor では，mvel＊13と呼ばれる記述言 語によりルールが記述される． § 1 決定表によるルールの作成
Guvnorでは決定表（Decision table）[日本規格協 会 86] を用いて，ルールを記述することも可能であ る．図 13 に科研費国内出張に関する決定表を利用した ルール作成画面を示す．決定表には，条件部に相当す る「Condition columns」と結論部に相当する「Action columns」が主に設定できる．また，一行が一つのルー ルを表す．図 13 では，「Description」列に，各行に示 すルールの説明が記述されている．「職位」列は条件部 を表し，KDTModel のインスタンスの jobTitle フィール ドの値が「職位」列の値であった場合に，同じ行の「日 当」列の値が結論部として実行される．「日当」列は， 画面上では数値が表示されているだけであるが，「Action columns」の設定により，ルール実行時に，KDTModel のインスタンスの dailyAllowance フィールドの値とし 図 10 科研費国内出張に関する DSL の定義 図 11 科研費国内出張に関する DSL を用いたルール作成画面 図 12 科研費国内出張に関する DSL を利用したルールの ソースコード ＊13 http://mvel.codehaus.org
て，「日当」列の値がセットされるようになっている． 4･6 テストシナリオの作成とルールの実行 Guvnorでは，テストシナリオを作成し，ルールの動 作確認を行うことができる．科研費国内出張における日 当を求めるルールについて，表 3 のテストシナリオを作 成し，シナリオを実行した画面を図 14 に示す．図 14 の 「GIVEN」の部分で，モデルのインスタンスのフィール ドに値を設定することができる．図 14 の「GIVEN」で は，氏名が佐藤，職位が教授のインスタンスをテストシ ナリオとして用意している．また，「EXPECT」では， ルール実行後にセットされるインスタンスのフィールド の値を設定することができる．ここでは，職位が教授の 場合の日当は 4,000 円であることから，dailyAllowance フィールドの値に 4000 がセットされることを想定して いる．図 14 の「Run scenario」ボタンを押すと，「GIVEN」 の部分で設定された条件に適用可能なルールが実行さ れ，ルールの結論部で設定されたフィールドの値が， 「EXPECT」の部分で想定した値と一致しているかどう かを評価する．図 14 では，表 3 のテストシナリオにつ いて，TM1 から TM5 までの五つのインスタンスを用い てテストシナリオを作成し，実行した結果が表示されて いる．Results の右に表示された緑色のバーと 100％の 記述は，すべてのテストシナリオが想定どおりに実行さ れたことを示している． 4･7 統合開発環境 Eclipse との連携 統合開発環境 Eclipse と Guvnor を連携するために は，Java ライブラリである「drools-distribution」と 「droolsjbpm-tools」と呼ばれる Eclipse プラグインが 必要となる．これらは，Drools の Web サイトからダウ ンロード＊14できる．また，マニュアル＊15も Drools の Webサイトより参照可能である． 図 8 に示した Guvnor 上の科研費国内出張に関する ルールを実行する著者らによる Java サンプルプログラ ムを GitHub 上に公開した＊16．サンプルプログラムでは， 最初に，KAKENHIDomesticTrip パッケージのスナッ プショット「TEST」の URL を参照し，Guvnor より知 識ベースを取得する．その後，知識ベースに，name フィー ルドの値が「佐藤」，jobTitle フィールドの値が「教授」 となる，KDTModel のインスタンス「sato」を追加し， ルールを実行している（ksession.fireAllRules メソッド の実行により，知識ベース内のファクトに対して，定義 したルールを実行する）．その結果，「【科研費国内出張 日当 A】職位が教授の場合，日当は 4,000 円」ルールが 実行され，インスタンス「sato」の dailyAllowance フィー ルドの値に 4000 がセットされる．最後に，System.out. printlnメソッドにより，職位に応じて適切に日当がセッ トされているかどうかを確認している（「【ルール実行結 果】佐藤教授の日当：4,000 円」がコンソール上に表示 される）． 図 13 科研費国内出張に関する決定表を利用したルール 作成画面 図 14 科研費国内出張に関するテストシナリオ作成・実行 画面 ＊14 https://www.jboss.org/drools/downloads ＊15 http://docs.jboss.org/drools/release/ 5.5.0.Final/drools-guvnor-docs/html/ch09.html ＊16 https://github.com/t-morita/GuvnorExamples/ blob/master/KAKENHIDomesticTrip/src/main/java/ com/sample/KAKENHIDomesticTripTest.java 表 3 科研費国内出張ルールにおけるテストシナリオ 氏 名 職 位 日 当 佐 藤 教 授 4,000 鈴 木 准教授 3,500 高 橋 専任講師 3,500 田 中 助 教 3,000 渡 邉 助 手 3,000
以上より，Drools が提供する Java ライブラリを用い て，Guvnor 上で作成した業務ルールを業務アプリケー ションから実行し，結果を得ることができる．
5．お わ り に
本稿では，ES と BRMS の対比，Boyer らが提案し ている BRMS を考慮した業務ルール開発手法である ABRD，オープンソースの BRMS である Guvnor につ いて解説した．本稿で解説した BRMS を活用すること により，業務担当者が直接業務ルールを入力し変更可能 となり，詳細設計，プログラミング，単体テストなどの 情報システム開発工程が大幅に削減され，コスト削減 が期待され，多くの活用事例が報告されはじめた [日経 12]．しかしながら，3 章で述べたように，業務ルールの 発見や分析には，領域専門家が多く関わる必要があり， BRMSを用いたとしても，業務ルールを単純に外在化す ることは依然として困難である．業務ルールより上位に 位置する，業務フローや業務戦略まで考慮すれば，知識 獲得ボトルネックの再出は必至であり，今後，部門を横 断するオントロジーなどを導入した，より高度な（第 2 世代）BRMS が必要とされるであろう．◇ 参 考 文 献 ◇
[Amador 12] Amador, L.: Drools Developer’s Cookbook, Packt
Publishing（2012）
[Beck 03] Beck, K.: Test Driven Development: By Example, Addison-Wesley Professional（2003）
[BLAZE 07] ブレイズ・コンサルティング株式会社：ビジネスルー ル管理システム（BRMS）で構築するビジネスルールシステム について，http://www.waku-con.com/sample/lecture_ BRMS.pdf（2007）
[Boyer 11] Boyer, J. and Mili, H.: Agile Business Rule
Development, Springer（2011）
[Browne 09] Browne, P.: JBoss Drools Business Rules, Packt Publishing（2009）
[Cockburn 06] Cockburn, A.: Agile Software Development: The
Cooperative Game, Addison-Wesley Professional（2006）
[Forgy 82] Forgy, C.: Rete: A fast algorithm for the many pattern/ many object pattern match problem, Artificial Intelligence, Vol. 19, No. 1, pp. 17-37（1982）
[Fowler 12] Fowler, M.:ドメイン特化言語 パターンで学ぶ DSL の ベストプラクティス 46 項目，ピアソン桐原（2012）
[Gruber 93] Gruber, T. R.: A translation approach to portable ontology specifications, Knowledge Acquisition, Vol. 5, No. 2, pp. 199-220（1993） [日経 12] 特集「超高速開発」が日本を救う，日経コンピュータ， 2012年 3 月 15 日号，pp. 28-45（2012） [日本規格協会 86] JIS X 0125：決定表，日本規格協会（1986） [溝口 12] 人工知能学会 編集，溝口理一郎 著：オントロジー工学の 理論と実践（知の科学），pp. 238, オーム社（2012） [ロス 12] ロナルド・G. ロス，グラディス・S. W. ラム 著，宗 雅彦 監訳，渡部洋子ほか 翻訳：IT エンジニアのためのビジネスアナ リシス，pp. 326, 日経 BP 社（2012） 2014年 4 月 8 日 受理 森田 武史（正会員） 2003年静岡大学情報学部情報科学科卒業．2005 年 同大学院情報学研究科修士課程修了．2007 年日本学 術振興会特別研究員（DC2）．2008 年慶應義塾大学 大学院理工学研究科後期博士課程修了．同年，日本 学術振興会特別研究員（PD）．2009 年慶應義塾大学 大学院理工学研究科特別研究助教．2011 年青山学院 大学社会情報学部助手．2014 年同大学同学部助教， 現在に至る．博士（工学）．セマンティック Web とオントロジーに関す る研究に従事．情報システム学会，ACM，日本データベース学会，電子 情報通信学会の各会員． 山口 高平（正会員） 1979年大阪大学工学部通信工学科卒業，1984 年同 大学院工学研究科博士後期課程修了．同年，大阪大 学産業科学研究所助手．1989 年静岡大学工学部助教 授．1997 年同大学情報学部教授．2004 年より慶應 義塾大学理工学部教授．工学博士．定理証明の研究 を経て，知識システム，データマイニング，セマン ティック Web，オントロジー，知能ソフトウェア工 学に関する研究に従事．1992 年度本学会全国大会優秀論文賞．2002 年 度本学会研究会優秀賞．2007 年度大川出版賞．本学会会長．電子情報通 信学会，情報処理学会，情報システム学会，AAAI，IEEE-CS などの各 会員．
