jobs-to-be-done

Jobs To Be Done の視点から市場、製品、見込み客を分析します。これは Clayton Christensen（『Competing Against Luck』）が提唱し、Tony Ulwick（Outcome-Driven Innovation）が実践手法として体系化したイノベーションフレームワークです。

核心的な洞察: 顧客は製品を購入しているのではありません。特定の状況で前進するために製品を「雇って」いるのです。成功を予測するのは、顧客のデモグラフィックや製品機能ではなく、ジョブを理解することです。

二通りの活用方法:

• 営業/BDR モード: Forces of Progress とスイッチインタビューを使い、見込み客がなぜ乗り換えるのかを理解し、ジョブマップを軸にディスカバリーコールを組み立て、バリュープロポジションをアウトカムステートメントとして表現します
• 戦略モード: ODI の方法論を全面的に使い、アウトカムの重要度と満足度をスコアリングし、未充足の機会を特定し、競合の hiring/firing ダイナミクスを分析します

いつ有効化するか: ユーザーが jobs to be done、JTBD 分析、顧客のジョブ、outcome-driven innovation、forces of progress、スイッチインタビュー、またはなぜ顧客がソリューションを乗り換えるのかについて質問したとき。

<quick_start>

クイックスタート

トリガー: analyze [company/product/market] using JTBD

営業モード（ディスカバリーコール、見込み客リサーチ）:

1. 見込み客が「雇おうとしている」中核的な機能ジョブを定義する
2. Forces of Progress をマッピングする（何が乗り換えを後押ししているのか？）
3. ディスカバリーコール用のスイッチインタビューの質問を生成する
4. バリュープロポジションをアウトカムステートメントとして表現する

戦略モード（市場分析、製品イノベーション）:

1. ジョブステートメントを書く
2. ジョブマップ（8 ステップ）を作成する
3. 15〜30 個のアウトカムステートメントを生成する
4. 重要度と満足度をスコアリングする（ODI アルゴリズム）
5. 上位の未充足アウトカムを特定する
6. Hiring/Firing の競合環境を分析する

例: Analyze video conferencing for hybrid enterprise teams using JTBD </quick_start>

<core_concepts>

中核概念

ジョブとは何か？

ジョブとは、ある特定の状況において人が成し遂げようとしている前進のことです。ジョブには次の特徴があります:

• 時間が経っても安定している — 「速報ニュースを知る」というジョブは 200 年間変わっていません。変わるのはソリューションだけです
• ソリューション非依存 — ジョブステートメントには技術、製品、手法を含めません
• 機能的 + 感情的 + 社会的 — すべてのジョブはこの 3 つの側面を持ちます

ジョブの 3 つの種類

種類	定義	例
機能的	達成すべき実務的なタスク	「ライブ配信中のダウンタイムを削減する」
感情的	その人がどう感じたいか	「イベントの途中で配信が失敗しないと確信したい」
社会的	その人がどう見られたいか	「技術的に有能な制作チームとして見られたい」

重要な区別

概念	定義	例	混同した場合の問題
ジョブ	ある状況における前進	「リモート教室の品質を監視する」	—
ニーズ	文脈に依存する願望	「もっと高速なエンコーダーが必要だ」	ソリューションへの偏りが埋め込まれる
ユーザーストーリー	開発要件	「ユーザーとして、アラートが欲しい」	実装方法を指定してしまう
機能	製品の能力	「60fps での 4K エンコード」	自分たちの製品を説明しており、相手の前進を説明していない

テスト: そこに自社製品、技術、または特定の手法が含まれているなら、それはジョブではありません — ソリューションです。ソリューション非依存になるまで書き直してください。 </core_concepts>

<job_statement>

ジョブステートメント

公式

[When ___], [I want to ___], [so I can ___]

• When: 引き金となる状況（ペルソナではない）
• I want to: 機能ジョブ（ソリューション非依存の動詞 + 目的語）
• So I can: より高次の目的 / 望ましいアウトカム

良いジョブステートメントのルール

1. 技術、製品、ブランド名を含めない
2. 10 年以上安定している（2010 年にそのジョブが存在していたなら、同じように読めるはず）
3. 1 つのステートメントにつき 1 つの中核ジョブ（複雑なジョブは分解する）
4. 能動的な動詞を使う: capture、deliver、ensure、coordinate、monitor

例

ドメイン	ジョブステートメント
動画制作	リモート参加者を交えたライブイベントを制作するとき、すべてのソース間で一貫した映像・音声品質を確保したい。そうすれば、技術的な中断なくプロフェッショナルな配信を届けられる
営業支援	新規見込み客とのディスカバリーコールを準備するとき、相手の現状と課題を素早く理解したい。そうすれば、真のニーズを引き出す適切な質問ができる
IT 運用	重要なシステムのパフォーマンスが低下したとき、根本原因と影響範囲を特定したい。そうすれば、ユーザーに大きな影響が出る前にサービスを復旧できる
</job_statement>

<job_map>

ジョブマップ — 8 つの普遍的なステップ

すべてのジョブはこの 8 つのステップに従います。ディスカバリーコールを構成し、各段階で成果の機会を特定するために活用してください。

ステップ	定義	ディスカバリーの質問
1. 定義	目標を決め、進め方を計画し、リソースを評価する	「[ジョブ]にとって成功とは何か、どのように判断しますか？」
2. 探索	必要なインプットと情報を見つける	「必要な[情報/資料]はどこで見つけますか？」
3. 準備	環境を整え、インプットを整理する	「[ジョブを実行する]前に、どのようなセットアップや準備をしますか？」
4. 確認	実行前に準備が整っていることを検証する	「始める前に、すべての準備ができていることをどのように確認しますか？」
5. 実行	ジョブの中核となる活動を行う	「現在、[ジョブ]を実際にどのように行っているか、順を追って教えてください。」
6. 監視	ジョブが順調に進んでいるかを追跡する	「[ジョブ]の最中に、物事がうまく進んでいるか、問題が起きているかをどのように知りますか？」
7. 修正	状況が変わったときに調整する	「[ジョブ]の途中で問題が起きたとき、修正するために何をしますか？」
8. 完了	終了し、後片付けをし、結果を評価する	「どのように締めくくりますか？[ジョブ]がうまくできたかどうかをどのように知りますか？」

営業での活用: ディスカバリーの際に、見込み客をステップ 1〜8 に沿って導きます。相手が摩擦、回避策、課題を述べる各ステップは、機会のシグナルです。

戦略での活用: 各ステップにつき 2〜4 の成果ステートメントを生成し、包括的な成果セットを構築します（合計 15〜30 の成果）。 </job_map>

<outcome_statements>

成果ステートメント

公式

[Direction] + [metric] + [object of control]

方向性: 最小化、削減、増加、最大化、減少、排除

ルール

• 測定可能であること（時間、確率、数、量などの指標を含む）
• 制御可能であること（ユーザーが影響を与えられるもの）
• ソリューション非依存であること（製品への言及がない）

例

ジョブマップのステップ	成果ステートメント	重要度	満足度
探索	適切なインプットソースを特定するまでの時間を最小化する	9	4
準備	必要なセットアップ手順を漏らす確率を削減する	8	5
実行	実行中に必要な手動調整の数を最小化する	9	3
監視	出力に影響が出る前に問題を検知する能力を高める	10	4
完了	ジョブが正しく完了したことを検証するまでの時間を最小化する	7	6

重要度 = Importance（1〜10）、満足度 = Satisfaction（現在のソリューションへの満足度、1〜10）

よくある間違い

間違い	悪い例	修正後
曖昧すぎる	「もっと簡単にする」	「インプットソースを設定する手順の数を最小化する」
ソリューションが埋め込まれている	「Zoom と OBS を切り替える時間を削減する」	「ソースビューを切り替える時間を最小化する」
測定不能	「監視体験を改善する」	「5 秒以内に品質低下を検知する確率を高める」
</outcome_statements>

<forces_of_progress>

進歩の力

顧客がソリューションを切り替えるとき、4 つの力が働きます。2 つは変化を促し、2 つは変化に抵抗します。

  DRIVING CHANGE                    RESISTING CHANGE
  ─────────────                     ────────────────
  ┌─────────────────┐               ┌─────────────────┐
  │  PUSH            │               │  ANXIETY          │
  │  Current pain    │──────────────▶│  Fear of new      │
  │  "This is broken"│               │  "What if it's    │
  │                  │               │   worse?"         │
  └─────────────────┘               └─────────────────┘
  ┌─────────────────┐               ┌─────────────────┐
  │  PULL            │               │  HABIT            │
  │  New attraction  │──────────────▶│  Comfort of old   │
  │  "That looks     │               │  "I know how this │
  │   better"        │               │   works"          │
  └─────────────────┘               └─────────────────┘

切り替えが起こるのは: 推進力 + 引力 > 不安 + 習慣

BDR クイックリファレンス — ディスカバリー質問集

プッシュ（現在の課題を明らかにする）：

1. 「現在、[業務] の対応で最もストレスを感じるのはどの部分ですか？」
2. 「[現在のソリューション] に裏切られたのは最後にいつですか？そのとき何が起きましたか？」
3. 「魔法の杖を振れるとしたら、まず何を直したいですか？」

プル（新しいソリューションへの引き寄せ）：

1. 「代替手段を検討し始めたきっかけは何でしたか？」
2. 「[業務] の理想的なソリューションはどのようなものでしょうか？」
3. 「他にどなたを検討しましたか？どこが気に入りましたか？」

不安（変化への恐れを軽減する）：

1. 「[現在のソリューション] から乗り換えることについて、どのような懸念がありますか？」
2. 「安心して変更を決断するには、何が満たされている必要がありますか？」
3. 「以前に乗り換えを試みたことはありますか？そのとき何が起きましたか？」

習慣（惰性を乗り越える）：

1. 「[現在のソリューション] はどのくらいの期間使っていますか？」
2. 「[業務] のやり方を変えたら、チームは何と言うでしょうか？」
3. 「チームは現在のシステムのトレーニングを受けていますか？再トレーニングが必要なのは誰ですか？」

営業インサイト： プッシュが弱い場合、見込み客は準備ができていません — 売り込まずに育成しましょう。不安が強い場合、デモは相手の具体的な懸念に直接応えるものでなければなりません。 </forces_of_progress>

<hiring_firing>

採用／解雇分析

顧客は業務を遂行するためにソリューションを「採用」し、失敗すると「解雇」します。この視点から競合環境をマッピングしましょう。

テンプレート

現在採用しているソリューション	採用理由（どの業務のため？）	解雇理由（なぜ失敗する？）	使用されている回避策
手作業のスプレッドシートプロセス	入力の追跡、柔軟性	規模拡大で破綻、エラーが起きやすい	コピー＆ペースト、二重チェック
レガシーなオンプレミスソフトウェア	信頼性、IT 管理	更新が遅い、UX が悪い	並行して使うシャドー IT ツール
競合他社の SaaS	迅速なセットアップ、モダンな UI	エンタープライズ機能の欠如	後付けのカスタム統合
何もしない	コストゼロ、変更リスクなし	業務がうまく遂行されない	不十分な結果を受け入れる

重要な問い：

• 見込み客は現在、この業務のために何を「採用」していますか？
• なぜ現在のソリューションを「解雇」する可能性があるのか？（＝あなたの入口）
• どの回避策が未充足の成果を明らかにしているか？（＝あなたの差別化）
• 「何もしない」は競合か？（多くの場合、最も打ち負かすのが難しい）

気づきにくいインサイト： 最大の競合は、しばしば別の製品ではありません — 見込み客が組み上げた回避策、習慣、そして「これで十分」の組み合わせです。提案する前に、完全な「採用セット」を理解しましょう。 </hiring_firing>

<switch_interview>

スイッチインタビューのタイムライン

見込み客の最初の気づきから最終決定までの意思決定の旅をマッピングします。ボブ・モエスタのデマンドサイド・インタビュー手法に基づいています。

タイムライン

First       Passive      Active       Deciding     Consuming    Satisfaction
Thought     Looking      Looking
  │            │            │            │            │            │
  ▼            ▼            ▼            ▼            ▼            ▼
"Something  "I notice    "I'm         "Comparing   "Using the   "Was it
 isn't       alternatives  actively     options,     new          worth
 working"    in passing"   searching"   getting      solution"    switching?"
                                        buy-in"

フェーズごとの質問

最初の気づき： 「[業務] の現在のやり方がうまくいっていないと最初に気づいたのはいつですか？その瞬間のきっかけは何でしたか？」

受動的な探索： 「積極的に探し始める前に、何か代替手段に気づきましたか？どこで？何が目に留まりましたか？」

能動的な探索： 「『ただ気づく』段階から積極的に探す段階に移ったきっかけは何ですか？何を検索しましたか？誰に話を聞きましたか？」

決定： 「どのように選択肢を絞り込みましたか？最も重要だった基準は何ですか？意思決定には他に誰が関わっていましたか？」

利用： 「オンボーディング／セットアップの体験はどうでしたか？現実は期待と一致していましたか？」

満足： 「振り返ってみて、乗り換えは元々の問題を解決しましたか？良い意味でも悪い意味でも驚いたことは何ですか？」

営業への応用

• 受注案件の振り返り： 買い手と 6 つのフェーズすべてを辿りましょう — 実際に何が成約につながったのかが見えてきます（それはあなたが思っているものとはほとんど違います）
• 失注案件の振り返り： タイムラインのどこで失ったのかを見つけましょう — 最初の気づき（課題なし）か、決定（基準で敗北）か、利用（オンボーディングの失敗）か
• ディスカバリーコール： 最初の気づきと能動的な探索の質問を使って、見込み客が今タイムラインのどこにいるのかを理解しましょう </switch_interview>

<opportunity_algorithm>

機会アルゴリズム（ODI スコアリング）

Tony Ulwick のアウトカムドリブン・イノベーション（ODI）スコアリングは、どのアウトカムが十分に満たされていない（機会が大きい）か、逆に過剰に満たされている（コモディティ化している）かを特定します。

計算式

Opportunity Score = Importance + max(Importance - Satisfaction, 0)

• 重要度（Imp）: 1〜10、このアウトカムがジョブの達成にとってどれほど重要か？
• 満足度（Sat）: 1〜10、現在のソリューションがこれをどれだけうまく満たしているか？
• スコア範囲: 1〜20

解釈

スコア	分類	アクション
>15	未充足 — 重要度が高く、満足度が低い	主要なイノベーションの対象。営業提案ではこれを前面に出す
12-15	適切に充足 — バランスが取れている	参入の前提条件。競合に合わせる必要があり、ここでは差別化できない
<12	過剰充足 — 重要度が低い、または満足度が高い	簡素化・コスト削減。顧客は「十分な品質」に対してより少ない金額しか払わない可能性がある

スコアリング例

#	アウトカムステートメント	Imp	Sat	スコア	分類
1	ライブ配信中に品質低下を検知するまでの時間を最小化する	10	3	17	未充足
2	ソース間で音声同期の問題が発生する可能性を低減する	9	4	14	充足
3	ライブイベント中に必要な手動調整を最小化する	9	3	15	未充足
4	目に見える不具合なくソースを切り替える能力を高める	8	6	10	過剰充足
5	マルチソース録画をセットアップするまでの時間を最小化する	7	5	9	過剰充足

JTBD 機会指数（0〜100 の複合指標）

ブルーオーシャン戦略やビジネスモデルキャンバスのスコアリングとの一貫性を保つため：

def jtbd_opportunity_index(outcomes):
    """Normalize ODI scores to 0-100 composite index."""
    scores = [imp + max(imp - sat, 0) for imp, sat in outcomes]
    max_possible = 20  # imp=10, sat=0
    avg_normalized = sum(s / max_possible for s in scores) / len(scores)

    # Weight by number of underserved outcomes
    underserved_ratio = sum(1 for s in scores if s > 15) / len(scores)

    index = (avg_normalized * 70) + (underserved_ratio * 30)
    return round(index * 100) / 100

# Interpretation:
# 75-100: Massive opportunity — many critical underserved outcomes
# 50-74:  Solid opportunity — clear gaps to exploit
# 25-49:  Moderate — some gaps, market partially served
# 0-24:   Low opportunity — market well-served, compete on cost/convenience

</opportunity_algorithm>

<consumption_chain>

消費チェーン

このジョブに対して顧客がソリューションと関わるライフサイクル全体にわたる摩擦を分析します。

フェーズ	主要な問い
認知	顧客はこのジョブ向けのソリューションが存在することを、まずどのようにして知るのか？
獲得	どのように評価し、購入するのか？購買プロセスの摩擦は何か？
セットアップ	購入から初回利用までどれくらいかかるか？迅速な価値実現を妨げるものは何か？
日常利用	中核となる利用パターンはどのようなものか？どこにペインポイントがあるか？
補完	このソリューションと組み合わせて使う他のツールや回避策は何か？
メンテナンス	このソリューションにはどのような維持・更新・トラブルシューティングが必要か？
廃棄	どのように利用をやめるのか？スイッチングコストやデータのロックインはどうか？

消費チェーンにおける各摩擦点は、潜在的なイノベーションの機会または競争優位性となります。 </consumption_chain>

<example_session>

例：ハイブリッド企業チーム向けのビデオ会議

ジョブステートメント

会議室参加者とリモート参加者の両方がいる会議を調整するとき、全員が平等に見て、聞いて、貢献できるようにしたい。そうすることで、参加者がどこにいても生産的な会議を運営できるようにしたい。

ジョブマップ（主要ステップ）

ステップ	現状	摩擦
準備	IT が会議室の AV を 30 分前に事前チェック	時間がかかるうえ、それでも失敗する
確認	「全員聞こえますか？」という儀式	毎回の会議で最初の 5 分を浪費する
実行	リモート参加者が互いに話し始めて重なる	空間オーディオがなく、カメラのフレーミングも不適切
監視	リモートの音声が劣化しているかどうかを知る方法がない	「途切れていますよ」と言われて初めて気づく
変更	手動でのカメラ切り替え、音量調整	発表者がコンテンツから注意をそがれる

成果上位5項目（スコア付き）

#	成果	重要度	満足度	スコア
1	リモート参加者の音声・映像の問題を検出するまでの時間を最小限にする	10	3	17
2	会議室内の音声がリモート参加者にとって不明瞭になる可能性を下げる	9	4	14
3	会議中に必要となるカメラの手動調整を最小限にする	9	2	16
4	リモート参加者が平等に貢献できる能力を高める	10	4	16
5	ハイブリッド会議前に必要なセットアップ時間を最小限にする	8	5	11

JTBD の機会指数：72/100 — 有望な機会です。5項目のうち3項目でニーズが満たされていません。

進歩を促す力（従来型の会議室システムからの乗り換えを検討する見込み客）

力	根拠
プッシュ	「会議室システムに年間5万ドルを費やしていますが、リモートワーカーからはひどいと言われています。CEOも取締役会で気づきました。」
プル	「AI が話者を自動でフレーミングし、音声をミキシングするデモを見ました。私たちに必要なのはこれです。」
不安	「会議室は40室あります。既存の AV 設備をすべて撤去するのは6か月がかりのプロジェクトです。」
習慣	「AV チームは現行システムを熟知しています。変化には抵抗があります。」

結論： プッシュとプルは強力です。不安は段階的な導入で対処できます。習慣を変えるには、AV チーム内の推進役が必要です。

採用／解雇

ソリューション	採用した理由	解雇した理由
従来型の会議室 AV	信頼性、IT へのなじみやすさ	リモート体験の悪さ
Zoom Rooms	セットアップの簡単さ、使い慣れた UI	AV 品質を制御できる範囲が限られている
OBS ＋カスタム構成	最大限の柔軟性	複雑すぎて不安定
何も使わない（ノート PC のウェブカメラ）	コストゼロ	会議室での体験がひどい
</example_session>

<success_criteria>

成功基準

• ジョブステートメントが [When], [I want to], [so I can] の形式に従っている — 製品、テクノロジー、手法への言及がない
• ジョブマップが、発見のための質問とともに8つすべてのステップを網羅している
• 成果ステートメントが Direction + Metric + Object の式を使い、測定可能である
• 進歩を促す力が、一般論ではなく具体的な根拠／引用とともに整理されている
• ODI の機会スコアが算出されている：Importance + max(Importance - Satisfaction, 0)
• ニーズが満たされていない上位3つの成果が特定されている（スコア > 15）
• 採用／解雇の表で、ジョブの観点から競争環境が整理されている
• JTBD の機会指数が算出されている（複合スコア、0～100）

</success_criteria>

<integration_points>

戦略スキル群

JTBD は、第一原理思考のために他の4つの戦略スキルと連携します。

スキル	関連性
Blue Ocean	ニーズが満たされていない成果（ODI >15）は、Blue Ocean の「創造」および「強化」要素の候補です
BMC	ジョブステートメントは顧客セグメントを定義し、成果ステートメントは価値提案を定義します
Challenger Sale	リフレームのステップは、見込み客が自分に必要だと気づいていない、ニーズが満たされていない成果そのものです。ODI スコアを使って、その洞察を特定します。
NSTTD	調整された質問（「成功とはどのような状態ですか？」など）は、ジョブを発見するための質問です。進歩を促す力は、NSTTD が扱う感情的な動きを示します。

パイプライン： JTBD（どのジョブか？） → Blue Ocean（どこに余地があるか？） → BMC（どのように提供するか？） → Challenger（どのような洞察か？） → NSTTD（どのように伝えるか？） </integration_points>

成果サイドカーを出力する

最後の手順として、~/.claude/skill-analytics/last-outcome-jobs-to-be-done.json に書き込みます。

{"ts":"[UTC ISO8601]","skill":"jobs-to-be-done","version":"1.0.0","variant":"default",
 "status":"[success|partial|error]","runtime_ms":[estimated ms from start],
 "metrics":{"job_statements_created":[n],"outcome_statements":[n],"odi_scores_calculated":[n],"underserved_outcomes":[n]},
 "error":null,"session_id":"[YYYY-MM-DD]"}

一部の段階で失敗していても結果が生成されている場合は、ステータスに "partial" を使用してください。出力が何も生成されていない場合に限り、"error" を使用してください。