このコラムは、株式会社エル・ティー・エスのLTSコラムとして2017年11月に掲載されたものを移設したものです。
業務分析、システム導入などの案件に参画。The Open GroupやObject Management Group等の提供するグローバルスタンダードの方法論、モデリング手法を用いて多角的に業務を分析・評価し、ソリューションの提案、実装を支援。TOGAF9.1 Certified。（2021年6月時点）
近年この業務における意思決定の基準の可視化が注目を浴び始めました。2016年9月にはObject Management Group（以下OMG）がDMN（Decision Modeling and Notation）という意思決定モデリングの手法を発表しています。
意思決定の基準を可視化することができれば異なる担当者間での意思決定の基準の共有がとても楽になりますし、システム化の範囲もこれまでよりも大きく広げることが出来ます。このコラムではこのような近年の動向から、業務における意思決定の可視化の考え方を紹介していきます。まず第１回目の今回はそもそも意思決定とは何か、どのような構造なのかということについて掘り下げていきたいと思います。
意思決定とは何か
そもそも意思決定とはどういった行為を示すのでしょうか。意思決定の定義は複数の団体や専門家が行っていますが、このコラムではDMNを発行しているOMGの定義に基づいて考えていきたいと思います。OMGでは意思決定を「どのようにインプットの値からアウトプットの値を決定するのかあらかじめ定義されたロジック用いて、一つ以上のインプットからアウトプットを決定する行為」と定義しています※。つまり、意思決定とはあらかじめ定められたロジックを用いて判断材料（インプット）から結論（アウトプット）を出す行為と言えます。この定義は意思決定がどういったロジックに基づき処理をしているか、ということを重視していると考えられます。
こうした定義の背景にあるのは、近年業務の標準化やシステム化が進み意思決定におけるロジックを紐解くことに注目が高まっていることなどがあります。意思決定のロジックを明らかにすることができれば、担当者間でばらついていた意思決定の基準を合わせて再現性を高めたり（つまり標準化）、処理をシステム化することができます。
意思決定の構造
意思決定の基本的な考え方について理解いただいた上で、次は社内で意思決定が行われているプロセスを例にして意思決定の構成要素と要素間の関係について考えていきたいと思います。
経費申請を受け取ったプロジェクトマネージャーは経費の金額やプロジェクトの利益率を確認し判断を下します。先ほど意思決定の定義は「あらかじめ定められたロジックを用いて、インプットからアウトプットを決定する行為」と説明しました。この例の場合のロジックは何かというと、プロジェクトマネージャーが意思決定を下す際に用いている判断基準です。業務によって明文化されている場合もあれば、暗黙知として文書化されていない場合もあると思います。ここでの判断基準を「プロジェクトの利益率は45%以上にしなければならない」「経費が10万円以上である場合は稟議書を作成し担当取締役の決裁が必要である」と仮定します。ここでのインプットは、経費の申請書にあたります。そしてアウトプットはプロジェクトマネージャーの意思決定の結果。すなわち「否認」「承認」「稟議書作成指示」があてはまります。
ここまでの説明を図にすると以下のようになります。
この構造を一般化すると以下の図になります。
これにより意思決定はインプットとロジックを用いてアウトプットを導き出しているということがわかると思います。この際、意思決定の拠り所となるロジックのことをデシジョンロジックと呼んでいます。このデシジョンロジックの内容によって同じインプットでもアウトプットが変わる可能性があります。したがって意思決定においてデシジョンロジックはとても重要な要素になります。
デシジョンロジックについて
ではこのデシジョンロジックについてもう少し深く考えていきたいと思います。このデシジョンロジックが意思決定の拠り所として機能するためには、一つ一つのロジックがこれ以上分解できず、解釈の余地が入り込まないレベルで定義された宣言である必要があります。つまり、デシジョンロジックを確認するだけで意思決定を下せる状態にならなければなりません。また、注意すべきポイントとして多くの人が意思決定のルールだと考えている社内規定や文書等はデシジョンロジックそのものではありません。OMGの考え方ではデシジョンの論理そのものと、その根拠となる社内規定や文書等を分けて表記します。多くの場合、これらの規定類には「権限はあらかじめ設定された決裁権限基準表に従って行使されなければならない」のように、他の資料を参照したり、曖昧であったり、解釈を加えなければ機能しないものもあります。デシジョンロジックはだれが用いても同じ結論に至る必要がありますから、論理と、その根拠となる社内規定や文書を分けて考えるのです。この参照先になる社内規定や、文書のことをビジネスナレッジソースと呼びます。
デシジョンロジックとビジネスナレッジソースは違う
もう少しデシジョンロジックとビジネスナレッジソースの関係性について掘り下げていきたいと思います。デシジョンロジックはビジネスナレッジソースをもとにして作られているものではありますが、同じものではありません。
ビジネスナレッジソースの例としてLTSの社内規定をあげます。社内規定には「権限はあらかじめ設定された決裁権限基準表に従って行使されなければならない」「この規定において部門長の職務権限を越える事項については、稟議または申請により決裁を得て実施する」と書いてあります。この文章のままではロジックと言えません。「部門長の職務権限を越える事項」が何なのか不明確ですし、「稟議または申請により」というようにどちらの選択肢をとるべきか異なる解釈が入る余地があります。よって、これをもとに意思決定をしているとは言えないのです。
ここから「部門長は見積時に計上されていない経費に関して10万円以上の場合決裁できない」というルールに作り替え、組み合わせることによって初めてデシジョンロジックと言われるものになります。LTSの場合は当然、この金額は金額の定義（税の扱い等）も含めて別紙の基準に定義されていますが、場合によってはこれらの基準が存在せず、慣習や暗黙知に従って個々人が別途に判断している場合もあると思います。仮に参照先のビジネスナレッジソースが存在せず、個々人が慣習や暗黙知に従って意思決定をしている場合でもそれらの基準をビジネスロジックと言うことができます。
したがって、ある意思決定においてデシジョンロジックが存在しないということはあり得ません。仮に社内規定のようなビジネスナレッジソースが明文的にない場合でも、暗黙知として担当者の頭の中に存在しているといえます。ですからデシジョンロジックはあっても、ビジネスナレッジソースが見つからないということはあり得ます。また、同じ業務に従事する担当者間で異なるデシジョンロジックを用いている状態、つまり判断が属人化している状態も当然ありえますので、このような場合は社内で統一されたロジックは存在しない（記述することができない）ことになります。
意思決定のモデリングでは意思決定の基準そのものと、意思決定の基準の元となる明文化された規定やルールがあるかは分けて考えます。こういった意思決定の要素を明確にして記述していくことで、意思決定の再現性を高めることができます。誰が意思決定をしても同じ結果を導き出し、さらにシステム化に繋げるためにはこのデシジョンロジックの網羅性と完全性がとても重要になってきます。
まとめ
今まで説明してきた内容をまとめると、意思決定の構造は以下のような図で表現することができます。
意思決定は、ビジネスナレッジソースをもとに作られたデシジョンロジックとインプットを組み合わせることで、アウトプットを導くといえます。上の図で示した形が意思決定の基本形となるのでしっかりと理解しておいてください。
次回はDMNを用いて本格的に意思決定をモデリングする方法を説明したいと思います。
＜補足＞意思決定とプロセスの違いについて
意思決定をあらかじめ定められたロジックを用いて判断材料（インプット）から結論（アウトプット）を出す行為とするOMGの考え方は、分かりやすい定義だとは思いますが、一つ疑問が生じます。「何かインプットに処理を加えてアウトプットを送り出す」という考え方は過去に多くの専門家が「ビジネスプロセス（プロセス）」に対して行った定義と似ています。例えば“BPR“という言葉を生み出したマイケル・ハマー氏はビジネスプロセスを「一種類以上のインプットを使い、顧客に価値があるアウトプットを創り出すアクティビティの集合」と定義しています。
では、何故OMGはこのように似ている定義をしたのでしょうか。極論だとプロセスも意思決定もほぼ同じ行為を指します。なぜならば、多くの業務には何かしらの判断基準があらかじめ決まっており、それをもとに何らかの処理をしているからです。例えばねじを締めるといった一見意思決定を含んでいなさそうな業務をとっても、細かく考えていくと「どこまで締め付けるとねじを締めたといえるのか」といった基準が含まれています。（調べたところ、このような作業ではねじ締め付けトルク値という数値基準がありました）。
ですからある行為を「プロセス」と呼ぶか、「意思決定」と呼ぶかは、実はその行為の何に注目するかの違いです。プロセスという言葉は業務の依存関係や時系列を重視しています。それに対して意思決定という言葉は、その業務はどういったロジックに基づき処理をしているのかということを重視しています。つまりある業務が参照しているルールや条件を重視しています。
