Jobs-to-be-Done の限界——文脈依存性と顧客理解の盲点
フレームワーク

Jobs-to-be-Done の限界——文脈依存性と顧客理解の盲点

JTBDは正しい。しかし「ジョブを特定した」という確信が、顧客理解を逆に浅くするメカニズムがある。文脈依存性・社会的動機・コンテキスト・スイッチングの3軸から、Christensen理論の構造的限界と実務的な補完策を解析する。

JTBD Jobs-to-be-Done Christensen 顧客理解 フレームワーク 新規事業

E-E-A-T 情報開示

Expertise: Jobs-to-be-Done理論の原典(Christensen et al., 2016; Ulwick, 2005)および批判的研究(Klement, 2016)を軸に構成。理論の構造的前提と実務適用のギャップを体系的に分析。

Experience: toC・toB・B2G 各領域での適用失敗事例を検証。JTBD活用プロジェクトにおける「ジョブ特定後の意思決定ミス」パターンを3件収録。

Authority: Christensen, Clayton M., Taddy Hall, Karen Dillon, and David S. Duncan (2016). Competing Against Luck. HarperBusiness. / Ulwick, Anthony (2005). What Customers Want. McGraw-Hill. / Klement, Alan (2016). When Coffee and Kale Compete. Independently published.

Trustworthiness: JTBDの有効性そのものを否定する主張ではない。理論が正しいからこそ、誤用が生じやすい構造を明示することが本稿の目的。


ジョブを特定したとき、理解が止まる

Jobs-to-be-Done(以下JTBD)を学んだチームが陥る典型的なパターンがある。顧客インタビューを重ね、ユーザーが「何のためにこの製品を使っているか」を丁寧に掘り下げ、「ジョブステートメント」を作成する。そしてそのジョブが「正しい」と確信した時点で、顧客への問いかけが止まる。

「ジョブを特定した」という確信が、顧客理解のそれ以上の深化を妨げる。 これがJTBDの最も見落とされやすい機能的限界だ。

理論は正しい。顧客は製品を買うのではなく、片付けたい用事(ジョブ)のために製品を雇う——このClaytonクリステンセンの洞察は、プロダクト開発における本質的な発想転換をもたらした。問題はその理論が、適用の段階で構造的な盲点を生み出すことにある。本稿では文脈依存性・社会的動機・コンテキスト・スイッチングの3軸から、JTBDの限界を解体する。


JTBD理論の設計思想と前提条件

Christensenが解こうとした問い

クリステンセンがJTBDを体系化した背景には、従来の市場細分化への根本的な不満があった。年齢・性別・所得・地域でセグメントされた顧客像は、「誰が買うか」を記述するが「なぜ買うか」を説明しない。

2016年の著書 Competing Against Luck の冒頭で、クリステンセンはミルクシェイクの事例を提示する。朝の通勤途中にミルクシェイクを購入する顧客のジョブは「空腹を満たすこと」ではなく「長い退屈な通勤時間を乗り切ること」だった。この洞察は、製品の機能改善の方向を根本的に変える。顧客が製品を雇う理由(ジョブ)を理解すれば、競合は想定外の解決策になりうる。

アンソニー・ウルウィック(Anthony Ulwick)はこれをさらに形式化し、「アウトカム駆動型イノベーション(Outcome-Driven Innovation)」として展開した(Ulwick, 2005)。ジョブを機能的・感情的・社会的の3層で定義し、顧客が最も「満たされていない」アウトカムを定量的に特定する手法だ。

理論の前提:ジョブは安定的である

JTBDの機能は一つの前提に依存している。ジョブは時間を超えて比較的安定的であるという仮定だ。 ミルクシェイクのジョブ(通勤時間をやり過ごす)は、顧客が替わっても、季節が替わっても、基本的に変わらない——という想定のもとに、「普遍的なジョブを特定せよ」という方向性が導かれる。

この前提が崩れる局面がある。文脈が変わると、同じ「ジョブ」と名付けられた行動が、全く異なる解決策を求めるようになる場面だ。


3つの構造的限界

限界1:文脈依存性の軽視

最初の限界は文脈依存性(Context Dependency)だ。同じジョブであっても、文脈が変わると顧客が求める解決策は根本的に異なる。

事例(toC): あるフードデリバリーサービスが、ユーザーインタビューから「夜の食事を手間なく準備するジョブ」を特定した。このジョブに対して、デリバリー時間の短縮と品揃えの拡充を強化した。しかし解約率の分析では、解約ユーザーの最大グループが「平日の残業後の帰宅時」ではなく「週末の家族での食事」文脈で使っていた層だった。週末の家族食のジョブは「手間の省略」ではなく「一緒に選ぶ体験の共有」にあり、品揃えの拡充はむしろ選択の複雑さを増やしていた。

ジョブは同じ「食事準備の簡便化」と名付けられていても、文脈(平日残業後 vs. 週末家族)によって達成の定義が変わる。JTBDのフレームワークは、このジョブ内の文脈変動を捉える構造を持たない。

アラン・クレメント(Alan Klement)は2016年の著作 When Coffee and Kale Compete でこの問題を指摘し、ジョブには「フォース(Force)」——プッシュ(現状への不満)・プル(新しい解決策への引力)・不安・惰性——の4つの力が絡み合うと主張した。しかしクレメントのモデルも、文脈そのものをどう体系化するかの手法論は提供していない。

限界2:社会的動機の不可視化

第2の限界は社会的動機(Social Motivation)だ。JTBD理論は機能的・感情的・社会的の3層でジョブを定義するが、実務上は機能的ジョブへの注目が偏りやすい。

事例(toB): 中堅製造業向けのSaaS型生産管理システムの導入提案で、「製造ラインの可視化と在庫最適化」というジョブを特定した。製品改善の投資を可視化機能の強化に集中させた結果、同等の機能を持つ競合製品への乗り換えが起きた。実際の意思決定プロセスを追うと、購買決定者(工場長)の最大の関心は「経営会議で自部門の改善を数値で示せるか」にあった。機能的ジョブ(在庫最適化)より社会的ジョブ(組織内での自己正当化)が意思決定を支配していた。

B2B購買でこの傾向は特に強い。購買者の社会的ジョブ——社内政治、評価懸念、リスク回避の意図——はインタビューで直接表明されにくく、機能的ジョブの記述に隠れる。

限界3:コンテキスト・スイッチングへの無防備

第3の限界はコンテキスト・スイッチング(Context Switching)だ。顧客が同じ製品を使い続けながら、使用文脈が徐々に変化し、いつの間にか別のジョブのために製品を雇い直している状態だ。

事例(B2G): 自治体向け住民サービスプラットフォームの設計で、「窓口手続きのデジタル化」ジョブを特定した。当初の主要ユーザーは窓口業務の効率化を求める担当者層だった。しかし導入から2年後、実際の利用ログを分析すると、利用の主軸が「市民の手続き利便性」から「行政部門間のデータ連携・引き継ぎ」に移行していた。システムの「雇われ方」が変化したにもかかわらず、プロダクトロードマップは当初のジョブ定義に固定されていた。

ジョブは最初に定義した時点で固定されるものではない。製品の普及とともに使われ方が進化し、新しい文脈でジョブが再定義される。この動的なジョブの変化を定期的に問い直す仕組みを、JTBDは理論として内包しない。


補完:JTBDの限界を越える3つのアプローチ

JTBDの限界を認識したうえで、どう補完するか。3つの手法が実務上有効だ。

アプローチ1:使用文脈の明示的なマッピング

ジョブステートメントに文脈変数を付加する。「いつ・どこで・誰と・どんな感情状態で」という4変数をジョブ定義に組み込む。例えば「通勤時間を乗り切る(月曜朝・電車内・一人・軽い憂鬱状態)」と「通勤時間を乗り切る(金曜夜・電車内・一人・解放感)」は、同じジョブ名を持ちながら、求める解決策が異なる。文脈を明示することで、ジョブ内の変動性が可視化される。

実務的には、ユーザーインタビューのプロトコルに「前後の文脈」を掘り下げるシークエンスを組み込む。「その時、直前に何をしていましたか?」「その後どうなることを期待していましたか?」という問いかけが、文脈データを引き出す。

アプローチ2:社会的ジョブの明示的な調査

B2Bコンテキストでは、購買意思決定者へのインタビューに「社内でこの決定をどう説明しますか?」「反対意見はどこから来ますか?」という問いを意図的に含める。これにより、機能的ジョブの背後にある社会的動機が浮上する。

顧客発見の神話でも指摘されているように、顧客が「発言すること」と「行動すること」の乖離は、社会的ジョブが機能的ジョブの言語で語られる場面で特に大きくなる。両者を別のインタビュー設計で分けて調査することが有効だ。

アプローチ3:定期的なジョブ再評価サイクルの設計

プロダクトロードマップのサイクルと連動した「ジョブ再評価セッション」を四半期に1回設ける。製品の実際の利用ログ・チャーン分析・サポート問い合わせのパターンを起点に、「現在の顧客は何のためにこの製品を雇っているか」を定期的に問い直す。

ジョブは静的な発見物ではなく、動的に更新すべき仮説だ。 初期定義を「変えてはならない正解」として扱うことが、コンテキスト・スイッチングへの無防備さを生む。


JTBDは廃棄すべきか

答えは否だ。JTBDは顧客理解の出発点として依然として有効な視座を提供する。機能・スペック・属性から「なぜ使うか」へと問いの軸を移す発想転換は、製品設計の根本的な方向性を変える。

問題はJTBDの誤りではなく、JTBDの完成だ。 ジョブを特定した時点で顧客理解が完了したと誤解することが、理論の最大の限界を生み出す。文脈依存性・社会的動機・ジョブの動的変化——これらをジョブの定義に組み込む補完的アプローチが、JTBDの実務的価値を維持する。

デザイン思考のローカル最適化問題と構造的に共通している。フレームワークへの信頼が、フレームワークの外側への問いかけを止める。理論の精度を上げるには、理論の前提条件を問い続けることが必要だ。


実務チェックリスト:JTBDを補完する問い

ジョブを特定した後に使う確認リスト。

  • このジョブの定義は、特定の使用文脈を前提としていないか?
  • 同じジョブが異なる文脈で異なる解決策を求める場面はないか?
  • 機能的ジョブの背後に、社会的ジョブ(自己正当化・承認・リスク回避)が隠れていないか?
  • 6ヶ月前のジョブ定義を、現在の利用ログと照合したか?
  • 製品の普及とともに「雇われ方」が変化しているサインはないか?

JTBDは顧客理解の終点ではなく、より深い問いを発する出発点だ。 その用い方を正しく理解することが、フレームワークの限界を実務的に超える唯一の方法となる。

荒井宏之 / INNOVATION VOYAGE

関連記事