ソフトウェアのテストでは、さまざまな条件を組み合わせて実施されます。
例えば商品のSKU（サイズやカラーなどの違いを含めた商品管理単位）と在庫数、注文数を組み合わせてテストを行ったり、ユーザーのロールやアクセス権限を考慮したテストを行ったりします。
こうした複雑な条件下におけるテストでは、漏れなくテスト条件を洗い出さなければなりませんが、その上でさらに効率的なテスト設計が求められます。網羅性と効率を両立させるのは難しい課題です。
そこで、有効なのがデシジョンテーブルというテスト技法です。
本記事では、このデシジョンテーブルの基本的な概念と、ソフトウェアテストへの応用方法について解説します。
デシジョンテーブルとは？
デシジョンテーブルは、複数の条件とそれに対するアクションを整理して、テストケースを明確にするための表形式の手法です。
デシジョンテーブルを利用するメリットは以下の通りです。
- 複雑な条件の組み合わせを視覚的に整理できる
- テストケースの漏れを防ぎ、網羅性を向上させる
- テストケースの重複を排除し、効率的なテスト設計を実現する
業務システムや複雑なフロー制御の仕様整理、ならびにテストケース設計に広く用いられます。
デシジョンテーブルの構成
デシジョンテーブルは、以下の要素で構成されます。
- 条件（Condition） ：テスト対象の状態や入力値
- アクション（Action）：条件に基づいて実行される処理
- ルール（Rule）：条件とアクションの組み合わせ
デシジョンテーブルの典型的な表としては、上半分に条件行、下半分にアクション行を配置します。
列はルールを表し、各ルールは「条件値の組み合わせ」と「そのとき発動するアクションのON/OFF」です。
条件値は真偽（Y/N）だけでなく、範囲やカテゴリの離散値でも構いません。
ビジネス上の優先順位がある場合は、表外に優先度を明記するか、衝突時の決定規則（例えば“より厳しい規則が勝つ”）を脚注として添えます。
現実には「到達不能な組み合わせ」や「同義の組み合わせ」が含まれやすいため、これらを識別して削除・統合する工程が品質と効率に大きく寄与します。
デシジョンテーブルテストの活用シーン
3-1 複雑なビジネスルールの整理
業務システムでは、会員種別や契約期間、地域、残高や在庫、審査結果といった多様な条件が絡み合い、優先順位や例外規則も加わって、仕様が口頭や文章だけでは把握しにくくなりがちです。
デシジョンテーブルに落とし込むと、条件を上段に、期待されるアクションを下段に配置し、列ごとに「この組み合わせならこの結果」という対応関係を明確化できます。
結果として、暗黙の前提や矛盾、二重適用のような不具合の芽が早期に発見され、設計者・開発者・テスター・業務担当者のあいだで同じ絵を見ながら合意形成が進みます。
Markdownやドキュメントの表機能でも十分活用でき、Excelや専用ツールを使えば、条件値の増減やルールの修正履歴の管理も行いやすくなります。
3-2 条件組み合わせが多いテスト設計
分岐が多い機能では、条件の組み合わせを手作業で洗い出すと漏れが生じやすく、逆に無制限に展開するとケースが膨大になって現実的ではありません。
たとえば、値域が1〜100の条件が二つあるだけで、100×100＝10,000通りに達します。
そのため、デシジョンテーブルを使うことで、まず完全な組み合わせを俯瞰してから、実現不可能な列を取り除き、同じ結果に収束する列を統合するなどの「ルール圧縮」によって必要十分なケースへ縮約できます。
さらに同値分割や境界値分析を併用して条件をグルーピングすれば、網羅性を保ちながらテスト規模を現実的な水準に抑えられます。
表形式で一覧性が高いため、レビューもしやすく、チームでの品質担保に直結します。
デシジョンテーブルの書き方5ステップ
では、ここから実際にデシジョンテーブルを作成する手順を解説します。
4-1 条件の洗い出し
まず、テスト対象の状態や入力値を明確にするために、条件を洗い出します。
条件とは、テストケースが成立するための前提条件や入力値のことです。
例としては、以下の通りです。
- ユーザーのロール（管理者、一般ユーザー、ゲスト）
- 商品の在庫状況（在庫あり、在庫なし）
- 注文の状態（新規、処理中、キャンセル）
4-2 アクションの整理
次に、条件に基づいて実行されるアクションを整理します。
アクションとは、特定の条件が満たされたときにシステムがどのように振る舞うかのことです。
例としては、以下の通りです。
- ユーザーのロールに応じたアクセス権限の付与
- 商品の在庫状況に応じた購入可否の判定
- 注文の状態に応じた処理の実行
4-3 ルールの定義
洗い出した条件とアクションの組み合わせをルールとして定義します。
ルールとは、特定の条件が満たされたときに実行されるアクションを明確に示すものです。
例としては、以下の通りです。
- ユーザーが管理者で、商品が在庫ありの場合 → 購入を許可する
- ユーザーが一般ユーザーで、商品が在庫なしの場合 → 購入を拒否する
- ユーザーがゲストで、商品が在庫ありの場合 → ログインを促す
4-4 表の作成
ルールが定義できたら、実際にデシジョンテーブルの表を作成します。
表の形式は、条件とアクションを整理しやすいように工夫します。こうした表は、Excelや専用のツールを使って作成するのが一般的です。
▼表の例
| ユーザーのロール | 商品の在庫状況 | 注文の状態 | アクション |
| 管理者 | 在庫あり | 新規 | 購入を許可する |
| 一般ユーザー | 在庫なし | 処理中 | 購入を拒否する |
| ゲスト | 在庫あり | キャンセル | ログインを促す |
▼デシジョンテーブルの例
4-5 テストケースの抽出
最後に、デシジョンテーブルからテストケースを抽出します。
各ルールに対して、具体的なテストケースを定義します。
上記の表を基にすれば、以下のようなテストケースが考えられます。
- ユーザーが管理者で、商品が在庫あり、注文が新規の場合 → 購入を許可する
- ユーザーが一般ユーザーで、商品が在庫なし、注文が処理中の場合 → 購入を拒否する
- ユーザーがゲストで、商品が在庫あり、注文がキャンセルの場合 → ログインを促す
テストケースには、前提条件、入力データ、期待結果、観測方法、後処理を紐づけ、追跡可能性を確保します。リスクや頻度に応じて優先度を付け、時間やコストの制約に合わせて抽出範囲を調整します。
境界値に対する追加ケースや、負荷・エラー系の派生ケースは、デシジョンテーブルの外で補完することも有効です。
★よくある書き方のミスや注意点
デシジョンテーブルを作成する際には、条件やアクションの洗い出しに注意しましょう。
条件を網羅的に洗い出しておかないと、テストケースにも漏れが発生する可能性があります。
また、アクションも具体的に定義することが重要です。抽象的な表現ではなく、実際のシステムの振る舞いを明確に示すようにしましょう。
また、表の形式は整理しやすいように工夫することも大切です。条件やアクションが多くなると、表が複雑になりがちですが、見やすく整理された表を作成すれば、チーム内での共有やレビューがスムーズになります。
デシジョンテーブルテストのポイント
デシジョンテーブルテストの要点は、網羅性と実効性のバランスです。
無作為な全展開は現実的ではない一方、感覚的な抽出では漏れが生じます。
そこで、同値分割と境界値分析で条件値を圧縮し、到達不能・冗長なルールを整理してから、頻度・影響度・検出困難性に基づいて優先度を付けます。
▼年齢区分に同値分割を使用したデシジョンテーブルの例
また、ビジネス優先順位や例外の扱いを表外メモではなく、テーブルの脚注や列構造に織り込み、読み手が表だけで判断できる状態に整えることも重要です。
作り方の面では、軽量な段階ではMarkdownやドキュメント表を使い、運用フェーズに入ったらExcelや専用ツールでフィルタ・差分・履歴管理を取り入れると、変更に強いテスト資産になります。
特に数値条件の大量生成は便利な反面、1〜100の二条件だけで10,000通りという具合に膨張するため、展開の前に縮約方針を確立しておくことが重要です。
まとめ
デシジョンテーブルとは、複数の条件とそれに応じて実行されるアクションの対応関係を表に整理し、テストケースを明確にする手法です。
SKU×在庫×注文数やロール×権限のように条件が絡む場面で、漏れや矛盾を早期にあぶり出し、仕様の共有・レビューをしやすくします。
ただし全組み合わせは膨らみやすいため、まず同値分割で意味が同じ値を代表値にまとめ、境界値を重点的に拾います。
次に、到達不能な組み合わせや結果が同じ列を削除・統合して表を圧縮し、残ったケースを発生頻度・影響度・検出の難しさで優先度付けすれば、網羅性と効率の両立が可能です。
作成はまずはMarkdownやExcelで十分で、運用で育てる段階では専用ツールを使うと差分・履歴管理が楽になります。
デシジョンテーブルを体系的に学びたい方は、「テスト技法入門ガイドブック」がおすすめです。
ぜひダウンロードしてご活用ください。
