🧩 ジョブマップが“美しいほど”決められない—翻訳機としてのJTBDのススメ
会議室のホワイトボードには「Job Map」の文字。その下には付箋が、Define、Locate、Prepare、Confirm……と、教科書通りの工程に沿って整然と並んでいる。
出来上がった図は、たしかに“それっぽい”。
それなのに、意思決定が前に進まないのはなぜなのでしょうか。
プロダクトの優先順位はあやふやで、次の手を打つ勇気も湧いてこない。結局、最後は「追加でユーザーインタビューしましょう」という、安全だが何も解決しない決定で幕を閉じる。
私はこれまでDeeptechの現場で、このような光景を何度も見てきました。
今回は、経験上特に「ジョブマッピングが美しく完成するのに、実装で詰まる」ことが多い（と感じている）ヘルスケア領域を例にジョブマッピングの罠とおすすめの運用法を提案してみます（もちろん他領域でも同様に有効かと思います）。
ヘルスケア領域においてジョブマッピングが実装でつまる理由はシンプルに、顧客が一人ではないからです。
医師、看護師、検査技師、事務、購買、情報システム、コンプライアンス、患者。
臨床的な価値を握っている人と、日々の運用のなかで詰まる人が決定的に異なる。さらに、プロダクトの性能以前に「規制・監査・説明責任」という外壁が、厚く立ちはだかってきます。
この状況下でジョブマッピングを単なる「顧客理解の道具」として扱うと、ほぼ例外なく三つの泥沼に足を取られます。
1. 「医師の熱狂」バイアス
一つ目は、「顧客＝医師」という単一化です。
医師に深くフォーカスするほど、臨床的な議論は精緻を極めます。しかし、実際に導入の足を止めるのは、医師ではなく情報システム部門のセキュリティ要件だったり、購買部門の稟議プロセスだったりします。
医師の「欲しい」は、臨床現場では正義でも、病院という組織の扉を開ける「鍵」にはなり得ません。結果、ジョブマップは「理解できた気がする絵」で止まり、導入・運用・更新という、組織としての工事の工程が空白のまま残されることになります。
2. 精度が上がるほど、購買が遠のくパラドックス
二つ目は、「精度」がすべての意思決定を支配してしまう問題です。
AI診断や検査支援の領域では特に顕著ですが、モデルの精度に議論が集中するほど、組織としての「買い」の判断は遅滞します。精度は必要条件に過ぎず、組織にとっての十分条件ではないからです。
「誤判定時の責任所在はどうなるのか」「監査ログはどう残るのか」「既存のワークフローをどれだけ壊すのか」etc。
こうした“導入後に必ず突きつけられる問い”がマップの工程に組み込まれていない限り、組織ははっきり「Yes」と言えません。優先順位が「精度の追求」に一点張りされる一方で、意思決定を動かすための「説明可能性」や「ワークフロー統合」が後回しにされていく。これは戦略上の大きなミスです。
3. 「全員大事」という名の思考停止
三つ目は、マルチステークホルダーの混線です。
患者、医師、保険者、製薬企業。全員のジョブを一枚の図に無理やり統合しようとすれば、それは「誰も傷つけないが、何も決められない図」に成り下がります。
「全部大事」は、戦略においては「何も選んでいない」のと同義です。
この手の話をすると、「では結局ジョブマッピングは必要ないのか？」と問われることがままあります。
が、この点私は、以前ジョブマッピングは有効であるとお伝えしています。ただし、それは“顧客を深く理解する”ためではありません。
「ジョブマッピングは、組織内の異なる言語を繋ぐ「意思決定の翻訳機」として使ったときにこそ、真価を発揮する」
と、私は考えています。ここでいう翻訳機とは何か。
研究開発、営業、コンプライアンスetc、部門ごとにバラバラな「評価基準」を、一つの共通した「判断の単位」に揃える装置のことです。
昨今のJTBD研究では、インタビューを回すための形式知が整いつつあります。しかし同時に、「JTBDさえ使えば成功する」という因果関係を断言できるほど、エビデンスはまだ十分ではありません。
だからこそ、私たちがここで狙うべきは“学術的な正解”ではなく、“現場が決められる状態”を作ることです。
以降、本稿では、ジョブマッピングを「工程図」から「意思決定を動かす翻訳テーブル」へと再設計する方法論をお示しします。
目次
- 目次
- 1) ジョブ（Job）の定義を「成功条件」に絞り込む
- 2) ジョブマッピングは「政治的」な工程図である
- 3) 似て非なる「道具」との境界線
- 4) 翻訳機が「宗教」に堕ちないための3要件
- 「で、ジョブマッピングは本当に有効なんですか？」
- A：認知の有効性
- B：予測の有効性
- C：経営の有効性
- ジョブマッピング実践
- 0) 付箋を並べる「陶酔」から抜け出す
- 1) Step 1：最初に「意思決定」を固定する
- 2) Step 2：ジョブの境界を「成功条件」で切り出す
- 3) Step 3：「意思決定の工程」をマッピングする
- 4) Step 4：工程ごとに「合格ライン（アウトカム）」を定義する
- 5) Step 5：「代替」という名の真の競合を並べる
- 6) Step 6：拒否権者の「拒否理由」を先回りする
- 7) Step 7：「翻訳テーブル」に集約する
- 8) 優先順位は「拒否権×硬さ」で決める
- 9) PoCの定義を「証拠集め」に書き換える
- おわりに
上記で、ジョブマッピングは顧客理解の道具ではなく「意思決定の翻訳機」である、という主張をしました。
しかし、この主張には避けて通れない弱点があります。それは、「ジョブ」という言葉自体が、驚くほど人によって違うものを指しがちだという点です。
同じ「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」と言うための条件を揃え、停滞を打破する
ジョブマッピングの真価は、顧客を“理解すること”ではなく、組織が“決めるための単位”を揃えることにある。
これが、本稿が一貫して提示する立場です。
ジョブマッピング実践
ここまでで、ジョブマッピングの本質は顧客理解ではなく「意思決定の翻訳機」である、という立ち位置を明確にしました。
では、この翻訳機をどう組み上げ、現場に実装していくべきか。本章では、ヘルスケア領域を例に、あらゆる複雑な意思決定が絡む領域で応用可能な「最短で回る実装ステップ」を提示します。
0) 付箋を並べる「陶酔」から抜け出す
多くのプロジェクトが、Define、Locate、Prepare……とホワイトボードに付箋を並べ終えた瞬間に、奇妙な満足感に包まれます。
しかし、それは精巧な旅程表を描いて満足している旅人と同じです。目的は“到着”であって、“旅程表の美しさ”ではありません。
翻訳機としてのジョブマッピングは、描く順番が逆です。まず「意思決定（どこに到着したいか）」から逆算して、杭を打っていきます。
1) Step 1：最初に「意思決定」を固定する
工程を描き始める前に、まず次の問いをチームと共有してください。
- 意思決定の対象： 今、この瞬間、何を決めたいのか？（優先順位か、要件の採否か、PoCの設計か）
- 意思決定者： 最後に「Yes」と言う一人は誰か？
- 拒否権者： 導入が決まった後、横から「待った」をかけてプロジェクトを殺せるのは誰か？
ここが曖昧なまま描かれるマップは、ただの「希望的観測」に過ぎません。意思決定者1名＋拒否権者2〜3名まで絞り込めないなら、そのジョブはまだ大きすぎて、翻訳不能、といってしまってよいかと思います。
2) Step 2：ジョブの境界を「成功条件」で切り出す
次に、ジョブの境界線を引きます。前章の定義（状況・目的・成功条件）をメスとして使い、対象を「意思決定が発生するサイズ」まで小さく切り出します。
特にヘルスケアのような多層的な領域では、ジョブを「診断」や「治療」といった巨大な塊で扱おうとして、ステークホルダー全員の正義が混線しがちです。
「導入稟議を通す」「監査をクリアする」「現場の入力負荷を破綻させない」。このくらいのレベルまで落として初めて、翻訳機は動き出します。
3) Step 3：「意思決定の工程」をマッピングする
既存のフレームワーク（Define→Locate→Confirm…）の骨格は流用して構いません。ただし、そこに載せるのは「ユーザーの気持ちの旅」ではなく、「意思決定に必要な関門（ゲート）」です。
例えば、顧客理解の視点では落ちがちな以下の工程こそが、翻訳機においては主戦場となることが往々にしてあります。
- セキュリティ審査： 情報システム部門の関門
- 購買・稟議プロセス： 購買・経理部門の経済的合理性の関門
- 監査・説明責任の立証： コンプライアンス・医療安全部門の防衛関門
これらは顧客の「感情」ではありませんが、組織が動くための「物理的な工程」です。
4) Step 4：工程ごとに「合格ライン（アウトカム）」を定義する
続いて、ようやく各工程に、アウトカムを刺していきます。
ここで鉄則となるのは、「翻訳不能な、測れない言葉」を禁止することです。
「便利」「安心」「使いやすい」といった情緒的な表現は、議論を濁らせるノイズに過ぎません。代わりに、次のような「合格ライン」へ変換してください。
- 速度： 「◯分以内」「◯ステップ以内」
- 確実性： 「エラー率◯％以下」「追跡可能性の担保」
- 責任： 「誰が最終判断し、どこに証跡が残るか」
精度偏重に陥るチームは、多くの場合「精度」以外に測れる基準を持っていないだけです。監査や責任の所在を数値や証跡の形へ無理やりにでも落とし込む。その強引さが、議論を「精度一点張り」から引き剥がします。
5) Step 5：「代替」という名の真の競合を並べる
各工程で、現場が今どうやって「凌いでいるか」を並べます。
真の競合は、他社の洗練されたプロダクトではありません。
- 現場の人力運用： Excel、紙のメモ、口頭伝達、ベテランの暗黙知
- 回避行動： そもそもその工程を飛ばす、外注する
意思決定者にとって、現状の「凌ぎ方」は最大の比較対象です。これが可視化されることで、初めて「わざわざ新しい仕組みを入れるリスク」を上回る価値を議論できるようになります。
6) Step 6：拒否権者の「拒否理由」を先回りする
導入の泥沼で起きる悲劇は、ほぼすべてここで回収できます。
「誰が、どの工程で、何が満たされないと拒否権を発動するか」を事前にマップに埋め込みます。
拒否権の発動は、決して担当者の悪意ではありません。彼らには彼らの「職務上の合格ライン」があるだけです。翻訳機とは、その異なる部門の合格ラインを、開発の初期段階でテーブルの上に揃えてしまう装置なのです。
7) Step 7：「翻訳テーブル」に集約する
ここまで揃ったら、図（Map）を卒業し、表（Table）に落とし込みます。
図は議論を拡散させますが、表は議論を収束させてくれます。例としてはこんな感じです。
8) 優先順位は「拒否権×硬さ」で決める
一般的なODIでは「重要度×不満足度」で優先順位をつけますが、（特にB2B領域では、）それでは不十分です。
優先順位は、次の3軸で力学的に決定すべきです。
- 拒否権の強さ： そこで止められたら、すべてが終わりになる工程か
- 合格ラインの硬さ： 規制・監査・法規のように、妥協の余地がない条件か
- 未充足の大きさ： 現状の凌ぎ（代替）が、どれほど限界に近いか
この視点で並べ直すと、実は「精度」を数％上げるよりも、監査ログの実装や責任分界の整理のほうが、意思決定を前進させるために優先度が高い、という事実が浮き彫りになるはずです。
9) PoCの定義を「証拠集め」に書き換える
最後に、PoCの目的を転換します。
「とりあえず現場に使ってもらい、感想を聞く」という情緒的な実験は今日限りでやめてください。
翻訳機としてのPoCとは、「特定の拒否権者がYesと言うための証拠（エビデンス）集め」です。
精度を証明するのではなく、「このログ粒度なら監査をパスできるか」「この運用なら責任所在が明確か」を突き止める。これが、組織の重い腰を上げさせる唯一の方法です。
以上の通り、工程ごとに成功条件、代替、拒否権者を刺し抜き、意思決定を動かすための「翻訳テーブル」として運用すること。その設計図こそが、停滞したプロジェクトを実装へと導く鍵となるはずです。
おわりに
改めて私たちが直視すべきは、何を敵に回しているのか、という点です。
敵は、ジョブマッピングという手法そのものではありません。私は、「それっぽい図が完成した瞬間に訪れる、偽りの安心感」にあると考えています。
付箋が整然と並び、教科書通りの工程が埋まる。
その瞬間、チームは「無風の合意」に包まれ、前に進んだ錯覚に陥ります。ところが現実のプロジェクトは、優先順位は霧の中、拒否権は土壇場まで気づかないふりをされ、PoCは「なんとなくの感想」を集めて終わる。結局、最後に残るのは「追加のユーザーインタビュー」という、最も安全で、何も解決しない先送りのカードだけです。
この停滞を断ち切るために、「ジョブマップの価値は“理解の深さ”ではなく、“決めるための単位”を揃えることにある」ということを明確に意識すべきでしょう。
そのために必要なのは、一瞬の煌めきのような洞察ではありません。むしろその逆です。
翻訳機としてのジョブマッピングは、徹底して事務的で、徹底して不格好で、徹底して政治的な装置です。
- 工程ごとに合格ライン（アウトカム）を刺し通す。
- 工程ごとに代替（今の凌ぎ）を並べ立てる
- 工程ごとに拒否権者（プロジェクトを殺せる人）を暴き出す
- PoCを、情緒の収集から「Yesを引き出すための証拠集め」へ作り変える
この4つが噛み合ったとき、ジョブマップはただの“絵”を卒業し、組織を動かす意思決定の装置へと変貌します。
最後に一つ問いかけです。今、あなたの目の前でプロジェクトを止めている「正体」は何でしょうか。
- 斬新なアイデアが足りないからですか？
- 顧客への愛や理解が浅いからですか？
- それとも、「合格ラインどこにあり、誰が引くのか」が明確に見えていないからですか？
もし最後の一つに心当たりがあるなら、進むべき道は明確です。新しい発見を求めて顧客の深層を掘り続ける必要はありません。
「誰が、どこで、何を満たせばYesと言うのか」を、テーブルへ落とし込むこと。そして、そのYesを梃子にして、組織の意思決定を最短距離でこじ開けること。
ジョブマップを“完成させる”ことへの執着を捨て、意思決定が“前に進む”ための設計図として組み直す。
その瞬間にだけ、ジョブマッピングは真に「使える道具」になります。
付箋を増やすことは、誰にでも、いつでもできます。
しかし、「合格ライン」を先に揃えてしまった組織は、以前のようには停滞できません。
なぜなら、「決める」という武器を手にしてしまったからです。
今回は以上。参考になれば幸いです。ではまた！
今週の問い
会議で一番よく出る“曖昧ワード”は何ですか？
例：
・便利／使いやすい／安心
・品質が高い／精度が高い
・現場が回る／運用できる
・ガバナンスが担保できる
・まずやってみたい
ぜひコメントを残していってください！
350人以上の方達が購読中
いつでも購読解除可能です