JTBD顧客理解PM

ジョブ理論(JTBD)とは?|顧客が製品を雇う理由から、作るものと伝え方を決める

2026年09月20日 ・ MonaLens

新機能を出したのに使われず、競合と機能を比べて足りないものを埋めたのに、解約が止まらない。こうした場面に心当たりはないでしょうか。

原因のひとつは、顧客が何のために製品を使っているのかを、私たちが製品の側から説明してしまっていることです。この記事では、その視点を顧客の側へひっくり返す考え方であるジョブ理論(Jobs to Be Done、以下JTBD)を、初めての方にもわかるように体系立てて解説します。

ジョブ理論(JTBD)とは何か

JTBDは、ハーバード・ビジネス・スクールの教授だったクレイトン・クリステンセンと、長年の協力者であるボブ・モエスタらが育ててきた、顧客の選択を説明するための理論です。2016年には、クリステンセンらの共著『Competing Against Luck』(邦題『ジョブ理論』)として体系的にまとめられました。

顧客は製品を買うのではなく雇う

JTBDの中心にあるのは、顧客は製品を買うのではなく、自分の用事を片づけるために雇うという見方です。ここでいう用事がジョブで、ある状況の中で顧客が成し遂げたい進歩のことを指します。

たとえば、ドリルを買う人が欲しいのはドリルそのものではありません。壁に穴を開けたいのであり、さらに言えば棚を付けて部屋を片づけたいのかもしれません。

製品は、その進歩を実現するために一時的に雇われる手段にすぎません。そして、もっとうまく用事を片づけてくれる手段が現れれば、顧客はためらわずに製品を解雇して乗り換えます。

機能・社会・感情の3つの側面

ジョブは、作業を済ませるという機能的な側面だけでできているわけではありません。周りからどう見られたいかという社会的な側面と、どんな気持ちでいたいかという感情的な側面も含まれます。

分析ツールを例にとると、機能的なジョブは離脱の多いページを見つけることです。一方で、会議で根拠のある提案をして信頼されたいという社会的なジョブや、数字が読めずに不安な状態から抜け出したいという感情的なジョブも同時に存在します。

機能だけを比較表に並べても、後ろの二つは見えてきません。ところが、実際の乗り換えを決めているのは、しばしば社会的・感情的な側面のほうです。

属性で顧客を切ると何が見えなくなるのか

多くのマーケティングは、年齢や業種、企業規模といった属性で顧客を分けます。属性は集計しやすく便利ですが、同じ属性の人が同じ理由で製品を選ぶとは限りません。

JTBDが問うのは誰かではなく、どんな状況で何を片づけたいのかです。30代のPMという同じ属性でも、立ち上げ直後で指標を決めたい人と、経営会議の前夜に説明材料を探している人とでは、雇いたいものがまったく違います。

ミルクシェイクの話が教えてくれること

JTBDを語るときに必ずといってよいほど紹介されるのが、クリステンセンが広めたミルクシェイクの事例です。ファストフードチェーンがミルクシェイクの売上を伸ばそうとした話として知られています。

競合はカテゴリの外にいる

チェーンは当初、顧客に味や量、価格の好みを尋ね、その声に沿って改良を重ねました。しかし売上はほとんど動かなかったとされています。

そこで観察を変えたところ、ミルクシェイクの多くが朝、車で通勤する一人客に買われていることがわかりました。彼らが雇っていたのは、退屈な運転の時間を紛らわせ、昼まで空腹をしのぐという用事でした。

この用事で見ると、競合は他社のミルクシェイクではありません。バナナやドーナツ、ベーグル、あるいは何も食べないという選択肢まで、同じ用事を片づけようとするあらゆる手段が競合になります。

状況が主語になる

この事例の学びは、同じ製品でも状況が変われば雇われる理由も変わるという点にあります。夕方に子どもと来店した親が買うミルクシェイクは、また別の用事のために雇われているはずです。

ソフトウェアでも同じことが起きます。同じダッシュボードが、ある人には毎朝の定点観測として、別の人には四半期に一度の報告書づくりとして雇われているのです。

状況を主語にすると、打ち手も変わります。前者には表示の速さや通知が効き、後者にはエクスポートや期間比較が効くかもしれません。

乗り換えを左右する4つの力

JTBDの実践で広く使われているのが、モエスタとクリス・スピークらが整理した進歩の4つの力(Forces of Progress)というモデルです。顧客がいまの手段から新しい手段へ乗り換えるかどうかを、四方向の力の綱引きとして説明します。

押す力と引く力

一つ目は、いまの状況への不満が顧客を押し出す押す力(Push)です。二つ目は、新しい手段が約束する未来が顧客を引き寄せる引く力(Pull)です。

多くのプロダクトは、引く力ばかりを磨きがちです。けれども、いまの状況に困っていない人に魅力的な機能を見せても、そもそも動く理由がありません。

不安と習慣という見えにくいブレーキ

三つ目は、新しい手段がうまくいかなかったらどうしようという不安(Anxiety)です。四つ目は、慣れたやり方から離れたくないという習慣(Habit)です。

この二つはブレーキとして働き、しかも顧客自身が口にしにくいという特徴があります。押す力と引く力の合計が、不安と習慣の合計を上回ったときに乗り換えが起きると考えると整理しやすくなります。

四つの力と、それぞれに効きやすい打ち手の例を表にまとめます。打ち手はあくまで一般的な例で、製品ごとに見直してください。

力 向き 典型的な声 効きやすい打ち手の例
押す力(Push) 乗り換えを促す 毎週の集計に半日かかる 痛みを言語化する訴求
引く力(Pull) 乗り換えを促す 自動で原因まで見られるなら 成果が見える事例やデモ
不安(Anxiety) 乗り換えを妨げる 導入が失敗したら責められる 無料トライアル、移行支援
習慣(Habit) 乗り換えを妨げる 今のスプレッドシートで回っている 既存データの取り込み、段階導入

この表を眺めると、ブレーキ側の打ち手が機能開発ではない場合が多いことに気づきます。オンボーディングや料金設計、導入支援の文章そのものが、プロダクトの一部として働いているのです。

JTBDの二つの流派と使い分け

JTBDは一枚岩の手法ではありません。大きく分けると、乗り換えの物語を掘り下げる流派と、顧客の成功基準を測定可能な形で洗い出す流派があります。

スイッチ・インタビュー型

モエスタらが実践してきたのが、実際に製品を乗り換えた人に、その経緯を時系列で聞き取るスイッチ・インタビューです。最初に不満を感じた瞬間から、情報を探し、比較し、購入を決め、使い始めるまでを、ドキュメンタリーのように再現していきます。

ポイントは、意見ではなく実際に起きた出来事を聞くことです。なぜ選んだのかと尋ねるより、その日は何があったのか、誰と話したのかと尋ねるほうが、本当の理由に近づけます。

ODI型(成果主導のイノベーション)

もう一つは、アンソニー・ウルウィックが提唱したODI(Outcome-Driven Innovation)です。ジョブを工程に分解したジョブマップを描き、各工程で顧客が成功をどう測っているかを、方向と指標と対象を組み合わせた成果記述として書き出します。

たとえば、離脱の原因を特定するまでの時間を最小化する、といった書き方です。こうした記述は特定の解決策を含まないため、技術が変わっても長く使えるとされています。

どちらを選ぶべきか

二つの流派はどちらが正しいというより、得意な問いが違います。特徴を並べると次のようになります。

観点 スイッチ・インタビュー型 ODI型
主な問い なぜ乗り換えたのか どの成果が満たされていないか
主な手法 少人数への深い聞き取り 成果記述の洗い出しと定量調査
向いている場面 訴求、オンボーディング、解約理由の理解 機能の優先順位づけ、新市場の探索
注意点 話し手の記憶違いに引きずられやすい 準備と調査のコストが大きい

小さなチームなら、まずスイッチ・インタビューから始めるのが現実的です。数件の聞き取りでも、顧客の言葉で書かれた押す力と不安が手に入り、訴求文や画面の文言をすぐに直せます。

実務での進め方:ジョブを見つけて、言葉にして、測る

ここからは、PMやインディーハッカーが小さく始めるための手順を紹介します。重い調査設計は不要で、聞く、書く、確かめるの三段階を回すことが目的です。

最近乗り換えた人に話を聞く

最初に話を聞くべきは、ここ数か月で製品を使い始めた人と、逆にやめた人です。記憶が新しいうちでないと、乗り換えの経緯は後づけの理屈に置き換わってしまいます。

聞き取りでは、次の流れで時系列を埋めていくと話が散らかりません。

  • 最初にこのままではまずいと感じたのはいつで、何があったか
  • そのとき、どんな代わりの手段を試したか
  • 比較するときに、何が一番気がかりだったか
  • 決め手になった出来事と、そのとき誰がそばにいたか
  • 使い始めてから、思っていたのと違った点は何か

インタビューの設計そのものについては、ユーザー調査の設計|定量と定性を往復して数字と声をつなぐも参考になります。聞き取った内容は、そのまま製品の比較表に写すのではなく、次のジョブステートメントに翻訳します。

ジョブステートメントに落とす

聞き取りの結果は、状況と動機と期待する成果の三つを一文にまとめると扱いやすくなります。よく使われる型を、架空の分析ツールの例で示します。

【型】
___のとき(状況)、
___したい(動機)、
そうすれば___できる(期待する成果)。

【例:架空の分析ツールの場合】
月曜の定例でCVRの低下を指摘されたとき(状況)、
どのページで離脱が増えたのかを30分以内に特定したい(動機)、
そうすれば根拠を持って改善案を出し、チームの信頼を保てる(期待する成果)。

【この例から読み取れる4つの力】
押す力:定例で数字を指摘され、答えられなかった
引く力:原因の場所まで一目でわかること
不安 :設定が難しく、結局使いこなせないのでは
習慣 :いつものスプレッドシート集計で何とかなっている

この一文には、機能名が一つも出てきません。解決策を含まないからこそ、ダッシュボードを改良するのか、通知を足すのか、テンプレートを用意するのかを、あとから公平に比べられます。

ジョブステートメントが決まると、プロダクトマーケティングの言葉も変わります。機能の一覧ではなく、状況と成果で語る訴求の作り方は、プロダクトマーケティング(PMM)とは?|ポジショニングとローンチ戦略を設計する仕事で詳しく扱っています。

行動データで裏を取る

インタビューで得たジョブは、あくまで仮説です。話してくれた数人の物語が、黙っている大多数にも当てはまるのかは、行動データで確かめる必要があります。

たとえば、定例前の月曜朝に原因を探したいというジョブが本当に多いなら、月曜午前にアクセスが集中し、特定のレポート画面に直行する導線が見えるはずです。仮に、月曜午前に分析画面へ直行する訪問が全体の4割あったとしましょう(数値は説明用の仮定です)。

その場合は、ジョブ仮説が行動に裏づけられたと考えてよい材料になります。

逆に、その導線がほとんど見当たらなければ、ジョブの見立てを疑うべきサインです。MonaLensのようなCookieを使わない解析ツールでも、ファネル分析やN1分析で、こうした導線を匿名のまま確かめられます。

機能ごとの定着を追う方法は、機能の定着率(アダプション)|作った機能が使われない状態を測って直すで解説しています。ジョブに対応する機能が使われていないなら、機能の問題なのか、ジョブの見立ての問題なのかを切り分けることが次の一手になります。

よくある誤解と落とし穴

JTBDは直感的でわかりやすいぶん、形だけ取り入れて効果が出ないことも少なくありません。つまずきやすいポイントを三つ取り上げます。

ジョブを抽象化しすぎる

もっと幸せになりたい、仕事で成功したい、といった抽象度の高いジョブは、どんな製品にも当てはまってしまいます。それでは打ち手が決まりません。

目安は、そのジョブを読んだだけで、状況と場面が思い浮かぶかです。月曜の定例前という時間や、CVRの低下を指摘されたという出来事まで書けていれば、チームの誰が読んでも同じ場面を想像できます。

ペルソナの言い換えで終わる

ジョブステートメントを書いたつもりが、実はペルソナの説明になっているケースもよくあります。30代のマーケターで、忙しく、データに強くない、という記述は属性であってジョブではありません。

属性は、ジョブを持つ人の顔ぶれを知るための補助情報にとどめましょう。主語はあくまで状況であり、同じ人が状況によって別のジョブを持つことを前提に置きます。

聞き取りだけで決めてしまう

深いインタビューは強力ですが、話してくれる人には偏りがあります。熱心なユーザーほど取材に応じてくれるため、静かに離れていった人の声は集まりにくいのです。

だからこそ、聞き取りで得た仮説を行動データで検証し、さらに小さな実験で確かめる流れが欠かせません。作る前に確かめる進め方の全体像は、プロダクトディスカバリー入門|作る前に確かめる進め方にまとめています。

まとめ:作るもの・伝え方・測り方をひとつの問いでつなぐ

JTBDの価値は、新しい用語を覚えることではありません。顧客はどんな状況で、何を片づけるために、この製品を雇っているのかというひとつの問いを、チーム全員の共通言語にすることにあります。

この問いが共有されると、機能開発の優先順位も、LPの訴求も、オンボーディングの文言も、同じジョブを基準に判断できるようになります。競合も、機能表の隣に並ぶ製品だけでなく、スプレッドシートや何もしないという選択肢まで視野に入ります。

最初の一歩は小さくて構いません。今月使い始めてくれた人に一人だけ連絡を取り、その日に何があったのかを聞いてみてはいかがでしょうか。

MonaLensで、あなたのサイトの導線を可視化しませんか?

Cookieレスで、離脱ポイントとコンバージョンが数分でわかります。

無料で始める