JTBDは、顧客が商品や機能そのものを買っているのではなく、何かを前に進めるための「仕事」を片づける手段として選んでいる、と見る考え方です。
要するに、「この機能が欲しい」という言葉をそのまま受け取るのではなく、その人はどんな状況で、何を片づけたかったのかまで見にいくための補助線です。
プロダクトの会議で迷い始めると、議論はだいたい機能の話に寄っていきます。
競合にあるから必要、ユーザーが欲しいと言っているから優先、営業が提案しやすいから入れたい。どれももっともらしいのですが、それだけで決めると後からズレやすいです。
私がJTBDを使いたくなるのは、そういう時です。顧客が欲しいのは機能そのものではなく、何かを前に進めるための手段かもしれない。そこに立ち戻れると、ロードマップの見え方がかなり変わります。
この記事では、JTBDを理論の紹介で終わらせず、SaaSやAIプロダクトの実務でどこに効くのかに絞って整理します。
JTBDの本質、「何を雇うか」ではなく「どんな進歩を求めているか」
JTBDの核心はシンプルです。顧客はスペックや機能一覧だけで選んでいるのではなく、特定の状況で何を前に進めたいかというジョブを片づけるために手段を選びます。
この見方に立つと、比較対象も変わります。競合製品だけでなく、Excelで我慢する、会議で確認する、外注する、いったん放置する、といった現実の代替行動まで含めて見えるからです。
私はここがJTBDの強さだと思っています。機能比較の話から抜けて、「なぜその手段が選ばれているのか」という文脈の話に戻せるからです。
ジョブには、早く終わらせたいという機能面だけでなく、安心して進めたい、周囲にちゃんと説明したい、失敗を避けたい、といった感情面や社会面も含まれます。だからこそ、要望をそのまま受け取るだけでは足りません。
たとえば業務ツールの改善でも、「ダッシュボードが欲しい」という声をそのまま受け取るとズレることがあります。本当に片づけたいのは、状況確認に時間をかけたくない、上司への説明をすぐ作りたい、危ない案件を先回りで見つけたい、といった別の仕事かもしれません。
会議まわりのツールでも同じです。「議事録AIが欲しい」という要望の裏で、本当に求められているのが全文の文字起こしではなく、会議後のアクション漏れをなくすことだったりします。ここを見誤ると、機能は増えたのに使われない、という状態になりやすいです。
これがJTBDの基本です。顧客の声を否定するのではなく、その声が生まれた状況と進歩まで見にいく。ペルソナ分析が「誰か」を描くのに対し、JTBDは「いつ、どんな文脈で、何を片づけたいのか」を明らかにします。
要望を集めるだけでは、顧客理解は浅いままです。要望の背景にある不便、不安、前に進めたい仕事まで見えてはじめて、機能の優先順位が実務に近づきます。私はここが重要だと思っています。
私はここで、顧客理解の粒度が変わるのが大事だと思っています。属性や要望だけを並べていると、結局は似た施策しか出てきません。でも状況と進歩まで見えると、同じユーザーに見えても必要な打ち手が変わります。ここが、JTBDが実務で効くいちばん大きな理由です。
現代ビジネス、特にSaaS・AIプロダクトでなぜ効くのか
いまのSaaSやAIツールの市場は機能競争が激しく、「AIで自動化」「生成AIで要約」みたいな打ち出しだけでは差がつきにくいです。そこにJTBDを当てはめると、「このAIは何のジョブを雇われるために作るのか」 が明確になります。
例えば、私たちが扱うような業務効率化SaaSの場合：
- 表面的：「月次レポート作成を楽にしたい」
- 本質のジョブ：「経営判断を早くするために、散らばったデータを素早く整理・インサイト化して、ミスなく意思決定したい（感情的：不安を減らしたい）」
前者だと「ダッシュボードにグラフ追加」みたいな機能で終わりがち。後者だと「自然言語で質問したら即座に根拠付きのサマリーが出て、チームで共有できる」みたいな体験設計になります。実際、AI時代では「AIが何ができるか」より「ユーザーがどんな仕事の詰まりを解消したいか」を定義しないと、ChatGPTやClaudeに「雇い負け」してしまいます。
マーケティングでも効きます。従来の「高機能・低価格」訴求じゃなく、「あなたの『プロジェクトの遅延を防ぎたい』ジョブを、AIで3分の1の時間で片づけます」というメッセージに変わる。BtoBでは特に、決裁者が「先進的企業に見られたい」という社会的ジョブも無視できません。
もう一つの強みは、イノベーションの予測可能性が上がること。クリステンセンは「イノベーションは運任せ」と指摘していましたが、JTBDで顧客のジョブを体系的にマッピングすれば、どの領域に未充足のジョブがあるかが見えてきます。結果として、失敗リスクを減らせるんです。
特にAIプロダクトでは、手段の進化が速すぎて、機能ベースの差別化だけだとすぐ埋もれます。だから私は、何ができるかではなく、どの仕事のどの詰まりを肩代わりするのかまで下ろす方が、結果として長く強い設計になると思っています。
実務で私が実際に試した活用例と、効いたポイント・危ないポイント
ツクリエでAIを日常的にプロダクト開発に使っている立場から、具体的にどう活かしているかをお伝えします。
- 顧客インタビューでの質問の変え方 以前は「このツールのどの機能が好きですか？」と聞いていました。今は「その状況で、どんな進歩を遂げたかったんですか？ それまでどうやって片づけていましたか？ 何が一番ストレスでしたか？」と深掘りします。すると、意外な代替手段が出てきます。例えば「Excelで手作業してた」という声から、「実はジョブは『正確性より、チームで即共有して議論を加速させたい』だった」と気づく。
これで得られたインサイトを基に、AI機能の優先順位を決めると、使われない機能が激減しました。
-
機能優先順位付けとロードマップ 「ユーザーが要望したから」と追加しがちな機能を、ジョブマップ（ジョブ発生→準備→実行→完了までのステップ）で評価するようになりました。ペインポイントが集中するステップだけをAIで強化。結果、開発リソースの無駄が減り、NPSも上がりました。
-
社内ツール選定や業務改善 意外と効くのが社内です。「新しいAI議事録ツールを入れる」じゃなく、「会議後のアクションアイテムを漏らさず共有し、フォロー漏れの不安をなくしたい」というジョブで選ぶと、過剰機能のツールを避けられます。
効いた実感：機能競争から脱却できたこと。AIだからこそ「何を自動化するか」より「どのジョブのどの部分を肩代わりするか」が大事で、JTBDがそのコンパスになってくれます。
危ないポイントも正直に：
- 真のジョブを掘り出すのはスキルと時間がかかる。表面的な回答に満足すると、結局「便利そう」止まり。
- 定量データ（利用ログ）と組み合わせないと、稀な状況のジョブを見逃す。
- 日本企業だと「本音を言わない」文化があるので、インタビューで「状況のストーリー」を聞く工夫が必要（例：具体的な1日のタイムラインを一緒に描く）。
完璧じゃないけど、方向感としては「機能の羅列から、ジョブ中心の会話へ」シフトするだけで、チームの議論の質が明らかに上がります。
ここで実感するのは、JTBDはインタビュー手法というより、優先順位のつけ方そのものを変えるということです。要望を全部拾うのではなく、どの状況で最も強い進歩欲求があるかを見るようになるので、ロードマップの納得感も上がりやすいです。
JTBDを見誤ると何が起きるか
JTBDは便利なフレームですが、表面的に使うと逆にズレます。よくあるのは、ジョブを単なる言い換えで終わらせてしまうことです。たとえば「レポートを早く作りたい」という要望を、そのまま「早くレポートを作るジョブ」と言い換えても、あまり意味がありません。
本当に見たいのは、その先にある進歩です。上司に安心して説明したいのか、顧客対応を先回りしたいのか、チームで同じ前提を共有したいのか。ここまで掘り下げないと、結局は機能追加の話に戻ってしまいます。
もう一つ怖いのは、強い顧客の声だけでジョブを定義してしまうことです。声が大きい人が代表ユーザーとは限りません。私は、定性インタビューに加えて利用ログや失注理由、サポート問い合わせの文脈も一緒に見る方が、ジョブの解像度は上がると思っています。
JTBDをチームで使うときの進め方
実務では、いきなり高度なジョブマップを作ろうとしなくても十分です。まずは、1つの機能要望や失注案件を題材にして、「この人はどんな状況で、何を前に進めたかったのか」を3人くらいで言語化するところから始めるのが現実的です。
そのうえで、競合比較ではなく代替行動を見ると、意外な発見が出ます。Excelで頑張る、Slackで聞く、会議で確認する、外注する、何もしないで放置する。これらも全部競合です。JTBDが効くのは、プロダクト同士の比較ではなく、顧客が実際にやっている回避策まで含めて見られるからです。
私は、JTBDは派手なフレームというより、会話の焦点をずらさないための軸だと思っています。「誰が」「どんな状況で」「何を前に進めたいのか」に戻るだけで、ロードマップの議論はかなり健全になります。
チームで使う時は、最初から難しく考えなくても大丈夫です。会議の中で1回だけでも「この機能は、誰のどんな仕事を前に進めるのか」と聞けると、それだけで議論の向きが変わります。私はこの一言を挟めるだけでも、JTBDを持つ価値は十分あると思っています。
JTBDをAI時代に使うときの補助線
AI時代は、顧客のジョブがより見えにくくなっている面もあります。なぜなら、ユーザー自身が「AIで何ができるか」をまだ言語化しきれていないことが多いからです。だから私は、ユーザーの要望をそのまま機能に落とすより、「その人はどんな前進を求めているのか」「いま何に時間を取られているのか」「どこで不安になっているのか」を先に整理した方が良いと思っています。
AIはジョブを解くための手段であって、ジョブそのものではありません。ここを取り違えないだけで、流行りの機能を追いかける議論から、顧客価値を軸にした議論へ戻しやすくなります。JTBDは、そのための補助線としてかなり強いです。
私は、AI時代ほどJTBDが必要になるのは、手段の魅力が強すぎるからだと思っています。できることが多いほど、何を前に進めたいのかを見失いやすいです。だからこそ、ジョブに戻る問いを持っているかどうかが、実務では大きな差になります。
JTBDを使うと会話がどう変わるか
私がJTBDを好きなのは、議論の主語が「機能」から「前に進みたいこと」に変わるからです。機能の議論は増やすか減らすかになりがちですが、ジョブの議論は、何を前進させたいのか、どこで詰まっているのか、なぜ代替行動が選ばれているのかという話に変わります。ここまで来ると、施策の優先順位もつけやすくなります。顧客理解の会話を浅い要望整理で終わらせないために、JTBDはかなり実用的な軸です。
まとめ、次に「この機能必要？」と思ったときに思い出してほしいこと
JTBDの良さは、顧客理解を要望整理で止めず、実際に何を前に進めたかったのかまで掘り下げられることです。
私は、JTBDは派手なフレームワークというより、議論の主語を機能から状況へ戻すための実務的な軸だと思っています。機能の話で迷ったときに、「この人はどんな状況で、何を片づけたかったのか」に戻れるだけで、優先順位の付け方も、メッセージの出し方もかなり変わります。
AI時代は手段が増えやすいからこそ、ジョブに戻れる軸を持っているかどうかが実務では大きな差になります。私は、機能議論が迷ったときほどこの視点に戻る価値があると思っています。要望の整理で止まらず、進歩の整理まで下りるためです。そこまで見えると、優先順位もメッセージもかなり強くなります。JTBDは、そのための実用的な補助線であり、現場で使い続けやすい軸でもあります。
