AI時代に必要なのは、「判断」を扱うライフサイクルだった

第1章　AIは便利だ。でも、その後に人は何を意思決定するのか

AIが仕事を終えたあと、人は何をするのだろう。

この問いが、ずっと頭から離れなかった。
AIにメールを書かせる。
AIに議事録をまとめさせる。
AIに資料を作らせる。
AIに企業を調べさせる。
最近は、
「このAIがすごい。」
「このプロンプトがすごい。」
「AIエージェントならここまでできる。」
そんな話をよく耳にする。
私自身も、その進化には何度も驚かされた。
数か月前にはできなかったことが、もう当たり前のようにできる。
しかし私は、いつも一つのことが気になっていた。

そのメールを書いて、そのあと何をするのだろう。
その資料を作って、そのあと何を決めるのだろう。
具体的には、次に何をするのだろう。

企業活動を眺めていると、その流れはとてもシンプルだった。

情報収集
↓
解釈
↓
意思決定
↓
行動

AIは情報を集められる。
解釈を手伝うこともできる。
資料をまとめることも、選択肢を提示することも得意だ。
しかし、その次にある「意思決定」はどうだろう。
どの顧客へ提案するのか。
どの商品を勧めるのか。
どこへ投資するのか。
その会社らしさが最も表れるのは、この意思決定ではないだろうか。
私は次第に、AI導入とは単なる作業効率化ではなく、企業の意思決定をどう支援するかを考えることなのではないかと思うようになった。
そして、さらに一つの考えにたどり着いた。

システムというものは、本来すべて意思決定のためにあるべきなのではないか。

この問いが、私の試行錯誤の始まりになった。

第2章　もっと本質的にシステムを設計したかった

私は20年以上、システム開発に携わってきた。
主に要件定義や上流工程を担当し、さまざまな業務システムの設計に関わってきた。
また、中小企業診断士として、経営や業務改善に携わる中で、Business Model Canvas（BMC）やCustomer Journeyなどの経営フレームワークにも触れてきた。

要件定義では、As-Is（現状）を書き、To-Be（あるべき姿）を考え、アクティビティ図や業務フローを作る。
私も長年、そのやり方でシステムを設計してきた。
もちろん、それらは必要な工程である。
しかし、どこか違和感もあった。
To-Beを書く。
理想の業務フローを考える。
そしてシステムを設計する。
しかし実際に運用が始まると、その通りには動かないことが少なくなかった。

現場には現場の事情がある。
長年の経験から身についた仕事の進め方がある。
顧客との付き合い方がある。
業務フローには書ききれない暗黙知がある。
To-Beの方が効率的だと思っていても、現場はそう判断しないことがある。
そこに摩擦が生まれる。
もちろん、その摩擦を乗り越えて業務を変えるべき場面もある。
しかし私は次第に考えるようになった。

本当に変えるべきなのは業務フローなのだろうか。

現場を理想の業務へ合わせることが目的なのだろうか。
それよりも、

現場の判断を活かしたまま、補強する方法はないのだろうか。

そんなことを考えるようになった。

そのヒントになるのではないかと思ったのが、以前から関心を持っていた経営フレームワークだった。
Business Model Canvasは、会社全体を俯瞰できる。
Customer Journeyは、顧客の変化を捉えることができる。
どちらも経営を理解するためには優れたフレームワークだった。
私は以前から、システム開発もこうした大きな視点から始められないだろうか、と考えていた。

そして、自社の営業活動をシステム化する機会が訪れた。
私は、この機会にずっと試してみたかったことを実践してみることにした。

第3章　経営フレームワークから設計してみることにした

自社の営業活動をシステム化することになった。
せっかくなら、以前から試してみたかった方法で設計してみようと思った。

まず取り組んだのは、Business Model Canvas（BMC）だった。
会社は誰に、どんな価値を提供し、どのように利益を生み出しているのか。
機能一覧を作る前に、まず会社そのものを理解したかった。
AIに会社の情報や営業活動を伝えると、それなりの精度で整理してくれた。
以前なら何日もかかっていたような作業が、短時間で形になっていく。
AIのおかげで、試行錯誤を何度も繰り返せるようになった。
BMCを書き終えると、会社全体が一枚の紙の上に整理された。
ここまでは思った通りだった。

次に考えたのは、現場の業務だった。
まず知りたかったのは、営業担当者は日々どのように仕事をしているのか、ということだった。
どのタイミングで電話をするのか。
どのタイミングでメールを送るのか。
どのような流れで提案し、フォローしているのか。

その全体像を整理するために、営業担当者のJourneyを書き始めた。
しかし、書きながら気づいた。
営業担当者だけを見ても、仕事は理解できない。
営業は相手がいて初めて成り立つ。
顧客がどのように変化しているのか。
それも同時に見なければ、本当の業務は見えてこない。

そこで今度は、Customer Journeyも作ってみた。
顧客の変化。
営業担当者の行動。
この二つを並べて見比べてみようと思った。

ストーリーマッピングのようなイメージだった。
本来であれば、このあとアクティビティ図へ落としていくつもりだった。
要件定義では、ごく普通の流れである。
しかし、ここでまた手が止まった。

この二つのJourneyを、わざわざアクティビティ図へ落とし込む必要があるのだろうか。
分岐を書き始めれば、図はどんどん複雑になっていく。
そして結局、またTo-Beを書き始めることになる。

それよりも、この二つのJourneyをそのまま設計対象にできないだろうか。
私はまた、同じ問いにぶつかった。
具体的には、次に何をすればいいのだろう。

第4章　交点には判断があった

二つのJourneyを並べて眺めていたときだった。
営業担当者は、顧客の変化に合わせて行動している。
当たり前のことなのに、それまで私は見えていなかった。
本来であれば、ここから機能や業務フローを整理していく。
ストーリーマッピングも、そのための考え方である。

しかし、私が眺めていたのは機能ではなかった。
顧客が変化したとき、営業担当者は何をしているのだろう。

顧客が興味を持った。
そのとき営業担当者は、今メールを送るべきか考えている。

顧客が資料請求をした。
そのとき営業担当者は、電話をするべきか考えている。

顧客が比較を始めた。
そのとき営業担当者は、提案するべきか考えている。

行動しているのではない。
行動するかどうかを決めている。

その瞬間、頭の中で何かがつながった。
メールを送るか。
電話をするか。
提案するか。

それだけではない。
優先順位を上げるか。
見込みがあると判断するか。
行動の前には、必ず判断があった。
これまで私は、「現場には判断がある」と漠然と考えていた。

しかし、このとき初めて、それは経験や勘という曖昧なものではなく、業務の中から切り出せる設計単位なのだと気づいた。
業務フローの中に埋もれていたものが、突然輪郭を持って見えた瞬間だった。

そして、もう一つ見えてきたことがあった。
顧客の状態が変わる。
それに対して企業が何をするかを決める。

つまり、二つのJourneyの交点では、必ず判断が行われている。

顧客が比較している。
では、提案するのか。

顧客が反応した。
では、有望と見るのか。

顧客が迷っている。
では、追いかけるのか。

企業活動とは、タスクの連続ではなかった。

判断の連鎖だった。

私はようやく、「具体的には何を設計すればいいのか」という問いの答えを見つけた気がした。
設計すべきものは、業務フローではない。
タスクでもない。

企業の判断だった。

第5章　判断を設計するという発想

設計すべきものが分かった。
企業の判断である。
ただ、答えが見つかったわけではなかった。
むしろ、本当の課題はここから始まった。

では、その判断をどう扱えばいいのだろう。
例えば営業担当者は、
「この企業は見込みがある。」
と判断する。

しかし、それだけではシステムは作れない。
なぜ見込みがあると思ったのか。
何を見て判断したのか。
誰が判断したのか。
何を重視したのか。
その判断によって、次に何が起きるのか。
そこまで整理しなければ、人にもAIにも伝わらない。

つまり、判断そのものを設計する必要があった。

私は、一つひとつの判断を分解し始めた。
判断の対象は何か。
判断するために必要な材料は何か。
どんな条件で判断するのか。
誰が判断するのか。
そして、その判断によって対象はどのような状態へ変わるのか。
そうやって整理していくと、それまで営業担当者の頭の中にしかなかった判断基準が、少しずつ言葉になっていった。

さらにわかってきたことがあった。
判断は設計して終わりではない。
実際に判断し、
その結果を記録し、
あとから、その判断が妥当だったのかを振り返る。
そうして初めて、判断は改善されていく。

判断とは、一度作って終わるものではなく、育てていくものだった。

後になって、この考え方を Judgement-Driven Architecture（JDA） と呼ぶようになった。

もちろん、何もないところから新しい理論を思いついたわけではない。
Business Model Canvasも、Customer Journeyも、ストーリーマッピングも、状態遷移も、ログも、それぞれ以前から存在していた考え方である。
私がやったことは、それらを「判断」という一つの軸でつなぎ直したことだった。

第6章　JDAは何が違うのか

JDAという考え方が形になってきた頃、私はAIや業務改善に関するセミナーへ足を運ぶようになった。
ここで改めて気づいたことがある。
多くの手法は、同じ流れで業務を整理していた。

業務
↓
タスク
↓
AI・システム

まず業務を分析する。
タスクを洗い出す。
その中からAIで置き換えられる部分や、自動化できる部分を探す。
とても合理的な考え方である。

実際、私も長年その方法でシステムを作ってきた。
後から調べると、顧客と企業側の活動を対応させる考え方は、サービスブループリントなどの手法にも存在していた。
つまり、顧客と企業を並べて考えるという発想自体は新しいものではない。私が見つけたかったものは少し違っていた。
私が見ていたのは、サービスの流れでも、タスクでもない。

その交点で行われている判断だった。

だからJDAでは、最初に見る対象が違う。

業務
↓
意思決定（判断）
↓
AI・システム

重要なのは、
「何を判断するのか」
を最初に整理することである。

セミナーや本でも、「意思決定が重要だ」と語られることは多い。
私もそう思う。
しかし、その先がなかった。

具体的には、どうすればいいのだろう。

判断をどう発見するのか。
どう設計するのか。
どう実装するのか。
どう記録するのか。
どう評価するのか。
どう学習するのか。
その方法論が、私には見当たらなかった。

だから私は、JDAを「AI導入手法」としてではなく、組織の判断を扱うためのアーキテクチャとして整理することにした。

第7章　判断を育てる方法論

ここまで考えを整理してきて、ようやくJDAの全体像が見えてきた。
JDAは、AIを導入するための手順ではない。
判断を扱うための方法論である。

私は、判断を扱うために必要な流れを六つに整理した。
まず、判断を発見する。
業務の中から、本当に設計すべき判断を見つける。
次に、判断を設計する。
何を見て判断するのか。
何を重視するのか。
判断した結果、対象はどのように変化するのか。
それを言葉にする。
そして、判断を実装する。
設計した判断を、実際の業務で使える形にする。

ただ、実装しただけでは終わらない。
判断を記録する。
あとから、その判断がどういう結果になったのかを評価する。
そして、その結果を次の判断へ反映する。
つまり、学習する。

発見
↓
設計
↓
実装
↓
記録
↓
評価
↓
学習

この六つは、それぞれ独立した作業ではない。
判断を扱う一つのライフサイクルである。

判断を繰り返すたびに、判断基準は少しずつ磨かれていく。
組織は経験を積み重ねていく。
そして、その経験は個人の頭の中だけではなく、組織全体の知識として残っていく。

私は、このライフサイクルこそが、企業の競争力を育てる仕組みになるのではないかと考えるようになった。

第8章　AI時代だから実現できるようになった

ここまで読んで、「それなら昔からできたのではないか。」
そう思われるかもしれない。
私もそう思う。
考え方そのものは、もっと昔でも思いつけたかもしれない。
しかし、実際には難しかった。

判断を記録し続ける。
その判断が正しかったのかを評価する。
次の判断へ反映する。
これを企業全体で繰り返し続けるには、あまりにも手間がかかった。
だから、多くの判断は個人の経験として終わってしまう。
優秀な営業担当者は育つ。
しかし、その判断基準は十分には残らない。
私は、それがずっと不思議だった。

AIが登場したことで、その状況は大きく変わり始めている。
AIは大量の情報を整理できる。
判断材料を集めることができる。
過去の判断を比較し、共通点を見つけることもできる。
だから初めて、組織全体で判断を学習し続ける仕組みが現実になってきた。

ここで私は、もう一つ重要なことに気づいた。
JDAは、AIに判断させるための方法論ではない。
判断する主体は、人でもよい。
AIでもよい。
ある判断は人が行い、
別の判断はAIが支援する。
将来、AIが判断する場面が増えるかもしれない。
その実行主体は、技術の進歩とともに変わっていくだろう。

しかし、JDAが扱っているものは変わらない。
判断を発見し、
設計し、
実装し、
記録し、
評価し、
学習する。
この循環である。

私はAIのための方法論を作りたかったわけではない。
AIはこれからも変わる。
だから私は、AIが変わっても変わらないものを作りたかった。
それが、企業の判断だった。

第9章　判断は組織に残せる

私は最初から、
「判断を記録しましょう。」
と言ったわけではなかった。
それでは抵抗があると思ったからだ。

判断を記録するということは、
「なぜ、その判断をしたのか。」
「その判断は本当に正しかったのか。」
という責任とも向き合うことになる。
誰でも少し身構えてしまう。

だから私は、
「AIが学習するための材料を残したい。」
そう説明した。
それは嘘ではなかった。

AIがより良い支援を行うためには、
過去にどのような判断が行われ、どんな結果になったのかを学習する必要があるからだ。

実際に記録を始めると、思ってもいなかったことが起きた。
学習していたのは、AIだけではなかった。
組織そのものが学習を始めていた。

これまでは、
「なぜ、その企業を優先したのか。」
「なぜ、その提案を選んだのか。」
「なぜ、見込みがあると思ったのか。」
その理由は、営業担当者本人しか知らなかった。

判断を記録し、あとからその妥当性を振り返るようになると、判断はブラックボックスではなくなっていった。

例えば、
「資料請求があった企業は、案件化につながりやすい。」
そんな小さな気づきも、個人の経験ではなく、組織全体の知識として残っていく。

私はそこで初めて気づいた。
JDAが学習させていたのは、AIだけではない。
組織そのものだった。

個人の経験は、判断として記録される。
判断は評価される。
そして次の判断へ生かされる。

その積み重ねによって、組織そのものが少しずつ賢くなっていく。
私は、それこそが企業文化なのではないかと思うようになった。

企業文化とは、理念や行動指針だけではない。
日々、どのような判断を積み重ねてきたか。
その集合なのである。

だから私は、判断を残すことは企業文化を残すことでもあると考えている。

第10章　AIは変わる。でも、問いは変わらない

自社の営業活動をシステム化するところから始まった試行錯誤は、一つの方法論になった。
私は、それを Judgement-Driven Architecture（JDA） と呼んでいる。
ただし、この作品で伝えたかったのは、JDAという名前ではない。

もっと伝えたかったことがある。
「判断が重要である。」

そう語られることは、以前から少なくなかった。
私もそう思う。
しかし、その先がなかった。
あのとき感じた、
「具体的には、どうすればいいのだろう。」
その問いに、私はJDAという形で答えようとした。
判断を発見する。
判断を設計する。
判断を実装する。
判断を記録する。
判断を評価する。
そして、判断を学習する。
その一つひとつを、現場で実践できる方法論として整理したかった。

AIはこれからも進化し続ける。
新しいモデルが生まれる。
10年後には、今とはまったく違うAIが当たり前になっているかもしれない。

しかし、その変化の中でも変わらないものがある。
企業は毎日、無数の判断を積み重ねている。
どの顧客へ提案するのか。
どの案件を優先するのか。
どこへ投資するのか。

その積み重ねが企業らしさを生み、競争力を生み、企業文化を形づくっている。
だから私は、AIのための方法論ではなく、
企業の判断を、発見し、設計し、実装し、記録し、評価し、学習できる方法論を作りたかった。

AIは変わる。

しかし、より良い意思決定（判断）を積み重ねられる組織が競争力を持つ。

その本質は、これからも変わらない。

本記事で紹介したJDA（Judgement-Driven Architecture）の理論や実装は現在も公開・更新しています。

・JDA公式サイト：https://judgement-driven.com

・GitHub：https://github.com/judgement-driven-architecture

・これまでの関連記事：https://note.com/shuntake