Jobs To Be Done(JTBD、ジョブ理論)は、「顧客はなぜ特定の製品・サービスを選ぶのか」を「その製品に依頼している仕事(Job)」として理解するフレームワークです。デザイン思考のDefineフェーズにおいて、ペルソナだけでは捉えられない「顧客の真の動機」を解明するために用います。
「人」を見るのではなく「仕事」を見る
JTBDの核心的な転換は、「どんな人が買うか(Who)」ではなく、「どんな仕事を依頼するために買うか(Why)」に着目することです。
従来のマーケティング・リサーチは「ペルソナ」を作ります。「35歳、男性、都市部在住、年収600万円、健康意識高め……」という属性の記述によって顧客を定義します。しかしこのペルソナは、なぜ特定の時点に特定の製品を選ぶかの説明には不十分です。
イノベーション研究者のクレイトン・クリステンセンは「ミルクシェイク」のケースでこの問題を示しました。
ミルクシェイク問題:属性分析の限界
ファストフードチェーンがミルクシェイクの売上を上げようとして、「どんな客がミルクシェイクを買うか」を調べました。購買データを分析し、年齢・性別・時間帯・注文との組み合わせなどの属性情報を集めました。しかし属性データに基づいて改良を行っても、売上は変わりませんでした。
クリステンセンのチームは別のアプローチを取りました。実際にミルクシェイクを買った人に「なぜ今ミルクシェイクを買ったのか」を聞いたのです。
明らかになった事実は属性データからは見えないものでした。朝にミルクシェイクを買う客の多くは「車で通勤している」「片手でハンドルを握りながら何かを口に入れたい」「朝食を食べてきたが、昼前に空腹になる。ミルクシェイクはゆっくり飲めるから昼まで持つ」という理由で購入していました。
つまり、彼らがミルクシェイクに依頼していた「仕事(Job)」は「朝の通勤中、手を汚さずに、時間をかけながら、昼まで空腹を満たす」というものでした。この仕事のライバルは、他チェーンのミルクシェイクではなく、バナナ・ベーグル・コーヒー・ドーナツ——すなわち「同じ仕事を依頼できる代替品」だったのです。
属性データはミルクシェイクを「誰が買うか」は教えてくれますが、「何のために買うか」は教えてくれません。JTBDはこの「何のために」を解明するフレームワークです。
ジョブの三分類
クリステンセンのフレームワークでは、ジョブを三つのレベルで分類します。
機能的ジョブ(Functional Job)
製品・サービスが担う具体的な機能的役割です。「書類を整理する」「移動する」「食事をとる」といった実用的な目的。最も可視化しやすいジョブですが、最も競争が激しく、差別化が困難な領域でもあります。
感情的ジョブ(Emotional Job)
使用中・使用後に感じたい感情に関わる目的です。「自分が有能だと感じたい」「不安を減らしたい」「家族の安全を守っていると感じたい」——これらは購買決定に大きく影響しますが、顧客自身が言語化しにくいジョブです。
エンパシーマップの「Feel(感じていること)」レーンが、感情的ジョブを発見するための観察フレームとして機能します。
社会的ジョブ(Social Job)
他者にどう見られたいかという社会的文脈に関わる目的です。「同僚にデキると思われたい」「環境意識の高い人間として認識されたい」「センスの良い人と思われたい」——消費財やファッション、高級品の購買動機に特に強く作用します。
ジョブステートメントの書き方
ジョブを特定したら、ジョブステートメントとして言語化します。フォーマットは次の通りです。
When I [状況・コンテキスト],
I want to [動機・目的],
So I can [アウトカム・理由].
例:
通勤の電車の中でスマートフォンを見ているとき(When)、
何か面白いコンテンツを短い時間で消費したい(I want to)、
仕事の疲れを気分転換で少し和らげるために(So I can)。
このフォーマットの三要素は、それぞれ具体的な設計の示唆を持ちます。
When(コンテキスト):どんな状況でそのジョブが発生するか。この情報は、製品がどの場面で使われることを前提に設計すべきかを決定します。
I want to(動機):達成しようとしていること。これが「解くべき問題」の正確な記述です。
So I can(アウトカム):その達成によって得られる状態。感情的・社会的ジョブはしばしばここに現れます。
JTBDインタビューの進め方
JTBDは「ユーザーに直接聞く」観察から成立します。インタビューでは、属性情報ではなく「最後に○○を選んだとき」の具体的なエピソードを掘り下げます。
起点の質問
「最後に[対象製品・サービス]を使い始めた(または切り替えた)ときのことを教えてください」
属性を聞くのではなく、具体的な「出来事」を起点に置くことが重要です。「なぜ買いましたか?」という直接的な質問よりも、「その日はどんな状況でしたか?」「それ以前はどうしていましたか?」という状況の掘り下げが、より正確なジョブを見つけます。
聞くべき内容
- 切り替えのトリガー(何がきっかけで変えようと思ったか)
- 検討した代替案(何と比較したか)
- 決め手(最終的に選んだ理由)
- 使用後の体験(想定通りだったか、期待と違ったことは)
ペルソナとJTBDの併用
ペルソナとJTBDは対立するフレームワークではなく、相補的に使うものです。
ペルソナは「誰に伝えるか」「誰のために設計するか」の指針として、マーケティングコミュニケーションや製品設計の「文脈の共有」に有効です。
JTBDは「なぜその人はこの製品を選ぶか」の因果メカニズムを解明します。ペルソナに「ジョブの記述」を組み合わせることで、「この属性の人が、この状況で、このジョブを達成するためにこの製品を選ぶ」という、より行動予測精度の高いユーザー理解が得られます。
Defineフェーズの成果物として、「ペルソナのシート」にJTBDの三つのジョブタイプを追記するという形式が実務的によく使われます。
よくある誤り
誤り1:製品を前提にジョブを定義する。 「私たちのスマートウォッチを使う人のジョブは?」という問いの立て方は誤りです。製品より先に「人の状況」を起点に置くことが原則です。「運動を習慣にしようとしている人のジョブは?」から出発します。
誤り2:機能的ジョブだけ列挙する。 感情的・社会的ジョブを見落とすと、競合差別化の核心を見逃します。「速く移動する」というジョブだけを見ていると、テスラがなぜ選ばれるかが説明できません。
誤り3:ジョブを「ソリューション」で記述する。 「スマートフォンを使いたい」はジョブではなく、既存ソリューションへの参照です。そのスマートフォンを使って「何を達成したいか」まで掘り下げることが必要です。
参考文献
- Clayton M. Christensen, Taddy Hall, Karen Dillon & David S. Duncan, Competing Against Luck: The Story of Innovation and Customer Choice, Harper Business, 2016
- Bob Moesta & Chris Spiek, Demand-Side Sales 101, Lioncrest Publishing, 2020
- Anthony W. Ulwick, Jobs to Be Done: Theory to Practice, IDEA BITE PRESS, 2016
- Tony Ulwick, “Turn Customer Input into Innovation”, Harvard Business Review, January 2002