JTBD（Jobs-to-Be-Done）とは？顧客視点で本質的な価値を生み出すフレームワーク

「JTBD（Jobs-to-Be-Done／ジョブ理論）」は、顧客が製品やサービスを選ぶ本当の理由を明らかにし、そこから価値提供を設計するためのフレームワークです。従来の市場セグメント分析やペルソナ分析が「どんな人が買うのか」を問うのに対して、JTBDは「顧客はどんな用事（ジョブ）を片づけるために、それを雇っているのか」を問います。

マーケティングの世界には「人が欲しいのは4分の1インチのドリルではなく、4分の1インチの穴である」という有名な言い回しがあります。顧客が本当に欲しいのは製品そのものではなく、それによって達成される状態です。JTBDはこの発想を、思いつきの標語ではなく再現性のある手順に落とし込んだものだと考えると理解しやすくなります。

本記事では、JTBDの基本概念、従来手法との違い、理論の背景にある2つの系譜、ジョブの分解方法、導入プロセス、そして現場で起きやすい失敗までを解説します。新規事業や既存事業の立て直しに携わる方が、明日から実務で使える粒度でまとめました。

JTBDとは？従来のマーケティング手法との違い

JTBDの基本概念：顧客は何を「雇用」しているのか？

JTBDでは、顧客は製品を「購入する」のではなく、あるジョブを片づけるために製品を「雇用（hire）」していると捉えます。そして、そのジョブをうまく片づけられなければ、顧客はその製品を「解雇（fire）」して別の手段に乗り換えます。

この雇用と解雇という比喩が重要なのは、顧客の行動を属性ではなく状況で説明できるようになるからです。「30代の男性会社員だからこの商品を買った」という説明は、同じ属性の人が買わなかった理由を説明できません。一方で「朝の通勤中に片手で長く時間をつぶしたかったから雇った」という説明であれば、いつ・どんな状況で需要が生まれるかを予測できます。

JTBDの主要要素

ジョブ（Job）
顧客が達成したい目的や解決したい課題。
例：「健康的な食事を手軽に取りたい」

プロダクトの雇用（Hiring）
目的を達成するために顧客が選ぶ製品やサービス。
例：「サラダのデリバリーサービスを利用する」

競合（Competing Solutions）
顧客がジョブを達成するために選ぶ可能性のある他の選択肢。同じ業界の製品とは限りません。
例：「自炊する」「コンビニでサラダを買う」「そもそも昼食を抜く」

3つ目の「競合」の捉え方が、JTBDが実務にもたらす最大の変化かもしれません。市場シェアの分母を同業他社に限定している限り、顧客が本当に比較している選択肢は視界に入ってきません。「何もしない」という選択肢もまた、強力な競合です。

従来のマーケティング手法との違い

ペルソナ分析・セグメンテーション・JTBDの3つを、フォーカスと使いどころで比べてみます。

• ペルソナ分析：顧客の属性や行動（年齢・性別・職業・趣味）に注目します。広告のターゲティングやクリエイティブの方向づけに向いています
• セグメンテーション：市場の特性（業界・企業規模・購買履歴）に注目します。どの市場を狙うかというマーケット選定に向いています
• JTBD：顧客の目的や達成したいジョブ（課題・使用シナリオ・状況）に注目します。プロダクト開発や、そもそも何を作るべきかという意思決定に向いています

従来の手法では「どのような人が購入するのか」に注目しますが、JTBDでは「顧客はなぜその製品を選ぶのか」を考える点が大きな違いです。これらは対立するものではなく、役割が違います。何を作るかをJTBDで決め、それを誰にどう届けるかをペルソナやセグメンテーションで設計する、という組み合わせが実務では機能します。

JTBDが生まれた背景と、2つの系譜

JTBDを調べていると、書き手によって説明の粒度がかなり違うことに気づきます。これは偶然ではなく、JTBDには源流の異なる2つの系譜があるためです。ここを押さえておくと、書籍や記事ごとの記述のばらつきに戸惑わずに済みます。

ミルクシェイクは「朝の退屈な通勤」に雇われていた

JTBDを一躍有名にしたのが、ハーバード・ビジネス・スクールのクレイトン・クリステンセン教授らが紹介した、あるファストフードチェーンのミルクシェイクの事例です。

売上を伸ばすため、同社は当初、顧客の属性を分析して「ミルクシェイクをよく買う人物像」を描き、その層に向けて味や濃さを改良しました。ところが売上は動きません。そこで調査チームは、店舗に張りついて「いつ、誰が、何と一緒に買っていくか」を観察しました。

すると、売上の相当部分が朝の早い時間帯に、単独で来店した客が、持ち帰りで買っていくものだと分かりました。話を聞くと、彼らは長い車通勤を抱えており、片手で扱えて、こぼれにくく、目的地まで20分以上もつ「退屈しのぎ」を求めていたのです。バナナはすぐ食べ終わってしまい、ドーナツは手が汚れ、ベーグルはハンドルを握りながらでは食べにくい。粘度が高く飲み終わるまで時間のかかるミルクシェイクは、この用事に驚くほど適していました。

つまり競合は他社のミルクシェイクではなく、バナナ・ドーナツ・ベーグル・コーヒー、そして「何も買わない」でした。この視点に立てば、打ち手は「味を濃くする」ではなく「もっと長持ちさせる」「注文の列を短くする」に変わります。属性ではなく状況を見ることで、改善の方向そのものが変わるという典型例です。

系譜1：クリステンセン系（ジョブ理論）

クリステンセン教授と、実務家のボブ・モエスタ氏らによる系譜です。著書『Competing Against Luck』（邦訳『ジョブ理論』）に代表され、顧客が乗り換えを決断した瞬間のストーリーを深掘りすることに重心があります。

この系譜でよく使われるのが、購買の意思決定に働く4つの力（Forces of Progress）という考え方です。

• プッシュ：現状への不満。「今のやり方ではもう回らない」
• プル：新しい解決策の魅力。「これなら解決しそうだ」
• 不安：乗り換えることへの不安。「導入して失敗したら誰が責任を取るのか」
• 惰性：現状への慣れ。「今のままでも一応は動いている」

新規事業がうまくいかないとき、私たちはつい「プル」つまり製品の魅力を高めることばかり考えます。しかし顧客が動かない理由は、多くの場合「不安」と「惰性」の側にあります。特にBtoBでは、社内稟議や既存業務フローの変更コストが強烈な惰性として働きます。この観点は、新規事業を前に進める社内調整力（ステークホルダーマネジメント）の議論とも直結します。

系譜2：アルウィック系（ODI／成果ドリブン・イノベーション）

アンソニー・アルウィック氏によるOutcome-Driven Innovation（ODI／成果ドリブン・イノベーション）の系譜です。こちらはジョブを定量的に測定可能な「望む成果」へ分解することに重心があります。

ODIでは、顧客の望む成果を「方向＋測定対象＋対象物＋文脈」という決まった構文で書き出します。たとえば「食材が傷むまでの時間を（方向：最小化する／測定対象：時間）」といった形です。こうして数十個の成果指標を洗い出し、それぞれについて「どれだけ重要か」「どれだけ満たされているか」を顧客に評価してもらいます。

重要度が高く、かつ満足度が低い成果が満たされていないニーズ（unmet needs）として浮かび上がります。ここが投資すべき領域です。逆に、重要度が高く満足度も高い領域に機能を追加しても、顧客は価値を感じません。この考え方は、バーニングニーズ（Must haveとNice to haveの見極め）と同じ問題意識を、より測定可能な形にしたものと言えます。

どちらを使えばよいのか

実務では、探索フェーズと検証フェーズで使い分けるのが現実的です。

• まだ何を作るか決まっていない段階：クリステンセン系。少数のインタビューから、乗り換えの物語と状況を掘り起こします
• 方向は見えていて優先順位を決めたい段階：アルウィック系。成果指標を洗い出し、重要度と満足度のギャップで機能開発の順番を決めます

ジョブの構造を分解する

「顧客のジョブを見つけましょう」と言われても、最初はどの粒度で書けばよいか迷います。ジョブには構造があり、それを知っていると分解しやすくなります。

メインジョブと関連ジョブ

メインジョブは、顧客が達成しようとしている中心的な用事です。関連ジョブは、それに付随して発生する用事を指します。

たとえば経費精算システムであれば、メインジョブは「使った経費を正しく会社に請求する」ですが、その周囲には「領収書を紛失しないように保管する」「上司の承認をすばやく得る」「月末に作業が集中しないようにする」といった関連ジョブが並びます。競合との差がつくのは、しばしばメインジョブではなく関連ジョブの側です。

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

ひとつのジョブには、3つの側面が同時に含まれます。

• 機能的ジョブ：達成したい実務上の結果。「移動時間を短縮したい」
• 感情的ジョブ：得たい感情や避けたい感情。「時間を無駄にしていないと感じたい」「失敗して恥をかきたくない」
• 社会的ジョブ：他者からどう見られたいか。「仕事のできる人だと思われたい」

BtoBの新規事業では、感情的・社会的側面が軽視されがちです。しかし実際の購買判断では、「この選択で自分の評価が下がらないか」という担当者の感情的ジョブが、機能比較の結果を上回ることが珍しくありません。機能で勝っている提案が通らないとき、疑うべきはここです。

ジョブストーリーの書式

見つけたジョブをチームで共有するとき便利なのが、ジョブストーリー（Job Story）という書式です。

「〜という状況のとき、私は〜したい。なぜなら〜だからだ」

たとえば「月末で承認待ちの申請が溜まっているとき、私は未処理のものだけを一覧で見たい。なぜなら、締切に間に合わないものを先に片づけたいからだ」といった具合です。

アジャイル開発で使われるユーザーストーリーが「〜として（役割）」から始まるのに対し、ジョブストーリーは役割ではなく状況から始まる点が特徴です。役割で書くと架空の人物像に引きずられますが、状況で書けば、実際にその機能が必要になる瞬間が具体的に立ち上がります。

JTBDの導入プロセス

プロセス1：顧客インタビューを実施する

顧客が製品を購入・利用する際の「動機」や「期待」を把握します。ここで本音を引き出せるかどうかが精度を左右するため、ユーザーインタビューでラポール（信頼関係）を築く手法もあわせてご覧ください。

JTBDのインタビューには、通常のユーザーインタビューと違うコツがあります。意見や要望ではなく、実際に起きた出来事を時系列で聞くことです。「どんな機能が欲しいですか」と尋ねても、返ってくるのは既存製品の延長線上の答えにしかなりません。

そのまま使える質問例

• これを使おうと最初に思ったのは、いつ、どこで、何をしているときでしたか
• その前は、同じことをどうやって片づけていましたか
• 他にどんな選択肢を検討して、なぜそれをやめましたか
• 導入するとき、いちばん不安だったことは何でしたか
• もしこれが明日から使えなくなったら、代わりに何をしますか

最後の質問は特に有効です。返ってきた答えが、その顧客にとっての本当の競合を教えてくれます。

プロセス2：顧客のジョブを特定する

インタビューで集めた事実から、ジョブを言語化します。前述の3側面で整理すると抜け漏れが減ります。

• 機能的ジョブ：「移動時間を短縮したい」
• 感情的ジョブ：「時間を効率的に使って満足感を得たい」
• 社会的ジョブ：「周囲からスマートに見られたい」

このとき、ジョブは解決策を含まない言葉で書くのが鉄則です。「配車アプリで車を呼びたい」と書いてしまうと、解決策が先に固定されてしまいます。「今いる場所から目的地まで、待たずに移動したい」と書けば、配車以外の打ち手も検討対象に残ります。

プロセス3：既存の競争相手を分析する

顧客がどのような代替手段でジョブを達成しようとしているのかを洗い出します。同業他社の製品だけでなく、手作業・表計算ソフト・外部への委託、そして「何もしない」までを competing solutions として並べます。

ここで挙がった代替手段のコスト構造を把握しておくと、価格設計の議論がぶれません。人手による対応が代替手段になっている領域であれば、BizDev・事業開発を外注する費用相場のような外部委託の相場観が、そのまま比較対象の基準値になります。価格そのものの決め方はBizDevが知るべきプライシング戦略も参考になります。

プロセス4：プロダクトやマーケティング戦略に反映する

得られた洞察をもとに、価値提供の方法を最適化します。ジョブが明確になっていれば、提供価値の言語化はぐっと楽になります。バリュープロポジションを書き直し、MVPやMSPとして最小構成で世に出し、反応を見る。この一連の流れはプロトタイプによる検証と組み合わせると回転が速くなります。

訴求文言にもジョブは効きます。製品スペックを並べる代わりに、顧客が置かれた状況をそのまま書く。「月末に承認待ちが溜まって困っていませんか」という一行は、機能一覧よりも早く相手の状況に届きます。状況を起点に打ち手を組み立てる考え方は、コンテクスト・マーケティングとしても整理されています。

JTBDでよくある3つの失敗

失敗1：ジョブの粒度が大きすぎる

「業務を効率化したい」「売上を上げたい」といったジョブは、間違ってはいませんが打ち手に結びつきません。粒度が大きすぎるジョブは、あらゆる製品が当てはまってしまうため、意思決定の役に立たないのです。

目安として、そのジョブが発生する具体的な瞬間を思い浮かべられるかを確認してください。思い浮かべられなければ、まだ抽象的すぎます。

失敗2：顧客の「要望」をそのままジョブと呼んでしまう

「CSV出力機能が欲しい」は要望であって、ジョブではありません。その背後には「経理システムに手入力せずに取り込みたい」というジョブがあり、さらに背後には「月末の残業を減らしたい」という状況があります。

要望のまま実装を続けると、機能は増えるのに満足度が上がらないという状態に陥ります。要望が出てきたら、それを使って何を片づけようとしているのかを最低2回は掘る習慣をつけてください。

失敗3：ジョブを見つけただけで満足してしまう

JTBDの分析は、それ自体が知的に面白いため、きれいなジョブ一覧ができた時点で終わってしまいがちです。しかしジョブは仮説にすぎません。市場規模はあるのか、自社がそのジョブを他社より上手に片づけられるのか、価格に見合うのか。この検証を通らなければ、事業にはなりません。

顧客の課題のうち、どれが本当に切実なのかを見極める視点はバーニングニーズで、そのうえでどこを最初に倒すかという順序の判断はセンターピン理論で補完できます。

他のフレームワークとの使い分け

JTBDは万能ではありません。他のフレームワークとの役割分担を整理しておきます。

• ペルソナ：誰に届けるかを決める。JTBDで「何を作るか」を決めた後、チャネルと訴求を設計する段階で使います
• カスタマージャーニーマップ：既存顧客の体験を可視化して改善点を探す。JTBDが「そもそもなぜ雇われたか」を問うのに対し、こちらは雇われた後の道のりを扱います
• バリュープロポジションキャンバス：JTBDと最も相性がよいフレームワークです。顧客側の「ジョブ・痛み・利得」を、自社の提供価値と突き合わせます
• デザイン思考：共感から始める点は共通しますが、JTBDは「状況」という再現可能な単位に落とし込むぶん、チーム間の合意形成に向いています

整理して言えば、JTBDは「何を作るべきか」という問いに答えるためのフレームワークです。「どう作るか」「どう届けるか」は別の道具に任せるほうが、それぞれの精度が上がります。

まとめ：JTBDを活用して、顧客の本当のニーズを掴もう

JTBDは、「顧客の視点から本当に解決したいことは何か」を考えるフレームワークです。市場分析や属性データだけでは見えない「ジョブ」を理解することで、より効果的なプロダクト開発やマーケティングが可能になります。

本記事の要点を振り返ります。

• 顧客は製品を買うのではなく、ジョブを片づけるために雇っている。うまく片づかなければ解雇される
• 競合は同業他社とは限らない。手作業も、外部委託も、「何もしない」も競合になる
• 2つの系譜がある。探索にはクリステンセン系、優先順位づけにはアルウィック系（ODI）が向く
• ジョブは解決策を含まない言葉で、状況が思い浮かぶ粒度で書く
• 顧客が動かない理由は、製品の魅力不足ではなく不安と惰性にあることが多い

特に、BizDevにおいては新規事業のアイデア発掘や市場開拓に直結する考え方です。顧客が本当に求めている価値を深く掘り下げ、競争優位性を築いていきましょう。BizDevという役割そのものについてはBizDev（ビズデブ）の仕事とは？もあわせてご覧ください。