属性の質問順序の設計原則
問題: 詳細な属性を先に聞いて、後から「対象外でした」は最悪のUX
障害者控除を例に考える。
障害者控除の適用条件（対象者別）:
| 対象者 | 障害者であること | 合計所得金額の要件 |
|---|---|---|
| 本人 | 必要 | なし |
| 配偶者 | 必要 | 同一生計配偶者であること（配偶者の合計所得金額 ≤ T） |
| 扶養親族 | 必要 | 扶養親族であること（親族の合計所得金額 ≤ T） |
配偶者・扶養親族の場合、障害があっても合計所得金額の要件を満たさなければ控除を受けられない。
悪い質問順序
1. 配偶者は障害者ですか？ → はい
2. 障害の種類は？ → 身体障害者手帳
3. 障害等級は？ → 2級（特別障害者）
4. 同居していますか？ → はい（同居特別障害者）
5. 配偶者の合計所得金額は？ → 200万円
→ 同一生計配偶者に該当しないため、障害者控除は受けられませんユーザーは4つの質問に答えた後で「対象外」と知らされる。
良い質問順序
1. 配偶者の合計所得金額は？ → 200万円
→ 同一生計配偶者に該当しないため、障害者控除の対象外です
（障害の有無を問う必要がない）所得が閾値以下の場合にのみ、障害者に関する質問に進む。
原則: 足切り条件を先に、詳細な属性を後に
質問順序は以下の優先度で設計する:
- 答えやすい属性を先に聞く: 合計所得金額、年齢、続柄など、多くの人が即答できるもの
- 足切りになる条件を先に聞く: その回答次第で後続の質問が不要になるもの
- 詳細な属性は足切りを通過した後に聞く: 障害者区分、障害等級、同居の有無など
足切り条件 詳細な属性
（答えやすい） （答えにくい・複雑）
────────────── ──────────────
合計所得金額 → 障害者区分（一般/特別）
→ 同一生計配偶者? 障害等級
→ 扶養親族? 同居の有無（同居特別障害者?）
↓ 該当しない場合
→ 障害者の質問をスキップ答えやすさの基準
| 属性 | 答えやすさ | 理由 |
|---|---|---|
| 合計所得金額（概算） | 高 | 給与収入から概算できる。給与データ連携があれば自動 |
| 年齢・生年月日 | 高 | 誰でも知っている |
| 続柄（配偶者・子・親等） | 高 | 誰でも知っている |
| 同居の有無 | 高 | 即答できる |
| 障害者に該当するか | 中 | 本人は知っているが、判断に迷う場合がある |
| 障害の種類・等級 | 低 | 手帳の確認が必要。区分の理解も必要 |
| 勤労学生の要件（所得種類別内訳） | 低 | 所得の種類区分は一般人には難解 |
複雑な要件に対する判定支援機能の提供
問題: 複雑な分岐条件による誤判定リスク
障害者控除を例に考える。障害者の区分（一般の障害者 / 特別障害者 / 同居特別障害者）によって控除額が大きく異なる:
| 区分 | 控除額 |
|---|---|
| 一般の障害者 | 27万円 |
| 特別障害者 | 40万円 |
| 同居特別障害者 | 75万円 |
特別障害者に該当するのに一般の障害者と誤って申告した場合、最大48万円の不利益が生じる。 これは申告者にとって明確な損害であり、システムとして防ぐべきエラーである。
しかし、障害者の該当有無および区分の判定は以下のように複雑である:
- 入口が多岐にわたる: 身体障害者手帳、精神障害者保健福祉手帳、療育手帳（知的障害）、傷病恩給、原子爆弾被爆者認定、寝たきり判定、65歳以上の市町村長認定 等
- 同じ手帳でも等級で区分が分かれる: 身体障害者手帳1-2級→特別障害者、3-6級→一般の障害者
- さらに同居要件で区分が変わる: 特別障害者 + 同居 → 同居特別障害者
一般の申告者がこれを正しく判定するのは困難である。
→ 障害者の該当条件の詳細は 障害者控除 参照
原則: 複雑な判定にはウィザード/フローチャートで判定支援を提供する
TASHIKAの「属性で考える」設計思想に従い、申告者が答えるのは「自分の属性」（手帳の種類、等級、同居の有無）であり、 区分の判定（一般 or 特別 or 同居特別）はシステムが行う。
ただし、手帳の種類や等級の入力自体に迷うケースがあるため、以下の判定支援機能を提供する:
| 支援形式 | 適用場面 | 例 |
|---|---|---|
| ウィザード形式 | 条件分岐が多い判定 | 障害者区分の判定（手帳種類→等級→同居→区分を段階的に案内） |
| フローチャート表示 | 全体像を俯瞰したい場合 | 判定フローの可視化（「自分がどの経路に該当するか」を視覚的に確認） |
| ヘルプテキスト/ツールチップ | 個別の用語が不明な場合 | 「特別障害者とは？」「療育手帳の等級の見方」等 |
判定支援が必要な控除・属性
障害者控除以外にも、以下のような複雑な判定が存在する:
| 控除・属性 | 複雑さの理由 |
|---|---|
| 障害者控除の区分判定 | 手帳の種類×等級×同居の組み合わせが複雑 |
| 勤労学生控除の判定 | 所得の種類別内訳（勤労所得 vs 不労所得）の理解が必要 |
| 寡婦 vs ひとり親の判定 | 死別/離婚/未婚、子の有無、所得、事実婚の有無の組み合わせ |
| 生命保険料控除の区分 | 一般/介護医療/個人年金の3区分 × 旧制度/新制度 |
「属性で考える」設計との整合
判定支援機能は「属性で考える」設計と矛盾しない。むしろ補完関係にある:
- 属性を正確に答えてもらう ← 判定支援機能がここを助ける
- 属性から控除を自動判定する ← 税額計算エンジン が行う
ウィザード/フローチャートの目的は「どの控除を受けるか」を教えることではなく、 「自分の属性を正確に答えてもらう」ことを支援すること。 結果としてシステムが正しい区分を判定し、申告者に不利益が生じないようにする。
Born Digital との組み合わせ
TASHIKAでは多くの属性が自動連携されるため、「質問する」場面自体が限られる。 自動取得できる属性は足切りにそのまま使え、質問順序の問題は手入力が必要な属性間で発生する。
自動取得（質問不要） 手入力（質問が必要）
────────────── ──────────────
給与データ → 合計所得金額概算 配偶者・親族の合計所得金額（見積額）
生年月日 → 年齢 障害者区分
FamilyRelationship → 続柄 勤労学生の在学証明手入力が必要な属性の中で、足切りになるもの（所得見積額など）を先に聞く。
「事実と控除判定結果の分離」との関係
この質問順序の原則は UIの設計原則 であり、データモデルの設計原則（事実は常に記録する）とは独立。 データモデル上は障害者情報も所得情報も等しく保持するが、UIで情報を収集する順序 として、 足切りになる所得を先に、詳細な障害者情報を後に聞く。
ただし、前年データが引き継がれている場合は既に障害者情報がデータ上に存在するため、 「今年も障害者に該当しますか？」という確認のみで済む場合もある。 このときは質問順序の問題は発生しない（確認フローで一括確認）。