jobs-to-be-done
作成者 deanpetersjobs-to-be-doneスキルを使って、顧客フィードバックを「仕事（Jobs）」「痛み（Pains）」「得られるもの（Gains）」の構造化されたJTBD分析に変換します。プロダクトマネジメント、ディスカバリーインタビュー、ポジショニング、未充足ニーズの分析に最適で、ありきたりなプロンプト以上のものを求める場合に向いています。
このスキルは78/100の評価で、ディレクトリ利用者にとって十分有力な掲載候補です。JTBDの実務ワークフローにしっかり役立ち、適用シーンも明確で、汎用プロンプトより実用性のある構成になっています。一方で、実行用のサポートファイルはなく、SKILL.mdとテンプレート／例をもとに運用するため、導入時にはある程度の手間がかかる点は見込んでおく必要があります。
- トリガーと意図が明確で、未充足ニーズの整理、製品の再ポジショニング、発見活動やメッセージングの改善に使う場面がはっきりしています。
- 運用しやすい構成が強みで、顧客の仕事・痛み・得られるものを機能面・社会面・感情面に分け、完全なテンプレートまで備えています。
- 導入判断の材料として優秀で、分量のあるSKILL.mdと実例があるため、空のプロンプトよりも少ない迷いで実行できます。
- インストールコマンドや補助ファイルがないため、ツール連携型ではなく、ドキュメント中心のスキルとして採用する前提になります。
- 根拠は主に概念整理とテンプレートに基づいており、出力の一貫性を強制するスクリプト、ルール、参照情報はありません。
jobs-to-be-done スキルの概要
jobs-to-be-done スキルは、あいまいな顧客課題を、機能的ジョブ・社会的ジョブ・感情的ジョブ・ペイン・ゲインに整理された JTBD 分析へと落とし込むのに役立ちます。顧客が「何を欲しいと言っているか」だけでなく、「なぜその製品を選ぶのか」を理解したいときの、プロダクトマネジメント、メッセージング、ディスカバリーインタビュー、プロダクトの再定位に特に向いています。
単なる汎用プロンプト以上のものを求めているなら、これは有力な導入候補です。このスキルは、表面的な機能要望と、その背後にある動機を切り分けるための再現性のあるレンズを提供します。そのため、ロードマップの議論、チャーン分析、新規プロダクト探索が「意見のぶつかり合い」で止まりがちな場面でも役立ちます。
jobs-to-be-done スキルでできること
顧客コンテキストを、製品やセグメントをまたいで使い回せる実践的なテンプレートに整理します。最大の価値は明快さにあります。どんな仕事を片づけたいのか、どこで摩擦が生まれているのか、そしてユーザーにとっての「より良い」とは何かを、具体的に定義しやすくなります。
jobs-to-be-done スキルが向いている人
プロダクトの探索を改善したい人、あるいは顧客の言葉を行動につながる示唆に変えたい PM、創業者、マーケター、UX リサーチャー、アナリストに向いています。特に、フィードバック自体は集まっているのに、その解釈が整理されていないチームで効果を発揮します。
jobs-to-be-done スキルが強く効く場面
未充足ニーズを理解したいとき、アイデアを検証したいとき、ポジショニングを磨きたいとき、あるいは現行ソリューションを顧客の本当のジョブと比較したいときに選ぶとよいでしょう。顧客の証拠を伴わない、手早いコピー案出しや大づかみなブレストだけが目的なら、あまり向いていません。
jobs-to-be-done スキルの使い方
インストールして、実際の課題に当てる
スキルマネージャーから jobs-to-be-done install の流れで導入し、skills/jobs-to-be-done の repo path を基点に進めます。上流のスキルは軽量でファイルベースなので、最初に読むべきなのは SKILL.md、次に template.md、最後に examples/sample.md です。
具体的な顧客コンテキストを与える
このスキルは、対象ユーザー、状況、意思決定がプロンプト内で明示されていると最もよく機能します。弱い入力例は「自社プロダクトを分析して」です。より強い入力例は「スプレッドシートから移行したあとの支払い漏れに悩むフリーランス向けのサブスクリプション請求ツールについて、Product Management の観点で jobs-to-be-done を使って分析して」です。
漠然とした目的を、使えるプロンプトに落とし込む
良い jobs-to-be-done の使用プロンプトには、次の要素を入れます。
- 対象ユーザーセグメント
- 需要を生むきっかけとなる出来事
- 現在の代替手段または競合
- 改善したい成果
- インタビュー記録やサポートチケットなど、すでに持っている証拠
例: 「プロジェクト納品後に、より早く請求書を送る必要がある小規模代理店のオーナー向けに JTBD 分析を作成してください。ジョブ、ペイン、ゲインに焦点を当て、手動フォローアップがどこで摩擦を生んでいるかを強調してください。」
書く前にテンプレートを読む
template.md には、このスキルが想定する構成が示されています。examples/sample.md には、出力を実用的にするために必要な具体性のレベルが載っています。入力が薄いと、出力もたいてい薄くなります。先にテンプレートを見て、モデルに埋めてもらう前に何が足りないかを把握しておくとよいでしょう。
jobs-to-be-done スキル FAQ
jobs-to-be-done スキルは通常のプロンプトより優れていますか？
はい、一貫性が必要なときは特にそうです。通常のプロンプトでも一度は機能しますが、jobs-to-be-done スキルなら再利用可能な構造があるため、分析ごとのブレが減り、セグメント間の比較もしやすくなります。
この jobs-to-be-done スキルは初心者向けですか？
はい。ユーザーと状況を説明できれば十分です。始めるのに深い JTBD 理論は必要ありませんが、汎用的な出力を避けるだけのコンテキストは必要です。このスキルが最も力を発揮するのは、製品領域は理解していて、より鋭い切り口が欲しいときです。
うまく対応できないことは何ですか？
インタビュー、行動データ、市場調査の代わりにはなりません。入力が社内の意見だけだと、もっともらしく見えても、実際の顧客ジョブを取り逃がすことがあります。また、純粋な技術文書や機能仕様だけを作る用途にも最適ではありません。
Product Management には役立ちますか？
はい。Product Management 向けの jobs-to-be-done スキルは、ディスカバリー、ポジショニング、優先順位付け、メッセージテストに適しています。解決策に飛びつく前に、まず顧客の言葉で問題を定義させるからです。
jobs-to-be-done スキルを改善するには
元になる素材をもっと豊かにする
品質を大きく上げるのは、より良い入力です。インタビューの引用、サポートで多いテーマ、解約理由、商談メモ、あるいはユーザーが自社製品の前に何を試していたかの例を入れてください。文脈が具体的であるほど、スキル側の推測は少なくて済みます。
機能ではなく、ジョブを明確にする
「より良い onboarding」を求めると、ありがちな助言が返ってきやすくなります。一方で、「初回ユーザーがサポートに頼らずに最初の請求書を作成できるようにする」と指定すれば、ジョブが検証可能になるため、jobs-to-be-done の出力はぐっと実用的になります。
ありがちな失敗パターンに注意する
最大の失敗は、機能に寄りすぎてユーザーの状況説明が足りなくなることです。もう一つは、複数のセグメントを 1 つの分析に混ぜてしまうことです。最初の結果が広すぎると感じたら、1 セグメント、1 つのトリガー、1 つの望ましい成果に絞って jobs-to-be-done ガイドを再実行してください。
不足と矛盾を使って反復する
最初の出力のあとに、何が足りないかを問い返して改善します。どのペインが最もコスト高なのか。どのゲインが必須で、どれが「あればうれしい」程度なのか。どの社会的ジョブや感情的ジョブが採用を後押ししているのか。こうした二回目の見直しで、Product Management の意思決定やメッセージングに本当に使える材料が最もよく出てきます。