2026.09.17 Webマーケティング施策

ジョブ理論とは？顧客が片づけたい用事の捉え方と機能要件への落とし方

ジョブ理論とは、顧客は製品を買っているのではなく、ある状況で片づけたい用事（ジョブ）のために製品を「雇っている」と捉え直す枠組みです。提唱したのはハーバード・ビジネス・スクールのクレイトン・クリステンセンら。年齢や業種といった属性ではなく、購入の直前に何が起きたのかを問うため、競合の範囲も訴求の置き方も変わります。この記事の前半で整理するのは、定義と3層のジョブ、購買を動かす4つの力、ジョブ記述の書式とインタビュー設計です。後半は、見つけたジョブをサイトや業務システムの機能要件へ変換する手順と、ジョブ理論を使わない方がよい条件を扱います。

まとめ：ジョブ理論で決まるのは機能ではなく顧客が進みたい方向

ジョブとは「ある状況で人が遂げたい進歩」です。製品は、その進歩のために一時的に雇われ、より良い候補が現れれば解雇されます。
属性で顧客を括る枠組みとは問いが違います。ペルソナが「誰が買うか」を描くのに対し、ジョブ理論は「なぜその日、その瞬間に買ったか」を扱います。
ジョブは機能的・感情的・社会的の3層で同時に働きます。機能だけを満たした製品が売れない理由は、この2層目と3層目の取りこぼしにあります。
ジョブを言語化するときは、解決策の名前を含めない書式にします。「移動中の退屈をしのぐ」は使えますが、「ミルクシェイクを飲む」は使えません。
発注の現場で効くのは、ジョブを画面・通知・データ項目に変換する段です。ここを飛ばすと、調査報告書だけが残って製品は変わりません。
規制や仕様で解が固定されている領域、ジョブの範囲を広げすぎて競合が無限になる場面では、別の枠組みに切り替えた方が早く進みます。

ジョブ理論の定義と提唱者、ニーズ・ペルソナとの違いが生む視点の転換

用語の輪郭を先に固めます。ジョブ理論は英語で Jobs to Be Done、略してJTBDと書かれます。日本語では「片づけるべき用事」「顧客が雇う理由」といった訳が併用され、表記が揺れやすい枠組みです。

ジョブの定義「特定の状況で人が遂げたい進歩」と雇用・解雇の比喩

ジョブ理論でいうジョブは、作業や職業のことではありません。ある特定の状況に置かれた人が「前に進みたい」と思う、その進歩そのものを指します。Christensen Instituteの理論ページは、この理論を「人や組織を意思決定へ向かわせる、あるいは遠ざける状況と力を明らかにするレンズ」と説明し、機能的・社会的・感情的な側面を露わにする点を従来型の市場分析との違いに挙げています。

雇用と解雇の比喩が使われるのは、製品と顧客の関係が固定的でないからです。顧客は進歩のために製品を雇い、進歩が得られなければ解雇して別の候補に切り替えます。ブランドへの忠誠心ではなく、その場の状況が選択を決めるという捉え方が、この比喩の意味です。理論の骨格を広めた論文は、クレイトン・クリステンセン、タディ・ホール、カレン・ディロン、デイビッド・S・ダンカンによるKnow Your Customers’ “Jobs to Be Done”（Harvard Business Review 2016年9月号）で、日本では2017年8月刊の書籍『ジョブ理論イノベーションを予測可能にする消費のメカニズム』とあわせて読まれています。

ニーズ・ペルソナとの違いは「誰が買うか」でなく「なぜ今か」の問い

ニーズという言葉は便利ですが、粒度が粗くなりがちです。「健康になりたい」「業務を効率よく回したい」という水準の記述は方向を示すだけで、なぜ他社ではなくこの製品を、なぜ今月選んだのかを説明できません。ジョブ理論は、そこに状況（いつ・どこで・何が起きた直後か）を足して、購買の引き金まで含めて記述します。

属性で描く枠組みとの関係も整理しておきます。ペルソナマーケティングの手順は「誰が買うか」を具体化し、施策の伝え方を揃えるために働きます。ジョブ理論は「なぜその瞬間に買ったか」を扱うため、両者は排他ではありません。属性の似た顧客が別々の理由で同じ製品を選んでいるとき、ペルソナだけでは訴求が当たらず、ジョブ側からの定義が必要になります。

観点	ニーズ	ペルソナ	ジョブ理論
主な問い	何が欲しいか	誰が買うか	なぜ今買ったか
記述の単位	欲求・不満	人物像	状況と進歩
競合の範囲	同カテゴリ中心	同属性の利用先	代替手段すべて
向く場面	方向づけ	伝え方の統一	製品の再定義
弱点	粒度が粗い	購入理由が薄い	調査コストが高い

3つを競わせる必要はありません。市場や競合の全体像を押さえる段では3C分析で事業環境を読む手順が効き、顧客の切り分けにはSTPが効きます。枠組み同士の並びと使う順番はマーケティングフレームワークの一覧と使い分けに整理しています。

機能的・感情的・社会的の3層と、購買を動かす4つの力の見取り図

ジョブは単層ではありません。同じ購買行動の裏側で、3つの層が同時に動いています。層の取りこぼしが、そのまま売れない理由になります。

3層のジョブが同時に働く例と、機能だけ満たした製品が外れる理由

機能的ジョブは実務的な用件です。Christensen Instituteは、機能面の例として広さやサイズといった実用条件を挙げ、社会面は家族や近隣との関係、感情面は世話をする感覚や達成感として説明しています。社内システムに置き換えると、こうなります。機能的ジョブは「月末の集計を今日中に終える」、感情的ジョブは「差し戻しで責められる不安を消す」、社会的ジョブは「経理として仕事が早いと見られる」。

3層をそろえないと、機能で勝っていても採用されません。承認画面の項目を削って入力を速くしたのに使われない、という現象はここで起こります。速さという機能的ジョブは満たしていても、「誰の承認を経たか後から示せる」という社会的ジョブを削ってしまったからです。設計判断としては、削る対象を決める前に、その項目が3層のどれを支えているかを確認する順序になります。

4つの力（プッシュ・プル・不安・惰性）で乗り換え時の抵抗を読む

ジョブが存在しても、人は簡単には乗り換えません。この抵抗の読み解きには、Forces of Progress（進歩を促す力）と呼ばれる整理が使われます。乗り換えを進める2つの力と、押しとどめる2つの力の組み合わせです。

プッシュ：現状への不満。「毎月3日残業している」など、現在の解を押し出す圧力です。
プル：新しい解の引力。「自動で突合される」という期待が、乗り換え先へ引き寄せます。
不安：切り替えそのものへの恐れ。移行の失敗、データの欠落、学習の負担が含まれます。
惰性：今のやり方への執着。慣れたExcelの操作手順を手放したくない、という抵抗です。

商談が止まる場面の多くは、プルの不足ではなく不安と惰性の側にあります。機能を足しても決まらない案件で効くのは、移行手順の可視化、旧データの並行運用期間、操作画面の見た目を旧システムに寄せる配慮といった、抵抗を削る設計です。提案書に機能一覧を積み増す前に、この2つの力を数える方が近道になります。

ミルクシェイク事例が示す、競合範囲がカテゴリ外へ広がる読み替え

ジョブ理論の説明で必ず引かれるのが、ファストフード店のミルクシェイクの事例です。有名すぎて要約だけが流通していますが、実務に効くのは結論ではなく、調査の視点を切り替えた手順の方です。

朝と午後で同じ商品が別のジョブに雇われる、需要の二重構造の読み方

Christensen Instituteの説明では、朝のミルクシェイクは空腹をしのぎ、運転を退屈でなくし、片手で持てる食べ物として雇われていました。午後になると、同じ商品が子どもへのご褒美という別のジョブで雇われます。買っている人が同じでも、ジョブが違えば求める条件も同じではありません。朝は飲み終わるまで時間がかかる濃さが利点になり、午後の親子連れには、その濃さが待ち時間という欠点に変わります。

この二重構造は、Webサイトの数字にもそのまま現れます。同じ料金ページに、比較検討の初期段階で概算を知りたい人と、社内稟議のために正式な金額根拠を取りに来た人が混在している状態です。ページの平均滞在時間を眺めても分かりません。流入時刻、参照元、直前に見たページを合わせて見ると、二つの流れとして分離できます。

競合がバナナやベーグルに変わるとき、比較軸をどこへ置き直すのか

朝のジョブで競合になっていたのは、他店のシェイクではなくバナナやベーグルでした。ジョブを軸に置いた瞬間、競合はカテゴリの外へ広がります。BtoBでも同じことが起きます。業務システムの競合は同種のパッケージだけでなく、Excelの手作業、派遣スタッフの増員、そして「何もしない」という選択肢です。

比較軸の置き直しは、次の順で進めると具体になります。第一に、顧客が今そのジョブをどう片づけているかを列挙する。第二に、その方法が抱える不満を金額と時間に換算する。第三に、自社の解がその不満をいくら減らすかを示す。無消費（今は何もしていない状態）を競合として数える視点が、この作業の肝です。市場規模を既存カテゴリの売上から見積もると、この層がまるごと抜け落ちます。

ジョブ記述の書式と、購入直前の状況を掘り出す質問設計の組み立て

ジョブ理論が現場で空回りする原因は、たいてい記述の粒度にあります。書き方の型と、材料を集める聞き方を先に決めておきます。

解決策を含めないジョブ記述の型と、成果指標を50〜150個に分解

ジョブ記述は、解決策の名前を含めない形（solution-free statement）で書きます。JTBDを実践手法に落とした Outcome-Driven Innovation を提唱するStrategynは、同社のJobs-to-be-Done解説ページで「木材をまっすぐ切る」「患者のバイタルサインを監視する」といった記述例を示しています。動詞＋目的語＋文脈で書き、製品名やカテゴリ名を入れないのが要点です。

同ページによれば、Tony Ulwick氏がJTBDを概念化したのが1990年、最初の大きな成果がCordis社での1992年、手法をODIと命名したのが1999年とされています。一つの市場には測定可能な成果指標（desired outcome）が50から150ほど含まれるとし、この分解を経た製品開発の成功率を86%、業界平均を約17%とするのが同社の説明です。数値は同社が自社手法について公表しているもので、第三者の検証値ではない点を踏まえて読む必要がありますが、「ジョブを100前後の測れる粒度まで割る」という作業量の目安としては参考になります。

実務では、いきなり150個は現実的ではありません。主要なジョブを3つに絞り、各10から15個の成果指標へ分解するところから始めると、1週間程度で仮説の骨組みができます。

インタビューで買った理由でなく、買う前の出来事を時系列で聞く設計

「なぜ買いましたか」と尋ねると、後から整えた理由が返ってきます。ジョブを掘るインタビューで取るのは、購入という一点ではなく、その前後の時間を追う形式です。質問の順序は、購入日の特定から始めて時間を巻き戻す流れが扱いやすくなります。

導入を決めた日と、その日に社内で何が起きたかを確認する
検討を始めた最初のきっかけ（プッシュ）が発生した時期まで遡る
比較した候補を、製品以外の代替手段まで含めて挙げてもらう
採用を止めかけた瞬間と、その理由（不安・惰性）を聞く
導入後、以前のやり方をどの範囲で残しているかを確かめる

5番目の質問が効きます。旧来の手順が残っている範囲は、新しい解が片づけ損ねたジョブがどこにあるかをそのまま示す手がかりです。聞き取りで得た仮説は、そのまま製品化せず小さく試して確かめます。検証の設計はテストマーケティングの手法と撤退基準の考え方と合わせると、撤退ラインを先に決めた形で進められます。

ジョブ記述をシステムの機能要件へ変換する、受託開発現場での手順

ここからが、競合記事がほとんど扱わない領域です。ジョブを見つけても、画面・通知・データ項目に翻訳されなければ製品は変わりません。発注側と開発側の間で、この変換をどう分担するかを決めます。

ジョブから画面と通知を決める、要件定義の突き合わせ表の組み立て

変換の作業は、1行1ジョブの表に落とすと迷いません。列は「ジョブ記述／状況の引き金／今の代替手段／成果指標／必要な画面・通知／測る数値」の6つを置きます。たとえば「月次請求の差し戻しをゼロにする」というジョブなら、引き金は月初3営業日の締め、代替手段は目視のダブルチェック、成果指標は差し戻し件数と確認にかかる分数、必要な機能は入力時の警告表示と承認者への通知、測る数値は差し戻し率になります。

この表があると、機能の取捨が議論しやすくなります。どの機能も、いずれかのジョブと成果指標に紐づいていなければ落とす候補です。逆に、ジョブはあるのに機能が空欄の行は、要件の抜けです。サイト側の改修でも同じ表が使えます。料金ページに二つのジョブが混在しているなら、概算を知りたい流れと稟議用の根拠を取りに来た流れで、出すコンテンツと次の導線を分けます。サイト構造と集客の設計から相談する場合は、Webマーケティング戦略の支援で扱える範囲は、ジョブの整理から画面と計測の設計までの一連の作業です。

発注側が要件を持つ体制と、IPAが挙げる128の勘どころとの接点

ジョブを知っているのは、ベンダーではなく業務を回している人です。この構図は、要件定義の責任分担の議論と重なります。IPAが2019年12月20日に公開したユーザのための要件定義ガイド第2版は、副題に「要件定義を成功に導く128の勘どころ」を掲げ、システムの要件を定義する責任は構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあるとし、業務部門が主体的に関与するスタイルへの変革を背景に挙げています。

ジョブ記述は、その主体的な関与を成立させる材料になります。「この画面が欲しい」という要望の形だと、なぜ必要かが伝わらず、開発側は言われた通りに作るしかありません。「どの状況で、何を前に進めたいか」で渡されれば、実現手段の提案が可能になります。発注側が用意するのは前述の表の左3列、開発側が埋めるのは右3列、という分担が現実的です。会議の1回目で左3列を共有できていれば、要件定義の往復は目に見えて減ります。

ジョブ理論を採用しない方がよい場面と、実務で失敗する使い方の型

どの枠組みにも守備範囲があります。先に示すのは、ジョブ理論が向かない場面です。ここは玉虫色にせず、条件を付けて言い切ります。

規制や仕様が固定の領域でジョブから発想しない判断の線引きと根拠

法令や業界仕様で手順が固定されている領域では、ジョブ理論から入りません。電子帳簿保存法の要件を満たす保存機能、医療情報システムの安全管理ガイドラインに沿ったアクセス制御、インボイス制度の記載事項。これらは「顧客が片づけたい用事」を掘っても答えが変わらず、準拠すべき条文と仕様が先に立ちます。この領域でジョブインタビューに時間を使うのは、順序として誤りです。

判断の線引きは、「解が外部要件で一意に決まるか」で引きます。一意に決まるなら仕様準拠の作業、複数の解がありうるならジョブから発想する。同じプロジェクトの中でも、請求データの保存要件は前者、請求内容を確認する画面の作りは後者、という具合に混在します。全体をどちらか一方の流儀で押し通そうとすると、規制側は抜け、体験側は硬直します。

ジョブを広げすぎて競合が無限になる、抽象化のやりすぎという失敗パターン

もう一つの典型が、ジョブの抽象度を上げすぎる失敗です。「時間を節約する」「安心を得る」まで広げると、ほぼすべての製品が競合になり、施策が決まりません。ジョブ記述には状況を必ず含める、という制約がここで効きます。「月初3営業日の締め処理で、差し戻しを出さずに終える」なら、比較対象も打ち手も具体に定まります。

加えて、聞き取りの人数を増やせば精度が上がるという誤解も見かけます。ジョブの発見は統計ではなく構造の把握なので、同じジョブの語りが3人目、4人目で繰り返され始めたら、その仮説は一度止めて検証に回した方が早く進みます。100人の定量調査で属性別の集計を作っても、状況の記述は得られません。調査票を配る前に、5人から10人の時系列インタビューを終えておく順序をすすめます。

よくある質問

ジョブ理論について、検討の現場でよく挙がる質問を5つ取り上げます。

ジョブ理論とニーズの違いは何ですか？

ニーズは「何が欲しいか」を示す欲求の記述で、方向づけには使えますが、購入の引き金までは説明しません。ジョブ理論は「どの状況で、何を前に進めたかったか」を記述するため、いつ買うか、何と比較されるかまで含めて扱えます。たとえば「業務を速くしたい」はニーズ、「月初3営業日の締めで差し戻しを出さずに終えたい」はジョブです。後者からは、警告表示や通知といった具体的な機能が導けます。

ジョブ理論のミルクシェイクの事例は何を示していますか？

同じ商品が、時間帯によって別のジョブで雇われていたという発見です。朝は長い通勤の退屈をしのぎ片手で持てる食べ物として、午後は子どもへのご褒美として選ばれていました。ジョブが違えば求める条件も競合も変わり、朝の競合は他店のシェイクではなくバナナやベーグルでした。商品カテゴリの内側だけを見て競合を数えていると、需要の構造を読み違えるという教訓になります。

ジョブ理論はBtoBの受注活動でも使えますか？

使えます。BtoBでは購買に複数の関係者が関わるため、担当者・承認者・経営層でジョブが分かれる点に注意が必要です。担当者の機能的ジョブが「作業時間を減らす」でも、承認者の社会的ジョブは「稟議で説明できる根拠を持つ」になります。提案書に載せるべき内容も、このジョブの分岐に応じて変える必要があるのです。商談が止まった案件では、機能の不足より、承認者側のジョブが空欄になっているケースが目立ちます。

ジョブ理論のインタビューは何人に聞けばよいですか？

人数より、聞く相手の選び方と質問の順序が結果を左右します。直近3か月以内に実際に購入・導入を決めた人を対象に、5人から10人の時系列インタビューを行うところから始めると、主要なジョブの輪郭を掴むことが可能です。3人目、4人目で同じ構造の語りが繰り返され始めたら、そこで一度止めて検証に移ります。属性別の集計が必要な場面では、ジョブ仮説を立てた後で定量調査を設計する順序にします。

ジョブ理論とペルソナはどちらを先に作るべきですか？

製品やサービスの定義を見直す段ではジョブが先、伝え方や表現を揃える段ではペルソナが先です。属性の似た顧客が別々の理由で同じ製品を選んでいるとき、先にペルソナを固めると理由の違いが潰れてしまいます。逆に、ジョブが定まった後の広告文やLPの制作では、語り口を統一する道具になるのがペルソナです。両方を作る場合も、ジョブ記述を先に確定させてから人物像を肉付けする順番が扱いやすくなります。