前回は「DXにおけるビジネスルールの重要性」を解説いたしました。

今回はビジネスルールから発展して「意思決定マネジメント」の話です。

まず、用語の定義です。意思決定とはどういうことでしょうか。当たり前のことですが。

• ビジネス上の意思決定とは、企業が目標を達成するために「ある状況における複数の可能な選択肢の中から、最適な選択肢を選ぶこと」です。

そして、ビジネス上の意思決定には大きく分けて戦略上、戦術上、業務上の3種類あります。

戦略上の意思決定

• 長期的影響をもつ、トップマネジメントの意思決定
• 例：　企業買収、市場参入、事業撤退などで1回のみ行われます。

 戦術上の意思決定

• 部門・プロジェクトレベルでの最適化判断など
• 例：　営業戦略、チャネル設計などで意思決定の回数は少ないものです。

 業務上の意思決定

• 日々の業務で反復的に発生する判断
• 例：　保険契約の引受判断、ローン審査などで毎日数多く行われます。

戦略上の意思決定が重要で、業務上の（日常的な）意思決定はたいして重要ではないと思いがちですが、数多い（1日に数万回行われる）業務上の意思決定を正しく行うことは、戦略的な（1回のみ行われる）意思決定に引けを取らずに重要です。

これから議論するのはこの「業務上の意思決定」で自動化の対象になりやすいものです。

業務上の意思決定の定義

英語の「Decision」という言葉には一般に2つの意味があります。Decisionは複数の可能な選択肢の中から、選択する行為（決定すること）を示すこともあれば、Decisionは選択される選択肢そのもの（決定事項）を示すこともあります。これから解説する「業務上の意思決定（Decision）」はこの前者の意味で用います。

• 業務上の「意思決定」はアウトプットがどのインプットからどのように決定されるかを定義するロジック（意思決定ロジックと言います）を使って、多くのインプット（可能な選択肢）からアウトプット値（選ばれた選択肢）を決める行為です。
• 意思決定ロジックは、ビジネス・ルール、アナリティカル・モデル、などの「ビジネス知識モデル」として表されます。

意思決定モデルが作成されている基本的な構造は、下図のように表記されます。

[図のクリックで拡大表示]　意思決定モデルの基本要素　（OMG　DMN1.1　より）

業務上の意思決定が求められる典型的業務例（損保業界）

• 引受け：　　この契約は引受可能か？
• 査定：　　　支払対象となるか？
• 顧客分類：　この顧客はゴールドか？リスク顧客か？
• 商品適用：　どの商品が最適か？

これらの意思決定の多くは業務担当者が行っていたので次の様な課題があります。

• 不透明性   ：        判断の根拠が属人的で説明できない
• 一貫性欠如  ：     担当者によって判断が異なる
• 複雑化 ：    　　  多様なルールが絡み合って管理が困難
• 遅延  ：　　　　情報や判断の伝達に時間がかかる（上司に判断を仰ぐなど）

上記問題を解決するためにいくつかのアプローチが取られてきました。

• ルール分離 ：          業務プロセスから判断ルールを分離し、再利用・変更しやすくする
• 可視化と説明責任：    「なぜこの判断がなされたのか？」を構造的に説明できる設計
• 自動化（BRMS連携）： 判断をシステムで実行し、迅速・正確な対応を可能にする

DX時代における業務上の意思決定の重要性

DX時代はVUCAがつきものです。外部環境の変化に応じて意思決定を柔軟に変化する必要があります。

そのために最近グローバルで注目されているのがDMN（Decisio Model and Notation：意思決定モデルと表記法）です。

DMNとは、ビジネス上の意思決定をモデル化・表現・共有・実行可能な形で記述するための表記法（Notation）であり、OMG（Object Management Group）が定義する業界標準です。

このDMNにより次のことが可能になります。

• 意思決定ロジックを明示・共有可能にできる
• 業務担当者（非技術者）にも理解・検討可能なように可視化される
• 意思決定を実行可能な形で定義して自動化まで可能
• BPMN（ビジネスプロセスモデルと表記法）と組み合わせることにより、ルールを含む業務を自動化できる

上図をDRD（意思決定要求ダイアグラム）と言います。

このDRDの構成要素（図形）は上図のとおり、4つの図形（意思決定、入力データ、ビジネス知識、知識ソース）と要求の関係を表す3種類の矢印（情報要求線、知識要求線、根拠要求線）です。わずか7つの図形と矢印で意思決定をモデル化できますから、分かりやすくIT人材やビジネスアナリストのみならず業務担当者に容易に理解してもらうことが可能です。

意思決定するためには入力情報（データ）、意思決定するための知識（主にビジネスルール）が必要です。そして意思決定のアウトプットも情報（データ）になりますから、メインの意思決定にはサブ意思決定の結果を入力することが可能です。

ビジネス知識（主にビジネスルール）としてよく使用されるのはデシジョンテーブルです。上図はカード所有者の「勤務状況」「全債務/年収」の組合せでその個人の信用格付けを意思決定するロジックです。ビジュアルに意思決定がモデル化されることが分かると思います。これなら業務担当者でも容易に理解することが可能です。
このようにして意思決定は簡単にモデル化され自動化までできます。

意思決定とプロセスの自動化による業務の自動化

業務はプロセスとルールの組み合わせという前回の冒頭のパートを思い出してください。業務を自動化するにはプロセスと意思決定を同時に自動化する必要があります。

DMNはOMG（オブジェクト・マネジメント・グループ）が標準化したものですが、この団体はITシステムへの実装方法を標準化しています。つまり図形の意味を標準化するだけではなく、そのITへの実装方法を定義していますので、システム間で互換性があります。A社のシステムで作成されたDMNモデルはB社のシステム上でも稼働できるということです。

更にビジネスプロセスモデルとして有名なBPMN（ビジネスプロセスモデルと表記法）もこのOMGが標準化したものです。同じOMGが標準化したため、BPMNとDMGのデータ構造が共通に設計されており、DMNの意思決定のアウトプットデータをBPMNが使用することが可能です。その簡単な例が次の図です。

上図の右側がDMN意思決定モデルです。左側がBPMNプロセスモデルです。DMNで融資の申請が審査され、融資の意思決定（受入、拒否）がされます。そして意思決定のアウトプットが左側のBPMNで使用されます。DMNの決定を基にビジネスプロセスが動き、「受入れ」なら融資が決定します。簡単な図ではここまでですが、実際にはこの先プロセスが自動的に動きますので融資が決定されれば振込みまで自動で進むことができるようになります。極端に言えば、条件が問題なければ融資が申請された直後に銀行口座に融資額が振込まれる、ことまで自動化されるということになります。保険で言えば、保険金を請求したら保険金が即刻が振り込まれることが可能になる、ということです。そうなったらいいですよね。

DMNモデルにより複雑な意思決定を設計することができるようになりました。その効果は計り知れません。単にビジネスルールを管理することに比べて、以下のようなメリットがあります。

• ビジネスルールを判断の文脈（意思決定）として位置付けられる
• DRDで視覚的に記述されるので、意思決定の流れが表現できる
• 再利用・保守性が意思決定構造全体として最適化ができる
• 「なぜそう判断されたのか」を明確に説明できるので、説明責任能力が極めて高い

実際のDRD（意思決定要求ダイアグラム）とビジネスプロセスモデルをご覧ください。

上図のBPMNには次の3つのGateway（分岐）があります。

• 信用調査戦略を判定する（信用調査、スルー、謝絶）
• 判定ルーティング（受諾、参照、謝絶）
• 申込みを見直す裁定（受諾、謝絶）

その分岐条件は意思決定（DMN）の結果により分岐先が決まります。

最初のStrategy（信用調査戦略）判定に関するDRDは次のとおりです。

3つの意思決定（判定）要求ダイアグラムを合体したものが次の意思決定要求グラフです。

そして、4つの入力データです。

• Requested product（要求された金融商品）
• Applicant data（申込み者データ）
• Bureau data（信用調査会社データ）
• Supporting documents（サポート書類）

実例は下記リンク先のOMG標準　DMN1.1日本語版を参照ください。

DMN1.1 日本語版

金融サービスのみならず、意思決定の自動化はDX環境において極めて重要になります。例えばIoTではデバイスからの多くの入力データの組合わせにより自動判定が必須です。温度変化に応じてドアなどの自動開閉。ジェットエンジンの使用時間・飛行時間により月間使用量の自動算出・自動請求．．．枚挙にいとまがありません。

日本では保険支払いの膨大な過去データをAIに覚えこませて、保険サービスの意思決定を自動化する試みが見受けられます。しかし、グローバルではEUのGDPR（一般データ保護規則）に代表されるように、自動化された意思決定に対し個人が説明を求める権利を認めています。ですから残念ながら説明能力が不十分なAIでは対応できないようです。いずれ日本でも個人情報保護の強化が必要になるかもしれません。

ビジネスルール管理とDMN（意思決定モデル）との違いは以下のとおりです。

DMN（意思決定モデル）は、「ビジネスルール管理」を超えて、「意思決定の全体像」をモデルとして扱える点が決定的に異なります。

ビジネスを意思決定の立場から考えようというアプローチがあります。

参考文献：意思決定マネジメントのマニフェスト（日本語版V1.5）

参考：意思決定の法律（政策）への適用の試み

BBC2020カンファレンスでのプレゼンの一部を紹介します。

グローバルではDecisionを法律（政策）にまで適用しようとする試みがあります。まだ完成されたわけではありませんが、そのチャレンジ精神には頭が下がる思いがします。

Newzealand政府の政策の自動実行への試みです。
発表者はGladys Lam（Business Rules Solutions, LLC） 氏

目指すところは政策（自動実行）の対話形式での開発です。

必要なことは法律（Governing Rules）をビジネスルールに変換し自動化ルールにまで落とし込むことです。
法律をビジネスルールに変換し、さらにそれを自動化ルールに変換するのです。

そのためには多くのステークホルダーの協力が欠かせません。
特に　法律作成者、ビジネスアナリスト、そしてソフトウェア開発者です。

RuleSpeakはビジネスアナリストによる、ルールの表記法です。
これをは政策（法律）をコンピュータ言語に変換する通訳の役割を果たします。

詳細はNewzealand政府発行のWebページをご覧ください。

https://www.digital.govt.nz/dmsdocument/95-better-rules-for-government-discovery-report/html

ブラウザがGoogle Chromeなら同時翻訳で日本語で読めますので、概要は理解できると思います。

5月31日にVCPC（バリューチェーンプロセス協議会）において、ビジネスルール研究WGの発表をいたしましたので、その概略を解説いたします。
前号まで、連載した「ビジネスルールとビジネスプロセス」の最終結論という位置づけにもなります。

約1年にわたり、ビジネスルールとビジネスプロセスとの関係を研究してきましたが、WG（ワーキンググループ）の結論（正確にはまだ仮説）です。

【総論（結論）】

• ビジネスプロセスの階層とビジネスルールの階層をきれいに対応付ける
  ことに成功した（特に、SCOR/ESCORTモデルにおいて）

まず、次の図をご覧ください。

発表資料はVCPCのWEBページより閲覧可能となっていますので、ご覧いただいても結構です。

http://vcpc.org/modules/d3downloads/index.php?page=singlefile&cid=17&lid=65

VCPCは前身のSCC（サプライチェーンカウンシル）時代から、ビジネスプロセスを階層化して整理することに精力を注いできていました。その一つが有名なSCORモデル（Supply Chain Operational Reference-model）です。階層構造もレベル1、レベル2、レベル3とグローバルに標準化されて大きな実績があります。さらに日本ではSCORモデルを拡張しレベル4の参照モデルまで確立しています（ESCORTモデル）。最近、東京海上日動システムズがこの方法論でビジネスアナリシスを成功させ、話題になっているのはご存知だと思います。

東京海上日動システムズの事例発表は下記ページをご覧ください。

http://babooks.jp/news/issues/report_VCPC130308A.html

一方、USでは、ビジネスルールのコミュニティが10年以上前から活発な活動をしていて、BRCommunity.com　などがあり、大きな成果を発揮しています。
そのBRCommunity.comの成果に、ビジネスルールの階層モデルがありました。

詳しくは下記URLのWebページを参照ください。
http://www.brcommunity.com/b661.php

著者のKathy A. Longによると、ビジネスルールにも階層構造があり、上位から

• 全社ポリシー（Company Policy）
• 部門ポリシー（Department Policy）
• 作業手順（Job Procedure）
• ビジネスルール

となります。

また、それに対応するビジネスプロセスは

• ビジネス活動（Business Activity）
• ビジネスタスク（Business Tasks）
• ビジネスステップ/ワークフロー

となっていました。

ビジネスルールにも階層構造があるということは大きな発見でした。それならば、日本で得意のビジネスプロセスの階層モデルと関係づけることができるのではないかと、研究活動を進めることにしたのです。

それをイメージしたのが次の図です。

特に、SCOR/ESCORTモデルの階層とビジネスルールの階層を対応できないかと活動を進めていきました。
途中、新しいビジネスルールの書籍（「ITエンジニアのためのビジネスアナリシス」ロン・ロス著）が日本語化されたのは研究を大きく加速することができました。
ポリシー憲章、FACTモデル、ビジネスプロセスからのルールの抽出、マイルストーンモデル、決定分析、などルールを作成する具体論が明確になり研究も一気に進んでいきます。
前出の結論（総論）を支える3つの各論です。

１．のポリシー憲章については、関連する内容が連載（4）にありますので、参照してください。

　URL ：　http://www.kbmanagement.biz/sub225.html

２．はSCORモデルのレベル3のイネーブルプロセスの記述です。

詳細は割愛しますが、SCORモデルのレベル3（Enable Process）にビジネスルールの記述があるのですが、内容を吟味するとルールというよりポリシーに該当することがわかりました。これを基に、ポリシーをビジネスプロセスのレベル3に対応することに成功。

ポリシーより下位のビジネスルールはレベル4とレベル5に対応させればよいのです。ルール側だけでは、レベル4とレベル5の区別はできません。ビジネスプロセスと対応させることにより可能になります。レベル4プロセスから導かれるルールはレベル4。レベル5プロセスから導かれるルールはレベル5となります。逆にプロセスと対応付けることにより、モレやヌケを防ぐことが可能になるというメリットがあるようです。

最後のまとめですが。
ビジネスプロセスのレベルとルールの対応関係は以下の通りです。

• レベル0：　　企業ミッション
• レベル1：　　ビジネスミッションとゴール
• レベル2：　　ビジネス戦術
• レベル3：　　ビジネスポリシー
• レベル4：　　ビジネスルール
• レベル5：　　ビジネスルール

最後に、このVCPCのWGは本年度（2013年度）も活動を継続します。結論はまだ仮説の段階ですので、それを検証するために適用事例を研究する方向です。

本WGに参加をご希望の方はVCPCのページからお申し込みください。

その前に、VCPC会員にもお申し込みください。

よろしくお願いします。

まず、弊社の公開コースの受付プロセスをご覧ください。

コース管理者は常に各コースの申し込み状況をモニターしています。人気のある（申込者が多い）コースはあまり問題ないのですが、少ないと本当に開催できるか心配です。例えば上記の例では、開催の10日前に、最低人数に達しているかが問題になります。もし最低人数に達していなければ開催をキャンセルし申込者に連絡しなければいけません。同時に教室のキャンセル手続きも必要です（そのプロセスは上図には記載されていませんが）。

運よく申込みが順調ですと、早目に最低人数に達します。その時点から「受講票」が発行できます。同時に請求書を発行したりビジネスとしては順調な状況になります。ある日、申込み人数が定員をオーバーします。それ以降の申し込みに対しては「キャンセル待ち」を連絡することになります。上図はこのコース受付のプロセスを図示したものです。

続いて、次の図をご覧ください。

全く同じことをルールを別出しにしたプロセスです。ワークフローが簡略化されていることがわかると思います。しかし業務は全く同じものです。これがプロセスからビジネスルールを別出しして作成している例です。

実際の業務はもう少し複雑です。コースの「定員」はコースによってすべて異なります。例えば、演習やロールプレイの多い「失敗しない要求開発」コースの定員は16名（4名x4チーム）、レクチャー中心の「ビジネスアナリシス基礎」の定員は20名プラス（教室が大きければ少し増やせます）です。また、最近スタートした「CBAP試験対策」コースは個人指導に近く、定員（最大）は12名です。おのおのコースの特色を加味した定員が設定されています。

コース開催の「最低人数」も同様です。教室の費用を考慮すると最低人数もおのずから決まります。赤字を避けるために必要なものです。例えば「最低人数」は4名です。さらに、コースの特色が加味されます。「失敗しない要求開発」はロールプレイや演習を行うために最低限必要な人数があります。クラス構成上2チームを考えると最少人数は6名となります。赤字にならない要素だけではありません。

このように、ルールを別出ししてもそのルールそのものがかなり複雑で、コース毎に異なりますから、システム化する際にはフローとルールを別出しすることが極めて重要になります。実際のイメージは次の図のようなものです。

こうすれば、新しいコースを開発しても、コース受付のフローは全く同じです。異なるのはビジネスルールだけそのコースに最適なルールを作成すればよいのです。

５．３　ビジネスマイルストーンからビジネスルールを抽出する

このプロセスの中で、「コースを申し込む」とか「申し込みを受領する」というプロセスがあります。それらの目的語は「受講申込み」（以下単に「申込み」）です。

この用語「受講申込み」にはそれ自体で状態が変わることがお分かりでしょうか。

例えば、受領した後でも、人数が催行人数に達すると「申込み（有効）」になり、請求されれば「申込み（請求済み）」になります。請求された申し込みが支払われるとその「申込み」は売り上げではなく（まだサービスが供されていないため）、前受金処理されますから「申込み（前受済）」となります。その後申込者がコースを受講することにより、前受金扱いだった「申込み」は売り上げ処理されますから「申込み（売上済）」になり、「申込み（完了）」となります。

下図のビジネスマイルストーンをご覧ください。

このように状態が変わる節目をマイルストーンと言います。

【申込み】→【申込み（有効）】→【申込み（請求済）】→【申込み（前受済）】→【申込み（売上済）】→【申込み（完了）】

このマイルストーンが順調に進んでいくのはHappyなストーリーです。

ところが、いつも順調（Happy）に進むとは限りません。申し込んだのちにいくつかの事情により、「申込み」はキャンセルされる場合があります。

申込者が少なければ、コースは開催されませんから「申込み」はキャンセルになることがあります。また、期日までに請求の支払いがない場合もキャンセルされます。

上図は期日までに催行人数に達しなかったために「申込み」を断った場合と、「申込み（請求済）」が期日までに入金されなかったために、「申込み」がキャンセルされた例です。

このようなマイルストーンモデルが有効な具体的な例は保険業です。何もなければ（Happyなら）、保険金が支払われていきます。Unhappyな出来事（事故）が発生すると、請求が発生します。

今週からビジネスルールの抽出方法を簡単に紹介します。

下記、5つの方法を解説します。

• ファクトモデルからビジネスルールを抽出する
• ビジネスプロセスからのビジネスルールを抽出する
• マイルストンからビジネスルールを抽出する
• 決定分析からビジネスルールを抽出する

今週はファクトモデルですが、退屈するかもしれません。少し我慢してください。

５．１　ファクトモデルからビジネスルールを抽出する

【用語（Term）】

当たり前のことからスタートします。ビジネスルールを決めるためには、ビジネスで使用する用語を定義しなければなりません。ですから用語が最も重要です。当たり前すぎることなので困惑するかもしれませんが、同じ社内、ユーザーとベンダー、また顧客との間でも用語が統一されていないとコミュニケーションが取れなくなります。

先日来ご紹介している東京海上日動システムズにおけるビジネスアナリシスの実践においても、担当されたビジネスアナリストは「用語集」が最も重要と述べています。たとえば「クレーム」という言葉は、保険業では「事故処理」を意味しますが保険代理店では「顧客からの苦情」を意味していました。このように認識が異なるままインタビュー、要求分析を続けていったらどうなるでしょうか。空恐ろしいことになることが想像できますね。

BABOKでは、「用語集」を「組織または部署が使用するすべての用語を識別し、定義するための公式文書」と解説しています。この解説を見るだけでもビジネスアナリシスにおける重要性がわかります。

用語：ビジネス運用に関わるものを示すために用いる名詞、および名詞句

例は、「顧客」、「注文」、「従業員」、「出荷」．．．などですが、それらをしっかりと定義しておかなければなりません。スタートですから当たり前で簡単のようですが、意外と深い意味があります。当たり前（自明）と思える用語を定義するのですから意外と大変かもしれません。

例えば「顧客」の定義ですが、

顧客：商品やサービスを購入する者、特に規則的に、あるいは高頻度で購入する者

（メリアム・ウェブスター大辞典[MWUD]）

規則的とはどういうことでしょうか。高頻度とはどのくらいの頻度を意味するのでしょうか。それらも決めておく必要があるのです。もちろんビジネスドメインにより頻度の意味は大きく異なります。自動車の顧客が新車を購入する頻度（数年に一度）とコンビニの顧客が買い物をする頻度（ほとんど毎日）は大きく異なりますね。ですから同じ頻度でも、組織においてしっかり定義しなくてはいけないのです。

【表現法（Wording）】

上で定義した用語どうしの関係を動詞で表現したものです。

ビジネスにおいて、「顧客」、「注文」、「出荷」、「従業員」などは用語として基本的なものですが、それらの関係を記述します。

例：　顧客が注文を出す

出荷が従業員により承認される

これらのように、名詞－動詞（Wording）で構成された表現を「ファクトタイプ」と言います。

表現法（Wording）により、動詞や動詞句をビジネス用語集に追加したものを、「構造化ビジネス用語集」と言います。

【ファクトモデル】

ファクトタイプを下のように図形表示したものがファクトモデルです。UMLをご存知ならクラス図とみてもかまいません。

ファクトモデルまたはファクトタイプからビジネスルールを導くことができます。

上記のファクトタイプから導き出されるビジネスルールの例は下記のようなものです。

• 顧客は少なくとも1個の注文を出さなくてはならない
• 出荷は少なくとも2人の従業員により承認されなくてはならない

用語、表現法、ファクトモデル、ビジネスルールの関係をまとめると次の図のようになります。

実際のファクトモデルの例です。

BRMS（とBPM）を導入しさえすれば、超高速開発が実現できるのでしょうか。実はそう単純なものではありません。少なくとも2つの課題があります。

一つは、導入するためにはビジネスルールそのものが整理、整備されている必要があります。どんなに優れたBRMSでも、入力するべきビジネスルールがしっかり整備されていなければシステムから得られる結果が正しい（効果的な）ものとは程遠いものになってしまいます。ルールのヌケ、重複、矛盾などはBRMS導入する前に整備、整理しておくべきものです。これを何もしないまま、ただBRMSを導入しても効果が期待できないことは言うまでもありません。ツール（BRMS）のなかには重複や矛盾を指摘してくれるものもあり、チェックに使える便利なものです。しかし、便利だからといって、ツールをうのみにするわけにはいきません。特にルールのヌケを指摘してくれるわけではありませんし、またルールの粒度もそろえておく必要もあります。ですからしっかりしたビジネスルールを体系化する必要があります。

もう一つは、ビジネス戦略との関係です。ルールにヌケ、重複、矛盾が（形式的に）なかったとしてもビジネス戦略を反映していないルール体系では、効果的なビジネス運営とは程遠いものになってしまいます。また、ビジネス戦略を変更した場合、ビジネスルールもそれに応じたものに変更する必要があります。その際どのルールを変更し、どのルールは変更しないと判断するのでしょうか。ビジネスアナリシスのグローバルスタンダードのBABOKではステークホルダー要求やソリューション要求は、ビジネス要求にトレースする必要ことになっています。ビジネスルールの世界でも同様のことが言えます。ビジネスルールもビジネス戦略につながった体系にしておく必要があります。それは、BRMS導入以前（もしくは導入と同時）の問題としてしっかりビジネスルールを、基となるビジネス戦略が反映したものにしておく必要があります。それができて初めて、ビジネス戦略と同期したビジネスソリューションが構築できるのです。

４．最新書籍「ITエンジニアのためのビジネスアナリシス」の訴求点

上記2つの課題を解決するために、最近、良書が発売されています。それが、前述の「ITエンジニアのためのビジネスアナリシス」（日経BP社）です。

４．１　モレなくビジネスルールを抽出する方法

この書物では、最近10年間のビジネスルール世界の技術（ITとは限りませんが）の進歩による体系的なビジネスルールの抽出方法が数種類紹介しています。代表的なものは下記のとおりです。

• ビジネスプロセス
• ビジネス用語集とFACTモデル
• ビジネスマイルストーン
• 決定分析（意思決定）

など。

これらの抽出方法により、ビジネスルールをモレなく抽出することができるようになります。BRMSと併用することが可能です。特にビジネス用語集は最も重要です。この用語集の用語を使用してビジネスプロセスも記述します。ビジネスで使用する主要な用語は全て用語集に収録しなければなりません。

各々の抽出方法（ビジネスプロセスやFACTモデルなど）は次回以降、各論の解説に譲りまして、本号では次のポリシー憲章を解説します。

４．２　ポリシー憲章

この書物の価値（著者たちのビジネスルール世界での大きな貢献）は、下位レベルのビジネスルールを上位のビジネスミッション、目標（ゴール）、戦術など、いわゆるビジネス戦略とリンクさせる方法論を確立したことだと思います。ビジネスプロセスやFACTモデルなどは従来から存在していたのですが、いくら下位レベルのビジネスルールをモレなく抽出できたとしても、ビジネス戦略に立脚していない限り、ソリューションのビジネスへの貢献は保証できません。ソリューションの使われない機能（この場合はルール）が増える可能性すらあります。使われないルールを実装してもBRMS（ビジネス管理システム）が重くなるだけで、効果的なビジネス戦略の実行には程遠いものです。そのビジネス戦略とビジネスルールとを整合させる一つの方法論がポリシー憲章と言えます。

ビジネス戦術とビジネスポリシーを作成する方法の例です。極めて単純な例です。

5つの質問により、ビジネス目標（ゴール）、ビジネス戦術、リスク、ポリシーを導きます。

質問1：「ビジネス目標（ゴール）を達成するために最適なビジネス戦術は何か？」

質問2：「そのビジネス戦術を具体化するため使用できる追加のビジネス戦術、または

ビジネスポリシーは何か？」

質問3：「ビジネス戦術またはビジネスポリシーの成功を妨げるビジネスリスクは何か？」

質問4：「そのビジネスリスクは受容可能か？」

質問5：「受容できないビジネスリスクに対する最善の防御策となるビジネス戦術、

またはビジネスポリシーは何か？」

簡単な例として、ピザ屋さんを取り上げてみましょう。このピザ屋さんのビジネス目標（ゴール）は「顧客に満足してもらい続けること」です。そのためのビジネス戦術は「顧客の自宅や会社にピザを宅配する」ことになります。それを実現するためのポリシー（ルールの親分的なもの）はピザを1時間以内に届けることですが、ルール的な表現で「ピザを1時間以内に届けなければならない」となります。その実現を妨げるリスクとして、「交通渋滞」があります。リスクに対する防御策として、「ドライバーに道路状況のわかるGPSを渡す」があります。

このようにして、縦方向に戦略をダイアグラム的に書いたものをポリシー憲章と言います。

（「ITエンジニアのためのビジネスアナリシス」（日経BP社）より抜粋）

ビジネスルールをルールエンジンで自動化するだけでは、ビジネスに貢献するソリューションとはなりません。下位のルール体系が上位のビジネス戦略と整合しているとは限らないからです。整合しないごみの山のようなルール（使われないルールもあるかもしれません）、極めて属人的なルールもあるかもしれません。また、ルールそのものに矛盾があるかもしれません。そのようなルールでは、ルールエンジン（BRMS）で自動化してもITリソースの無駄になるばかりです。ですから、ポリシー憲章で戦略とルールを結合させれば、上位のビジネス戦略（ポリシー）の変更、追加に応じて、いつでも整合を保たせたままルール変更が迅速に可能になり、アジャイルなビジネス運用が可能になります。

しかし、ビジネス戦略とビジネスルールを整合させるためには、もう一つ重要なことがあります。下位のビジネスルールをモレなくダブりなく作成しておくことです。ポリシー憲章とMECEなビジネスルールを組み合わせることにより、ビジネス戦略と整合のとれたビジネスルールが作成されることになります。

３．１　BRMSとは

ルールエンジンはビジネスルールを実行するフレームワークまたはライブラリです。

そして、BRMS（ビジネスルール管理システム）はルールエンジンを含むビジネスルールを管理する環境で。ビジネスルールライフサイクルを多くの側面からサポートしてくれます。

• ビジネスルールの可視化
• ビジネスルールの編集
• ビジネスルールの検証

BRMS導入の代表的なメリットは、頻繁に変更されるビジネスルールをアプリケーションコードから切り離し管理、実行してくれることです。具体的には、

• 複雑なビジネスルールの判断を手助けしてくれますから、意思決定プロセスを自動化し、アプリケーション保守のコストが大幅に低減することが可能です。
• ビジネスルールの可視化してくれるので、業務担当者とISエンジニアのコミュニケーションの大幅な改善とより正確なビジネスサービスが実現できます。
• 運用時にダイナミックにルールを変更できるので、業務担当者（ビジネスパーソン）がアプリケーションの意思決定ロジックを直接実装、変更できます。（そのためのExcelツールなど）
• その結果、マーケットの変化に迅速に対応することが可能となります。
• 開発の簡素化/効率化が実現（仕様を決めればほとんどそのまま実装）します。

つまり、BRMSを活用すれば、情報システムは急速なビジネス変化に対応したビジネスサービスを提供することが可能になるというわけです。

３．２　BRMSの具体例

いくつかのビジネスルール管理システム（BRMS）を見てみます。

　　　　　　　　ブレイズコンサルティング社資料より

 BRMSの代表的存在のProgress社のCorticonシステムです。業務プロセスから業務ルールを抽出し、外部で一元管理することを図示しています。

アーネスト・ビジネスソリューション社資料より

韓国のイノルールズ社のInnoRulesです。同様にプログラム（アプリケーションコード）からビジネスルールを外にだし管理することを図示しています。

このツールは強力なルールエンジンが特徴です。日本でもポピュラーなソリューションです。

韓国のサムソンが採用し話題になっているツールです。

日本IBM社資料より

IBMのツールです。ビジネスプロセスからディシジョン・ポイント（ビジネスルール）を抽出している図です。

BRMSも各社から各種ツールが販売されています。本連載はBRMSの比較をすることが目的ではありませんから、このくらいにしておきます。

ツールの比較表は日経コンピュータ誌（3月7日号）を参照ください。

３．３　最近のBRMSの進歩　（BPMとの組み合わせ）

さらに、最近の傾向としてBPM（ビジネスプロセス管理）との組み合わせが可能になってきました。

ブレイズコンサルティング社資料より

Corticonの例ですが、BPM/BPMインテグレーションをうたっています。

ワークフロー管理システムで、従来担当者の判断で行っていたものをBRMS（ルールエンジン）と連携することにより、75％の工数減が達成されたようです。

Red Hat社資料より

さらに、上記例はBPMN（Business Process Management Notification）との組み合わせです。

BPMNはBPMの標準的表記法でコードの自動生成ツールが用意されています。

プロセスをBPMNで記述し、ビジネスルールを別出しておけば、BPMNでアプリケーションコードが自動生成されルールはBRMSがそのまま実行してくれることになります。そうすると超高速開発ということが実現でえきることになりそうです。

Red Hat社資料より

上記ツールは、仕様を定義すればそのまま実装が可能ということを示唆しています。

さらに運用時におけるルールの変更は、情報システムのエンジニアでなく業務担当者で対応できるというと、まるでいいこと尽くしという感じです。ではこのBRMSに大きな問題・課題はないのでしょうか。

実は、大きな課題が残っています。それはビジネス戦略との関係です。

従来の業務システムの開発方法の問題は何でしょうか。それがもたらす悪影響はどんなものが予想されるでしょうか。逆に問題が解決できると、どのようなメリット（恩恵）が得られるのでしょうか。順番に考えてみます。

２．１従来の業務システム（プロセスベース）開発の問題点

従来の業務システムの開発では、業務プロセス（業務ロジック）の中で、制約条件や判定基準などのビジネスルールを組み込んでアプリケーションコードを作成していました。

データベースをアプリケーションから切り離すこと（いわゆるDOA：データーオリエンテッドアプローチ）に主眼が置かれていて、データベース管理として長く定着してきた歴史があります。しかし、その反面ビジネスルールへの関心はあまり高くなく、アプリケーション（プロセス）の一部分という認識しかなかったのです。

Red Hat社資料より

業務アプリケーション＝　プロセス　+　ルール　+　データ

のはすが、実際のアプリケーションでは

業務アプリケーション＝　プロセス[ルール含む]　+　データ

だったのです。

それでも多くの業務アプリケーションでは問題ありませんでした。それは比較的単純な業務でデータだけしっかり管理していれば効果が高く得られていたからです。

Red Hat社資料より

ルールを変更しようとすると、システムのアプリケーションコードを書き換えなくてはいけず、多大な工数を必要とします。最近このことのデメリットが目立ってきました。

２．２　ルールがプロセスに混在することの悪影響

運用時においてビジネスルールは変更する可能性が多いものです。例えば、ビジネス環境が変化し、競合他社の戦略が変更されたりすると、ビジネスルールも変更せざるを得なくなるケースがしばし見受けられます。携帯電話の料金プランはその典型例と言えます。ABCプラン、XYZプラン、DEF割引など、毎月のように新たなルールが登場します。

このような状況で、ルールがプロセスに混在したままアプリケーションコードを作成してしまうと、ビジネスの環境変化に対応することが大変困難です。ルールだけ変更するためにも、システム開発するのに匹敵するだけの工数を必要とすることになりかねません（すべてのプロセスを見直す必要が生じた場合）。競合状況も悪化します。ルールを環境に合わせるのに数か月かかってしまうと、競合状況も一変してしまいます。競合に差をつけられるだけでなく、顧客満足度にも影響が出るかもしれません。スポンサーの期待からもほど遠いものになるでしょう。社員のリストラや工場売却などが現実味を帯びてきます。かつての日本を代表する超一流メーカーの凋落ぶりは大変歯がゆいものがあります。韓国のサムソンに大きく差をつけられている要因かもしれません。

Red Hat社資料より

２．３　ルールとプロセスの混在を解消した場合のメリット

逆に、ルールをプロセスから分離できたとしたら、どんなメリットがあるのか考えてみましょう。システムを運用中であったとしても、アプリケーションコードをいじる必要なくルールだけを変えることができるようになるでしょう。ひょっとしたら情報システムのエンジニアでなくてもルールを変更できるかもしれません。そうなると、ルールをその日のうちに変更することができ、その日のうちに新ルールで実行が可能になります。ビジネス環境の変化に素早く対応することができ、逆にビジネス環境の変化をリードすることすら可能になります。

また、競合に遅れていたものが逆に競合をリードできる立場になり、先手で対策を打つことが可能になります。顧客が期待していたルールが早期に実現できるので顧客満足度も向上します。その結果スポンサーの満足度も向上することになるでしょう。

ルールがプロセスからうまく分離できれば、プロセスはよりシンプルになり、アプリケーションコードはより安定（長持ち）することになります。運用時の要求変化をルールの形でうまく吸収することも可能になります。

どうやらルールをプロセスから分離するべきことのようですね。

次回は最近のBRMS（ビジネスルール管理システム）の動向を見てみましょう。

最近、ビジネスルールが重要だという話を耳にすることが多くなりました。日経コンピュータ誌でも「超高速開発が日本を救う」などというエキセントリックなタイトルでビジネスルール管理システム（BRMS）を大々的に取り上げたりもしています（2012年3月15日号）。また直近では本格的にビジネスルールを扱った「ITエンジニアのためのビジネスアナリシス」（日経BP）が出版されるなど、多方面で注目を集めています。

一方、ビジネスルールは日本ではなじみの薄い概念でその内容に関する知見はまだ少ないのが実情です。そこで、本メルマガではビジネスルールおよびビジネスプロセスに関して連載で解説を試みます。

以下、連載の目次です。

1. なぜ、ビジネスルールが注目されているのか。
2. 従来の業務システム（プロセスベース）の問題点
3. 最近のBRMS（ビジネスルール管理システム）の特徴と利点
4. 最新書籍「ITエンジニアのためのビジネスアナリシス」の訴求点
5. ビジネスルールの作成方法

重要なことは全体像です。各論は別の機会にすることとして、本当のメリット、デメリットは何なのかに焦点を当てて解説しようと思います。

１．なぜ、ビジネスルールが注目されているのか。

１．１　メディアの関心

なんといっても、メディア（特に日経BP）の取り上げ方が尋常ではありませんね。

約1年前の「超高速開発が日本を救う」はエキセントリックな内容でした。

システム開発も超高速で可能になり、保守作業もITエンジニアではなく業務の担当者がルール変更のエディタを使えば、その日から新しいルールに基づいたシステムが出来上がると、吹聴していました。約1年前の特集ですが、日経コンピュータ誌をお持ちの方は是非ご覧ください。特集記事の大項目と概要だけ見ても、その効果の大きさには驚いた読者も多いのではないでしょうか。

「韓国企業に見る威力」

韓国製のBRMSとしてイノルールズ社のinnoRulesが大きく紹介されています。

主な項目は、

• スピードの秘訣はBRMSにあり
• サムスン生命はスピード3倍増
• 開発期間を半減させた現代海上

「「攻守」の両方に効く」

• 自然言語で業務ルールを入力
• 画面やDBに自動生成
• アジャイル開発が現実的に
• BRMSの導入効果が高い業務
• 分岐条件や四則演算などを多く含み、複雑である
• 四半期ごとのなど変更が頻繁に発生する
• 一時的ではなく、毎日実行する

「10倍速で攻める」

• 開発工数を9割削減
• ルール作成時間を半分に
• システム保守は当日対応

「コスト9割減で守る」

• 医師の仕事を肩代わり（保険の医務査定業務）
• 自治体でも1億円削減

日経コンピュータ誌では、最後に「超高速開発ツールの活用の巧拙が、日本企業の競争力を左右する時代に突入しつつある」と締めくくっています。

１．２　ビジネスアナリシスのアプローチの一つとして

毎年開催されているビジネスアナリシスのカンフェランス（Building Business Capability：BBC）では、IIBAとともに、BR&D（Business Rules& Decisions）フォーラムを同時開催していて、IIBAとの協調路線を築いています。

本年（2013年）11月予定のカンフェランスの案内をご覧ください。

http://www.businessrulesforum.com/

IIBAの立場からは、ビジネスアナリストの一つの手法（手段）として定着しつつあるようです。特に、最近日本語訳された「ITエンジニアのためのビジネスアナリシス」はIIBA本部がスポンサーとなって出版された初めての書籍という位置付けです。それだけビジネスアナリシスの見地からしてもビジネスルールは重要なもののようです。