Purpose
Implementationは、Phase3で設計したJudgementを実際の業務で動かす段階である。
JDAでは業務フローを実装するのではなく、Judgement Point（JP）を実行可能な構造として実装する。
目的は、自動化ではない。
人の判断を実行・記録・学習できる状態を作ることである。
Judgement Harness
JDAでは、JPを共通実行基盤で動かす考え方を採用する。
これを、Harness Engineeringの考え方を参考にしつつ、JDA独自の概念として Judgement Harness と呼ぶ。
Judgement Harnessとは、状態・入力・実行・ログを統一し、判断を再現可能かつ学習可能な形で運用するための実装基盤である。
各画面や各機能に個別の判断ロジックを埋め込むのではなく、判断を外部定義として管理し、共通基盤から実行する。
これにより、判断の追加・変更・学習を継続的に行える構造を実現する。
Judgement Injection
Judgement Injectionは、Judgement Harnessを構成する実装パターンの一つである。
JPはプログラム内部に固定的に実装しない。
JDCで定義された判断内容を外部定義として保持し、実行時に注入する。
これにより、実装対象は画面や業務フローではなく、判断そのものとなる。
execute_jp
JPの実行は共通関数 execute_jp に集約する。
execute_jp は以下を統一的に実行する。
- 現在状態の取得
- 判断の実行
- 状態遷移
- JLogの保存（判断理由を含む）
これにより、すべての判断が同じ方式で実行される。
JLogは必ずexecute_jpを経由して記録される。
Judgement Slice Implementation
JDAでは全業務を一度に実装しない。
JULIAによって優先度の高いJPを選定し、その判断を中心に小さく実装する。
これをJudgement Slice Implementationと呼ぶ。
まず主要JPを実装し、その後に周辺JPを段階的に追加する。
判断を中心に小さく始めることで、早期に価値を検証できる。
Implementation Scope
実装範囲を広げるかどうかは、以下の基準で判断する。
- この実装はJLogを増やすか
- この実装はVLogに接続できるか
- 主要JPの運用に直接必要か
JDAでは、Learningにつながる判断を優先する。
JLogやVLogが蓄積されない実装は、価値を生まない可能性が高い。
そのため、実装範囲は機能数ではなく、学習価値を基準に決定する。
また、未実装工程はOperational Bridgeで補完できないかを先に確認する。
現場運用で十分に成立する場合は、無理にシステム化しない。
重要なのは実装範囲を広げることではなく、Learningにつながる判断を増やすことである。
Operational Bridge
現実の業務では、すべての工程を同時に実装することは難しい。
そのため未実装部分は現場運用によって補完する。
JDAでは、この接続層をOperational Bridgeと呼ぶ。
Excel、既存システム、手作業、チャットなども橋渡しとして活用する。
重要なのは、業務全体を止めないことである。
AIの役割
Implementation段階においても、AIは判断主体ではない。
AIは判断材料の収集、整理、要約、仮説生成を支援する。
判断そのものは人が行う。
JDAは人の判断を置き換えるためではなく、人の判断を再利用可能な資産にするためのアーキテクチャである。
Output
Implementationの成果は以下である。
- JPが実行可能になっている
- 状態遷移が管理できる
- JLogが取得できる
- Operational Bridgeを含めて業務が回る
これらによって、Learningへ接続可能な状態が構築される。
Implementationは完成を目指す段階ではない。
判断を実際の業務で動かし、学習可能な状態を作る段階である。
