2024.10.29

デシジョンテーブル（決定表）とは？メリットや書き方をわかりやすく解説

著者株式会社SHIFT　マーケティンググループ

お役立ち資料

複雑な条件が組み合わされたソフトウェアが仕様書通りに動作するか。そのテストをするために使用するのが「デシジョンテーブル（決定表）」です。

仕様を整理して記述しなければならないため、作成を躊躇してしまう人もいるかもしれません。
しかし、デシジョンテーブルを作成することで、テストによる抜け・漏れを大幅に減らすことが期待できます。

本記事では、デシジョンテーブルの概要と作成するメリット・デメリット、デシジョンテーブルの書き方や作成時のポイントを解説します。

デシジョンテーブル（決定表）とは

デシジョンテーブル（decision table）は、想定されるすべての条件と、それに対して実行すべき動作を整理した表のことです。

仕様ベースのブラックボックス技法のひとつとして、仕様の論理関係、論理的条件の組み合わせを表にまとめ、論理検証の網羅性を高める方法としてよく利用されます。

日本産業標準調査会（JICS）日本産業企画のJIS X 0125:1986において、「決定表」として規定されています。

デシジョンテーブルテスト

デシジョンテーブルを使用して論理的な条件をカバーし、入出力の組み合わせを規則ごとに実行するテストケースを設計するテストを「デシジョンテーブルテスト」といいます。

入力する条件の組み合わせによって実行結果が変わる場合に有効であり、起こりえない条件の組み合わせの把握や、それによるテストケースの効率化にも役立ちます。

また、実際にテストを行った規則の数を、デシジョンテーブル内のすべての規則の数で除算してカバレッジを求めることも可能です。

便利なテストケーステンプレートはこちらからダウンロードいただけます。
＞＞テストケーステンプレートのダウンロードページへ

ソフトウェアテスト入門動画

デシジョンテーブルをつくるメリット

デシジョンテーブルを作るメリットとして、次の5つがあげられます。

・複雑な条件や複数の条件の組み合わせを整理することができる
・網羅性を可視化し抜け漏れがないか確認できる
・矛盾している条件の組み合わせを特定することができる
・可視化されているので他者にもわかりやすい
・すべてのテストレベルに適用できる

「デシジョンテーブルの活用方法」でも触れましたが、デシジョンテーブルを作成して活用することで、ソフトウェアテストにおける項目の明確化や、複雑な条件や組み合わせを整理することができます。

また、仮に開発者とテスト実行者が異なる場合でも、デシジョンテーブルがあれば誰でもテスト実行が容易になるでしょう。

すべてのテストレベルに対応できるため、作成に手間暇がかかったとしても作っておくことを推奨します。

デシジョンテーブルをつくるデメリット

非常に便利なデシジョンテーブルですが、一方で作成するデメリットがあることも忘れてはいけません。

・複雑な条件や複数の条件の組み合わせが増えるとテストケースが増加する
・複雑な条件や複数の条件の組み合わせが多いと作成に時間がかかる

詳しくは「デシジョンテーブルの書き方」で解説しますが、デシジョンテーブルはソフトウェアの仕様を整理して作成しなければなりません。
複雑な条件や組み合わせが多いと、作成するだけで時間がかかってしまうでしょう。また、それぞれの条件をクリアできているかを確認するために、テストケースが増加する可能性もあります。

しかし、開発したソフトウェアが問題なく動作するかどうかを判定するためには、デシジョンテーブルを作成しておいた方が得策です。

作成やテストケースの手間はあるものの、不備のないソフトウェアを完成させるために必要なものであり開発したソフトウェアの品質を担保しやすくなるため、作成しておくメリットの方が大きいと言えます。

デシジョンテーブルの活用方法

デシジョンテーブルは、以下のように活用することができます。

・仕様の抜け漏れや、条件の曖昧さを把握する
・組み合わせ条件に基づいて不具合の原因分析を行う
・テスト作業の自動化に繋げる

デシジョンテーブルは、ソフトウェアの仕様を整理して論理的な条件を明確化するため、作成の段階で仕様の抜け漏れや曖昧さに気づくことができます。
テストを実行する前に問題を把握できるため、仕様確認の手戻りを減らすことにつながります。

また、テストで不具合を検出した時に、どの組み合わせ条件がOKで、どの条件がNGになったということを明確に示すことができます。そのため、ソフトウェア開発でありがちな組み合わせ条件の誤りを短時間で絞り込むことができ、合わせて類似の原因による誤りも発見できる可能性が高まります。

さらに、文章ではなく表で記述することから、さまざまな自動化ツールを適用しやすく、テストの効率化につながります。

ソフトウェアテスト入門動画

デシジョンテーブルの構成

デシジョンテーブルは、以下のようなフォーマットで記述します。

上記の図で記載されている項目の内容は以下の通りです。

・表見出し：「決定表の内容や用途」を記載
・初期化部：「順番に実行すべき動作」を記載
・条件記述部：「考慮すべき条件やデータ」を記載
・動作記述部：「考慮すべき動作や結果」を記載
・条件指定：「判定結果の組み合わせ」を記載
・動作指定：「組み合わせの動作や結果」を記載

1つの規則は1つのテストケースに対応し、条件指定と動作指定の組み合わせで表現されます。通常は複数の規則があり、1列が1つの規則となるように記述します。

補足として補完規則には「実行すべき動作の補助」を記載しますが、初期化部と補完規則は任意であり記載しなくても構いません。

用語解説

それぞれの用語の概要を下表にまとめました。

用語	概要
表見出し（table heading）	決定表のパターンの明確な内容や説明、用途などを記載します。
初期化部（initialization section）	考えられる条件をすべて記載するため、実行すべき条件を洗い出し記載します。初期化部は表見出しの次の行に記載しますが、記載は任意です。
条件（condition）	条件を列挙する条件記述部と条件の組み合わせを記載する条件指定部分をまとめて条件と定義します。
動作（action）	条件の結果を記載する動作記述分と条件の組み合わせ結果がどのような判断となるかを記載する動作指定をまとめて動作と定義します。
条件記述部（condition stub）	問題の記述において考慮すべきすべての条件を列挙します。
動作記述部（action stub）	問題の記述において実行すべきすべての動作を列挙します。
条件指定（condition entry）	ある条件と特定の規則との関連づけのことを示します。条件を満たす場合は「Y（YES）」、満たさない場合は「N（NO）」などを記載します。（指定形式：Y、N、語句、値又はコード、-、#など）
動作指定（action entry）	ある動作と特定の規則との関連づけのことを示します。動作する場合は「X（execute）」、しない場合は「-」などを記載します。（指定形式：X、語句、値またはコード、-など）
規則（rule）	条件指定部および動作指定部を通る一つの列のことで、列ひとつひとつをテストケースとして記載していきます。
補完規則（ELSE-rule）	規則において指定形式が表示されていない条件に対する補足を記載します。

デシジョンテーブルの書き方

デシジョンテーブルの構成を理解したところで、実際の書き方を見てみましょう。作成の順番は次の通りです。

1．条件が何かを特定して記述する
2．動作が何かを特定して記述する
3．条件の組み合わせをすべて指定する
4．条件の組み合わせに対応する動作をすべて指定する

おおまかな流れとしては、条件→動作→条件→動作の順です。それぞれの工程で何をするのか、詳しく見てみましょう。

①条件が何かを特定して記述する

はじめに、条件を記載します。上記の表は、チケット購入における割引の条件と動作について一例としてあげたものです。

仕様書に書かれている条件のうち、該当するものをすべて選び出して条件記述部にその内容を記載しましょう。今回の場合、年齢区分が条件として仕様書に書かれていると仮定して、表内に記載しています。

②動作が何かを特定し記述する

続いて動作記述部に、動作を記述します。上記の表の場合、15％と5％の割引および割引なしを記載しています。

デシジョンテーブルの役割は、複雑な条件や動作を可視化し、わかりやすくすることです。動作に該当するものは、すべて動作記述部に記載するようにしてください。

③条件の組み合わせをすべて指定する

洗い出した条件に対し、組み合わせを指定します。条件が真の場合は「Y（YES）」を、偽の場合は「N（No）」を記載します。

このとき記載するのは、すべての組み合わせのパターンです。上記の場合であれば全部で3通りの条件があり、それを記載している状態です。条件の組み合わせに抜け・漏れがないように記載しましょう。

④条件の組み合わせに対応する動作をすべて指定する

続いて、それぞれの条件の組み合わせに対して先に設定した動作を割り当てます。条件に当てはまる場合に動作する項目に「X（execute）」を記載しましょう。該当がない場合は「-」を記し、条件の組み合わせに対する動作が一目でわかるようにしておくことが重要です。

なお、該当する動作が無かった場合は、仕様の記述漏れか組み合わせの矛盾なので確認する必要があります。

⑤規則を取捨選択する

複数の独立した条件がある場合には、テストの網羅性を高めるためにすべての組み合わせを検討します。例えば、上記の表は、年齢（条件1）とサービスデー（条件2）の2つの条件の組み合わせを表したものです。この条件の組み合わせを網羅するには6通りの組み合わせが必要となります。しかし、独立した条件がさらに増えると組み合わせ数が爆発的に多くなり、すべてをテストすることが困難になります。その場合は、実際にテストを行いたい規則を絞り込み、現実的な規則数に収めることを行います。

テスト設計基礎（機能テスト編）テスト設計手法の適切な使い方～2因子間網羅～

デシジョンテーブル作成における4つのポイント

デシジョンテーブルを作成する際のポイントをわかりやすくまとめると、以下の4つがポイントといえます。

・条件記述部にはすべての条件を書き出すこと
・動作記述部にはすべての動作を書き出すこと
・条件記述部と動作記述部の矛盾している条件は削除すること
・複雑な条件や複数の条件の組み合わせが多い場合、決定表を分けること

さらに気をつけるべき点として、条件記述部はすべて書き出し、記載する順番を合わせて作成することがあげられます。

ただし、複雑な組み合わせや複数の組み合わせが多い場合は、組み合わせを分けて作成した方が整理しやすくなるといえるでしょう。

条件記述部にはすべての条件を書き出すこと

条件記述部には、仕様に記載されている条件はすべて書き出さなければなりません。条件が書き出せていないと、テストの漏れに繋がり、結果として不具合やリリース遅延に繋がる可能性があります。

新しく条件を指定する場合も、追加する場合も条件をすべて書き出すようにしましょう。

動作記述部にはすべての動作を書き出すこと

動作記述部にもすべての動作を書き出す必要があります。書き出しが不十分だった場合、こちらもテストの際にチェックの漏れに繋がる可能性があります。利用者や関連する人に対して迷惑をかけないためにも、必ずすべて書き出してください。

条件記述部と動作記述部の矛盾している条件は削除すること

条件記述部と動作記述部の矛盾している条件は、必ず削除してください。仕様上ありえない組み合わせになっている場合は、テストをする必要はありません。

複雑な条件や複数の条件の組み合わせが多い場合、デシジョンテーブルを分けること

例で示した条件は単純なものでしたが、複雑な条件や組み合わせが多く存在する場合は、デシジョンテーブルを分割するようにしましょう。可視化できることがデシジョンテーブルの強みですが、複雑な条件がいくつも存在していると、逆にわかりにくくなってしまうことがあります。

あまりにも複雑な条件の場合はデシジョンテーブルを分割し、視認性を高めるようにしてください。ミスや抜け・漏れを防ぐ意味でも非常に重要です。

開発やテストの相談はSHIFTへ

デシジョンテーブルは、その構成（フォーマット）に従い、入力（条件）と出力（動作）の組み合わせを規則ごとに洗い出した表です。複雑な条件や複数の条件の組み合わせを整理する上でとても役立ちます。

デシジョンテーブルを使用してテストケースとして作成することで網羅性を可視化し、デシジョンテーブルテストを行うことで抜け漏れのないテストが可能となります。

SHIFTでは、デシジョンテーブルを使用したテストも対応可能です。第三者がテストを行うことで、時間やコストを最小限に抑えつつ、品質を高めることができます。開発やテストのご相談は、ぜひSHIFTまでお問い合わせください。

＞＞お問い合わせページへ
＞＞料金についてページへ

参考資料：

SEC BOOKS 高信頼化ソフトウェアのための開発手法ガイドブック
https://www.ipa.go.jp/files/000004550.pdf

JIS X 0125：1986 決定表
https://webdesk.jsa.or.jp/preview/pre_jis_x_00125_000_000_1986_j_pr10_i4.pdf

ISTQBテスト技術者資格制度
Foundation Level シラバス日本語版 Version 2018V3.1.J03
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

監修

株式会社SHIFT
「ヒンシツ大学」クオリティエヴァンジェリスト　永井敏隆

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座

・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数

――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

デシジョンテーブル（決定表）とは？メリットや書き方をわかりやすく解説