決定表テストの効果的な活用法：複雑なビジネスロジックを簡潔にテストする

決定表テストは、条件の組み合わせと、それに対する動作を表に並べて、抜けと矛盾を見つける技法です。「条件が3つ以上絡む業務ロジック」に対して最も効きます。

使ううえで守るべきルールがひとつあります。条件がn個なら、まず2のn乗すべての組み合わせを機械的に並べることです。ここを省くと、決定表を作る意味がなくなります。抜けを見つけるための道具なのに、表自体が抜けているという事態になるためです。

この記事は2024年の公開後、2026年9月に見直しました。 公開当時に載せていた表は、2条件なのに3ルールしか無く、1つの組み合わせが欠落していました。正しい形に直したうえで、実務で必要な簡約化の手順を追記しています。

決定表の構造

決定表は4つの領域で構成されます。条件を縦に並べ、ルール（組み合わせ）を横に並べるのが標準的な形です。

	ルール1	ルール2	ルール3	ルール4
条件1	N	N	Y	Y
条件2	N	Y	N	Y
動作1	–	✓	✓	✓
動作2	–	–	–	✓

条件記述部（左上）：判定する条件を並べる
条件指定部（右上）：各ルールでその条件がY（真）かN（偽）か
動作記述部（左下）：起こりうる動作を並べる
動作指定部（右下）：そのルールで動作が実行されるか

1つの列（ルール）が、1つのテストケースになります。 上の表なら4ケースです。

作成手順

手順1：条件と動作を洗い出す

仕様書から、Yes/Noで答えられる形に条件を分解します。「購入金額に応じて」のような曖昧な表現は、そのままでは条件になりません。

✕ 購入金額に応じて送料が変わる
○ 条件：購入金額が5,000円以上である（Y/N）

手順2：全組み合わせを機械的に並べる

ここが最重要です。 条件がn個なら 2のn乗のルールを、例外なく全部並べます。

条件の数	ルール数
2	4
3	8
4	16
5	32

並べ方にもコツがあります。一番下の条件から Y/N を交互に、上に行くほど繰り返し単位を倍にすると、機械的に漏れなく書けます。

手順3：各ルールの動作を埋める

ここで「仕様書に書かれていないマス」が浮かび上がります。 それが決定表を作る本当の目的です。

手順4：簡約化する

結果に影響しない条件を「-」（don’t care）にまとめます。手順は後述します。

実践例：送料と割引の判定

仕様：オンラインショップで、購入金額とプラチナ会員かどうかによって、送料無料と10%割引の適用を決める。

条件1：購入金額が5,000円以上である
条件2：プラチナ会員である
動作1：送料を無料にする
動作2：10%割引を適用する

まず4ルールすべてを並べる

	R1	R2	R3	R4
購入金額 5,000円以上	N	N	Y	Y
プラチナ会員	N	Y	N	Y
送料無料	–	✓	✓	✓
10%割引	–	✓	–	✓

R2（5,000円未満だがプラチナ会員）を落とさないことが重要です。 3ルールしか無い表をよく見かけますが、それは「金額が条件を満たしていないプラチナ会員」の扱いが決まっていないだけです。

この表を作った時点で、開発者に確認すべき点が明確になります。

R2 でプラチナ会員は本当に送料無料になるのか（金額の条件を無視してよいのか）
R3 で割引は適用されないのか
割引の対象は税込か税抜か
送料は割引の計算に含まれるか

「仕様書にはR2のことが書いてありませんでした」と報告できるのが、この技法の価値です。

簡約化：don’t care にまとめる

ルール数が増えると表が読みづらくなるので、結果に影響しない条件を「-」にして列をまとめます。

3条件の例で説明します。

条件1：在庫がある
条件2：支払い方法がクレジットカード
条件3：配送先が離島

簡約化する前（8ルール）

	R1	R2	R3	R4	R5	R6	R7	R8
在庫がある	N	N	N	N	Y	Y	Y	Y
クレジットカード	N	N	Y	Y	N	N	Y	Y
離島	N	Y	N	Y	N	Y	N	Y
注文を受け付ける	–	–	–	–	✓	✓	✓	✓
離島追加料金を加算	–	–	–	–	–	✓	–	✓
即時決済する	–	–	–	–	–	–	✓	✓

簡約化した後（5ルール）

R1〜R4 はすべて動作が同じ（在庫が無ければ何も起きない）なので、1列にまとめられます。

	R1′	R2′	R3′	R4′	R5′
在庫がある	N	Y	Y	Y	Y
クレジットカード	–	N	N	Y	Y
離島	–	N	Y	N	Y
注文を受け付ける	–	✓	✓	✓	✓
離島追加料金を加算	–	–	✓	–	✓
即時決済する	–	–	–	✓	✓

8ルールが5ルールになりました。

簡約化のときに守ること

先に全組み合わせを並べてから、まとめる。最初から「-」で書き始めると抜けに気づけません
動作が完全に一致する列だけをまとめる。1つでも違えば別ルールです
まとめた列も、テストは1回でよいとは限らない。「-」にした条件が実装上分岐している可能性があります。リスクが高い箇所は展開して確認します

あり得ない組み合わせの扱い

全組み合わせを並べると、現実には存在しない行が出てきます。 これも重要な情報です。

条件1：無料プランである
条件2：有料オプションを利用中である

→ 「無料プランで有料オプション利用中」は、あり得ないはず

このとき確認すべきことが2つあります。

本当に発生し得ないのか：解約直後の一瞬だけ発生する、といったことは珍しくありません
発生した場合にシステムはどう振る舞うのか：想定外の状態でクラッシュしないか

「あり得ないので考えない」で消すのではなく、「あり得ないことを確認した」と記録に残してください。 データ不整合で実際に発生したときに、そこが調査の起点になります。

条件が増えすぎたときの対処

条件が6個を超えると64ルールになり、表として扱いづらくなります。対処は3つです。

1. 表を分割する

独立して判断できる条件のかたまりを別の表にします。 「送料の判定」と「割引の判定」が互いに影響しないなら、1つの表にする必要はありません。

2. 階層化する

複数の条件をまとめて1つの中間条件にします。

条件A：会員である
条件B：登録から1年以上
条件C：購入回数10回以上
     ↓
中間条件：「優良会員である」（A かつ B かつ C）

ただし中間条件の定義そのものを別の決定表で確認する必要があります。まとめて隠すのではなく、階層に分けるという意味です。

3. ペアワイズに切り替える

条件がすべて独立していて、単に組み合わせが多いだけなら、決定表ではなくペアワイズテストが適しています。

2つの技法は目的が逆なので、混同しないでください。

	決定表	ペアワイズ
目的	条件と結果の対応を漏れなく定義する	実行できる件数まで減らす
組み合わせ	原則すべて列挙	2因子分のみ網羅
向く対象	業務ロジック、料金計算	環境や設定項目

決定表が向かないケース

順序が結果に影響する場合、決定表では表現できません。 決定表は「今の状態」しか扱えないためです。

例：「申請 → 承認 → 完了」の順でないと処理できない
    「完了」から「申請中」には戻せない

→ 条件のY/Nでは表せない。状態遷移テストの領域

この場合は状態遷移テストを使ってください。また、1つの入力項目の範囲を確認したいだけなら同値分割と境界値分析の担当です。

まとめ

決定表は条件記述部・条件指定部・動作記述部・動作指定部の4領域で構成する
条件がn個なら2のn乗のルールを、必ず全部並べてから始める
2条件なら4ルール。3ルールしか無い表は、1つの組み合わせが抜けている
埋めていく過程で「仕様書に書かれていないマス」が見つかるのが最大の価値
簡約化は全部並べたあとに行う。動作が完全一致する列だけをまとめる
あり得ない組み合わせは消さず、「あり得ないことを確認した」と残す
条件が多すぎるときは分割・階層化。単に組み合わせが多いだけならペアワイズ
順序が絡むものは状態遷移テストの領域

会議で口頭確認した仕様は翌週には忘れられますが、表は残ります。認識合わせの道具としても有効です。上流工程での使い方はウォーターフォール開発におけるQAの重要性とテスト技法の活用法にまとめています。