目的
選んだ判断について、何を見て、誰が、どう決めるかを設計します。
答える問い
何を見て、誰が、どう決めるか
できあがるもの
判断の状態と流れの設計（JSC）、判断の中身の設計（JDC）、判断対象と状態の定義
判断を設計する
Phase0〜Phase2では、対象の業務を整理し、判断を発見し、実装対象を選びました。
しかし、判断を見つけただけでは、まだ実装することはできません。
人は判断を行うとき、無意識のうちに多くの情報を見ています。
何を材料に判断するのか。
誰が判断するのか。
誰が責任を持つのか。
判断できない場合は誰に相談するのか。
判断した結果、何が変わるのか。
これらを整理しなければ、判断を再現することも、AIで支援することもできません。
Phase3 Designは、判断を実装可能な構造へ変換するための工程です。
なぜ判断設計が必要なのか
判断設計の目的は、JSCやJDCを作ることではありません。
判断設計を行うことで、それまで人の頭の中にあった暗黙知を可視化できます。
例えば、
- 判断に必要な情報
- 判断を行う主体
- 判断責任者
- エスカレーション先
- AIが支援できる領域
- 判断後に変化する状態
- 次に発生する判断
です。
実装段階になると、
「どの情報を集めればよいのか」
「どの情報を画面に表示すればよいのか」
「AIに何を支援させればよいのか」
といった問いに必ず直面します。
判断設計は、それらの答えを明らかにする工程でもあります。
状態変化の設計（JSC：Judgement State Chart）
JSCは、判断対象が取り得る状態と、JPによる状態遷移を定義します。
例：「この候補を営業対象として採用するか」
未評価 → 採用判断 → 採用 / 見送り / 保留
状態名は説明用です。対象業務に合わせて設計します。
状態を明確にすることで、
- 今どの状況にいるのか
- どの判断が発生するのか
- 判断後にどこへ進むのか
を整理できます。
JPは状態を確定させる判断です。
「採用」と、その後の登録・接触の完了は区別します。登録タスクが失敗しても、確定済みの採用判断を上書きしません。作業結果をもとに業務上の完了を認める判断が必要なら、その判断と状態を別途設計します。
判断の中身の設計（JDC：Judgement Design Canvas）
状態だけでは判断を再現することはできません。
同じ状態であっても、
- 誰が判断するのか
- 何を見て判断するのか
- どのような結果を選択するのか
によって判断結果は変わります。
JDCは、人が行っている判断を再現可能な形に整理するための設計書です。
| 要素 | 設計する内容 |
|---|---|
| 目的（Purpose） | 何のために判断するか |
| 判断対象（Subject） | 何を対象に判断するか |
| 判断材料（Data Sources） | どの情報が必要か |
| 条件（Conditions） | 客観的に判定できる条件 |
| 観点（Perspectives） | 経験・文脈に依存する観点 |
| 判断結果（Decision） | 取り得る判断結果（選択肢）。JSCの遷移先状態に対応する |
| 判断主体（Actor） | 誰が判断を実行するか |
| 判断責任（Accountability） | 誰が責任を持ち、承認・引き継ぎを担うか |
| 出力（Output） | 次の行動や判断へ何を渡すか |
これにより、暗黙的に行われていた判断を構造として扱えるようになります。
判断材料（Data Sources）
取得元、必要な内容・詳しさ・鮮度、いつ必要か、取得できない場合の扱いを定めます。業務上の制約も残します。集める担当と判断する担当を分け、具体的な取得方法はPhase5で設計します。
材料が欠けたまま判断する場合は、何が欠け、なぜ取得できなかったかを、Phase4で判断時点の記録に残せるようにします。
出力（Output）
結果ごとの後続作業、渡す情報・相手、完了条件、責任や期限を定めます。判断が確定したことと、その後の作業が完了したことを分けて扱います。
Case / Proposal
「この候補を営業対象として採用するか」を設計するときは、何を1件として判断するかを決めます。例えば、ある媒体の特集向けに候補を探しているなら、候補と、その候補を評価する特集の文脈を組にして考えられます。同じ候補でも、文脈が違えば判断が変わる場合があります。
このような判断対象をCaseと呼び、対象と文脈の組み合わせ（Entity × Context）で定義します。これを実行時に扱う具体的な単位として表したものがProposalです。「企業 × 企画」はその一例で、すべての業務に共通する固定構造ではありません。
State
Stateは、Proposalの現在位置を表します。
JDAでは、
State
↓
判断（JP）
↓
State変更という構造で管理します。
この候補の採用可否を判断する例では、現在状態を「未評価」、判断後を「採用・見送り・保留」とします。判断が「採用」でも、登録や接触が完了したとは限りません。これらの状態名は説明用です。
Stateを明確にすることで、
- 現在位置
- 次の判断
- 判断履歴
を一貫して管理できるようになります。
Phase5への接続
Phase5の実装計画では、判断設計と記録設計をもとに、材料取得・判断実行・後続作業のタスクと流れを具体化します。範囲と見積もりを整理して投資判断を行い、実装に進む場合は必要最小限を作ります。
判断設計だけで実装方法は一意に決まりません。不足が見つかれば設計へ、別の判断が見つかればPhase1へ戻ります。JSCには判断による状態変化を書き、処理手順はPhase5で具体化します。
進め方
- 何を1件として判断するかを決めます。 「この候補を営業対象として採用するか」について、候補と、その候補を評価する文脈を確認します。同じ候補でも文脈が変わる場合の扱いを決めます。
- 判断前後の状態を整理します。 状態変化の設計（JSC）に、現在状態、選択肢、判断後の状態を記します。保留した場合の追加確認と再判断もつなぎます。
- 材料・条件・観点を分けます。 判断の中身の設計（JDC）に、何のための判断かと、必要な情報・鮮度・取得できない場合の扱いを記します。客観的に確かめる条件と、経験や文脈を踏まえる観点を分けます。
- 判断する人と責任を決めます。 誰が判断し、誰が責任を持つか、判断できない場合に誰へ引き継ぐかを定めます。AIが材料を整える役割と、最終的に判断する役割は区別します。
- 判断後の受け渡しを決めます。 採用・見送り・保留に応じて、渡す情報・渡し先・必要な行動・完了条件を整理します。採用の確定と、登録や接触の完了は分けます。
- 記録と評価へつなげます。 材料・理由・前後状態を残せるか、期待する結果を後から確かめられるかを確認します。記録・評価で具体化する事項はPhase4へ、実行タスクの具体化はPhase5へ渡します。
次へ進む前の確認
- 判断対象の単位と、選択肢に対応する状態が明確ですか。
- 材料・条件・観点と、判断主体・責任・引き継ぎ先を整理しましたか。
- 保留から再判断する道筋と、後続の作業との区別がありますか。
- 判断時の情報を残し、その後の結果から評価できる設計ですか。
詳しくは、JDA MethodのPhase3を参照してください。
Phase3の成果物
Phase3では以下を作成します。
- JSC（Judgement State Chart）
- JDC（Judgement Design Canvas）
- Proposal / Case定義
- State定義
これらは、後続の実装フェーズにおいて判断を実行可能な構造へ変換するための設計図となります。
Next
Phase4 Logでは、設計した判断について、何を記録し、どう評価するかを設計します。