目的
実装範囲と見積もりを整理して投資判断を行い、設計した判断を現場で使える形に小さく実装します。
答える問い
どこまで作り、現場でどう動かすか
できあがるもの
実装計画と投資判断の記録。実装に進む場合は、判断を実行して記録できる仕組みと、今ある方法でつないだ前後の作業
判断を起点に、必要なタスクとフローを実装する
JDAでは、選定した判断（JP）を現場で運用できる最小構成をJudgement Sliceと呼び、その範囲から実装します。判断材料を集める処理、判断の実行と記録、後続アクションをつなぎます。
業務全体のフローを一度に作り込む必要はありません。既存機能や、既存運用との橋渡し（Operational Bridge）を利用し、主要JPを運用できる最小構成から始めます。
実装計画（Implementation Planning）から始める
JULIAで選んだ判断について、必要な機能・タスクを整理し、最初に作る範囲と見積もりを確認します。判断設計・記録設計と、Phase2からの引き渡しメモを使い、新しく作る部分、既存機能を使う部分、Excel・CSV・JSON・手作業などでつなぐ部分を分けます。
下の「進め方」では、Step1〜3が実装計画に含まれます。Step3で見積もりに必要なタスク・実行フローを具体化し、期待する価値と費用・運用負担を照らし合わせて、実装に進むかを判断します。実装する場合は、Step4から必要最小限を作ります。不確実な点や、実装中に変わった前提があれば、計画を見直します。
最初の範囲が小さい場合は、範囲・見積もり・判断の理由を短いメモに残せば足ります。計画を整えることより、先に動かして確かめることを優先します。
判断の実行基盤（Judgement Harness）
JDAでは、JPを共通実行基盤で動かす考え方を採用します。
これを、Harness Engineeringの考え方を参考にしつつ、JDA独自の概念として Judgement Harness と呼びます。
Judgement Harnessとは、状態・入力・実行・ログを統一し、判断を再現可能かつ学習可能な形で運用するための実装基盤です。
各画面や各機能に個別の判断ロジックを埋め込むのではなく、判断を外部定義として管理し、共通基盤から実行します。
判断定義と実行・記録の仕組みを分け、判断の追加や内容の変更を扱いやすくすることを目指します。
現在の実証では、営業業務の1つのプロセスを取り上げています。ほかの業務やプロセスに同じ仕組みを適用できるかは、これから検証します。
判断定義の組み込み（Judgement Injection）
Judgement Injectionは、Judgement Harnessを構成する実装パターンの一つです。
JPはプログラム内部に固定的に実装しません。
JDCで定義された判断内容を外部定義として保持し、実行時に注入します。
なぜ判断を外に持つのか
判断は、あとから見つかったり、変わったりします。徹底的に洗い出しても、抜けはテストや実運用で見つかります。
判断の中身をシステムの外に持ち、実行と記録の仕組みを共通にしておけば、判断を足したり変えたりしても、仕組みを作り直さずに済みます。システムを作り直す場合も、判断の定義と記録は持ち越せます。
ただし、軽く直せるのは、判断の追加や中身の変更です。判断の形そのものが想定と合わない場合は、仕組みの側を見直す必要があります。小さく始めて先に動かす考え方は、What is JDAの「なぜ小さく始めるのか」で説明しています。
判断の実行・記録（execute_jp）
JPの実行は共通関数 execute_jp に集約します。
execute_jp は以下を統一的に実行します。
- 現在状態の取得
- 判断の実行
- 状態遷移
- JLogの保存（判断理由を含む）
この実装方針では、判断の実行と記録を同じ経路で扱います。
JLogは必ずexecute_jpを経由して記録されます。
判断を中心に小さく実装する（Judgement Slice Implementation）
JDAでは全業務を一度に実装しません。
JULIAによって優先度の高いJPを選定し、その判断を中心に小さく実装します。
これをJudgement Slice Implementationと呼びます。
まず主要JPを実装し、その後に周辺JPを段階的に追加します。
判断を中心に小さく始めることで、早期に価値を検証できます。
進め方
Step1〜3が実装計画です。範囲・見積もり・投資判断を整理してから、Step4へ進みます。番号は、JDA Method本体のStepと同じです。
- 選定された判断を確認します。 選定理由とPhase2のメモ、Phase3・Phase4の設計を確認します。
- 判断材料を定義します。 「この候補を営業対象として採用するか」に必要な材料と、その取得元・鮮度・取得できない場合の扱いを具体化します。
- タスク・実行フローを設計し、投資判断を行います。 材料取得から判断・記録・後続作業・評価までを洗い出し、作る部分と既存運用で補う部分を分けて見積もります。実装に進むかを、ここで決めます。
- 必要最小限を作ります。 材料を見て、採用・見送り・保留と理由を入力し、状態と判断の記録が残る構成を作ります。
- 前後の作業をつなぎます。 前の工程から受け取る情報と、後の工程へ渡す情報を決め、Excel・CSV・JSON・手作業など今ある方法でつなぎます。少しずつシステム化します。
- 現場で使います。 現場で判断でき、材料が提示され、理由が残ることを確認します。完成度を上げ続けるより、先に動かして確かめます。
- 記録を観測します。 材料不足、判断待ち、記録漏れ、事後評価の難しさ、入力しづらい箇所を確認します。
- 必要な判断だけ追加します。 運用で分かった不足をもとに、周辺の判断を追加します。範囲や費用が変わる場合は、実装計画を見直します。
- 判断のつながりを整理します。 複数の判断が連鎖して動き始めたら、その実行のつながり（Judgement Journey：JJ）を整理します。最初から完全に設計するものではありません。
Step3：タスク・実行フローを設計する
Data Sourcesから材料の取得・整理・照合・提示を、JSC・JDCとログ設計から判断実行・状態遷移・記録を、OutputとVLog設計から後続アクション・結果追跡・評価を具体化します。
各タスクの実行条件、入力・出力、担い手、タイミング、完了条件を定めます。すべてを直列に実行する必要はなく、事前取得、共有、並列・非同期処理も選べます。
execute_jpとの境界
execute_jpは、判断の実行・状態遷移・JLog記録を担います。材料の取得・整理と後続アクションは、その前後のタスクとして扱います。
失敗と欠損
取得失敗時は再試行・保留・人への引き継ぎを設計します。欠損した材料のまま判断した場合は、その内容と把握できた理由をJudgement Snapshotに残します。判断が実行されていない失敗はタスクの記録として扱います。
判断状態とタスク実行状況
採用判断後に登録処理が失敗した場合、判断は「採用」、登録タスクは「失敗」として追跡します。後続タスクの状態を主要JPの判断状態に混ぜません。作業結果に基づく業務上の完了判断が必要な場合は、その判断を別途設計します。
設計へのフィードバック
判断設計の不足はPhase3へ、独立した判断の発見はPhase1 Discoveryへ戻します。各JPに専用の取得処理を重複して作る必要はありません。
タスクを具体化しても、どの判断の対象・材料・結果・責任・記録に対応する処理かを確認します。
洗い出したタスクから、最初の実装範囲と、既存運用で補う範囲を分けます。開発だけでなく、材料の取得・接続・テスト・運用・評価の負担を見積もり、前提と不確実性を残して投資判断を行います。対象の選び直しが必要ならPhase2へ戻ります。
Step4：必要最小限を実装する
実装計画で整理した範囲・見積もりと投資判断に基づき、現場運用と評価に必要な最小構成を実装します。新規実装、既存機能の利用、既存運用との橋渡しを組み合わせます。実装中に範囲や費用の前提が変わった場合は、計画を見直します。
実装範囲の決め方（Implementation Scope）
実装範囲を広げるかどうかは、以下の基準で判断します。
- この実装はJLogを増やすか
- この実装はVLogに接続できるか
- 主要JPの運用に直接必要か
JDAでは、Learningにつながる判断を優先します。
JLogやVLogが蓄積されない実装は、価値を生まない可能性が高くなります。
そのため、実装範囲は機能数ではなく、学習価値を基準に決定します。
また、未実装工程はOperational Bridgeで補完できないかを先に確認します。
現場運用で十分に成立する場合は、無理にシステム化しません。
重要なのは実装範囲を広げることではなく、Learningにつながる判断を増やすことです。
範囲を広げる場合は、追加の費用や運用負担を実装計画に反映し、進め方を見直します。
既存運用との橋渡し（Operational Bridge）
現実の業務では、すべての工程を同時に実装することは難しいものです。
そのため未実装部分は現場運用によって補完します。
JDAでは、この接続層をOperational Bridgeと呼びます。
Excel、既存システム、手作業、チャットなども橋渡しとして活用します。
重要なのは、業務全体を止めないことです。
AIの役割
初期の実証では、AIが材料を整え、人が判断する形から始めます。将来的な判断再現・委譲は、Learningでの評価と責任設計を踏まえて検討します。ActorとAccountabilityは分けて設計します。
次へ進む前の確認
- 範囲・見積もり・投資判断の記録と、実装内容が対応していますか。
- 材料・理由・前後状態が残り、事後評価へ接続できますか。
- 採用判断と登録などの作業状況を分け、欠損や失敗を追跡できますか。
- 現場で使え、前後の受け渡しと入力負荷を確認できましたか。
ログ件数だけでなく、現場で判断できることと、記録を評価に使えることを確認します。
詳しくは、JDA MethodのPhase5を参照してください。
Output
まず、実装範囲・見積もりの前提と投資判断の記録を残します。実装に進む場合は、以下を確認します。
- JPが実行可能になっている
- 状態遷移が管理できる
- 判断時の記録を取得し、事後評価へ接続できる
- Operational Bridgeを含めて業務が回る
これらによって、Learningへ接続可能な状態が構築されます。
Implementationは完成を目指す段階ではありません。
判断を実際の業務で動かし、学習可能な状態を作る段階です。
Next
Phase6 Learningでは、蓄積した記録をもとに判断を評価し、改善します。