Jobs to be Done（JTBD）は、ユーザーがあるプロダクトを選ぶとき、「どのような進歩（進展）を遂げようとしているのか」を問いかけます。その答えには、その選択を必要とした状況や利用可能な代替手段、そしてその人にとって重要な実務的・感情的・社会的な影響が含まれます。

クリステンセン研究所の解説では、プロダクトは進歩を後押しするために「雇用（採用）」されるものとして捉えられています。これにより、顧客の属性を無視することなく、単なる機能リストの枠を超えて目を向けられるようになります。

実際の意思決定のプロセスを時系列でたどる

スプレッドシートから請求書発行ソフトウェアへの移行を考えている、ある中小企業のオーナーを例に挙げてみましょう。ここで役立つ問いは、単に「どの機能が好みか」ではありません。リサーチでは、ツールの検討を始めるきっかけとなった支払いの遅延、督促にかかった手間、検討された選択肢、そして新しい支払いフローがクライアントにとって不便になるのではないかという懸念などを探求することになります。

直近の意思決定の順序を尋ねてみてください。探し始める前に何が起きていたのか？ なぜこれまでのやり方では不十分になったのか？ 他に誰が関わっていたのか？ 変化を阻みそうになった要因は何だったのか？ 半構造化インタビューを行えば、参加者間で比較可能な範囲をカバーしつつ、そうした細かな文脈を柔軟に掘り下げることができます。

時系列を把握することで、「魅力的に見える機能」と「行動を起こす決定打となった理由」を区別しやすくなります。デモ画面ではダッシュボードに目を奪われたとしても、最終的に乗り換える決め手となったのは、わかりやすいリマインドを送信できる機能だった、といったことです。

プロダクトを決めつけずに、成し遂げたい「進歩」を描く

有用なジョブステートメントは、置かれた状況と目指す進歩を結びつけます。請求書の例でいえば、「支払いが何件も滞っているとき、各クライアントにすでに何を伝えたかを見失わずにフォローアップしたい」という表現なら、多様な解決策の余地が残されます。一方、「自動リマインド機能が欲しい」としてしまうと、すでに特定の解決策を1つ選んでしまっています。

ただし、実用的な価値が失われるほど表現を広げすぎないようにしてください。「コントロールできている感覚を持ちたい」というのは感情面でのニーズを捉えているかもしれませんが、リサーチでは、その状況において「コントロール」が具体的に何を意味し、それを本人がどう認識するのかまで明らかにする必要があります。

競合する選択肢には、他のプロダクトだけでなく、手作業での対応、誰かに頼むこと、あるいはタスクそのものを先送りにすることも含まれます。提案する体験が「何を改善すべきなのか」を形づくるのはこうした代替手段であるため、これらもリサーチの対象に含めるべきです。

得られたストーリーをもとに、解決策を比較検討する

明確になったジョブは、コンセプトテストやポジショニング、何を開発すべきかの判断に役立ちます。例えばチームで、リマインドのワークフローと支払い状況の共有ビューを比較し、それぞれがユーザー体験のどの部分を解決するのかを検討できます。

JTBDそれ自体は、市場規模を測定したり、その状況に置かれた人がどれくらいいるかを特定したりするものではありません。その判断には、さらなるサンプリングや定量的な測定が必要になる場合があります。また、ペルソナと置き換える必要もありません。ペルソナが行動や文脈における重要な違いを残すのに対し、ジョブは特定の状況で求める「進歩」に焦点を当てるという違いがあります。

分析や要約だけでなく、元の生の声も手元に残しておきましょう。このフレームワークが最も真価を発揮するのは、変化を起こす価値がなぜ生まれたのかをチームが理解し、具体的な人間の意思決定を単なる抽象的な「ニーズ」へと矮小化させずに済むだけの十分なディテールが得られたときです。