DXにおける意思決定マネジメント

【DXにおける意思決定マネジメント】

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

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

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

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

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

戦略上の意思決定

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

 戦術上の意思決定

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

 業務上の意思決定

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

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

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

業務上の意思決定の定義

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

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

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

DMN1_2017年1月31日

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

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

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

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

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

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

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

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

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

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

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

OMG_スライド_2025年6月14日

 

 

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

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

DMN1_2016年4月10日

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

DMN2_2016年4月10日

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

 

DRD関係の種類_スライド_2025年6月14日

 

 

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

DMN単純モデル5_2017年3月20日

 

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

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

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

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

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

 

BPM_DMN_2017年3月5日

 

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

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

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

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

融資判定_BPMN_2025年6月15日

 

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

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

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

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

融資StrategyDRD_スライド_2025年6月15日

 

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

 

融資DRG_スライド_2025年6月15日

 

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

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

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

DMN1.1 日本語版

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

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

 

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

観点

DMN(意思決定モデル)

ビジネスルール管理

意思決定の構造 DRDにより明示的に記述される 限定的。単体ルールの集積でしかない
活用目的 判断の自動化、実行可能性 ドキュメント・統制目的。
保守性 再利用・改善の対象となる 断片的で依存関係が不透明なので、限定的。
説明責任・透明性 極めて高い あまり高くない

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

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

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

 

参考:意思決定の法律(政策)への適用の試み

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

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

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

BBC2020_Gladysスライド_2025年6月15日

 

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

NZ政府_スライド_2025年6月15日

 

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

Rule_Casesudyスライド_2025年6月15日

 

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

 

Team_スライド_2025年6月15日

 

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

NZ_Better rule_2025年6月15日

 

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

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

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