デシジョンテーブルの書き方：業務ルールとテストの具体例

デシジョンテーブル（決定表）は、業務ルールを条件と結果の組み合わせで表したものです。条件を列に、ルールを行に置き、その行に一致したときの処理を決めます。実際にありそうな入力を当てはめ、意図した結果が一つに決まるかを確かめると、ルールの問題を見つけやすくなります。

例えばサポートチームでは、本番環境への影響、通常の作業の停止、回避策の有無によって問い合わせの振り分け先が変わります。表なら、これらの組み合わせを並べて比較できます。フローチャートには、その判断が業務全体のどこにあるかを描けます。

フローチャートより決定表が分かりやすい場面

複数の入力から結果を決め、ルール同士を比較したい場合は決定表が向いています。最初に何をして、次に何をし、例外が起きたらどこへ戻るかを示したい場合はフローチャートが向いています。同じ業務を異なる粒度で表すこともできます。Boardmixで前後の業務フローを描き、該当する判断の横に振り分けルールを置く方法です。

フローチャートで「本番環境に影響があるか」を判断した後、複数の分岐で「回避策があるか」を繰り返しているとします。矛盾する行き先に到達する分岐があっても、見落としやすくなります。表なら、同じ問いを一つの列にまとめ、交差する矢印を追わずに行を比較できます。

デシジョンテーブルと意思決定マトリクスは別のものです。意思決定マトリクスは、費用や使いやすさなどの基準で選択肢を採点します。決定表は、本番環境で通常の作業が止まっているかといった条件を評価し、決められた結果を返します。この例では、確率や期待金額の計算も扱いません。

ルールを書く前に入力を定義する

ここで扱うのは説明用に設定したサポート業務であり、Boardmixのサポート方針ではありません。目的は一次振り分け先を選ぶことです。応答時間を約束したり、障害の原因を診断したりするものではありません。

• 本番環境への影響：通常業務で使う稼働中の環境に問題が起きていること。テスト環境だけの問題なら「いいえ」です。
• 通常の作業の停止：利用者が通常の手順では目的の作業を完了できないこと。表示上の不具合だけなら「いいえ」です。
• 回避策の有無：利用者が同じ作業を完了できる、確認済みの一時的な代替手順があること。まだ試していない修正案は回避策に含めません。

「通常の作業が止まっている」と「回避策がある」は反対の意味ではありません。通常の手順が使えなくても、手作業や別の経路では完了できる場合があります。この区別を表の横に書いておかないと、同じ報告に対して人によって異なる入力を選んでしまいます。

この例では、三つの入力がすべて分かってから表を評価します。報告だけでは本番環境への影響が分からない場合は、先に情報を集めます。不明な値を黙って「いいえ」に置き換えません。

サポート業務で使うデシジョンテーブルの完成例

次の表では、一行が一つのルールです。「どちらでも」は、その値が当該ルールの結果に影響しないことを表します。情報が欠けていてよい、という意味ではありません。必要な入力がそろったときに、一行だけに一致するように設計しています。

R3を文章にすると、「本番環境に影響があり、通常の作業が止まっているが、回避策がある場合は、優先サポートへ送る」となります。結果は振り分け先です。問題が解決したことを意味しません。

「本番環境の一括エクスポートボタンは動かないが、個別レコードのダウンロードは使える」という報告を考えます。個別ダウンロードで目的の作業を完了できると確認できたら、入力は「はい／はい／はい」です。本番に影響があるためR1には一致しません。通常の作業が止まっているためR2にも一致しません。R3には一致し、回避策があるためR4には一致しません。

次に、問題が起きた環境だけをテスト用ワークスペースに変えます。この場合は、残る二つの値にかかわらずR1に一致します。不具合が重要でないという意味ではなく、この例で定めた振り分け方を適用した結果です。別の方針を採用するチームでは、注記に例外を隠さずルール自体を変更します。

重複するルールと、どの行にも当てはまらない入力を探す

真偽値の入力が三つあると、組み合わせは八通りです。R1は四通り、R2は二通り、R3とR4はそれぞれ一通りを扱います。これらは重複しないため、この小さな表で真偽値の全組み合わせを網羅できます。

網羅していることと、業務上正しいことは別です。すべての組み合わせを扱えても、誤った方針を実装する表になっているかもしれません。振り分け方針の責任者に結果を確認してもらい、特にその組織で「優先」や「インシデント」が何を意味するかをそろえます。

よくある誤りは、次のように確かめられます。

• 重複：R2の作業停止条件を「いいえ」から「どちらでも」に変えると、本番の通常作業が止まっていて回避策がある報告は、R2とR3の両方に一致します。一件に二つの行き先ができてしまいます。
• 漏れ：R3を削除すると、本番の通常作業が止まっていて回避策がある報告は、どの行にも一致しません。似ている行を選んで処理すると、存在しないルールを作ったことになります。

正式な意思決定モデルのツールでは、この一致時の扱いをヒットポリシーと呼びます。Camundaのヒットポリシー解説では、Uniqueは複数ルールへの一致を許さず、Firstは最初に一致したルールを選びます。Firstの表は行を並べ替えると結果が変わることがあるため、この違いは重要です。順番を方針の一部として定めていない限り、見た目の行順に判断を任せないようにします。

この記事の表は設計用の文書であり、実行できるDMNモデルではありません。ルールエンジンやアプリケーションに実装するときは、入力の型、一致時の扱い、エラー処理も実装側で定義します。

具体的なケースを当てはめて確かめる

ルールの横に事例を置くと、後から編集したときに結果への影響が分かります。次のケースで、すべての振り分け先と、情報不足時の別経路を確認できます。

数値や日付を使うルールでは、境界の直前・境界上・直後のケースも追加します。「金額が100より大きい」という条件なら、対象の通貨と精度に合わせて99.99、100、100.01を試します。図を描く前に、境界を含むかどうかを決めましょう。「大きな依頼」のような表現は、業務上の定義がなければ一貫して評価できません。

許容値に含まれない入力も試します。「はい」と「いいえ」しか受け付けないなら、空欄、誤字、「おそらく」などの扱いを明確にします。既定の振り分け先を設ける場合も、不正な入力を隠すためではなく、意図して決める必要があります。

自分の業務に使えるルール記述のひな形

次の項目を短く書いてから、ルールの行を追加します。別のプロジェクト文書にコピーされても、表の意味を理解できるようにするためです。

• 判断すること：この表は、どの一つの問いに答えるのか。
• 入力：各条件の名前、定義、許容値。
• 出力：返せる振り分け先、分類、処理の正確な名称。
• 一致時の扱い：一行だけに一致するのか、最初の一致を採るのか、別の方針なのか。
• 不明な入力：必要な事実が欠けているとき、評価前に何をするのか。
• 事例：各結果に至る通常のケースと、範囲を使う場合の境界ケース。

Boardmixのキャンバスでは、左に入力の定義、中央にルール表、右に報告例を置けます。表とテストケースで同じルールIDを使えば、レビューでも「真ん中の三番目」ではなく「R3」と指定できます。未決定の方針は、合意済みの行とは分けて置きます。

振り分け先が決まったら、報告の受け付け、必要情報の収集、ルールの評価、担当先への送付という前後の流れにつなげます。Boardmixを開いて、決定表と業務フローを整理しましょう。