What is JDA

こんな困りごとはありませんか

候補を探す。情報を集める。資料を作る。

システムやAIを使えば、こうした作業は速くなります。それでも、業務の改善やAIの導入を進める中で、こんなことは起きていないでしょうか。

  • 作業は速くなったのに、成果につながっているか分からない
  • 同じ情報を見ているはずなのに、担当者によって判断がばらつく
  • なぜその対象を選んだのか、後から振り返る記録がない

作業を進める途中には、「どれを選ぶか」「今進めるか」「いったん保留するか」という判断があります。JDAは、こうした判断を業務の中から見つけ、改善の対象にします。


JDAとは

JDA(Judgement-Driven Architecture)は、仕事の中の「どう決めるか」を明確にし、記録と振り返りを通じて改善していくためのアーキテクチャです。

判断が発生する場面を見つけ、必要な情報、決め方、担い手と責任を整理します。そして実際の業務で使い、判断時の記録とその後の結果をもとに見直します。

ここでいう判断は、状態を確定させる行為です。たとえば「この候補を営業対象として採用するか」を決めると、採用・見送り・保留という状態が確定し、その後の行動につながります。JDAでは、こうした判断の一つひとつを Judgement Point(JP)と呼びます。


たとえば、営業対象を選ぶとき

AIが営業先の候補を集めてくれても、どの候補に働きかけるかは決めなければなりません。

JDAでは、「この候補を営業対象として採用するか」という一つの判断について、次のことを明確にします。以下は設計の例です。

何を決めるのか

候補を採用するか、見送るか、情報が足りないため保留するかを決めます。「採用した」ことと、「実際に接触した」ことは分けて扱います。

何を見て決めるのか

候補企業の商品や事業、提案する媒体・企画との適合、過去の接触履歴などを確認します。足りない情報があれば、それも分かるようにします。

誰が決めるのか

たとえば、AIが情報を集めて整理し、営業担当者が決めます。判断の責任を持つ人と、担当者だけでは決められない場合の相談先も定めます。

決めた理由をどう残すか

「企画との相性がよいので採用した」などの理由を、判断時に見た情報と一緒に残します。後から情報が変わっても、当時何を根拠に決めたかを振り返れるようにします。

その後どう評価するか

採用した候補に接触したのか、どのような反応があったのかを追いかけます。ただし、反応がなかったことだけで採用判断が間違っていたとは決めません。まだ接触していない場合や、提案内容・時期の影響も分けて考えます。

こうして、次に候補を選ぶとき、何を確認し、どの観点を見直すべきかを検討できるようにします。


なぜ判断から始めるのか

作業を速くすることと、適切な対象や行動を選ぶことは、どちらも成果に関わります。JDAは後者を独立した設計対象として扱います。

タスクやフローを整理する過程では、判断が「確認する」という作業や分岐条件の中に埋もれることがあります。何を決めるのか、何を根拠にするのか、誰が判断し責任を持つのかを明示することで、改善したい箇所を捉えます。

最初から業務全体を細かく設計する必要はありません。業務の範囲を捉え、重要な判断から選び、その判断に必要な情報収集・実行・後続アクションを具体化します。実装で不足が見つかれば、判断の設計に戻って見直します。

業務を自動化する前に、判断を設計する。

これが、JDAの出発点です。


なぜ小さく始めるのか

従来のシステム開発では、業務全体を洗い出し、統一してから作ることが多くありました。JDAは、対象を絞って始めます。

徹底的に洗い出しても、抜けはテストや実運用で見つかります。最初にすべてを対象にしても、あとで直す必要がなくなるわけではありません。そこでJDAは、次の4つを組にして進めます。

  • 1つに絞って始める:業務の全体像は先に見渡し、その中から最初に取り組む業務と判断を選びます。
  • 先に動かす:抜けは動かさないと見つかりません。判断の記録も、動かさないとたまりません。まだシステム化していない前後の作業は、Excelや手作業など今ある方法でつなぎます。
  • 戻ることを前提にする:運用で見つけた抜けは、判断の見つけ方や設計に戻して直します。
  • 戻りを軽くしておく:判断の中身をシステムの外に定義として持ち、実行と記録の仕組みを共通にします。判断を足したり変えたりしても、仕組みを作り直さずに済むようにするためです。

小さく始めるのは、手を抜くためではなく、早く確かめるためです。

軽く直せるのは、判断の追加や中身の変更です。判断の形そのものが想定と合わない場合は、仕組みの側を見直す必要があります。複数の業務で同じ仕組みを使えるかどうかは、これから検証します。


他の手法とどう組み合わせるか

業務フローの可視化や、作業の排除・結合・交換・簡素化を考えるECRSも、判断や例外の改善に役立ちます。JDAはそれらと併用し、判断を継続して記録・評価する単位として扱います。

タスク分解やフロー設計を省略するわけではありません。判断を起点に、その前後で必要な作業と流れを具体化します。

標準手順では処理できない状況についても、必要な情報、責任、保留や引き継ぎの扱いを設計します。AIによる情報整理や判断支援を使えますが、あらゆる例外をAIだけで解決できるという意味ではありません。

JDAがなくてもAI導入はできます。JDAは、取り組む判断と、その評価方法を明確にし、業務改善やAI導入が成果につながる確率を高めることを目指しています。効果の実証は継続中です。


記録を知見に変える

判断時の情報や理由を残し、その後の結果と突き合わせて、判断材料や基準を見直します。この改善の循環をLearning Cycleと呼びます。

まず継続して評価できる基盤を作り、判断材料を改善します。その先で、AIが判断を再現できるかを検証し、妥当性の確認と責任の設計を踏まえて、任せる範囲を検討します。

記録を保存するだけで、自動的に判断が良くなるわけではありません。また、学習はAIモデルの再学習だけを意味しません。組織が判断材料や基準を見直すことも含みます。


次に読むページ

  • Method:業務の中から判断を見つけ、設計・実装・改善する進め方
  • Implementation:重要な判断から小さく実装し、現場で使い始める考え方
  • Core Concepts:JDAで使う概念と用語の説明
  • About:JDAが生まれたきっかけ、背景、実証について