デシジョンテーブルの書き方｜要件を詰める5ステップ

はじめに

料金、在庫、会員ランク、申請金額、承認権限。条件が増えるほど、文章だけで業務ルールを正確に伝えるのは難しくなる。

たとえば「会員には割引する。ただしセール品と一部商品は対象外で、クーポンとの併用はできない」と書かれていても、会員がセール品にクーポンを使った場合の結果はすぐには分からない。

担当者ごとに解釈が分かれれば、画面、API、テストで別々の仕様が実装される。

このような条件の組み合わせを表にして、結果を一意にするのがデシジョンテーブル（決定表）である。本記事では、ECサイトの配送料無料判定を題材に、要件定義で使えるデシジョンテーブルの書き方を5ステップで整理する。

デシジョンテーブルとは、条件と結果の組み合わせを表す仕様である

デシジョンテーブルは、判断に使う条件と、その組み合わせに対して実行する行動を表にしたものだ。一般に、表には次の要素を置く。

• 条件：判断材料。例は会員か、購入金額が基準以上か
• 条件値：Yes／No、区分、範囲など
• 行動：条件の組み合わせに対する結果
• ルール：一つの条件組み合わせと行動を結ぶ列

ISTQBの用語集では、デシジョンテーブルテストを、条件の組み合わせとそれに対応する行動を表現した決定表に基づくブラックボックステスト技法としている。つまり決定表は説明資料だけではない。仕様をそのままテスト条件へ接続できる。

一方、すべての判断を二値の表にする必要はない。OMGのDecision Model and Notation（DMN）は、業務上の意思決定をモデル化し、入力データ、判断、知識の関係を表現する標準である。単純な決定表から始め、判断が複数段に分かれる場合はDMNのようなモデルへ広げるとよい。

フロー図が処理の順序を表すのに対し、デシジョンテーブルは「同じ地点で、条件の組み合わせにより何が変わるか」を表す。業務フロー図の書き方で判断点を見つけ、複雑な判断だけを決定表に切り出すと役割が重ならない。

ステップ1：判断の入口と出口を一つに絞る

最初から条件を並べると、異なる判断が一つの表に混ざる。まず、この表が何を決めるのかを一文で固定する。

今回の入口と出口は次の通りだ。

「配送方法を決める」「到着予定日を計算する」は別の判断である。送料表へ一緒に入れると、条件数が急増し、どの変更がどこへ影響するか分かりにくくなる。

入口と出口を固定すると、関係者も決まる。営業はキャンペーン条件、物流は配送可能地域、経理は請求額、開発は入力値と返却値を確認する。一枚の表で合意する対象が明確になる。

判断名には動詞を使い、出力はシステムが扱える値まで具体化する。「優遇する」ではなく「送料を0円にする」、「対象外」ではなく「注文を受け付けず理由コードを返す」と書く。

ステップ2：条件を独立した問いに分解する

次に、判断に必要な条件を、一行につき一つの問いへ分解する。

悪い条件は「有料会員で1万円以上購入したか」だ。会員区分と購入金額の二つが混ざっているため、無料会員や9,999円の扱いを再利用できない。

良い条件は次のように分ける。

1. 配送地域はサービス対象内か
2. 商品は通常配送の対象か
3. 有料会員か
4. 割引後の商品合計が1万円以上か

ここで「購入金額」の定義も固定する。税込か税抜か、クーポン適用前か後か、送料を含むか、複数配送先ならどの単位で判定するか。数値条件は境界値で不具合が出やすいので、「1万円以上」なら9,999円、10,000円、10,001円をテストできる表現にする。

条件には、画面に表示された値だけでなく、判断時点で取得できる事実を使う。「優良顧客か」のように算出根拠が曖昧な条件は、会員マスターのランクや直近12か月の確定購入額など、参照元と更新時点まで決める。

データ項目の意味が揺れる場合は、データディクショナリの作り方と併用する。決定表は項目定義の代わりではなく、定義済みの値をどう判断へ使うかを示すものだ。

ステップ3：組み合わせを列挙し、優先順位を決める

4個の条件がすべてYes／Noなら、理論上の組み合わせは16通りある。ただし、全列をそのまま残す必要はない。結果に影響しない条件は「—（不問）」にまとめられる。

R1では地域が対象外なら、会員や金額に関係なく配送不可になる。R2では特殊商品向けの別配送へ渡すため、通常送料の計算をしない。R3以降で初めて会員区分と金額を評価する。

この表では列の左側を優先する。ただし、実装者が暗黙に左から読むと期待してはいけない。「最初に一致したルールを採用する」「複数一致は禁止する」などの評価方法を仕様に書く。

複数の割引を同時に適用できるなら、結果は一つとは限らない。併用可否、計算順序、上限額、端数処理を別の行動として追加する。優先順位を表の外の注記だけに置くと見落とされるため、ルール番号と適用順を明示する。

ステップ4：漏れ、重複、矛盾をレビューする

表が埋まったら、見栄えではなく三つの欠陥を探す。

漏れ

どのルールにも一致しない入力がないかを確認する。会員区分が「有料／無料」だけの想定でも、未ログイン、退会済み、データ取得失敗が実際には入り得る。未定義値を正常系へ丸めるのか、判定不能として止めるのかを決める。

重複

一つの入力が複数ルールに一致しないかを確認する。R3を「会員なら無料」、R4を「1万円以上なら無料」と書くこと自体は問題ないが、有料会員かつ1万円以上が両方に一致する。結果が同じでも、将来片方の特典だけを変更すると競合する。重複を許すなら、その意図と優先順位を残す。

矛盾

同じ組み合わせに異なる行動が定義されていないかを確認する。業務規程、キャンペーン資料、既存システムの挙動が食い違った場合、表を勝手に平均化しない。論点として担当者、決定日、根拠、適用開始日を記録する。

レビューでは条件を上から読むだけでなく、具体例を表へ当てる。「沖縄へ9,999円の商品を送る無料会員」「対象外地域へ送る有料会員」など、境界と例外を含む注文をルール番号へ結び付ける。要件定義レビューのチェックリストと同じく、誰が何を判断したかを記録すると、変更時に背景を追える。

ステップ5：受け入れテストと実装へ同じIDで渡す

完成した決定表には版番号を付け、各ルールを受け入れテストへ変換する。

ルールごとに最低一つのテストを置き、数値の境界、無効値、データ取得失敗を追加する。これで「表にはあるがテストされない条件」と「テストにはあるが根拠がない期待値」を見つけられる。

実装へ渡すときも、条件式だけをコード生成AIへ貼らない。判断名、入力の型、ルールID、出力、優先順位、エラー時の扱い、テストIDを一緒に渡す。AIが読める仕様書の書き方で扱ったように、構造と識別子があれば、人間とAIが同じ判断を追跡しやすい。

業務ルールを変更するときは、コードを先に直すのではなく表の版を更新する。変更された列を確認し、対応テストを再実行する。決定表をソース・オブ・トゥルースにすれば、企画書、実装、テストのずれを減らせる。

デシジョンテーブルを使うべき場面

次の場面では、文章やフロー図だけより決定表が向いている。

• 割引、料金、手数料、税の計算
• 申請金額や役職による承認経路
• 権限、公開範囲、操作可否の判定
• 本人確認や不正検知の追加審査
• 在庫、地域、配送方法による受注可否
• エラー種別ごとの再試行、停止、有人対応

反対に、単純な手順の順序、画面間の移動、非同期処理の時間的なやり取りは、業務フロー図、画面遷移図、シーケンス図の方が伝わりやすい。図を一つに統合するのではなく、判断点から決定表IDを参照する。

まず一つの判断を表にする

デシジョンテーブルの価値は、条件を網羅した大きな表を作ることではない。曖昧な文章を、確認できる入力と一意の結果へ変えることにある。

まず、問い合わせが多い料金判定や承認条件を一つ選ぶ。入口と出口を決め、条件を分解し、組み合わせと優先順位を並べ、漏れ・重複・矛盾をレビューする。最後にルールIDを受け入れテストへ結ぶ。この5ステップなら、業務担当、開発者、テスターが同じ仕様を見て議論できる。

業務ルールを整理するツールを検討している場合は、Kakusillの紹介ページも参考にしてほしい。

株式会社Atsumellでは、業務フロー、条件分岐、例外、権限、受け入れ条件を整理し、実装へ渡せる要件定義を支援している。複雑な業務ルールが議事録や担当者の経験に散らばっている場合は、お問い合わせから相談してほしい。