JTBDは「顧客理解の完成形」ではない
Jobs-to-be-Done(JTBD)理論は、顧客が製品やサービスを「雇用する」のは特定の「仕事(Job)」を完了させるためだという洞察から始まる。クリステンセンらが発展させ、Tony Ulwickがデマンド・サイドのイノベーション手法として体系化したこのフレームワークは、2010年代以降のプロダクト開発とイノベーション実務に広く普及した。
「顧客は4分の1インチのドリルが欲しいのではなく、4分の1インチの穴が欲しい」——テオドア・レビットのこの言葉を洗練させた形で、JTBDは「顧客が本当に求めていること」を機能的・感情的・社会的ジョブの3軸で捉える。
しかし、この理論の普及とともに一つの問題が生じている。JTBDを「顧客理解の完成形」として位置づけ、その限界を直視しないまま適用するケースが増えていることだ。
フレームワークは「視点の提供」であって「答えの提供」ではない。JTBDが何を見えやすくし、何を見えにくくするかを理解した上で使うことが、このツールの正しい使い方だ。
JTBDが抱える4つの構造的限界
限界1:文脈依存性の過小評価
JTBDの基本的な問い——「顧客はどんなジョブを片付けるためにこの製品を雇用するか」——は、文脈を所与のものとして扱う傾向がある。しかし実際の顧客行動は文脈に強く依存する。
同一の顧客が、同一の製品を、異なる文脈で異なる目的に使う。コーヒーを「朝の通勤中に飲む」文脈では「退屈な通勤時間を有意義にする」ジョブが優先される。「昼食後に飲む」文脈では「眠気を払拭する」ジョブが優先される。「打ち合わせで提供する」文脈では「場を整える社会的シグナル」としてのジョブが優先される。
クリステンセン自身がミルクシェイクの事例でこの文脈依存性を示したが、その後継者たちがJTBDを一般化する過程で、「文脈を特定すれば普遍的なジョブが見える」という誤解が広まった。文脈を固定しなければジョブを定義できないが、文脈を固定すると異なる文脈への適用が困難になる。
ジョブの普遍性と文脈の特殊性は根本的に緊張関係にある。 JTBDはこの緊張を解消しない——管理するための視点を与えるだけだ。
限界2:競合定義の恣意性
JTBDは競合の概念を広げる。顧客が「退屈な通勤時間を有意義にする」ジョブを抱えているなら、競合はコーヒー屋だけでなく、ポッドキャスト、読書、スマートフォンのゲームも含まれる。
この拡張された競合定義は、視野を広げる点で有用だ。しかし実務的な問題が生じる——競合をどこで「切るか」の基準が恣意的になることだ。
「退屈を解消する」ジョブで競合を定義すれば、すべての娯楽産業が競合になる。「空腹を満たす」ジョブで定義すれば、すべての食品・飲料産業が競合になる。ジョブの抽象度を上げるほど競合範囲は広がり、抽象度を下げるほど従来の製品カテゴリ競合に収束する。
適切な抽象度の選択は、フレームワークが答えを出してくれる問いではなく、分析者が判断しなければならない問いだ。この判断の質がJTBD分析の質を規定するが、フレームワーク自体はその判断基準を提供しない。
限界3:潜在的ジョブの発見困難性
JTBDが最も価値を発揮するとされるのは、「顧客が言語化していない潜在的なジョブを発見する」場面だ。しかし、この発見プロセスには構造的な困難がある。
顧客インタビューや観察調査を通じてジョブを発見しようとすると、「すでに行動している文脈」でのジョブは発見しやすいが、「まだ行動していないが将来行動するかもしれない文脈」でのジョブは発見困難だ。
技術的な変曲点によって新しい行動が可能になった時——スマートフォンの普及、音声UIの登場——顧客は「新しいジョブ」を事前に表現できない。Appleがユーザー調査からiPhoneを発見できなかった理由の一端はここにある。JTBDは「既存の行動パターンの分析」には強いが、「存在しない行動パターンの予測」には機能しない。
限界4:ジョブとソリューションの往来の困難
JTBDは「ジョブ(顧客が達成したいこと)」と「ソリューション(製品・サービス)」を切り分け、ジョブから発想することを求める。しかし実務では、この切り分けが思いのほか困難だ。
既存製品を持つ組織がJTBD分析を行う場合、分析者が既存製品の論理から自由になれないことが多い。「この製品を使って顧客はどんなジョブを達成しているか」という問いで始めると、ジョブの発見が既存製品の機能・用途に引きずられる。これは「製品起点の顧客理解」であり、JTBDが排除しようとしていた発想パターンそのものだ。
完全に白紙のジョブ起点で発想するには、既存製品を「存在しないもの」として分析できる認識論的訓練が必要だ。この訓練を受けていない分析者がJTBDを使うと、既存製品を正当化するための分析に終わる。
JTBDを正しく機能させるための使い方
上記の限界は、JTBDを「使ってはいけない」という結論を意味しない。限界を認識した上で使うことが、過信によるミスを防ぐ。
JTBDが有効な場面: 既存市場の顧客行動の構造的分析。競合との差別化軸の再設定。既存製品の改良方向の優先順位付け。これらは「既存の行動パターンを深く理解する」局面であり、JTBDの強みが活きる。
JTBDが機能しにくい場面: 技術的変曲点における新市場の予測。まだ存在しない顧客行動の発見。製品コンセプトが先行している場合の適用。これらの局面では、JTBDより「未来のシナリオ設計」「エクストリームユーザー観察」「アナログからの類推」といった別のアプローチを組み合わせる必要がある。
分析の品質を上げる実践: 文脈を複数設定し、文脈ごとにジョブを定義する(「朝の通勤中のジョブ」「昼食後のジョブ」として分けて分析する)。競合を複数の抽象度で定義し、各抽象度での示唆を比較する。ジョブ仮説を「現場観察」で検証し、インタビューだけに依存しない。
フレームワークは「なぜ使うか」と「どう使うか」が同時に明確な時にのみ機能する。JTBDを「顧客理解のための最強のツール」として信奉することを止め、「特定の問いに対する特定の視点を提供するツール」として扱う時、このフレームワークは本来の価値を発揮する。
関連するインサイト
参考文献
- Christensen, C. M., Hall, T., Dillon, K. & Duncan, D. S. Competing Against Luck: The Story of Innovation and Customer Choice, Harper Business (2016)
- Ulwick, A. W. Jobs to be Done: Theory to Practice, Idea Bite Press (2016)
- Klement, A. When Coffee and Kale Compete, CreateSpace (2018)
- Levitt, T. “Marketing Myopia,” Harvard Business Review (July–August 1960)
- Norman, D. & Verganti, R. “Incremental and Radical Innovation: Design Research vs. Technology and Meaning Change,” Design Issues 30, no. 1 (2014)
荒井宏之 / INNOVATION VOYAGE
関連記事
フレームワーク
オープンイノベーションを殺すNDA——秘密保持契約が協業速度と信頼構築を同時に阻む構造
NDAは協業の「入口」として機能するが、その設計と運用が大企業とスタートアップ双方の信頼構築を阻み、協業速度を損なう構造的問題を解析する。
2026年6月22日
フレームワーク
プラットフォーム戦略の遅延リスク——大企業エコシステム構築の速度問題
大企業がプラットフォーム戦略を採用しても、エコシステム構築速度がスタートアップに比べて致命的に遅れる構造的理由を解析する。承認構造・パートナーシップ設計・「ポータル」との混同という3つの核心問題と、処方箋となる設計原則を提示する。
2026年6月21日
フレームワーク
組織変革コンサルティングの提言実装ギャップ——「知っている」と「やっている」の間に何があるか
組織変革コンサルティングで作られた提言書が、なぜ実装されないままになるのか。問題はコンサルタントの質でも提言の内容でもなく、「戦略設計」と「実行」を別の仕事として分離する組織構造そのものにある。
2026年6月13日