対象試験と出題頻度
決定表（デシジョンテーブル）は、基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェアの要件定義・設計・テスト技法の問題として定番化しており、「条件指定部」「動作指定部」「規則」の構成や、ブラックボックステストの技法（同値分割・限界値分析・原因結果グラフなど）との違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「決定表って結局、何のための表なの？フローチャートと何が違うの？」と混乱しがちです。
決定表（デシジョンテーブル／Decision Table）とは、一言で言うと
「条件の組合せと、それに対応する動作を表形式で整理した図表」
のことです。
イメージとしては、「遊園地の料金表」です。
料金表には「大人か子供か」「平日か休日か」「会員か非会員か」といった条件の組合せに応じて、金額がきっちり決まっています。窓口の人は表を見るだけで迷わず料金を出せます。
決定表も同じで、複雑な条件分岐を「もしAかつBなら、この処理をする」と表に落とし込み、抜け漏れや矛盾を防ぐ仕組みです。
📊 決定表の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Decision Table |
| 分類 | 論理表現技法／ブラックボックステスト技法 |
| 主な利用工程 | 要件定義・設計・テストケース設計 |
| 構成要素 | 条件記述部、条件指定部、動作記述部、動作指定部 |
解説
業務ルールを文章だけで書くと、「会員かつ高額取引のときは値引き対象だが、初回利用ではない場合のみ」といった重なりが発生し、解釈のズレや漏れが起こりやすくなります。
そこで条件と処理をマトリクスで対比させ、どの組合せでも処理が一意に決まることを保証する手段として決定表が使われます。
要件定義での仕様確認、テスト工程でのケース網羅、いずれにも応用できる汎用的な手法です。
4つの構成要素
決定表は左上・左下・右上・右下の4つの領域で構成されます。それぞれの役割を区別することが理解の土台です。
| 領域 | 位置 | 役割 |
|---|---|---|
| 条件記述部 | 左上 | 判断する条件を文章で列挙する（例：年齢が20歳以上か） |
| 条件指定部 | 右上 | 各条件が成立するか（Y）／しないか（N）を規則ごとに記入する |
| 動作記述部 | 左下 | 取り得る動作を列挙する（例：割引を適用する） |
| 動作指定部 | 右下 | 各規則で実行する動作にX（または○）を付ける |
図解：レンタカー料金の決定表
具体例として、レンタカーの割引判定を題材にした決定表を示します。「会員である」「3日以上の利用」という2つの条件で、4通り（2の2乗）の規則をすべて整理しています。
| 規則1 | 規則2 | 規則3 | 規則4 | ||
|---|---|---|---|---|---|
| 条件部 | 会員である | Y | Y | N | N |
| 3日以上の利用 | Y | N | Y | N | |
| 動作部 | 20%割引する | X | － | － | － |
| 10%割引する | － | X | X | － | |
| 通常料金 | － | － | － | X | |
▲ 上半分が「条件部」、下半分が「動作部」。Y=条件成立、N=不成立、X=その動作を実行
規則の数と「Don’t Care（－）」
条件がn個あれば、規則は最大で2のn乗通りになります。条件が3つなら8通り、4つなら16通りです。
ただし、条件の値がY／Nのどちらでも結果が変わらない場合は、条件指定部に「－」（ハイフン、Don’t Care）を入れて規則を圧縮できます。
これにより冗長な規則を1行にまとめられ、可読性が上がります。
類似技法との比較
決定表を正しく位置づけるには、類似の論理表現技法・テスト技法と「何を表現するか」で整理するのが近道です。
| 技法 | 何を表現するか | 見分けキーワード |
|---|---|---|
| 決定表 | 条件の組合せと対応する動作 | 表形式、条件と動作、Y/N |
| フローチャート | 処理の流れ・分岐の順序 | 処理の順番、ひし形、矢印 |
| DFD | プロセス間のデータの流れ | データフロー、データストア |
| 状態遷移図 | オブジェクトの状態変化 | 状態、イベント、遷移 |
| 原因結果グラフ | 原因と結果の論理関係をブール式で図示 | AND/OR、論理ゲート |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 決定表の核心を3行で
・条件と動作を対比させた表形式で論理を整理する技法
・上半分が「条件部（記述／指定）」、下半分が「動作部（記述／指定）」の4領域
・条件n個に対し最大2のn乗通りの規則を網羅でき、抜け漏れ・矛盾の発見に有効
試験ではこう出る！
決定表は、FE・APの午前で「用語説明を選ぶ問題」と、午前・午後で「実際に表を読み解く計算問題」の二刀流で出題されます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H26秋 問46 |
「決定表を説明したものはどれか」を選ぶ問題。 | ・「条件と処理を対比させた表形式」が正解 ・E-R図、DFD、流れ図の説明がひっかけ |
| AP H24秋 問45 |
分析・設計技法の説明として適切なものを選ぶ問題。 | ・正解は「決定表は、条件と処理を対比させた表形式で論理を表現したもの」 ・FE H26秋とほぼ同じ表現 |
| AP R5春 問47 |
上得意客・高額取引の値引き条件を決定表で示し、規則の漏れや表の正しい解釈を問う問題。 | ・条件指定部のY/Nから動作を読み取る計算系 ・Don’t Care（－）の扱いがポイント |
| FE H20秋 問15 |
改善提案の賞金を決定表で定義し、特定の提案がいくらの賞金になるかを計算させる問題。 | ・条件のY/Nを順に当てはめて該当規則を特定 ・複数の動作にXが付く場合の合算処理 |
📝 IPA試験での出題パターン
パターン1：「決定表の説明を選べ」
FE H26秋・AP H24秋に代表される定番形式。「条件と処理を対比させた表形式で論理を表現したもの」が正解。ひっかけは「エンティティを長方形で表し関係を線で結ぶ（E-R図）」「外部・プロセス・データストア間のデータの流れ（DFD）」「処理の流れを矢印で示す（フローチャート）」。キーワードは「条件」「動作」「表形式」。
パターン2：「決定表を読み解いて結果を求めよ」
AP R5春・FE H20秋のように、提示された決定表に対して具体的な条件（例：「会員でかつ3日以上利用」）を当てはめ、結果を導く計算問題。条件指定部をY/Nで埋めて、一致する規則の動作指定部を読み取る手順がそのまま解答ステップになります。
ここまでで合格点には十分です。決定表の作り方を一から自分で書く問題はFE・APでは出題されないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 決定表（デシジョンテーブル）の説明として、最も適切なものはどれでしょうか？
- A. プロセス、データストア、データフロー、外部エンティティの4要素を用いて、システム内のデータの流れを視覚的に表現した図である。
- B. 起こり得る条件の組合せと、それに対応して実行すべき動作を表形式で対比させ、複雑な業務ルールの抜け漏れや矛盾を防ぐために用いる技法である。
- C. 実体（エンティティ）を長方形で表し、実体間の関連を線で結ぶことで、データベースの静的な構造を表現した図である。
正解と解説を見る
正解：B
解説：
決定表は条件と動作を表形式で対比させ、すべての条件組合せに対する処理を網羅的に示すことで、業務ルールの抜け漏れや矛盾を発見しやすくする技法です。FE H26秋 問46やAP H24秋 問45でも、この「条件と処理を対比させた表形式」という表現が正解の決め手になりました。
選択肢AはDFD（データフローダイアグラム）の説明です。プロセス・データストア・データフロー・外部エンティティの4要素はDFD固有の構成要素で、決定表には登場しません。選択肢CはE-R図の説明です。実体（エンティティ）を長方形、関連を線で結ぶ表記法はデータベース設計で用いられるもので、条件と動作を扱う決定表とは目的が異なります。
よくある質問（FAQ）
Q. 決定表の「限定形」と「拡張形」の違いは何ですか？
限定形決定表は条件指定部にY／Nの2値だけを書く形式で、最も基本的なタイプです。拡張形決定表は条件指定部に具体的な値（例：「20歳以上」「20歳未満」など）を直接記入できる形式で、多値の条件をコンパクトに表現できます。IPA試験で扱われるのはほぼ限定形なので、まずはY／N形式の読み解きを優先してください。
Q. テスト工程で決定表を使うときのメリットは何ですか？
ブラックボックステストの一手法として、条件の組合せを規則として網羅できる点が最大のメリットです。同値分割や限界値分析が「単一の入力範囲」を対象とするのに対し、決定表は「複数条件の組合せ」を扱えるため、業務ロジックが絡む機能のテストケース設計に向いています。実務では、契約や料金計算など複雑なルールを持つシステムのテスト設計で重宝されます。
Q. 規則が増えすぎたときはどう整理しますか？
条件の数を減らすか、Don’t Care（－）で規則を統合するのが基本です。例えば条件が5つなら32通りの規則になりますが、結果に影響しない条件を「－」で表すと数行に圧縮できます。それでも複雑すぎる場合は、決定表を機能単位に分割するか、上位の判断と下位の判断で2段階の表に分けるアプローチが有効です。
Q. 決定表とフローチャートはどう使い分けますか？
「処理の順序」が重要ならフローチャート、「条件の組合せに対する結論」が重要なら決定表が適しています。たとえば「データを読み込み→検証→保存→通知」のような時系列の流れはフローチャートが見やすく、「会員区分×購入金額×時期」のような多軸の条件分岐は決定表のほうが整理しやすいです。両者は競合ではなく補完関係にあり、設計書では併用されることもあります。
