ユーザージャーニーにおけるJTBDとは？行動の背景から体験を設計する方法

ユーザージャーニーにおけるJTBDとは、ユーザーが各段階で「何を達成したいのか」「どのような進歩を求めているのか」を明らかにし、その視点から体験全体を設計する考え方です。JTBDは「Jobs To Be Done」の略で、日本語では「顧客が片づけたいジョブ」や「ユーザーが達成したい用事」と表現できます。ただし、ここでいうジョブは単なる作業ではありません。ユーザーが特定の状況で前に進むために求めている目的、変化、成果を指します。

ユーザージャーニーを作るとき、多くの場合は「認知」「比較」「登録」「利用」「継続」といったステージを並べます。しかし、ステージだけを見ていると、ユーザーが本当に何を達成したくてその行動をしているのかが見えにくくなります。たとえば、ユーザーが料金ページを見ているとき、単に価格を確認しているだけではありません。「自分にとって損ではないか」「社内で説明できるか」「失敗してもリスクが小さいか」を確認している可能性があります。JTBDを組み合わせることで、こうした行動の背景を深く理解できます。

ECサイトであれば、ユーザーは商品を買いたいだけではなく、「失敗しない選択をしたい」「自分に似合うものを見つけたい」「短時間で安心して購入したい」というジョブを持っているかもしれません。SaaSであれば、ユーザーは機能を使いたいだけではなく、「業務を早く終わらせたい」「チームに導入を納得してもらいたい」「上司に成果を説明したい」というジョブを持っている場合があります。

本記事では、ユーザージャーニーにおけるJTBDの意味、重要性、ジャーニーマップとの関係、構成要素、調査方法、マッピング手順、タッチポイント分析、ペインポイント分析、ECサイトやSaaSでの活用、AI時代の変化、よくある失敗まで詳しく解説します。

1. ユーザージャーニーにおけるJTBDとは

ユーザージャーニーにおけるJTBDとは、ユーザーが体験の各段階で達成したい「ジョブ」を明らかにし、そのジョブに沿って行動、感情、タッチポイント、ペインポイント、改善機会を整理する考え方です。ユーザーが何をクリックしたか、どの画面を見たかだけではなく、なぜその行動を取ったのか、何を解決したかったのか、どのような不安を減らしたかったのかを理解します。

通常のユーザージャーニーマップでは、ユーザーの行動や感情を時系列で整理します。これは非常に有効ですが、行動の背景にある「達成したいこと」まで深く掘り下げないと、施策が表面的になることがあります。たとえば、ユーザーがFAQを読んでいるという行動だけを見ると、FAQの見やすさを改善する発想になりやすいです。しかし、JTBDで見ると、そのユーザーは「購入前の不安を減らしたい」「失敗したときの対応を確認したい」「自分のケースにも使えるか判断したい」というジョブを持っている可能性があります。

JTBDをユーザージャーニーに組み込むと、ステージごとの目的が明確になります。認知段階では「自分の課題に名前をつけたい」、比較段階では「選択肢の違いを理解したい」、購入前には「リスクを減らしたい」、初回利用では「早く価値を感じたい」、継続段階では「成果を確認したい」といったように、ユーザーの内側にある目的を整理できます。

この考え方は、UX改善、プロダクト改善、サービスデザイン、マーケティング、カスタマーサクセスに役立ちます。なぜなら、ユーザーが本当に達成したいジョブを理解できれば、単に画面を改善するだけでなく、情報設計、サポート、オンボーディング、通知、資料、価格設計、導入支援まで含めて体験全体を改善できるからです。

重要なのは、JTBDを「ユーザーが欲しい機能」と混同しないことです。ユーザーは機能そのものを求めているのではなく、その機能によって達成できる進歩や成果を求めています。ユーザージャーニーにJTBDを加えることで、チームは「何を作るか」だけでなく、「なぜそれが必要なのか」を考えやすくなります。

2. なぜユーザージャーニーにJTBDが必要なのか

ユーザージャーニーにJTBDが必要なのは、ユーザーの行動だけを見ても、本当の動機や意思決定の理由が分からないことがあるからです。ユーザーが料金ページを見る、レビューを読む、問い合わせる、登録後に離脱するという行動は観察できます。しかし、その背後にある「何を達成したいのか」「何が不安なのか」「どのような変化を求めているのか」は、行動データだけでは見えにくいです。

JTBDを使うと、ユーザージャーニーを単なる行動の流れではなく、ユーザーが進歩しようとする流れとして捉えられます。これにより、表面的なUI改善だけでなく、ユーザーの目的に合った体験設計がしやすくなります。

2.1 行動の理由を理解できる

ユーザージャーニーでは、ユーザーが各ステージで何をしているかを整理します。しかし、同じ行動でも、背景にある理由は異なります。たとえば、同じようにレビューを読むユーザーでも、「商品の品質を確認したい」人もいれば、「自分と似た人が使っているか知りたい」人もいます。

JTBDを使うと、行動の背後にある目的を言語化できます。これにより、単にレビュー数を増やすのではなく、どのような不安を解消するレビューが必要なのかを考えられます。ユーザー行動を深く理解することで、施策の精度が高まります。

2.2 ペインポイントの根本原因を見つけやすい

ペインポイントは、表面的には「入力が面倒」「説明が分かりにくい」「料金が不安」として現れます。しかし、その根本には、ユーザーが達成したいジョブを妨げる要因がある場合があります。入力が面倒なのは、単にフォームが長いからではなく、「早く試したい」というジョブを妨げているからかもしれません。

JTBDを組み合わせると、ペインポイントを単なる不満ではなく、ジョブ達成を妨げる障害として捉えられます。これにより、どの障害を取り除けばユーザーが前に進めるのかを判断しやすくなります。

2.3 タッチポイントの役割を明確にできる

ユーザージャーニーには、広告、検索結果、公式サイト、料金ページ、レビュー、メール、サポート、アプリ画面など多くのタッチポイントがあります。JTBDを使うと、それぞれのタッチポイントがどのジョブを支援すべきかを明確にできます。

たとえば、導入事例ページの役割は、単に成功事例を見せることではありません。「自社に近い状況でも使えると判断したい」「社内説明の材料を得たい」というジョブを支援することです。このように考えると、掲載すべき情報や見せ方が変わります。

2.4 施策の優先順位を決めやすくなる

JTBDを使うと、改善施策の優先順位を決めやすくなります。すべての課題を同時に解決する必要はありません。ユーザーが前に進むうえで特に重要なジョブを妨げている課題から改善すべきです。

たとえば、SaaSで初回利用の離脱が多い場合、「機能を理解したい」というジョブよりも、「最初の成果を早く感じたい」というジョブが重要かもしれません。その場合、詳細な機能説明よりも、初回タスクの短縮やサンプルデータの提供が優先されます。

3. JTBDとユーザージャーニーマップの関係

JTBDとユーザージャーニーマップは、互いに補完し合う関係にあります。ユーザージャーニーマップは、ユーザーの行動、感情、タッチポイント、ペインポイントを時系列で整理するためのものです。一方、JTBDは、その行動の背後にある目的や進歩を明らかにするための考え方です。

つまり、ユーザージャーニーマップが「ユーザーはどのように動いているのか」を整理するものだとすれば、JTBDは「ユーザーはなぜそのように動いているのか」を説明するものです。両方を組み合わせることで、体験の流れと行動の理由を同時に理解できます。

3.1 ジャーニーは流れを示す

ユーザージャーニーは、ユーザーが目的を達成するまでの流れを示します。認知、検討、比較、登録、利用、継続、サポートといったステージを並べ、それぞれの段階でユーザーが何をしているのかを整理します。これにより、体験を点ではなく線として理解できます。

ただし、流れを整理するだけでは、ユーザーの内側にある目的までは十分に見えない場合があります。そこでJTBDを加えることで、各ステージにおける「ユーザーが達成したいこと」を明確にできます。

3.2 JTBDは理由を示す

JTBDは、ユーザーがなぜその行動を取るのかを示します。ユーザーが料金ページを見ている理由は、単に価格を知りたいからではなく、「損をしたくない」「社内で説明したい」「導入後の失敗を避けたい」というジョブが背景にあるかもしれません。

このように、JTBDはユーザー行動の意味を深く理解するために使えます。ジャーニーマップ上にJTBDを加えると、各ステージの行動が単なる作業ではなく、ユーザーが前に進むための努力として見えるようになります。

3.3 組み合わせることで施策に落とし込みやすくなる

ユーザージャーニーとJTBDを組み合わせると、改善施策を考えやすくなります。たとえば、比較段階で「違いを理解したい」というジョブがあるなら、比較表、導入事例、料金説明、FAQが重要になります。初回利用段階で「早く成果を感じたい」というジョブがあるなら、初回タスク、サンプルデータ、ガイド、成功メッセージが重要になります。

このように、JTBDはジャーニー上の各ステージに意味を与えます。施策を考えるときも、「この施策はどのジョブを支援するのか」を確認できるため、改善の方向性がぶれにくくなります。

3.4 JTBDを入れたジャーニーマップの例

JTBDをユーザージャーニーマップに入れる場合、ステージごとに「行動」「感情」「ジョブ」「ペインポイント」「改善機会」を整理すると分かりやすくなります。下記は、SaaSの無料登録から初回利用までを想定した簡易例です。

4. JTBDの構成要素

JTBDをユーザージャーニーに活用するには、ジョブをいくつかの要素に分けて整理すると分かりやすくなります。代表的な要素には、状況、機能的ジョブ、感情的ジョブ、社会的ジョブ、期待する成果、障害、代替手段があります。これらを整理することで、ユーザーがなぜその接点で行動するのかをより深く理解できます。

ジョブは一つだけとは限りません。ユーザーは同じ行動の中で、機能的な目的、感情的な目的、社会的な目的を同時に持つことがあります。たとえば、SaaSを導入する担当者は、業務を効率化したいだけでなく、社内で良い判断をしたと見られたい、導入に失敗して責任を負いたくないという気持ちも持っているかもしれません。

4.1 状況

状況とは、ユーザーがジョブを持つきっかけとなる文脈です。どのような問題が起きたのか、どのような制約があるのか、なぜ今その解決策を探しているのかを整理します。JTBDでは、ユーザーの属性だけでなく、状況を重視します。

たとえば、「30代会社員」という属性よりも、「毎月のレポート作成に時間がかかり、上司から改善を求められている」という状況のほうが、具体的なジョブを理解しやすくなります。ユーザージャーニーにおいても、状況を明確にすると、各ステージの行動理由が見えやすくなります。

4.2 機能的ジョブ

機能的ジョブとは、ユーザーが実際に達成したい作業や成果です。資料を作成したい、商品を比較したい、予約を完了したい、チームメンバーを招待したい、問題を解決したいといった具体的な目的が含まれます。

機能的ジョブは、UIや機能改善に直結しやすい要素です。ただし、機能的ジョブだけを見ると、ユーザーの不安や期待を見落とす場合があります。そのため、感情的ジョブや社会的ジョブと組み合わせて理解することが重要です。

4.3 感情的ジョブ

感情的ジョブとは、ユーザーがどのように感じたいか、またはどのような不安を減らしたいかに関わるジョブです。安心したい、自信を持ちたい、失敗を避けたい、焦りを減らしたい、面倒さを感じたくないといった感情が含まれます。

ユーザージャーニーでは、感情的ジョブが非常に重要です。ユーザーが購入前にレビューを読むのは、単に情報を集めたいだけではなく、「失敗したくない」「安心して決めたい」という感情的ジョブがあるからです。感情的ジョブを理解すると、信頼形成や不安解消の施策を設計しやすくなります。

4.4 社会的ジョブ

社会的ジョブとは、ユーザーが他者からどう見られたいかに関わるジョブです。上司に良い判断をしたと思われたい、チームに便利なツールを導入した人として評価されたい、友人にセンスが良いと思われたい、家族に安心してもらいたいといった目的が含まれます。

BtoBやSaaSでは、社会的ジョブが意思決定に強く影響することがあります。導入担当者は、自分が使いやすいだけでなく、社内で説明しやすいか、失敗したときに責任を問われないかを考えます。ユーザージャーニーに社会的ジョブを入れると、営業資料、導入事例、社内説明用資料の重要性が見えやすくなります。

4.5 期待する成果

期待する成果とは、ユーザーがジョブを達成した後に得たい状態です。時間を短縮したい、ミスを減らしたい、安心して購入したい、チームで共有しやすくしたい、成果を説明できるようにしたいなどが含まれます。

期待する成果を明確にすると、改善施策の評価基準も作りやすくなります。たとえば、ユーザーのジョブが「早く最初の成果を得たい」であれば、初回利用までの時間や初回タスク完了率が重要な指標になります。ジョブと指標をつなげることで、施策の効果を測定しやすくなります。

4.6 障害

障害とは、ユーザーがジョブを達成するうえで妨げになる要素です。情報不足、料金への不安、操作の複雑さ、社内承認の難しさ、時間不足、知識不足、信頼不足などが含まれます。障害を整理すると、ペインポイントの根本原因が見えやすくなります。

ユーザージャーニー上では、障害が発生するステージを特定することが重要です。比較段階で情報不足が障害になっているのか、登録段階で心理的リスクが障害になっているのか、初回利用で操作の複雑さが障害になっているのかによって、改善施策は変わります。

4.7 代替手段

代替手段とは、ユーザーが現在使っている別の方法や競合選択肢です。Excelで管理する、手作業で対応する、他社サービスを使う、担当者に直接聞く、検索で調べる、SNSで口コミを見るなどが含まれます。

JTBDでは、競合を同じカテゴリの製品だけに限定しません。ユーザーが同じジョブを達成するために使っている手段は、すべて代替手段になり得ます。代替手段を理解すると、ユーザーがなぜ今の方法を使い続けているのか、どのタイミングで乗り換えるのかを考えやすくなります。

5. JTBDをユーザージャーニーに入れる手順

JTBDをユーザージャーニーに入れるには、まず対象ユーザーと状況を明確にし、次に各ステージでの行動、思考、感情、タッチポイントを整理します。そのうえで、各段階に対応するジョブを言語化し、ジョブ達成を妨げる障害や改善機会を見つけます。

重要なのは、最初から完璧なジョブを書こうとしないことです。ユーザーインタビューや行動データをもとに仮説を作り、チームで検討し、検証しながら更新していくことが現実的です。

5.1 対象ユーザーと状況を決める

最初に、誰のジャーニーを扱うのかを決めます。新規ユーザー、既存ユーザー、離脱ユーザー、リピーター、管理者、利用者、決裁者など、対象によってジョブは変わります。さらに、そのユーザーがどのような状況にいるのかを明確にします。

たとえば、「SaaSの新規登録者」だけでは広すぎます。「業務改善を求められ、短期間でツールを比較している中小企業の担当者」のように状況を具体化すると、ジョブを見つけやすくなります。

5.2 ジャーニーステージを整理する

次に、ユーザーが目的を達成するまでのステージを整理します。認知、検討、比較、登録、初回利用、継続、サポート、更新判断など、ユーザー視点で段階を分けます。企業側の業務プロセスではなく、ユーザーがどのように前に進むのかを基準にします。

この段階では、各ステージでの行動やタッチポイントも一緒に整理します。どの情報を見ているのか、どの接点で判断しているのか、どこで迷っているのかを確認します。

5.3 各ステージのJTBDを言語化する

ステージを整理したら、それぞれの段階でユーザーが達成したいジョブを言語化します。ジョブは「〇〇したい」だけでなく、「どのような状況で」「何を達成し」「どのような状態になりたいのか」まで考えると具体的になります。

下記のように、ステージごとにジョブを整理すると、ユーザージャーニーとJTBDを接続しやすくなります。

5.4 障害と改善機会を整理する

各ステージのJTBDが見えたら、ジョブ達成を妨げている障害を整理します。情報が不足しているのか、操作が複雑なのか、信頼が足りないのか、社内説明が難しいのか、成果が見えにくいのかを確認します。

そのうえで、改善機会を考えます。比較段階で違いが分からないなら比較表を改善する、登録段階でリスクが不安なら無料体験条件を明確にする、初回利用で価値が見えないならサンプルデータや初回タスクを用意する、といった施策につなげます。

6. JTBDリサーチの方法

JTBDをユーザージャーニーに活用するには、ユーザーの発言や行動からジョブを見つける必要があります。単に「何が欲しいですか」と聞くだけでは、ユーザーの深いジョブは見えにくいです。ユーザーがどのような状況で、なぜその行動を取り、何を期待し、何に不安を感じていたのかを聞くことが重要です。

JTBDリサーチでは、特に「切り替えの瞬間」や「意思決定の背景」を重視します。ユーザーがなぜ今までの方法をやめたのか、なぜ新しいサービスを試したのか、何が決め手になったのかを調べることで、ジョブが見えやすくなります。

6.1 ユーザーインタビュー

ユーザーインタビューは、JTBDを理解するための基本的な方法です。ユーザーに、サービスを使い始めたきっかけ、以前使っていた方法、比較した選択肢、迷った理由、決め手、利用後の変化を聞きます。これにより、表面的なニーズではなく、実際に達成したかったジョブを探れます。

質問するときは、未来の希望よりも過去の具体的な行動を聞くことが有効です。「どんな機能が欲しいですか」よりも、「最後にこの課題を解決しようとしたとき、最初に何をしましたか」「なぜその方法を選びましたか」「何が不安でしたか」と聞くほうが、実際のジョブに近づきやすくなります。

6.2 行動観察

行動観察は、ユーザーが実際にどのように行動しているかを見る方法です。ユーザーは、自分の行動理由を正確に説明できない場合があります。実際にどこで迷い、どこを見直し、どの情報を無視し、どこでサポートを探すのかを観察することで、言語化されていないジョブや障害を見つけられます。

たとえば、ユーザーが料金ページの後にFAQへ移動している場合、「価格を知りたい」だけでなく、「失敗したときのリスクを確認したい」というジョブがあるかもしれません。行動観察は、ジョブを行動の文脈から理解するために役立ちます。

6.3 サポートログ分析

サポートログには、ユーザーがジョブを達成できなかった場面が多く含まれています。問い合わせ、チャット履歴、FAQ検索、クレーム、返品理由、解約理由を分析すると、どのステージでどのジョブが妨げられているのかが見えてきます。

たとえば、「設定方法が分からない」という問い合わせが多い場合、ユーザーのジョブは単に設定することではなく、「早く使い始めて成果を出したい」ことかもしれません。この場合、設定手順の説明だけでなく、初回価値までの導線を改善する必要があります。

6.4 レビュー分析

レビュー分析は、ユーザーが何に満足し、何に不満を感じているかを理解するために有効です。レビューには、購入前に期待していたこと、実際に得られた価値、失望した点、他者に伝えたい点が含まれることがあります。

レビューをJTBD視点で読むと、機能評価だけではなく、ユーザーが達成したかった進歩が見えてきます。たとえば、「思ったより簡単だった」というレビューは、「短時間で失敗せずに進めたい」というジョブが満たされたことを示しているかもしれません。

7. JTBDとタッチポイント分析

JTBDを使うと、タッチポイントの役割をより明確にできます。タッチポイントとは、ユーザーがブランドやサービスと接触する場所や瞬間です。Webサイト、アプリ、広告、SNS、メール、サポート、レビュー、営業資料などが含まれます。各タッチポイントがどのジョブを支援しているのかを整理すると、接点改善の方向性が見えやすくなります。

タッチポイントを単に並べるだけでは、接点の意味が曖昧になります。JTBDを加えることで、「この接点は何のために存在するのか」「ユーザーのどの不安を解消すべきか」「どのジョブ達成を支援すべきか」を判断できます。

7.1 認知接点のJTBD

認知接点では、ユーザーはまだ具体的な商品やサービスを探していない場合があります。この段階のジョブは、「自分の課題に名前をつけたい」「解決の方向性を知りたい」「今の困りごとが解決可能なのか知りたい」といったものです。

そのため、認知接点では、いきなり機能や価格を押し出すよりも、課題の整理、よくある状況、解決の選択肢を提示することが有効です。広告、記事、SNS投稿、動画、ホワイトペーパーなどは、このジョブを支援する接点になります。

7.2 比較接点のJTBD

比較接点では、ユーザーは複数の選択肢を見ています。この段階のジョブは、「自分に合うものを選びたい」「失敗しにくい選択をしたい」「違いを短時間で理解したい」といったものです。

比較表、料金ページ、導入事例、レビュー、FAQは、このジョブを支援する重要な接点です。単に情報を多く載せるのではなく、ユーザーが判断しやすい形で整理することが重要です。

7.3 登録・購入接点のJTBD

登録や購入の接点では、ユーザーは行動を起こす直前にいます。この段階のジョブは、「リスクを小さくして進めたい」「失敗しても戻れると確認したい」「安全に手続きを完了したい」といったものです。

この接点では、フォームの簡略化、入力補助、支払い方法の明確化、返品条件、無料体験条件、セキュリティ表示、確認画面が重要になります。ユーザーの不安を減らし、前に進みやすくすることが求められます。

7.4 利用・継続接点のJTBD

利用や継続の接点では、ユーザーは実際に価値を感じたい段階にいます。この段階のジョブは、「早く成果を出したい」「使い続ける理由を確認したい」「自分やチームに定着させたい」といったものです。

オンボーディング、ヘルプ、通知、利用レポート、サポート、カスタマーサクセスの連絡は、このジョブを支援します。特にSaaSでは、登録後に価値を感じるまでの時間が長いと離脱につながりやすいため、利用接点の設計が重要です。

8. ペインポイントをJTBDで分析する

JTBDを使うと、ペインポイントをより深く分析できます。ペインポイントは、ユーザーが困る場所や不満を感じる場所ですが、その本質は「ユーザーが達成したいジョブを妨げているもの」です。したがって、ペインポイントを単なる不便さとして見るのではなく、どのジョブが妨げられているのかを確認する必要があります。

たとえば、「登録フォームが長い」というペインポイントは、入力数の問題だけではありません。「早く試して価値を判断したい」というジョブを妨げている可能性があります。「料金が分かりにくい」というペインポイントは、「社内で説明できるようにしたい」「損をしたくない」というジョブを妨げている可能性があります。

8.1 表面的な不満と深いジョブを分ける

ユーザーの不満は、表面的に現れることがあります。「分かりにくい」「面倒」「高い」「不安」といった言葉だけを見ると、改善策が浅くなる場合があります。JTBDでは、その不満の奥にある達成したいことを探ります。

下記のように、表面的な不満をJTBDへ変換すると、改善施策が考えやすくなります。

8.2 ジョブ達成を妨げる障害を探す

JTBDでは、ユーザーが前に進めない理由を障害として整理します。障害には、情報不足、操作負担、信頼不足、リスクへの不安、社内承認の難しさ、既存習慣の強さなどがあります。これらは、ユーザーがジョブを達成するうえでの抵抗になります。

障害を整理すると、改善すべき対象が明確になります。ユーザーが比較段階で止まっているなら、選択肢の違いが分からないことが障害かもしれません。初回利用で止まっているなら、最初の価値までの距離が長いことが障害かもしれません。

8.3 既存習慣を理解する

ユーザーが新しいサービスを使わない理由は、必ずしも新サービスに魅力がないからではありません。既存の方法に慣れている、変更が面倒、社内で説明しにくい、失敗が怖いといった理由で、今の方法を使い続けることがあります。

JTBDでは、既存習慣を重要な抵抗要因として扱います。たとえば、SaaSを導入したいユーザーがいても、今までExcelで管理していた業務を変えるには心理的・組織的な負担があります。この抵抗を理解しないと、導入支援やオンボーディングは弱くなります。

8.4 改善機会へ変換する

ペインポイントとJTBDを整理したら、改善機会へ変換します。単に不満を解消するだけでなく、ユーザーがジョブを達成しやすくなるように接点や機能を設計します。

たとえば、「比較しにくい」という課題に対しては、比較表だけでなく、ユーザーの状況別におすすめを提示することが有効かもしれません。「初回利用が難しい」という課題に対しては、チュートリアルだけでなく、最初から成果が見えるサンプルデータを用意するほうが効果的な場合があります。

9. ECサイトでの活用

ECサイトでは、JTBDをユーザージャーニーに組み込むことで、購入前後の体験をより深く理解できます。ユーザーは商品を買うだけではなく、自分に合うものを選びたい、失敗したくない、安心して購入したい、購入後に満足したいというジョブを持っています。

商品ページ、レビュー、サイズガイド、配送情報、返品条件、決済画面、購入後メールなどの接点は、それぞれ異なるジョブを支援します。JTBDを使うことで、各接点が何を支援すべきかを明確にできます。

9.1 商品発見段階

商品発見段階では、ユーザーはまだ明確な商品を決めていない場合があります。この段階のジョブは、「自分に合う選択肢を見つけたい」「短時間で候補を絞りたい」「今の気分や目的に合う商品を探したい」といったものです。

この段階では、検索、カテゴリ、フィルター、ランキング、特集ページ、レコメンドが重要になります。単に商品を並べるだけでなく、用途、悩み、シーン、価格帯、人気度などで探しやすくすることが大切です。

9.2 比較検討段階

比較検討段階では、ユーザーは複数の商品を見比べています。この段階のジョブは、「失敗しにくい選択をしたい」「自分に合う理由を確認したい」「他の人の評価を見て安心したい」といったものです。

レビュー、比較表、写真、サイズガイド、素材説明、FAQが重要になります。特に、レビューは単なる評価ではなく、ユーザーの不安を減らす接点です。自分と似た人のレビューや、具体的な使用シーンが分かる情報があると判断しやすくなります。

9.3 購入段階

購入段階では、ユーザーは決済や配送の不安を減らしたいと考えています。この段階のジョブは、「安全に購入したい」「予想外の費用を避けたい」「失敗しても返品できると確認したい」といったものです。

決済画面、送料表示、配送予定日、返品条件、支払い方法、セキュリティ表示が重要になります。購入直前の接点では、派手な訴求よりも、安心して完了できる情報設計が必要です。

9.4 購入後段階

購入後段階では、ユーザーは「正しく届くか」「使い方は分かるか」「期待通りか」を確認しています。この段階のジョブは、「購入後も安心したい」「商品をうまく使いたい」「必要なら簡単に問い合わせたい」といったものです。

注文確認メール、配送通知、使い方ガイド、レビュー依頼、返品案内、サポート導線が重要になります。購入後体験が良いと、リピート購入や口コミにつながりやすくなります。

10. SaaSでの活用

SaaSでは、JTBDをユーザージャーニーに組み込むことで、導入前から継続利用までの課題を深く理解できます。SaaSのユーザーは、機能を使いたいだけではありません。業務を改善したい、チームに導入したい、成果を説明したい、失敗せずに定着させたいというジョブを持っています。

特にBtoB SaaSでは、利用者、管理者、決裁者が異なるジョブを持つことがあります。利用者は作業を楽にしたいと考え、管理者は運用を安定させたいと考え、決裁者は投資対効果を確認したいと考えます。これらを分けて整理することが重要です。

10.1 導入検討段階

導入検討段階では、ユーザーは自分の課題に合う解決策を探しています。この段階のジョブは、「自社の課題に合うか判断したい」「他社との違いを理解したい」「社内で説明できる材料を得たい」といったものです。

料金ページ、機能紹介、導入事例、比較資料、セキュリティ情報、FAQが重要になります。BtoBでは、利用者だけでなく決裁者や情報システム部門に向けた情報も必要になる場合があります。

10.2 無料登録段階

無料登録段階では、ユーザーはリスクを抑えて試したいと考えています。この段階のジョブは、「手間をかけずに試したい」「個人情報や支払い情報を出す前に価値を確認したい」「登録後に何をすればよいか知りたい」といったものです。

登録フォーム、無料体験条件、登録後メール、初回ガイドが重要になります。登録時点で不安が強いと、ユーザーは途中で離脱します。入力項目を減らし、試用条件を明確にし、次の行動を分かりやすく示すことが大切です。

10.3 初回利用段階

初回利用段階では、ユーザーは最初の価値を早く感じたいと考えています。この段階のジョブは、「迷わず使い始めたい」「最初の成果を出したい」「自分の業務に使えると確認したい」といったものです。

オンボーディング、サンプルデータ、初回タスク、ヘルプ、チュートリアル、進捗表示が重要になります。細かい機能説明よりも、最初に何をすれば価値を感じられるのかを示すことが重要です。

10.4 継続利用段階

継続利用段階では、ユーザーは使い続ける価値を確認したいと考えています。この段階のジョブは、「業務に定着させたい」「成果を見える化したい」「チームで使い続ける理由を説明したい」といったものです。

利用レポート、成果通知、カスタマーサクセスの連絡、チーム招待、権限設定、サポート対応が重要になります。継続利用のためには、機能の多さよりも、ユーザーが成果を実感できる接点を設計することが大切です。

11. サービスデザインでの活用

JTBDは、サービスデザインでも有効です。サービスデザインでは、ユーザーが接する表側の体験だけでなく、その裏側にある業務プロセス、システム、スタッフ、部門連携まで含めて考えます。JTBDを使うことで、各接点や業務がどのジョブを支援しているのかを整理できます。

サービス全体を見ると、ユーザーのジョブを妨げている原因が、UIではなく組織側の仕組みにある場合があります。たとえば、サポート回答が遅い原因は、担当者の努力不足ではなく、社内確認フローや情報管理の問題かもしれません。JTBDを使うと、接点と内部業務をユーザーの目的に結びつけて考えられます。

11.1 フロントステージのジョブを整理する

フロントステージとは、ユーザーが直接触れる接点です。Webサイト、アプリ、店舗、メール、サポート、広告、配送通知などが含まれます。JTBDを使うと、それぞれの接点がどのジョブを支援しているのかを整理できます。

たとえば、配送通知は単に配送状況を知らせるためだけではありません。「購入後も安心したい」というジョブを支援しています。サポートチャットは単に問い合わせを受けるためだけではなく、「困ったときにすぐ助けを得たい」というジョブを支援しています。

11.2 バックステージの障害を見つける

バックステージとは、ユーザーからは見えないが、体験を支えている内部業務やシステムです。注文処理、在庫管理、配送手配、顧客データ管理、サポート対応、営業連携などが含まれます。

ユーザーのジョブが達成されない原因は、バックステージにある場合があります。たとえば、ユーザーが「正確な配送予定を知りたい」というジョブを持っていても、在庫管理や配送システムが連携していなければ、そのジョブは満たされません。JTBDを使うと、内部業務の改善理由もユーザー視点で説明できます。

11.3 部門横断の改善に使う

JTBDは、部門横断の改善にも役立ちます。マーケティング、営業、プロダクト、サポート、カスタマーサクセスがそれぞれ異なる接点を管理していても、ユーザーにとっては一つの体験です。各部門が同じジョブを理解していれば、接点間のズレを減らしやすくなります。

たとえば、「社内で導入を説明したい」というジョブに対して、マーケティングは導入事例を用意し、営業は提案資料を整え、プロダクトは管理者向け機能を改善し、カスタマーサクセスは社内展開を支援できます。JTBDは、部門ごとの施策を同じ目的へつなげる役割を持ちます。

11.4 サービスブループリントへつなげる

JTBDを使ったユーザージャーニーは、サービスブループリントへ発展させることができます。ジャーニー上でユーザーのジョブを整理し、そのジョブを支えるフロントステージ、バックステージ、支援システムを整理します。

これにより、ユーザーの目的と組織の仕組みを結びつけられます。単に「この画面を改善する」ではなく、「このジョブを達成するために、どの接点と業務を改善する必要があるか」を考えられるようになります。

12. AI時代のJTBDとユーザージャーニー

AI時代には、JTBDとユーザージャーニーの組み合わせがさらに重要になります。AIチャット、レコメンド、AIエージェント、自動化、パーソナライズが体験に入ることで、ユーザーの行動や接点は複雑になります。AIが便利であっても、ユーザーのジョブを正しく支援していなければ、良い体験にはなりません。

AIを導入するときは、「どのジョブをAIが支援するのか」を明確にする必要があります。単にAI機能を追加するのではなく、ユーザーがどの段階で何を達成したいのか、どこで不安を感じるのか、どこで人間による確認が必要なのかを整理することが重要です。

12.1 AIが支援するジョブを明確にする

AIは、検索補助、要約、入力支援、レコメンド、自動返信、分析、提案など、多くのジョブを支援できます。しかし、すべてのジョブをAIに任せればよいわけではありません。どのジョブにAIが向いているのかを見極める必要があります。

たとえば、ユーザーが「大量の情報から候補を絞りたい」というジョブを持っている場合、AIレコメンドや要約は有効です。一方で、「重要な判断を安心して下したい」というジョブでは、AIの根拠表示や人間による確認が必要になる場合があります。

12.2 AIタッチポイントを整理する

AIタッチポイントとは、ユーザーがAI機能と接触する場所や瞬間です。AIチャット、検索補助、要約表示、レコメンド、入力支援、AIエージェントの実行画面などが該当します。これらをユーザージャーニー上に配置すると、AIがどのステージのジョブを支援しているかが分かります。

AIタッチポイントを整理するときは、便利さだけでなく、不安や誤解も確認する必要があります。ユーザーがAIの提案を信頼できるか、なぜその結果になったのか理解できるか、間違った場合に修正できるかを考えます。

12.3 人間による確認を設計する

AIが関わる体験では、人間による確認が重要になる場面があります。特に、金融、医療、法務、採用、セキュリティ、顧客対応などでは、AIの出力をそのまま使うのではなく、人間が確認するプロセスが必要です。

JTBDで見ると、人間による確認は「安心して判断したい」「失敗のリスクを減らしたい」「責任ある決定をしたい」というジョブを支援します。AI体験では、自動化と人間の確認を対立させるのではなく、ユーザーのジョブに応じて役割を分けることが重要です。

12.4 AIによるリサーチ支援を使う

AIは、JTBDリサーチやユーザージャーニー分析を支援することもできます。インタビュー記録の要約、サポートログの分類、レビュー分析、ペインポイント抽出、ジョブ仮説の整理などに活用できます。大量の定性データを扱う場合、AIは効率化に役立ちます。

ただし、AIの分析結果をそのまま結論にしてはいけません。ユーザーの文脈や感情、組織内の制約を解釈するには、人間の判断が必要です。AIは分析補助として使い、最終的なジョブ定義や施策判断は人間が確認することが重要です。

13. よくある失敗

JTBDをユーザージャーニーに使うときの失敗には、ジョブを機能要望として扱うこと、抽象的すぎるジョブを書くこと、ステージと接続しないこと、調査なしで想像だけで作ることがあります。これらの失敗があると、JTBDが実務に活きにくくなります。

JTBDは、ユーザーの本質的な目的を理解するための考え方です。単に「ユーザーは検索機能が欲しい」と書くのではなく、「ユーザーは必要な情報を短時間で見つけ、安心して次の判断に進みたい」といった形で、達成したい進歩を言語化する必要があります。

13.1 機能要望をジョブと混同する

よくある失敗は、ユーザーの機能要望をそのままジョブとして扱うことです。「検索機能が欲しい」「通知が欲しい」「比較表が欲しい」という要望は、ジョブそのものではありません。それらは、ジョブを達成するための手段です。

ジョブを考えるときは、「なぜその機能が欲しいのか」を深掘りします。検索機能が欲しい背景には、「必要な情報を短時間で見つけたい」というジョブがあるかもしれません。通知が欲しい背景には、「重要な変化を見逃したくない」というジョブがあるかもしれません。

13.2 ジョブが抽象的すぎる

ジョブが抽象的すぎると、施策につながりにくくなります。「便利に使いたい」「安心したい」「効率化したい」だけでは、どの接点をどう改善すればよいか分かりません。ジョブは、状況と期待する成果を含めて具体化する必要があります。

たとえば、「効率化したい」ではなく、「毎週のレポート作成に時間がかかっているため、ミスなく短時間で提出できる状態にしたい」と書くと、具体的な改善施策を考えやすくなります。ジョブは、抽象度と具体性のバランスが重要です。

13.3 ジャーニーステージと接続しない

JTBDをジャーニーステージと接続しないことも失敗です。ジョブだけを一覧化しても、どの段階でそのジョブが発生するのかが分からなければ、体験設計に活かしにくくなります。

JTBDは、認知、比較、登録、初回利用、継続、サポートなどのステージと結びつけることで実務に使いやすくなります。どの接点でどのジョブを支援するのかを整理することが重要です。

13.4 調査なしで作る

調査なしでJTBDを作ると、チームの想像に偏る可能性があります。社内メンバーはサービスに詳しいため、ユーザーがどこで迷うのか、何に不安を感じるのかを見落としやすいです。

もちろん、仮説としてJTBDを作ることは有効です。ただし、それを事実として扱うのではなく、ユーザーインタビュー、行動観察、アクセス解析、サポートログなどで検証する必要があります。

14. 実践導入ステップ

JTBDをユーザージャーニーに導入するには、対象ユーザーの定義、状況の整理、ジャーニーステージの作成、ジョブの言語化、障害の特定、改善機会の整理、施策化という流れで進めると分かりやすくなります。最初から大規模に行うのではなく、重要な体験範囲に絞って始めることが現実的です。

たとえば、SaaSなら「無料登録から初回価値実感まで」、ECサイトなら「商品発見から購入完了まで」、サポート改善なら「問い合わせから問題解決まで」に絞ると、ジョブを具体的に整理しやすくなります。

14.1 対象範囲を決める

最初に、どのユーザージャーニーを対象にするかを決めます。認知から購入までを見るのか、登録後のオンボーディングを見るのか、継続利用や解約前後を見るのかによって、必要なジョブは変わります。

範囲が広すぎると、ジョブが抽象的になりやすくなります。まずは、離脱が多い段階、不満が多い段階、ビジネス上重要な段階に絞ると、実務に活かしやすくなります。

14.2 ジョブ仮説を作る

次に、ユーザーインタビューや行動データをもとに、各ステージのジョブ仮説を作ります。最初から正解を求める必要はありません。ユーザーが何を達成したいのか、どのような不安を減らしたいのか、どのような成果を期待しているのかを仮説として書き出します。

ジョブ仮説は、チームで議論しやすい形にすることが大切です。たとえば、「比較段階のジョブは、複数の選択肢から失敗しにくいものを選びたいことではないか」といった形で整理します。

14.3 データで検証する

ジョブ仮説を作ったら、データで検証します。インタビュー、行動観察、アクセス解析、サポートログ、レビュー、アンケートを使い、ユーザーが本当にそのジョブを持っているのかを確認します。

検証では、ユーザーの言葉だけでなく行動も見ます。ユーザーが「料金は気にしていない」と言っていても、実際には料金ページを何度も確認している場合があります。発言と行動を組み合わせることで、より信頼できるジョブ定義ができます。

14.4 施策と指標に落とし込む

最後に、JTBDを改善施策と指標に落とし込みます。ジョブが「早く最初の成果を得たい」であれば、初回タスク完了率、初回価値実感までの時間、オンボーディング完了率などを指標にできます。ジョブが「社内で説明できる材料を得たい」であれば、資料ダウンロード数や商談化率、導入事例閲覧率などが指標になります。

施策と指標をつなげることで、JTBDは単なるリサーチ結果ではなく、プロダクト改善やUX改善の実行基盤になります。

おわりに

ユーザージャーニーにおけるJTBDとは、ユーザーが各段階で「何を達成したいのか」「どのような進歩を求めているのか」を明らかにし、その視点から体験全体を設計する考え方です。ユーザー行動を単に時系列で並べるだけでなく、その背景にある目的、感情、不安、期待する成果を理解することで、より本質的なUX改善につなげられます。

JTBDをユーザージャーニーに組み込むと、各ステージの意味が明確になります。認知段階では「課題に合う解決策を知りたい」、比較段階では「失敗しにくい選択をしたい」、登録段階では「リスクなく試したい」、初回利用では「早く最初の成果を得たい」、継続段階では「使い続ける価値を確認したい」といった形で、ユーザーの進歩を整理できます。

ECサイトでは、商品発見、比較検討、購入、購入後体験の各段階で、ユーザーが持つジョブを理解できます。SaaSでは、導入検討、無料登録、初回利用、チーム展開、継続利用の各段階で、利用者、管理者、決裁者の異なるジョブを整理できます。これにより、単なる画面改善ではなく、体験全体の改善が可能になります。

AI時代には、ユーザー体験がさらに複雑になります。AIチャット、レコメンド、AIエージェント、自動化が体験に入ることで、どのジョブをAIが支援し、どこで人間による確認が必要なのかを設計する必要があります。JTBDは、AIを含むユーザージャーニーをユーザー視点で整理するためにも重要な考え方です。