Jobs to Be Done でユーザーが本当に達成したいことを見極める
本章のガイド
最小 SOP
目的：読み終わった後、曖昧なアイデアを本当にユーザーシーンのあるニーズの一文に絞り込む方法がより明確になり、頭の中に機能名の羅列だけが残ることはありません。
アクション項目：曖昧なアイデアを 1 文書き、潜在ユーザー 3 人に「前回どう対処したか」を聞き、それを JTBD 文に整理する。
結果：より明確なニーズ仮説が得られ、初版で何を優先すべきかがわかる。
この章で学ぶ内容
- Jobs to Be Done とは何か、なぜ「機能ブレスト」よりもリアルなニーズに近いのか
- 「ユーザーが欲しいと言う機能」と「ユーザーが本当に達成したいこと」の区別方法
- 簡単なテンプレートを使って、曖昧なアイデアをシーン、トリガー、障害、成功基準に分解する方法
- JTBD を AI プロダクト、インタビュー質問、プロンプト整理にどう活用するか
1. Jobs to Be Done とは何か
Jobs to Be Done は JTBD と略されることが多いです。その背後にある核心的なアイデアは、Clayton Christensen のチームが広めた次の古典的な表現に関連しています：ユーザーはあるプロダクトを「雇用」して一つのことを完了させる。
ここで言う「こと」とは、ToDoリストにあるような表面的な動作ではなく、ユーザーが自分の状態を変えたいと思う一種の 進捗 です。例えば：
- 「AI 議事録ツールが欲しい」ではなく、「会議後 10 分以内に要点、ToDo、責任者を整理し、もう思い出しながらメモを補完したくない」
- 「家計簿 App が欲しい」ではなく、「お金がどこに消えているのかを知りたい、月末に不安を感じたくない」
- 「履歴書最適化ツールが欲しい」ではなく、「安心してまともな履歴書を提出したい、毎回提出するたびに自分の書いたものが不十分だと疑いたくない」
だから、JTBD が注目するのはプロダクトがどう見えるかではなく、ユーザーがなぜこの瞬間にそれを必要としているのかです。
これこそが、一見異なるプロダクトが実際には同じ Job を争っている理由でもあります。ユーザーが「通勤途中で退屈したくない」と思えば、雇用の対象はショート動画、ポッドキャスト、ゲーム、チャット、さらには居眠りかもしれません。ユーザーが「とても長い PDF を素早く理解したい」と思えば、雇用の対象は AI 要約ツール、インターン、同僚、自分で頑張って読む、あるいはとりあえず読まないことかもしれません。
この視点で問題を見ると、本当の競合相手は「自分と似たような App」だけではなく、ユーザーの現在受け入れ可能なすべての代替ソリューション であることに気づくでしょう。
2. JTBD とユーザーペルソナ、機能リストの違い
多くの初心者が初めてニーズ分析をする時、まずユーザーペルソナを書きます：25 歳、女性、一線都市、ホワイトカラー、効率ツールが好き、新しいプロダクトを試す意欲がある。この情報は全く役に立たないわけではありませんが、通常 一人がなぜこの瞬間に行動を起こすのかを説明するのには不十分です。
JTBD がより関心を持つのは次のような問題です：
- どんなシーンでソリューションを探すことを決めたのか
- その時、何につまずいたのか
- 何を次のステップに進めたいのか
- 今どんな不器用な方法でやりくりしているのか
- もし上手く解決できたら、どんな結果なら「価値があった」と思うのか
つまり、ユーザーペルソナは「この人が大体誰か」に近く、JTBD は「この人が今本当に何を達成したいか」に近い ということです。
同様に、機能リストも人を誤導しがちです。ユーザーが「Word エクスポートが欲しい」「AI リライトが欲しい」「音声入力が欲しい」と言っても、これらは表面的な表現にすぎません。JTBD はさらに掘り下げます：
- なぜ今 PDF ではなく Word でエクスポートする必要があるのか？
- リライトしたいのは、文章のスタイルが良くないからか、それとも異なる対象に合わせる必要があるからか？
- 音声入力が欲しいのは、タイプするのが面倒だからか、それとも歩いている時、運転している時、会議直後にすぐ記録するからか？
多くの場合、機能は Job の一時的な翻訳にすぎません。機能だけを集めると、プロダクトは「ユーザーが言うままに積み上げる」ものになりがちですが、背後にある Job が見えれば、本当に使いやすく、本当に競争力のあるソリューションを作れる可能性がずっと高くなります。
3. ゼロベースでも理解できる例
まず複雑な AI プロダクトを考えるのは後回しにして、生活の例から始めましょう。
ある人が朝出かける前にいつも朝食を食べる時間がなく、よく地下鉄の入り口でサンドイッチとコーヒーを買うと仮定します。表面的には彼は「朝食」を「購入」していますが、JTBD で見れば、彼が本当に達成したいことは：
- 急いでいる朝に、最も頭を使わない方法で一食を済ませる
- 会社に着く前に空腹でフラフラにならない
- 朝食のために通勤のペースを崩さない
この時、ユーザーが雇用しているのは「ある特定ブランドのサンドイッチ」ではなく、朝をスムーズに進められるソリューションです。隣のコンビニがより速く、より近く、より安定していれば、彼はすぐに元の選択を変えるかもしれません。
このロジックを AI プロダクトに持ち込むと、より明白になります。
例えば「AI 議事録ツール」を作りたいとします。機能のレベルに留まると、すぐに考え始めがちです：
- 音声アップロードに対応すべきか
- 話者分離に対応すべきか
- Markdown エクスポートに対応すべきか
- 自動 ToDo 生成に対応すべきか
これらは間違いではありませんが、まだ不十分です。JTBD でもう一段階問い直すと、ユーザーが本当に達成したいのは：
- 会議後 10 分以内に、議論結果を不参加者に同期したい
- ToDo、責任者、締切をきれいに抽出し、チームが記憶に頼ったコラボレーションをしなくて済むようにしたい
- 議事録の整理にかかる繰り返しの時間を減らし、意思決定と実行にエネルギーを注ぎたい
Job が明確になると、多くの機能の優先順位が自動的に見えてきます。初版で最も重要なのは「12 種類のエクスポート形式に対応すること」ではなく、次のようなことかもしれません：
- 議事録の構造が十分に明確であること
- ToDo 抽出が安定していること
- 共有リンクが便利であること
- 出力結果がチームに直接転送できる信頼性があること
これこそが JTBD の価値です：「どの能力を積み上げるか」から「ユーザーのどんな進捗を支援するか」に注意を戻すことができます。
4. 使いやすい JTBD テンプレート
ゼロベースなら、JTBD を学術的に考えすぎる必要はありません。まず最も実用的な 5 つの要素を掴めば十分です。
4.1 シーン
ユーザーはどんな瞬間、どんな環境でこのプロダクトを思い出すのか？
- 会議が終わった後
- 上司が急に資料を求めてきた時
- 夜履歴書を提出する準備をしている時
- 月末にお金がまた足りないことに気づいた時
シーンのないニーズは、通常まだリアルではありません。
4.2 トリガー
何が彼にすぐソリューションを探す決意をさせたのか？
- 長い文書に圧倒され、どこから読めばいいかわからない
- 明日提出の資料が、今日になってフォーマットがめちゃくちゃだと気づく
- 上司に進捗を追及され、自分が整理しきれていないことに気づく
- 記録を続けたいが、手書き、コピー、整理が面倒すぎる
トリガーには往々にして感情が伴います。この感情は重要です。なぜなら、ユーザーがなぜこの瞬間に行動を起こすのかを決めるからです。
4.3 達成したい進捗
彼は「一つの動作をする」だけでなく、自分をどんな新しい状態に進めたいのか？
- 混乱から明確へ
- 不安から安心へ
- 先延ばしからスタートへ
- 非効率からスムーズへ
- うまく説明できないから直接届けられるものへ
このステップで「進捗」という言葉が非常に重要です。なぜなら、多くの人が本当に買っているのはツールではなく、状態の変化 だからです。
4.4 現在の代替ソリューション
あなたのプロダクトがない今、彼はどうしているのか？
- 手作業でコピペ
- Excel やメモアプリでやりくり
- 同僚に頼る
- 先延ばしにする
- 複数のツールの間で行き来する
誰が代替ソリューションか、誰があなたの本当の競争環境か。
4.5 成功基準
どうなったら本当に解決したと言えるのか？
- 10 分以内に共有可能な結果が得られる
- 大きな修正なしで他人に送れる
- 抜け漏れ、ミス、忘れが起こりにくい
- 初めて使っても次のステップがわかる
「ユーザーがどうやって価値を判断するか」すら言えないなら、その方向性はおそらくまだ十分に絞り込まれていません。
5. そのまま使える一文公式
プロダクトの方向性を整理したい時、まずこの実用的なテンプレートに当てはめてみてください：
__________ の時、__________ がしたい、それは __________ のためだ。 今は __________ でなんとかこのことをやり遂げている。
例えば：
情報量が多いプロジェクト会議が終わった時、ToDo、責任者、締切を含む議事録を素早く得て、すぐにチームに同期し実行を推進したい。 今は自分の記憶、チャット履歴の確認、手作業での整理でなんとかやり遂げている。
もう一つの例：
新しい職種に応募する準備をする時、既存の経歴を職種に合ったバージョンに素早く書き換えて、安心してまともな履歴書を提出したい。 今は古い履歴書を繰り返しコピペし、言葉を手作業で修正し、最後にはどんどん自信がなくなっている。
一文をこの明確さまで書ければ、その後の画面設計、プロンプト設計、機能優先度の判断がずっと楽になります。
6. AI プロダクトを作る時、特に注目すべき 3 つのレイヤーの Job
多くの AI プロダクトは機能デモでは強そうに見えますが、実際にリリースされてもユーザーが定着しないことがよくあります。その一般的な理由は、表面的な動作を解決しただけで、より深い Job を解決していないからです。
Job は大まかに 3 つのレイヤーに分けて見ることができます：
6.1 機能レイヤー
最も表面的なタスクは何か？
- 文書の要約
- コピーのリライト
- ToDo の抽出
- 画像の生成
これはユーザーが口に出しやすいレイヤーです。
6.2 感情レイヤー
ユーザーはどんな不快感を減らしたいのか、またはどんな感情を得たいのか？
- 慌てたくない
- プロフェッショナルに見えたい
- 毎回ゼロから始めたくない
- コントロール感が欲しい
多くの有料意欲は、実際に感情レイヤーと深く関係しています。
6.3 社会レイヤー
ユーザーは他人の目にどうなりたいのか？
- より頼りに見られたい
- チームでより組織力があると思われたい
- 顧客の前でよりプロフェッショナルに見られたい
- SNS でより表現力があると思われたい
機能レイヤーだけをやっていれば、プロダクトは代替されやすいです。感情レイヤーと社会レイヤーも同時に理解すれば、より粘着性のある価値を見つけやすくなります。
7. JTBD を逆に使ってプロダクト方向を絞り込む
時にはすでにプロダクトがあるのではなく、3〜5 のアイデアがあって、どれを作るべきかわからないことがあります。この時、JTBD は選別に非常に適しています。
各アイデアを取り上げて、それぞれに 5 つの質問をすることができます：
- このアイデアに対応するシーンは十分に具体的か？
- ユーザーはすでに何らかの不器用な方法で解決しているか？
- この Job の痛みは十分に強いか、または十分に高頻度か？
- もし上手くできたら、ユーザーは明らかに「状態が良くなった」と感じるか？
- 初版はこの Job の重要な一歩だけを囲んで、小さいが有用なバージョンを作れるか？
ある方向性が最後まで説明しても「面白そう」としか言えず、トリガー、代替ソリューション、成功基準をはっきりと言えないなら、それはおそらくまだ曖昧なインスピレーションであって、成熟した方向性ではありません。
8. そのままユーザーインタビューに使える質問
多くの人は調査をする時、「どんな機能が欲しいですか？」と聞いてしまいます。この聞き方は表面的な回答を得やすいです。
JTBD は次のような質問により適しています：
- 前回この問題に直面したのはいつですか？
- その時何をしていて、なぜつまずいたのですか？
- 最終的にどう解決しましたか？
- このプロセスで一番面倒で、一番遅くて、一番不安なのはどこですか？
- もしツールがあれば、どんな結果なら本当に役に立つと思いますか？
- どんな代替方法を試しましたか？なぜ十分ではなかったのですか？
この聞き方には利点があります：会話をリアルな体験に引き戻し、想像上の好みに留まらせないことです。
9. AI に JTBD 分析を手伝ってもらう
JTBD 自体は AI が発明したものではありませんが、AI は JTBD の整理と洗練に非常に適しています。
例えば、5〜10 件のユーザーフィードバックを収集したら、それらをモデルに渡して次の構造でまとめてもらうことができます：
プロダクト研究アシスタントを演じてください。
ユーザーの生の言葉を渡します。まず機能提案をせず、
Jobs to Be Done のフレームワークで整理してください：
1. ユーザーはどんなシーンにいるか
2. 行動を起こすトリガーは何か
3. 本当に達成したい進捗は何か
4. 現在の代替ソリューションは何か
5. 最も重視する成功基準は何か
6. これらのフィードバックで繰り返し出現する感情ワードは何か
最後に、これらを最も優先的に検証すべき 3 つの JTBD 仮説に整理してください。もしすでにアイデアがあるなら、AI に第一段階の絞り込みをしてもらうこともできます：
[あなたのプロダクトアイデア] を作りたい。
機能リストを直接出すのではなく、Jobs to Be Done の方法で分析してください：
1. このプロダクトがサービスする可能性のある具体的なシーンは何か
2. 各シーンでユーザーが達成したいコア Job は何か
3. 既存の代替ソリューションには何があるか
4. どの Job が MVP の出発点として最も適しているか、なぜか
5. 最終的に推奨する Job を明確な JTBD 文に書いてくださいこのようにすることで、最初から AI に「50 の機能をブレスト」させるのではなく、方向性をまず明確にできます。
10. 初心者が最も陥りやすい 4 つの誤解
10.1 Job を機能名にしてしまう
「AI 要約」「スマート分類」「自動生成」は Job ではなく、それらは実現方法の可能性にすぎません。
10.2 ターゲット層を広く書きすぎる
「すべてのビジネスパーソン」「すべての学生」「すべての起業家」は通常広すぎます。広ければ広いほど、リアルなシーンを見えなくなります。
10.3 ユーザーの言葉だけを聞き、行動を見ない
ユーザーは自分が何を欲しがっているかを説明できますが、彼らの本当の優先順位は、今どのように問題をやりくりしているかに隠されていることが多いです。
10.4 最初から完全なプラットフォームを作ろうとする
JTBD の正しい使い方は、通常「何でもできる大きなプラットフォームを作る」ことではなく、まず一つのシーンで最も重要な一歩に注目し、それを非常に使いやすくすることです。
11. まとめ
Jobs to Be Done の最も価値のある点は、新しい用語を与えることではなく、観察の角度を変えてくれることです：プロダクトの機能だけを見るのではなく、ユーザーが何を次のステップに進めたいのかを見る。
あなたが次のようなことを繰り返し自分に問い始めると：
- ユーザーはどんなシーンでこのプロダクトを雇用しているのか
- 彼は一体どこでつまずいているのか
- 今どんな方法でやりくりしているのか
- 問題が解決した後、状態はどう変わるのか
元々曖昧だったアイデアが急にはっきりとし、元々派手だった機能も急に重要ではなくなっていくことに気づくでしょう。
プロダクトを作る時、特に AI プロダクトを作る時、最も怖しいのは最初から能力展示に夢中になることです。JTBD はあなたの注意を本当に重要なところに引き戻してくれます：ユーザーはなぜあなたを必要としているのか、そしてあなたは一体ユーザーのどんな進捗を支援しているのか。
12. AI を活用して JTBD を実践する方法
JTBD は AI が発明したものではありませんが、AI はこの手法で研究アシスタント、整理アシスタント、対照アシスタントとして非常に適しています。重要なのは：AI に整理と拡張をさせ、ユーザーの推測をAIに代行させないこと。
次のように活用できます：
12.1 AI に曖昧なアイデアを JTBD 仮説に書き直させる
頭の中に「大学生のインターン探しを支援するツールを作りたい」という曖昧な説明しかない時、まず AI にそれをいくつかの可能性のある Job に分解させることができます：
今、曖昧なプロダクトアイデアがあります：[あなたのアイデア]
機能リストを直接出すのではなく、Jobs to Be Done の方法で分析してください：
1. どのような具体的なシーンに対応する可能性があるか
2. 各シーンでユーザーが本当に達成したい進捗は何か
3. 現在の代替ソリューションは何か
4. どの Job を最初に MVP にするのが最も適切か
最後に各 Job を明確な JTBD 文に書いてください。非常に初心者っぽい入力でも全く問題ありません：
大学生のインターン探しを支援するものを作りたい。
具体的に何を作るかまだはっきり言えない。ユーザーが本当に何を達成したいかを考えてみて。AI が返す有用な出力は次のようになります：
可能性のある JTBD 方向：
1. 初めてインターンに応募する準備をする時、まず何を準備すべきかを素早く知りたい、
情報が乱雑で応募を先延ばしにしたくない。
2. インターンの求人を見た時、自分が応募する価値があるかどうかを素早く判断したい、
不適切な求人に時間を無駄にしたくない。
3. 応募を始める時、既存の履歴書を求人に合ったバージョンに素早く書き換えたい、
より早く応募を完了し、通過率を高めたい。このような出力の価値は、元々非常に漠然としていたアイデアを、よりリアルなシーンに近い方向に分解してくれることです。
12.2 AI にインタビューの生の言葉を整理させる
すでに何度かユーザーインタビューを終えたなら、インタビュー記録を AI に渡して、繰り返し出現するシーン、トリガー、代替ソリューション、成功基準を抽出させることができます。
以下は 5 人のユーザーのインタビュー生の言葉です。
まずソリューションを出さず、JTBD フレームワークで整理してください：
1. ユーザーはどんなシーンにいるか
2. 行動を起こすトリガーは何か
3. 本当に達成したい進捗は何か
4. 現在の代替ソリューションは何か
5. 最も重視する成功基準は何か
6. どの情報が複数のユーザーで繰り返し出現しているか
最後に、最も優先的に検証すべき 3 つの JTBD 仮説に整理してください。非常にシンプルな初心者入力も次のように書けます：
3 人に聞きました。大体こんな風に言っていました：
1. 毎回インターンに応募するたびに履歴書を書き直すのが本当に面倒。
2. 一番怖いのは、自分が書いたものが正しいかどうかわからないこと。
3. 今は先輩に見てもらうようにしているけど、毎回頼むのは申し訳ない。
彼らが本当に達成したいことを整理して。AI は次のように出力するかもしれません：
整理結果：
- 共通シーン：インターン応募前の履歴書処理
- 共通の困難：「十分良い」までどう修正すればいいかわからない
- 現在の代替ソリューション：先輩に見てもらう、自分で繰り返し修正
- 可能な JTBD：
インターンに応募する準備をする時、履歴書が応募可能なレベルに達しているかをより早く判断したい、
「もう少し修正」でずっと応募できずにいる状況から抜け出したい。このような出力は、散らばった生の言葉から「ニーズ」により近いものを抽出してくれるので、非常に有用です。
12.3 AI に軽量なウェブ調査を先に行わせる
大規模なインタビューを始める前に、AI に少し軽い外部情報スキャンをさせることができます。例えば：
- 公開フォーラムやコミュニティで、皆がこの問題にどう不満を漏らしているか
- 市場の既存プロダクトが主にどのレベルの問題を解決しているか
- ユーザーの最も一般的な代替ソリューションは何か
- 一般的な評価で、最も満足されている点と最も不満な点は何か
この調査はリアルなユーザーインタビューに代わるものではありませんが、Discover 段階のウォームアップとして、問題の地図を先に構築するのに非常に適しています。
シンプルな入力は次のようなものです：
調べてほしいことがあります：
「大学生が履歴書を修正してインターンに応募する時、最もよくあるペインポイントは何？」
公開フォーラム、経験談、就職コミュニティで皆が自分で言っていることを優先的に見てください。
最も一般的な問題を 5 つに整理して。AI は次のように出力するかもしれません：
よくあるペインポイントの整理：
1. 履歴書に何を書けばいいかわからない、経歴が少なすぎる
2. 異なる職種に合わせてどう修正すればいいかわからない
3. 何度も修正したが、まだ十分かどうかわからない
4. 信頼できる人に見てもらえない
5. 応募プロセスが複雑で、先延ばしにしがちこの種の出力は最終結論として扱うべきではありませんが、どの問題を優先してインタビューするかを決めるのに非常に適しています。
12.4 AI に「反論者」を演じさせる
多くの場合、私たちは自分のアイデアに感情を入れすぎてしまいます。意図的に AI に批判者を演じさせ、問題をより明確に説明するよう促すことができます：
非常に厳しいプロダクト研究コンサルタントを演じてください。
以下は私の JTBD 仮説です：[あなたの仮説]
次の観点から批判してください：
1. このシーンは広すぎないか
2. この Job は機能であり、本当に進捗であるかどうか
3. 代替ソリューションが弱すぎないか
4. 成功基準が不明確ではないか
5. この仮説で最も検証が必要なリスクは何かこのようにすることで、自分がニーズを見ているのか、それともただ自分が好きなソリューションを見ているのかをより早く発見できます。
📚 課題
上記の内容に基づいて、次の課題を完了してください：
- 最近やりたいプロダクトアイデアを一つ選び、JTBD 公式の一文で明確に書く
- このアイデアに 5 つの要素を補完する：シーン、トリガー、進捗、代替ソリューション、成功基準
- 潜在ユーザー 3 人に聞き、「前回この問題に直面したのはいつですか」を少なくとも 1 回は聞き出す
- インタビューの生の言葉を AI に渡し、最も優先的に検証すべき 3 つの JTBD 仮説に整理する