ジョブ理論(JTBD)フレームワーク:実践入門
← 記事一覧 正しいものを作る

ジョブ理論(JTBD)フレームワーク:実践入門

FabricLoopチーム  ·  2026年5月  ·  6分で読めます

クレイトン・クリステンセンは、ミルクシェイクの売上を伸ばしたいファストフード企業の話をよくしていました。その企業は、味の好み、甘さ、カップのサイズについて顧客にインタビューしました。しかし何を変えても、売上は動きませんでした。そこで、ある研究者が別のアプローチを試みます。駐車場に立って、人々がミルクシェイクを買う様子を観察したのです。そして、たったひとつだけ質問しました。「今朝ミルクシェイクを買おうと決めたとき、何をしようとしていましたか?」

答えはこうでした。朝のミルクシェイク購入者の多くは、このあと長くて退屈な通勤が待っていたのです。退屈をしのぎつつ、昼食前にお腹が空かないものが欲しかったのでした。ミルクシェイクは、バナナ(食べ終わるのが早すぎる)、ベーグル(手が汚れる)、コーヒー(量が少ない)よりも、その役目をうまく果たしてくれました。ミルクシェイクが競合していた相手は、他のミルクシェイクではなく、退屈と空腹だったのです。

その話がジョブ理論(JTBD)の本質です。人はプロダクトを買うのではありません。自分の生活における「ジョブ(仕事)」を成し遂げるためにプロダクトを雇うのです。

「ジョブ」が実際に意味すること

JTBD用語では、「ジョブ」とは特定の状況で人が達成しようとしている進歩のことです。タスク(「ファイルを送りたい」)ではありません。目標(「もっと生産的になりたい」)でもありません。特定の人が特定の状況で達成しようとしている具体的な進歩です — その瞬間を取り巻くすべてのコンテキスト、制約、感情も含めて。

ジョブには3つの構成要素があります。状況(ニーズを生み出すトリガー)、動機(人が達成しようとしていること)、そして成果(彼らの視点から見た成功の定義)です。3つすべてが重要です。動機を掴んでいるが状況を無視しているプロダクトは、間違ったタイミングで使われます。状況を掴んでいるが成果を無視しているプロダクトは、雇われてもすぐに解雇されます。

「人が欲しいのは4分の1インチのドリルではありません。4分の1インチの穴です。でも本当に欲しいのは壁の棚です — そして真に欲しいのは、パートナーから有能だと思われることです。」

JTBDステートメントのフォーマット

正式なJTBDステートメントを書くことで、あなたのプロダクトが実際にどのようなジョブを担うために雇われているかが明確になります。また、ジョブが何であるかというあなたの思い込みと、ユーザーが実際に体験することとのギャップが明らかになります。

JTBDステートメントテンプレート + 例
「状況のとき、動機したい。それによって成果できるように。」
例1 — プロジェクト管理ツール
「退職した同僚からプロジェクトを途中で引き継いだとき、何が決定されていて、なぜそうなったかを把握したい。それによって6回もキャッチアップ会議を設定せずにすぐに状況を把握できるように。」
例2 — コミュニケーションツール
「一日中会議に入っている人から急ぎの回答がほしいとき、失礼にならずに緊急性が伝わるメッセージを送りたい。それによって関係を損なわずに、自分の作業を前に進められるように。」
例3 — アナリティクスツール
「来週、取締役会でプレゼンするとき、明確なストーリーが伝わる形でリテンションの推移を示したい。それによって進捗をアピールし、チームへの信頼を保てるように。」

各ステートメントが、機能一覧では決して見えてこないものを浮かび上がらせていることに注目してください。感情面で懸かっているもの、せめぎ合う要因という文脈、そしてユーザーの視点から見た成功の定義です。「どんな機能が欲しいですか?」というアンケートからは、このどれも出てきません。

機能的、社会的、感情的な側面

すべてのジョブには3つの側面があり、機能的な側面だけに取り組むプロダクトは本来生み出せる価値を取りこぼします。

Slackが成長したのは、メッセージ送信においてメールよりも優れていたから(機能的)ではありません。チームをよりつながっていて活き活きとした気持ちにさせた(感情的)から、そして個人がインボックスのキューではなくリアルタイムの会話の一部であると感じさせた(社会的)から成長しました。機能的なジョブだけに取り組む機能はコモディティ化されやすいです。3つの側面すべてに取り組むプロダクトははるかに置き換えがたいものです。

インタビューテクニック 感情的・社会的な側面を明らかにするには、他者についての言葉に耳を傾けてください。「上司に〇〇だということを示す必要があった…」「クライアントに〇〇だと思われたくなかった…」「チームが〇〇だと思ってしまうのが心配だった…」— これらのフレーズは、社会的・感情的なジョブが存在しているシグナルです。

プロダクトが雇われているジョブを発見する方法

最良のJTBDリサーチは、雇用の瞬間 — プロダクトを使い始める決断 — と解雇の瞬間 — 使用をやめる決断 — に焦点を当てます。どちらの瞬間もシグナルに富んでいます。

雇用インタビューでは、こう聞いてみてください。「最後に[プロダクト]を使い始めると決めたときのことを思い出してください。何が起きていましたか?何を達成しようとしていましたか?最初に他に何を試しましたか?」解雇インタビューでは、こう聞きます。「[プロダクト]の使用をいつやめましたか?乗り換えを決める直前に、何をしていましたか?代わりのものは、何がどう違っていましたか?」

答えはほぼ常にあなたを驚かせるでしょう。ユーザーはあなたのチームが想定したことのない状況、不満、動機を説明します。それこそが重要な点です。JTBDリサーチは検証リサーチではなく、発見リサーチです。仮説をテストするのではなく、仮説をエビデンスに置き換えるのです。

デモグラフィックの罠 JTBDは意図的に「35歳のマーケティングマネージャー」のようなデモグラフィックペルソナから、状況的なペルソナへとシフトします。同じデモグラフィックを持つ2人が全く異なるジョブを持つことがあります。デモグラフィック的に共通点のない2人があなたのプロダクトをまったく同じジョブのために雇っていることもあります。年齢や役割ではなく、ジョブでセグメントしてください。

プロダクトの意思決定にJTBDを使う

プロダクトが雇われている主要なジョブを特定したら、重要なプロダクト決定のすべてにフィルターとして使ってください。提案されたどの機能についても問いかけてください:この機能はユーザーがどの具体的なジョブで進歩するのを助けるか?答えが「主要なジョブのどれでもない」であれば、たとえその機能が魅力的に見えても、優先度を下げる強いシグナルです。

JTBDはまた、過剰サービスを行っている部分を明らかにします。ユーザーがすでに十分にこなせているジョブがある場合、そのエリアに機能を追加しても収穫逓減をもたらすだけです — さらには、異なるジョブを持つユーザーにとってプロダクトが使いにくくなる複雑さを加えてしまう可能性もあります。ジョブという視点は、どこに投資してどこで止めるべきかを示してくれます。

FabricLoopとJTBDのつながり FabricLoopは特定のジョブのために雇われています。全員を同じコミュニケーションスタイルに押し込めることなく、チームを連携させ続けることです。そのジョブには機能的、社会的、感情的な側面があります — それを理解することが、すべてのプロダクト決定を形作りました。私たちは新機能を評価する際に社内でJTBDステートメントを使用し、その基礎となるリサーチをチーム全体に可視化しています。

この記事から持ち帰るべき10のこと

  1. 人はプロダクトを買うのではなく、特定の状況で進歩を達成するために雇います。ジョブは常にタスクより大きいです。
  2. ジョブには3つの構成要素があります:状況(トリガー)、動機(達成しようとしていること)、成果(成功の定義)。
  3. JTBDステートメントのフォーマット — 「〇〇のとき、△△したい。それによって□□できるように。」— 機能一覧では絶対に生み出せない明確さを強制します。
  4. すべてのジョブには機能的、社会的、感情的な側面があります。機能的な側面だけに取り組むプロダクトはコモディティ化されやすいです。
  5. インタビューでは、他者についての言葉に耳を傾けてください。機能的なジョブよりしばしば重要な、社会的・感情的なジョブの存在を示すシグナルです。
  6. 最良のJTBDリサーチは雇用の瞬間(なぜ使い始めたか?)と解雇の瞬間(なぜ使うのをやめたか?)に焦点を当てます。
  7. JTBDリサーチは検証リサーチではなく発見リサーチです。すでに持っている考えを確認するのではなく、仮説をエビデンスに置き換えます。
  8. ユーザーをデモグラフィックではなく、達成しようとしているジョブでセグメントしてください。共通点のない2人が同じジョブを持つことがあります。
  9. 特定されたジョブを機能の意思決定のフィルターとして使用してください。機能が主要なジョブでの進歩を助けないなら、優先度を下げてください。
  10. JTBDは過剰サービスの領域も明らかにします — 機能を追加しても収穫逓減をもたらすか、複雑さを増してしまう領域です。