mcpField
T
thinking-jobs-to-be-done

thinking-jobs-to-be-done

github.com/tjboudreauxマーケティング・グロース1.7k576 回インストール12 週間前に更新
リポジトリ

thinking-jobs-to-be-done について

製品チームが開発、削除、優先順位付け、再ポジショニングを判断するためのJobs to Be Doneスキルです。証拠をもとに、ユーザーが求める進歩、代替手段、成果、反証を整理し、判断につなげます。

主な機能

  1. 01状況と進歩に基づくジョブ定義
  2. 02切り替え要因と代替手段の整理
  3. 03成果指標の設定
  4. 04ユーザージョブに沿った機能評価
  5. 05反証と証拠の不足の確認

活用シーン

  1. 01製品ロードマップの優先順位付け
  2. 02機能の利用率低下の調査
  3. 03ソフトウェアと手作業の代替比較
  4. 04調査に基づく製品ポジショニング

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tjboudreaux/cc-thinking-skills --skill thinking-jobs-to-be-done

インストール後、Claude Code で/thinking-jobs-to-be-doneを入力して読み込まれたか確認します。

詳細

Jobs to Be Done

基本ルール：ユーザーは、ある状況で前進するために解決策を採用します。機能一覧ではなく、ジョブ、推進力、成果、競合する回避策を優先してください。

使用する場面

  • ユーザーニーズが不明確なときに、何を開発し、削り、優先するかを選ぶ
  • リリース済み機能の利用率が低い理由を説明する
  • 同じカテゴリの製品にとどまらず、競合を把握する（メール、スプレッドシート、手作業、何も使わないこと）
  • 求められている前進が争点となっているときのポジショニングや調査

少なくとも1つの証拠ソースが必要です。PRD／仕様書、チケット、サポート／営業の記録、分析データ／ログ、または現在の製品の動作が該当します。該当するものがない場合は、調査の不足を明記してください。引用を捏造してはいけません。

使用しない場面

  • ジョブが判明した後の純粋な実行（バグ修正、スキーマ、CI、パフォーマンスなど）。ジョブを再発見せず、実装してください
  • すでに確定した決定を後付けで正当化する場合。フレームワークの形骸化です
  • エンドユーザーの前進に関する決定がないインフラ／内部作業
  • 未解決の問いが、確定したジョブをどのように実装するかだけの場合

手順

  1. 実行者と状況を明確にする。 誰が解決策を採用するのか、どのようなきっかけとなる状況で、どのくらいの頻度で、どのようなリスクを伴うのかを明らかにします。まれにしか使わない二次的な実行者より、日々、重要度の高いジョブを担う主要な実行者を優先してください。
  2. 解決策ではなく、ジョブを記述する。 次の形式で記述します：[状況]のとき、[前進]したい。そうすれば、[成果]を得られる。 「Slackを使う」「ダッシュボードを追加する」のような、解決策ありきの記述は退けます。証拠が裏付ける場合に限り、機能的、感情的、社会的な側面を捉えてください。
  3. 推進力と切り替えを整理する。 記録から、従来の方法が機能しなくなった要因、新たな前進がもたらす魅力、切り替えを妨げる不安、現状を維持させる習慣を明らかにします。ソフトウェア以外の方法や、何も使わないことも含め、現在採用しているものを列挙してください。
  4. 完了条件と成果指標を定義する。 実行者がジョブの完了をどう判断するかを明らかにします。最小化する成果と最大化する成果を列挙してください（前進までの時間、手戻り、自信、予想外の事態など）。まれで十分な代替手段があるジョブより、頻度が高く十分に満たされていないジョブを優先してください。
  5. 候補をジョブに照らして評価する。 各機能／優先事項について、どのジョブのステップに役立つか、実行者のうちどの程度に当てはまるか、頻度、代替手段の質を確認します。頻度が高く十分に満たされていない側面を優先し、十分な対応がなされているジョブやリスクの低いジョブに対する、よく作り込まれた作業の優先度を下げます。
  6. 最も強い反証を示す。 記述したジョブが誤りであるという最善の根拠を示します（実行者が違う、虚栄指標、プロセスそのものがジョブ、競合が実際には何も使わないことなど）。反証のほうが証拠によく合う場合は、開発を推奨する前にジョブを見直してください。
  7. 終了する。 1つの主要なジョブの記述、競合する選択肢、成果指標に十分な証拠があり、開発やポジショニングの決定を変えられる段階になったら終了します。記録から答えを得られず、次に必要なのが調査だけの場合も終了します。

出力

JTBD の意思決定アーティファクトを作成します：

Job statement: When …, I want to …, so I can …
Performers: primary / secondary (frequency, stakes)
Forces: push / pull / anxiety / habit
Competition: direct | indirect | non-consumption
Outcomes: minimize […] ; maximize […]
Priority implication: build / cut / reposition — because job gap is …
Countercase checked: …
Evidence used / gaps: …

検証

  • 反証する： ジョブの記述を機能名に置き換えても推奨内容が変わらない場合、まだ解決策の領域から抜け出せていません。状況と前進からジョブを捉え直してください。
  • 終了する： 優先順位の決定が安定した後も、ジョブのステップを整理し続けてはいけません。
  • 過剰適用への注意： 純粋な実装タスクや、すでに判明しているジョブでは省略してください。不足している証拠を埋めるために、ユーザーの引用やペルソナを捏造してはいけません。

コメント

Markdown 対応