job-story-mapper

ジョブストーリーマッパースキル

機能を書くのはやめましょう。人々が達成したいことを理解しましょう。このスキルは、プロダクト要件やユーザーインタビューを、チームが成果に集中し、アウトプットにとらわれないための、明確なジョブストーリーに変換します。

Jobs-to-be-Done の基本

「ジョブ」とは、特定の状況で顧客が前進するために取り組んでいることです。人々は製品を買うのではなく、ジョブを達成するために製品を雇います。

あらゆるジョブの3つの側面：

• 機能的なジョブ： 実用的なタスク（「A地点からB地点へ移動する」）
• 感情的なジョブ： どのように感じたいか（「正しい選択をしたと確信したい」）
• 社会的なジョブ： どのように見られたいか（「チームから有能なプロフェッショナルだと思われたい」）

優れた製品は、3つすべてに対応します。多くのロードマップが対応するのは、機能的な側面だけです。

---

ジョブストーリーの形式

テンプレート：

[状況／きっかけ]のとき、[動機／目標]したい。それによって、[期待する成果]を実現できる。

ユーザーストーリーではありません： ユーザーストーリーは、役割と機能に焦点を当てます。「[役割]として、[メリット]を得るために[機能]がほしい。」 ジョブストーリーは、状況と動機に焦点を当てます。「[この具体的な状況]のとき、[この機能]がほしい。それによって、[この成果]を達成できる。」

状況が最も重要な部分です。「開発者として」よりも、「スプリントの途中で、PMから進捗を聞かれたとき」のほうが、きっかけをより豊かに表現できます。

---

マッピングのプロセス

ステップ1：中心となるジョブを特定する

一文で表します。あなたの製品が依頼される、中心的なジョブは何ですか？

「[状況]で、[ユーザーの種類]が[成果を達成]できるよう支援する。」

ステップ2：ジョブを手順に分解する

中心となるジョブには、どのようなサブタスクがありますか？ （ジョブマップを使います：定義 → 特定 → 準備 → 確認 → 実行 → 監視 → 修正 → 完了）

ステップ3：各手順のペインポイントを特定する

現在、ジョブがうまくいかないのはどこですか？顧客はどこで回避策を使っていますか？

ステップ4：各ペインポイントについてジョブストーリーを書く

異なる状況と動機の組み合わせごとに、ジョブストーリーを1つ書きます。

ステップ5：プロダクトの機会に対応づける

十分に満たされていないジョブストーリーはどれですか？既存の解決策があるのはどれですか？差別化できるのはどこですか？

---

出力形式

ジョブストーリーマップ — [製品／機能領域] — [日付]

中心的なジョブの記述：

[状況]のとき、[ユーザーの種類]は[中心となるジョブの成果]を達成したい。それによって、[最終的な目標]を実現できる。

---

ジョブマップ：

手順	サブジョブ	現在の解決策	ペインポイント	十分に満たされていないか？
定義	[ユーザーが行うこと]	[使用するツール／方法]	[不満]	高／中／低
特定
準備
確認
実行
監視
修正
完了

---

ジョブストーリー（充足度が低い順）：

ジョブストーリー1 — [状況のラベル]

[具体的な状況]のとき、[動機]したい。それによって、[成果]を実現できる。

機能的な側面：[達成する必要があること] 感情的な側面：[どのように感じたいか] 社会的な側面：[どのように見られたいか]

現在の回避策：[現在行っていること] 痛みの強さ：[高／中／低] 頻度：[この状況が起こる頻度] プロダクトの機会：[これに対応するために構築できるもの]

---

主要なジョブストーリーごとに繰り返します。

機会のスコアリング： 各ジョブストーリーを次の項目で評価します：

• 顧客にとっての重要度（1～10）
• 現在の解決策への満足度（1～10）
• 機会スコア = 重要度 + max(重要度 – 満足度, 0)
• 優先順位づけ：機会スコアが10を超えるもの

---

詳細資料

このスキルには補助ファイルが付属しています。利用可能な場合は使用してください。

• references/situation-mining.md — 状況の掘り下げ — 「When」こそが手法のすべてです。出力を作成する際に適用してください。上記の手法の概要では簡略化されている、調整方法や判断基準が記載されています。
• templates/job-story-canvas.md — 品質チェック項目が含まれた、記入式の成果物テンプレートです。ユーザーが生成を依頼するのではなく、自分でドキュメントを作成したい場合に提供してください。

スコアリング基準（0–40）

このスキルの出力は、引き渡す前に必ず評価してください。32点以上がリリースに適した品質です。

評価項目	0	5	10
状況の具体性	「〜するとき」という節が、役割や一般的な願望（「仕事を管理したいユーザーとして」など）になっています	タスクは示されていますが、具体的な瞬間がありません。きっかけ、時間、感情的な文脈が欠けています	どの状況も具体的で想像しやすい瞬間（「借家人から午後11時にメッセージが届いたとき」など）を示しており、動機がひと目でわかります
寸法の網羅性	機能的なジョブだけが整理され、感情的・社会的な項目は空欄か、記載されていません	3つの項目はすべて記入されていますが、感情的・社会的な内容は感情を表す言葉で機能的なジョブを言い換えただけです	機能的・感情的・社会的な各側面にそれぞれ異なる内容があり、少なくとも1つの非機能的な側面が機会分析に影響しています
代替手段の根拠	現在の代替手段が特定されておらず、ジョブが顧客の現在の行動から切り離されています	代替手段は挙げられていますが、単なる情報として扱われ、そこから何も推測されていません	機会の大きいストーリーにはすべて代替手段が記載され、そのジョブの価値を示す証拠（費やす時間、支払う金額、許容する遅延）として読み取れます
スコアリングと優先順位付けの徹底	機会スコアがないか、重要度／満足度の入力値を使わずにスコアが作られています	スコアは正しく計算されていますが、実現可能性や戦略との適合性を確認せず、そのまま開発順として扱われています	計算式が示され、スコアに矛盾がありません。境界線上のスコアは切り上げず、ロードマップで対応できない高スコアの項目は、開発対象に加えるのではなく戦略上の課題として明示されています

品質チェック

• ジョブストーリーは「〜するとき／〜したい／そうすれば〜できる」形式を使っています（ユーザーストーリー形式ではありません）
• 状況は具体的です（「ユーザーとして」ではなく、実際の瞬間やきっかけを示しています）
• 3つの側面すべてを扱っています：機能的、感情的、社会的
• 各ジョブストーリーの機会スコアを計算しています
• 機会の大きい各ストーリーについて、現在の代替手段を特定しています
• プロダクトの機会は「機能を作ること」ではなく、成果として区別されています

必要な入力情報

以下が提供されていない場合は、ユーザーに尋ねてください。

• 対象となるプロダクトまたは機能領域（例：オンボーディング、チェックアウト、ダッシュボード）
• ユーザーの種類またはペルソナ（誰のジョブを整理しますか？）
• 資料（ユーザーインタビューのメモ、サポートチケット、ディスカバリーの調査結果、または記憶に基づく説明）
• 範囲（プロダクト全体のジョブマップか、単一の機能領域か）

アンチパターン

• 状況と動機の組み合わせではなく、機能を説明するジョブストーリーを書かないでください
• 社会的・感情的な側面を省略しないでください。機能的なジョブだけを整理すると、最も模倣されにくい差別化の機会を見逃します
• 状況を広く定義しすぎないでください（「仕事を管理したいユーザーとして」など）。状況は具体的な瞬間やきっかけである必要があります
• 機会スコアリングと優先順位を混同しないでください。機会スコアが高くても、実現可能性と戦略との適合性を評価する必要があります
• 現在の代替手段を特定せずにジョブマップを作成しないでください。代替手段から、そのジョブが顧客にとってどれほど価値があるかがわかります

ガイドライン

• 機能のためのジョブストーリーではなく、その機能に価値をもたらす状況のジョブストーリーを書いてください
• 状況を特定できない場合は、まだジョブを理解できていません。ユーザー調査に戻ってください
• 社会的・感情的なジョブは見つけにくいものの、多くの場合、最も模倣されにくい差別化要因です
• ジョブストーリーをエンジニアリングチームと共有することを推奨してください。「なぜ」を理解することで、より適切な技術的判断ができるようになります