JTBD×デザイン思考 — 「片付けたい用事」から始める問題定義の統合アプローチ
Jobs To Be Done(JTBD)理論とデザイン思考を統合することで、より鋭い問題定義ができる。両フレームワークの相違点と補完関係を整理し、実務での組み合わせ方を具体的に示す。
Jobs To Be Done(JTBD)理論とデザイン思考を統合することで、より鋭い問題定義ができる。両フレームワークの相違点と補完関係を整理し、実務での組み合わせ方を具体的に示す。
「ユーザーはドリルを買いたいのではなく、穴を開けたいのだ」
Harvard Business Schoolのセオドア・レビットが述べたとされるこの言葉は、Jobs To Be Done(JTBD)理論の核心を端的に表しています。しかしワークショップでよく起こるのは、この言葉を知っていながら「ユーザーはどんな属性を持っているか」「どんな機能が必要か」という問いに戻ってしまうパターンです。
JTBD理論は、デザイン思考のユーザーリサーチ・問題定義フェーズを大きく強化できます。本記事では両フレームワークの相違点と補完関係を整理し、実務での組み合わせ方を具体的に示します。どちらかを捨ててどちらかを採る話ではありません。
JTBD(Jobs To Be Done)は、Clayton Christensenらが発展させた製品・サービス設計の理論です。核心的な主張は「人は製品を買うのではなく、人生のある文脈で片付けなければならない仕事(ジョブ)のために、製品を『雇用する』」というものです。
有名な事例を挙げます。McDonald’sがミルクシェイクの売上向上を研究した際、従来のアプローチ(性別・年齢・好みによるセグメンテーション)では有効な答えが得られませんでした。JTBDの視点でリサーチしたところ、朝のミルクシェイクの主要な購買者は「長い通勤時間を退屈せずに過ごしたい」というジョブのためにシェイクを購入していることが分かりました。競合はシェイクではなく、バナナや、ラジオの音楽でした。
この発見は、製品の「機能改善」ではなく「ジョブを解決する文脈の理解」から生まれます。
デザイン思考とJTBDは、目指すものは似ていますが、アプローチに明確な違いがあります。
デザイン思考: ユーザーを「特定の状況に置かれた具体的な人間」として捉えます。ペルソナで「34歳、東京在住、マーケター、子育て中」のような属性を定義し、共感インタビューでその人の感情・思考・行動を深く理解します。
JTBD: ユーザーを「状況の中でジョブを抱えている人」として捉えます。属性よりも「どんな状況で、どんなジョブが発生しているか」を重視します。「34歳のマーケター」という属性よりも「締め切り前夜に、資料作成が行き詰まっている状況」という文脈が設計の起点になります。
デザイン思考: 「ユーザーが感じていること・思っていること・行動していること」を観察・インタビューで収集し、インサイトに変換します。共感フェーズでは感情的・文化的な側面を重視します。
JTBD: 「ユーザーが解決しようとしているジョブは何か」を、行動の変化点(スイッチングインタビュー)から特定します。「なぜ以前の解決策をやめて、新しいものを選んだか」という購買・利用の変化点が最も重要な情報源です。
デザイン思考の問題定義フェーズでは「How Might We(HMW)」文を使います。JTBDの視点を加えると、HMWの質が変わります。
JTBDなしのHMW:「どうすれば田中さん(34歳・マーケター)が資料作成をより効率的に行えるか?」
JTBDありのHMW:「どうすれば締め切り直前に行き詰まった状況の人が、短時間で突破口を見つけられるか?」
後者はソリューションの幅が広がります。対象は「マーケターのツール」ではなく「行き詰まった状況を突破するあらゆる手段」になります。
JTBDが「購買・利用の状況文脈」を重視することは、デザイン思考の共感フェーズを補強します。
ユーザーインタビューでJTBDの問い方を使うと、より具体的な文脈情報が得られます。「このサービスを最後に使ったとき、その直前に何をしていましたか?」「使い始めたのはどんなきっかけでしたか? その直前、どんな状況でしたか?」
実際にやってみると、この「直前に何をしていたか」という問いが、ユーザーが置かれた状況の鮮明な描写を引き出します。抽象的な「不満」ではなく、具体的な「状況」が可視化されます。
JTBDのスイッチングインタビューは、デザイン思考のユーザーリサーチに強力な手法を提供します。
スイッチングインタビューは「以前やっていたことをやめて、今やっていることに変えた体験を話してもらう」インタビューです。変化の瞬間には、ジョブと解決策の関係が最も鮮明に現れます。
例:「3ヶ月前にタスク管理ツールをAからBに変えたと聞きました。変える直前、どんな状況でしたか? 何が最後の一押しになりましたか? 変えた後、どんな変化がありましたか?」
この問いから「ツールの機能の比較」ではなく「どんな状況でジョブが発生し、どんな解決策を選んだか」という設計に直結するインサイトが得られます。
リサーチを始める前に「このユーザーセグメントが抱えているジョブは何か」の仮説を、チームで書き出します。「機能的ジョブ(達成したいこと)」「感情的ジョブ(感じたいこと)」「社会的ジョブ(見られたいこと)」の3分類を使うと整理しやすい。
既存ユーザーと、最近競合サービスに乗り換えたユーザーにスイッチングインタビューを実施します。「変化の瞬間」の状況を詳細に記録します。
スイッチングインタビューで特定した重要な状況に対して、共感インタビューを実施します。「そのとき、どんな気持ちでしたか?」「頭の中で何を考えていましたか?」という問いで、感情的・社会的ジョブを掘り下げます。
POV文を「ユーザー属性」ではなく「状況×ジョブ」を起点に書きます。「[状況]に置かれた人は、[ジョブ]を片付ける手段を必要としている。なぜなら[感情的・社会的ジョブ]があるからだ」
特定したジョブを起点に「どうすればこのジョブをより良く解決できるか」というHMWを設定します。ジョブを起点にするとソリューションの幅が広がり、既存のカテゴリに縛られない発想が生まれやすくなります。
JTBDは強力ですが、「ジョブ」で割り切れない行動があります。
アートや音楽への没頭、ブランドへの愛着、ゲームに費やす5時間——これらを「片付ける仕事」で説明するのは、少し無理がある。デザイン思考の共感フェーズが重視する「感情・文化・物語」の次元は、JTBDの機能的合理性では捉えきれません。
JTBDが得意なのは「なぜその製品を選んだか」の説明。デザイン思考が得意なのは「その人がどんな体験を生きているか」の理解。この差を知って使うと、両者の組み合わせが格段に鋭くなります。