jobs-to-be-done

目的

顧客が何を達成しようとしているのか（機能的、社会的、感情的なジョブ）、どのような苦痛を経験しているのか、どのような利得を求めているのかを体系的に探ります。このフレームワークを使って、満たされていないニーズを見つけ、プロダクトのアイデアを検証し、表面的な機能要望ではなく、実際の動機にソリューションが応えていることを確認します。

これはアンケートではありません。顧客がなぜあなたのプロダクトを「雇う」のか、そして何があれば「解雇」するのかを理解するための、体系的な視点です。

入力

最も効果的な情報： 分析対象の顧客セグメント（またはその顧客が利用するプロダクト）。 あると役立つ情報： ジョブ、苦痛、利得を探るためのインタビュー記録、サポートチケット、調査資料や、関心のある状況・きっかけ。

呼び出し時に渡された情報はすべて（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追記された ARGUMENTS: 行など）、すでに回答済みの情報として扱います。それを利用し、該当する内容は再質問しないでください。

情報が何もなくても大丈夫です。 このスキルでは、JTBD の分析を構成する前に、顧客が誰で、どのような進歩を遂げようとしているのかを尋ねます。

呼び出し例： 自社の請求ツールを利用するフリーランスのデザイナーについて JTBD を実行してください。インタビューの要約が 6 件あります。

主な概念

ジョブ理論（Jobs-to-be-Done）

Clayton Christensen と Value Proposition Canvas（Osterwalder）の影響を受けた JTBD では、顧客のニーズを次の 3 つのカテゴリーに分類します。

1. 顧客のジョブ：

• 機能的なジョブ： 顧客が実行する必要のあるタスク（例：「請求書を送る」）
• 社会的なジョブ： 顧客が周囲からどう見られたいか（例：「クライアントにプロらしい印象を与える」）
• 感情的なジョブ： 顧客が得たい、または避けたい感情の状態（例：「自分の仕事に自信を持つ」）

2. 苦痛：

• 課題： 顧客が直面する障害
• コスト： 時間、費用、労力がかかりすぎること
• よくあるミス： 防止できる可能性のある顧客の誤り
• 未解決の問題： 現在のソリューションにおける不足

3. 利得：

• 期待： 現在のソリューションを上回るもの
• 節約： 顧客に喜ばれる、時間、費用、労力の削減
• 導入要因： 切り替えの可能性を高めるもの
• 生活の改善： ソリューションによって生活が楽しく、または快適になる方法

この構成が有効な理由

• ジョブとソリューションを分けられる： 「チームと連絡を取る」（ジョブ）≠「メール」（ソリューション）
• 根本的な動機を明らかにできる： 機能的なジョブは「経費を記録する」でも、感情的なジョブは「財務を管理できていると感じる」かもしれません
• 見えていなかった競合が明らかになる： 顧客は、意外な代替手段（紙とペン、スプレッドシート、回避策など）を「雇う」ことがあります
• 強さに基づいて優先順位を付けられる： すべての苦痛が同じではありません。特に深刻なものに注目しましょう

アンチパターン（これは何ではないか）

• 機能の要望リストではありません： 「AI、自動化、ダッシュボードが欲しい」はジョブではありません
• デモグラフィックではありません： 「ミレニアル世代はモバイルファーストを望む」はペルソナの特性であり、ジョブではありません
• 漠然としたものではありません： 「生産性を上げる」では曖昧すぎます。どのタスクなのか、そしてなぜなのかを掘り下げましょう
• 一面的なものではありません： 機能的なジョブだけに注目すると、社会的・感情的な動機を見落とします

使う場面

• 初期のディスカバリー（ソリューションが決まる前）
• プロダクト・マーケット・フィットの検証（ソリューションは適切なジョブに対応しているか？）
• ロードマップの優先順位付け（最も大きな苦痛、または重要なジョブはどれか？）
• 競合分析（顧客は何を目的に競合を「雇っている」のか？）
• マーケティングメッセージ（機能ではなくジョブに訴えかける）

使わない場面

• プロダクトをすでに作り終えた後（ディスカバリーには遅すぎます）
• 些細な機能の場合（小さな変更を分析しすぎないでください）
• 定量的な検証の代わりとして（JTBD は仮説の作成に役立ちます。データで仮説を検証してください）

---

適用

全項目を記入するための構成については、template.md を使用してください。

ステップ 1：コンテキストを定義する

JTBD を掘り下げる前に、次の点を明確にします。

• ターゲット顧客セグメント： 誰を調査していますか？（skills/proto-persona/SKILL.md を参照）
• 状況： どのような状況でジョブが発生しますか？（例：「プロジェクトの締め切りを管理するとき……」）
• 現在のソリューション： 現在、どのようなものを利用していますか？（競合、回避策、何もしないなど）

コンテキストが不足している場合： 顧客インタビュー、コンテキスト調査、または「乗り換えインタビュー」（以前のソリューションから乗り換えた理由を尋ねる）を実施します。

---

ステップ 2：顧客のジョブを探る

機能的ジョブ

質問：「どのようなタスクを完了しようとしていますか？」

### Functional Jobs:
- [Task 1 customer needs to perform]
- [Task 2 customer needs to perform]
- [Task 3 customer needs to perform]

例：

• 「税務申告のために月次経費を精算する」
• 「新しいチームメンバーのオンボーディングを 2 時間以内に完了する」
• 「ダウンタイムなしでコードを本番環境にデプロイする」

品質チェック：

• 動詞を中心にする： ジョブは行動を表します（「送信する」「分析する」「調整する」）
• ソリューションに依存しない： 「メールを使ってやり取りする」ではなく、「リモートチームメイトとコミュニケーションを取る」とします
• 具体的にする： 「財務を管理する」は広すぎます。「税控除のために事業経費を記録する」は具体的です

---

社会的ジョブ

質問：「他者からどのように見られたいですか？」

### Social Jobs:
- [Way customer wants to be perceived socially 1]
- [Way customer wants to be perceived socially 2]
- [Way customer wants to be perceived socially 3]

例：

• 「経営幹部チームから戦略的思考ができる人だと思われる」
• 「クライアントから対応が迅速で信頼できる人だと思われる」
• 「年下の同僚からテクノロジーに詳しい人だと思われる」

品質チェック：

• 対象を明確にする： 顧客は誰に良い印象を与えようとしていますか？（上司、クライアント、同僚など）
• 感情的な重み： 社会的ジョブは、機能的ジョブよりも導入を促すことがよくあります

---

感情的ジョブ

質問：「どのような感情の状態を実現したい、または避けたいですか？」

### Emotional Jobs:
- [Emotional state customer seeks or avoids 1]
- [Emotional state customer seeks or avoids 2]
- [Emotional state customer seeks or avoids 3]

例：

• 「重要な詳細を見落としていないと確信したい」
• 「手作業でのデータ入力ミスによる不安を避けたい」
• 「一日の終わりに達成感を得たい」

品質チェック：

• 肯定的な感情と否定的な感情の両方を含める： 求めること（「自分でコントロールできていると感じる」）と避けること（「恥ずかしい思いを避ける」）の両方を含めます
• 調査に基づく： 感情をでっち上げず、顧客の発言を使います

---

ステップ 3：ペインを特定する

課題

質問：「このジョブの完了を妨げている障害は何ですか？」

### Challenges:
- [Obstacle customer faces 1]
- [Obstacle customer faces 2]
- [Obstacle customer faces 3]

例：

• 「ツールが連携せず、手作業でのデータ入力を強いられる」
• 「チームメイトが何に取り組んでいるのか把握できない」
• 「承認プロセスに 3 日以上かかり、進行が妨げられる」

---

コスト

質問：「時間、お金、労力がかかりすぎているのは何ですか？」

### Costliness:
- [What's too costly in time, money, or effort 1]
- [What's too costly in time, money, or effort 2]

例：

• 「月次レポートの作成に、手作業で 8 時間かかる」
• 「専門家を雇うのに 1 万ドルかかり、予算が足りない」
• 「現在のツールの習得には 20 時間以上のトレーニングが必要」

---

よくあるミス

質問：「防止できるのに、頻繁に起こしてしまうミスは何ですか？」

### Common Mistakes:
- [Frequent error 1]
- [Frequent error 2]

例：

• 「重要なメールで関係者を CC に入れ忘れる」
• 「領収書がないために税控除額を誤って計算する」
• 「共有ファイルで他の人の作業を誤って上書きする」

---

未解決の問題

質問：「現在のソリューションで解決できていない問題は何ですか？」

### Unresolved Problems:
- [Problem not solved by current solutions 1]
- [Problem not solved by current solutions 2]

例：

• 「現在の CRM では顧客のヘルススコアを追跡できない」
• 「メールでは、スレッドの途中で人が追加されたときに会話のコンテキストが保たれない」
• 「既存のツールには、社内にない技術的な専門知識が必要」

---

ステップ 4：ゲインを明らかにする

期待

質問：「どのようなソリューションなら気に入るでしょうか？」

### Expectations:
- [What could exceed expectations 1]
- [What could exceed expectations 2]

例：

• 「手動でタグ付けしなくても経費を自動的に分類する」
• 「プロジェクトの状況に基づいて次のステップを提案する」
• 「すでに利用しているツールとシームレスに連携する」

---

削減

質問：「時間、お金、労力をどれだけ削減できれば、うれしいですか？」

### Savings:
- [Way of saving time, money, or effort 1]
- [Way of saving time, money, or effort 2]

例：

• 「レポート作成を 8 時間から 10 分に短縮する」
• 「専任の管理担当者を不要にする」
• 「オンボーディング期間を 2 週間から 2 日に短縮する」

---

導入要因

質問：「現在のソリューションから乗り換えるきっかけになるのは何ですか？」

### Adoption Factors:
- [Factor increasing likelihood of adoption 1]
- [Factor increasing likelihood of adoption 2]

例：

• 「クレジットカード不要の無料トライアル」
• 「既存データのインポートを支援する移行サポート」
• 「自社に似た企業の推薦コメント」

---

ライフ・インプルーブメント

問いかけ：「この仕事がもっと簡単になれば、あなたの生活はどう良くなりますか？」

### Life Improvement:
- [How solution makes life easier or more enjoyable 1]
- [How solution makes life easier or more enjoyable 2]

例：

• 「レポートを仕上げるために残業する代わりに、定時に退社できる」
• 「重要な締め切りを逃すことへのストレスが減る」
• 「雑務ではなく戦略的な仕事に集中できる」

---

ステップ5：優先順位づけと検証

• ペインを強度でランク付けする： どのペインが深刻で、どれが軽度の不快感ですか？
• 必須のゲインとあれば嬉しいゲインを特定する： 何が導入の決め手となり、何が単なるボーナスですか？
• ペルソナと照合する： 異なるペルソナは異なるジョブ／ペイン／ゲインを持っていますか？（skills/proto-persona/SKILL.md を参照）
• データで検証する： より広い対象者に調査を行い、インタビューから得た JTBD のインサイトを確認する

---

例

完全な JTBD の例については examples/sample.md を参照してください。

ミニ例の抜粋：

**Functional Jobs:** Coordinate tasks across a distributed team
**Pains - Challenges:** Team members use different tools, creating silos
**Gains - Savings:** Reduce status reporting time from 3 hours to 15 minutes

---

よくある落とし穴

落とし穴1：ジョブとソリューションの混同

症状： 「Slack を使う必要がある」または「AI 搭載の分析が必要だ」

結果： 根本にあるジョブではなく、ソリューションに固執してしまっています。

解決策： 「なぜ？」を5回問いかける。「Slack が必要だ」→「なぜ？」→「チームとコミュニケーションを取るため」→「なぜ？」→「素早く答えを得るため」→「なぜ？」→「プロジェクトの遅延を避けるため」。

---

落とし穴2：漠然としたジョブ

症状： 「もっと生産性を上げる」または「時間を節約する」

結果： 曖昧すぎて製品の意思決定に役立ちません。

解決策： 具体的にする。「時間を節約する」→「月次レポートの作成にかかる時間を8時間から1時間に短縮する」。

---

落とし穴3：ソーシャル／感情的ジョブの無視

症状： 機能的なジョブのみを記録する

結果： 強力な動機を見逃してしまいます。人は機能的なニーズだけでなく、感情的・社会的なニーズに基づいて購入することがよくあります。

解決策： インタビューで認識や感情について明確に尋ねる。「これを解決したらどう感じますか？」「これを解決したら誰が気づきますか？」

---

落とし穴4：調査なしで JTBD をでっち上げる

症状： 仮定に基づいてテンプレートを埋める

結果： 推測にすぎません。JTBD 分析は、実際の顧客インサイトに基づいている場合にのみ価値があります。

解決策： 「スイッチインタビュー」（以前のソリューションからなぜ乗り換えたかを尋ねる）、コンテキスト inquiry、または課題検証インタビューを実施する。

---

落とし穴5：すべてのペインを同等に扱う

症状： 優先順位をつけずに20個のペインを列挙する

結果： 何を最初に解決すべきかが明確になりません。

解決策： ペインを強度でランク付けする（深刻 vs. 軽度）。「もし1つのペインだけを解決するなら、どれが最も大きなインパクトをもたらしますか？」と問いかける。

---

参考資料

関連スキル

• skills/proto-persona/SKILL.md — これらのジョブ／ペイン／ゲインを持つのは誰かを定義します
• skills/problem-statement/SKILL.md — JTBD は「Trying to」と「But」のセクションに反映されます
• skills/positioning-statement/SKILL.md — JTBD は「that need」ステートメントに反映されます

外部フレームワーク

• Clayton Christensen, Competing Against Luck (2016) — ジョブ理論の原点
• Tony Ulwick, Outcome-Driven Innovation (2016) — ジョブとアウトカムの定量化
• Alexander Osterwalder, Value Proposition Canvas (2014) — 顧客のジョブ／ペイン／ゲインのフレームワーク

Dean の作品

• [該当する場合は Dean Peters の Substack 記事へのリンク]

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/jobs-to-be-done.md を改変したもの。

---

スキルの種類： コンポーネント 推奨ファイル名： jobs-to-be-done.md 推奨配置場所： /skills/components/ 依存関係： skills/proto-persona/SKILL.md を参照 使用元： skills/positioning-statement/SKILL.md、skills/problem-statement/SKILL.md、skills/epic-hypothesis/SKILL.md