🧩 ジョブマップが“美しいほど”決められない—翻訳機としてのJTBDのススメ
会議室のホワイトボードには「Job Map」の文字。その下には付箋が、Define、Locate、Prepare、Confirm……と、教科書通りの工程に沿って整然と並んでいる。
出来上がった図は、たしかに“それっぽい”。
それなのに、意思決定が前に進まないのはなぜなのでしょうか。
プロダクトの優先順位はあやふやで、次の手を打つ勇気も湧いてこない。結局、最後は「追加でユーザーインタビューしましょう」という、安全だが何も解決しない決定で幕を閉じる。
私はこれまでDeeptechの現場で、このような光景を何度も見てきました。
今回は、経験上特に「ジョブマッピングが美しく完成するのに、実装で詰まる」ことが多い（と感じている）ヘルスケア領域を例にジョブマッピングの罠とおすすめの運用法を提案してみます（もちろん他領域でも同様に有効かと思います）。
ヘルスケア領域においてジョブマッピングが実装でつまる理由はシンプルに、顧客が一人ではないからです。
医師、看護師、検査技師、事務、購買、情報システム、コンプライアンス、患者。
臨床的な価値を握っている人と、日々の運用のなかで詰まる人が決定的に異なる。さらに、プロダクトの性能以前に「規制・監査・説明責任」という外壁が、厚く立ちはだかってきます。
この状況下でジョブマッピングを単なる「顧客理解の道具」として扱うと、ほぼ例外なく三つの泥沼に足を取られます。
1. 「医師の熱狂」バイアス
一つ目は、「顧客＝医師」という単一化です。
医師に深くフォーカスするほど、臨床的な議論は精緻を極めます。しかし、実際に導入の足を止めるのは、医師ではなく情報システム部門のセキュリティ要件だったり、購買部門の稟議プロセスだったりします。
医師の「欲しい」は、臨床現場では正義でも、病院という組織の扉を開ける「鍵」にはなり得ません。結果、ジョブマップは「理解できた気がする絵」で止まり、導入・運用・更新という、組織としての工事の工程が空白のまま残されることになります。
2. 精度が上がるほど、購買が遠のくパラドックス
二つ目は、「精度」がすべての意思決定を支配してしまう問題です。
AI診断や検査支援の領域では特に顕著ですが、モデルの精度に議論が集中するほど、組織としての「買い」の判断は遅滞します。精度は必要条件に過ぎず、組織にとっての十分条件ではないからです。
「誤判定時の責任所在はどうなるのか」「監査ログはどう残るのか」「既存のワークフローをどれだけ壊すのか」etc。
こうした“導入後に必ず突きつけられる問い”がマップの工程に組み込まれていない限り、組織ははっきり「Yes」と言えません。優先順位が「精度の追求」に一点張りされる一方で、意思決定を動かすための「説明可能性」や「ワークフロー統合」が後回しにされていく。これは戦略上の大きなミスです。
3. 「全員大事」という名の思考停止
三つ目は、マルチステークホルダーの混線です。
患者、医師、保険者、製薬企業。全員のジョブを一枚の図に無理やり統合しようとすれば、それは「誰も傷つけないが、何も決められない図」に成り下がります。
「全部大事」は、戦略においては「何も選んでいない」のと同義です。
この手の話をすると、「では結局ジョブマッピングは必要ないのか？」と問われることがままあります。
が、この点私は、以前ジョブマッピングは有効であるとお伝えしています。ただし、それは“顧客を深く理解する”ためではありません。
「ジョブマッピングは、組織内の異なる言語を繋ぐ「意思決定の翻訳機」として使ったときにこそ、真価を発揮する」
と、私は考えています。ここでいう翻訳機とは何か。
研究開発、営業、コンプライアンスetc、部門ごとにバラバラな「評価基準」を、一つの共通した「判断の単位」に揃える装置のことです。
昨今のJTBD研究では、インタビューを回すための形式知が整いつつあります。しかし同時に、「JTBDさえ使えば成功する」という因果関係を断言できるほど、エビデンスはまだ十分ではありません。
だからこそ、私たちがここで狙うべきは“学術的な正解”ではなく、“現場が決められる状態”を作ることです。
以降、本稿では、ジョブマッピングを「工程図」から「意思決定を動かす翻訳テーブル」へと再設計する方法論をお示しします。
上記で、ジョブマッピングは顧客理解の道具ではなく「意思決定の翻訳機」である、という主張をしました。
しかし、この主張には避けて通れない弱点があります。それは、「ジョブ」という言葉自体が、驚くほど人によって違うものを指しがちだという点です。
同じ「Job Map」を見つめていても、研究開発はそれを「技術課題の分解図」として読み、プロダクトマネージャーは「機能要件の棚卸し」として読み、営業は「刺さる提案の台本」として読み、コンプライアンスは「リスクのチェックリスト」として読み解く、といった現象はかなり良くあります。
図面は一つなのに、判断の単位がバラバラ。これでは翻訳機として機能するはずがありません。
そこで本稿では、あえて乱暴なまでに定義を固定します。
1) ジョブ（Job）の定義を「成功条件」に絞り込む
ここでいうジョブとは、世に溢れる「ユーザーがやりたいこと」の一般論ではありません。
「特定の状況下で、代替手段と比較されながら、組織の意思決定を動かす目的（成功条件）」を指します。
状況（Context）： 「何をしたいか」ではなく「どの瞬間に、何が起きたときか」が特定されている
代替（Alternative）： 「何が欲しいか」ではなく「今、何と比較し、何に負けているか」が含まれている
アウトカム（Outcome）： 単なる願望ではなく、その工程における「成功の合格ライン」が明文化されている
例えば、ヘルスケア領域で頻出する「医師が診断を速くしたい」という記述は、ジョブ“らしく”見えますが、実務上は無価値です。それだけでは技術と臨床の議論に吸い込まれ、購買・運用・監査という「決定権者」の机には届かないからです。
意思決定を動かすには、「どの工程で」「何が成功の閾値で」「既存の何に不満を持っているのか」を、同一線上で語る必要があります。
2) ジョブマッピングは「政治的」な工程図である
本稿におけるジョブマッピングは、いわゆる「顧客の気持ちの旅」を描くものではありません。
私たちがやるべきは、もっと事務的で政治的な作業です。
工程の羅列： Define（定義）からConclude（終結）までの標準工程を並べる
成功条件（アウトカム）の刺入： 各工程で、ユーザーが何を以て「完了」と見なすかの基準を刺す
代替手段の明示： 現場が今、人力や既存フローでどう「凌いでいるか」を並置する
翻訳： そのうえで、「どこを優先的に解決すれば、組織がYesと言わざるを得ないか」を抽出する
これらを明確にしてこそ、部門間で評価軸を擦り合わせるための「意思決定の翻訳テーブル」となりうるです。
3) 似て非なる「道具」との境界線
ここで、混同されやすい他の道具と明確に線を引いておきます。
道具の使い分けを誤ると、中身のない「それっぽい図」が量産されるだけですので。
ユーザージャーニーマップ：
メリット：感情の起伏、タッチポイントの設計、UXの改善
罠： 意思決定の単位が「良さそう／悪そう」という主観に寄り、投資判断には弱い
業務プロセスマップ（BPMN等／運用の設計図）：
メリット：手順の可視化、責任分界、例外処理
罠： 「現状（As-Is）の最適化」に終始しがちで、新規事業が提供する「破壊的な価値」が埋もれる
ジョブマップ：
メリット：投資判断、優先順位付け、Go/No-Goの基準策定
罠： アウトカムを定義し損ねると、ただの退屈な工程図に成り下がる
4) 翻訳機が「宗教」に堕ちないための3要件
ジョブマッピングが形骸化し、一種の「宗教」と化すのは、言葉の定義だけが整理され、肝心の「判断」が置き去りにされるときです。
翻訳機として機能させるためには、次の3つが絶対に欠かせません。
アウトカムがあるか： 各工程に、数値化または明文化された合格ラインがあるか
代替があるか： 現場が比較している「真のライバル」が見えているか
意思決定点があるか： 誰が、何を根拠に、どの工程でプロセスを止める（拒否権を発動する）のかが描かれているか
例えばヘルスケア領域においては、ここに「監査・説明責任・責任所在」という重いピースが加わります。
単なる「使い勝手の良さ」を描いても、説明責任の所在が曖昧なままでは、組織は一歩も動けません。工程が正しくても、意思決定の争点が空白であれば、それは翻訳機の名に値しません。
ここまでが、議論を戦わせるための土台作りです。
この土台を共有せずに「ジョブマッピングは有効か？」を論じても、お互いの頭の中にある別々の評価軸で空中戦を展開することになるだけです。
「で、ジョブマッピングは本当に有効なんですか？」
この問いがあれるのは（時に不毛な議論に終わるのは）、人によって「有効」という言葉が指す射程がバラバラだからでしょう。
私は、議論を「宗教」にしないために、まずは争点を解体するのがよいと考えています。ジョブマッピングの有効性は、少なくとも次の3つのレイヤーに分けられます。
A：認知の有効性（チームの思考様式が変わるか）
B：予測の有効性（顧客の選択・切替を言い当てられるか）
C：経営の有効性（投資配分やGo/No-Goの判断が速くなるか）
これらを混ぜない。シンプルですが、これらを明確に切り分けるだけで、意思決定がかなりシャープになると思います。
A：認知の有効性
ジョブマッピングの最大のメリットは、議論の重心を「作るもの（機能）」から「達成すべき合格ライン（アウトカム）」へ、強制的に移す力にあります。
これがなぜ決定的なのか。理由はシンプルで、「機能」には、部門ごとに異なる正義が宿ってしまうからです。具体的には、
研究開発は、「技術的な美しさと新規性」を
営業は、「競合との差別化とキラーフレーズ」を
事業開発は、「LTVの最大化と継続の導線」を
コンプライアンスは、「事故の芽を摘む防御構造」を
機能ベースで語り合う限り、これら異なる正義は正面衝突して終わりです。
しかし、工程ごとに「アウトカム（合格ライン）」を定義すると、議論の性質が変わってきます。ヘルスケアの文脈であれば、次のような「問い」へと変質するのです。
「その機能は、監査を通るための合格ラインを満たしているか？」
「説明責任が成立し、責任分界点が破綻しないラインはどこか？」
「現場のワークフローを破壊せずに導入できる、最低限の閾値は何か？」
賛否を問う不毛な会議は、こうして「条件闘争」へと進化します。
この点、私が気に入っているアナロジーとして、
ジョブマップは「顕微鏡」ではなく「定規」である
というものがあります。ジョブマッピングを顧客の深層心理を覗き込む顕微鏡として使うと、見えるものは増えますが、比較はできません。一方で、組織の判断を測る「定規」として使えば、すべての議論は測定可能な単位へと揃っていく、というわけです。
B：予測の有効性
「ジョブを掴めばプロダクトは必ず当たる」「JTBDは成功率を劇的に高める」
こうした強い主張は心地よい響きですが、広いサンプルで強い因果を断言できるほどエビデンスは厚くないのが現状です。
ただし、「予測できないなら無意味だ」という短絡的な拒絶に陥るのは尚早。
予測の有効性とは、“当たること”ではなく、“外し方の質を上げること”にあると考えるべきではないでしょうか。
何が未知で、どこに不確実性があるかを可視化する
どの工程のアウトカムがボトルネックになっているかを特定する
「次の一手」として何を検証すべきか、実験の解像度を上げる
つまり、ジョブマップは未来を当てる占いではなく、「仮説の健康診断書」のようなものなのです。
特にヘルスケア領域において、この過信は致命傷になりがちです。規制や説明責任といった「構造上の制約」は、顧客個人の「好み」を超えた場所に存在するからです。顧客の意向をどれだけ精緻に言い当てても、構造の壁に突き当たれば、プロダクトは一歩も前に進みません（当たり前ですが）。
C：経営の有効性
ジョブマッピングを翻訳機として正しく運用できたとき、その恩恵を最も受けるのは、理解の深さではなく「決定の速度」です。
優先順位の客観化： 「声の大きい人の要望」が、「工程×アウトカム×代替」という比較に置き換わる
問いの転換： 「精度を上げるべきか？」という抽象的な悩みが、「どの意思決定点を突破するために、あと何％の精度が必要か？」という具体的な計算に変わる
拒否権の可視化： 「誰が、どのタイミングで止めるか」が事前に示され、プロジェクト後半の致命的な手戻りが激減する
実験の定義： 実証実験が「とりあえず使ってもらう」ことから、「特定の意思決定を突破するための証拠集め」に変わる
前章で挙げた「三つの泥沼」は、まさにこのCが機能していない証左です。
「医師の熱狂」バイアス： 意思決定点（購買・IT部門）を工程に組み込んでいなかった
精度偏重のパラドックス： 臨床価値にアウトカムが偏り、導入後の「合格ライン（説明責任等）」を無視していた
マルチステークホルダーの混線： 意思決定の単位を揃えず、全員の顔色を伺う「平均値の図」を作ってしまった
冷静に考えれば難しい話ではありませんが、これらはすべて、「顧客理解が足りない」せいではありません。
「組織が決められる形に、翻訳できていない」ことが原因なのです。ゆえに、翻訳機としてのジョブマッピングが最も鮮やかに効くのは、この「経営判断」の領域に他なりません。
ここまでを整理すると、結論は至極シンプルで、
A（認知）は効く： 議論を「正義の衝突」から「アウトカムの検証」へ移す
B（予測）は過信しない： 当てる道具ではなく、検証すべき仮説を炙り出す道具とする
C（経営）は最も効く： 組織が「Yes」と言うための条件を揃え、停滞を打破する
ジョブマッピングの真価は、顧客を“理解すること”ではなく、組織が“決めるための単位”を揃えることにある。
これが、本稿が一貫して提示する立場です。
ジョブマッピング実践
ここまでで、ジョブマッピングの本質は顧客理解ではなく「意思決定の翻訳機」である、という立ち位置を明確にしました。
では、この翻訳機をどう組み上げ、現場に実装していくべきか。本章では、ヘルスケア領域を例に、あらゆる複雑な意思決定が絡む領域で応用可能な「最短で回る実装ステップ」を提示します。
