jtbd-framing

Jobs-to-be-Done のフレーミング

シニアプロダクトリーダーが、Jobs-to-be-Done フレームワークを実践的な方法論として適用するためのプレイブックです。ジョブステートメント、苦境にある瞬間、採用・解雇の基準、機能思考とジョブ思考の違いを扱います。JTBD が明確さをもたらす場面と、形だけの儀式になってしまう場面を率直に示します。

JTBD は、プロダクト分野でよく引用される一方、実践されることの少ないフレームワークのひとつになっています。チームは戦略ドキュメントで引用し、ジョブステートメントのワークショップを開催し、壁一面に貼り出す成果物を作ります。それでも翌四半期には、機能リクエストやペルソナの典型像に基づいた開発を続けています。方法論は評価されても、実践は省かれているのです。

このスキルでは、JTBD を実践的なプロダクト方法論として扱います。このフレームワークが実際にもたらす価値は、ユーザーを好みの寄せ集め（機能リクエスト）や人口統計上の典型像（ペルソナという見せかけ）として捉えるのではなく、ユーザーが何を達成しようとしているのか（ジョブ）を明らかにすることです。苦境にある瞬間や採用・解雇の基準に根差したフレーミングは意思決定につながりますが、ジョブステートメントのワークシートで止まってしまえば、儀式を生むだけです。

このスキルでは、両方のあり方を率直に扱います。JTBD は厳密に適用すれば、ディスカバリー、優先順位付け、ポジショニングにおいて本当に価値を発揮します。チームがジョブステートメントを分析ツールではなく成果物として扱うと、形式的な儀式になってしまいます。

このスキルの語り手は、JTBD をうまく活用し、多くのチームが誤った使い方をする様子も見てきたシニアプロダクトリーダーです。具体的で、このフレームワークが実際にもたらす価値について明確な意見を持ち、過大評価されている点も率直に指摘します。

このスキルを使う場面：ディスカバリーサイクルに JTBD を適用する、ペルソナ主導の優先順位付けをジョブ主導に切り替える、ユーザーがプロダクトに何を期待して採用するのかを軸にポジショニングを再構成する、または組織内の既存の JTBD の取り組みが意思決定につながっているかを監査する。

---

このスキルの目的

このスキルでは、プロダクト業務におけるフレーミング手法として JTBD を扱います。PM スキルとの違いは次のとおりです。

• discovery-research-synthesis は、より広範な統合の手法です。JTBD はその中のフレーミング手法のひとつです。
• **jtbd-framing（このスキル）**は、JTBD の具体的な方法論、その強み、失敗しやすい点を扱います。
• pm-spec-writing は後続の工程です。仕様書では、ジョブを入力情報として参照します。
• creative-direction はポジショニングの領域です。JTBD はポジショニングに役立ちますが、クリエイティブディレクションに取って代わるものではありません。
• roadmap-planning は後続の工程です。ロードマップは機能ではなくジョブを軸に構成できます。

対象読者：シニア PM、プロダクトディレクター、プロダクトストラテジスト、ディスカバリーやポジショニングの業務を担う代理店、JTBD の導入を検討中またはすでに活用している社内チーム。

対象外：その他のプロダクト戦略フレームワーク（Wardley mapping、North Star、OKR）、より広範な統合の手法（discovery-research-synthesis で扱います）、JTBD と混同されることのある人口統計ベースのペルソナ作成。

---

機能リクエスト一覧 vs ペルソナ劇場 vs ジョブ・フレーミング

核となるフレーミングです。

機能リクエスト一覧。「ユーザーは X、Y、Z を求めています。」ユーザーを好みの集約者として捉えます。プロダクトチームは、最も多くリクエストされた機能を開発します。その結果、表明された好みは満たすものの、ユーザーが実際に達成しようとしていたことを見落とすプロダクトが生まれます。ユーザーは、問題を解決する方法をいつも知っているとは限りません。説明するのは症状であり、解決策ではありません。機能一覧主導のプロダクトは、意味のある改善を遂げないまま、漸進的に改良されることがよくあります。

**ペルソナ劇場。**親しみやすい名前を付けた、人口統計に基づくペルソナです。「マーケティングマネージャーのマリア、35歳、都市在住、Pinterest ユーザー、オーツミルクラテ好き。」見せかけにすぎず、意思決定にはつながりません。ペルソナの特性が、ユーザーがプロダクトに求めるものと相関することはほとんどありません。人口統計の詳細が、行動に関する洞察の代わりになっています。実際の現場では、ペルソナは壁のポスターとして掲示されているだけで、実際の優先順位付けの議論で参照されることはほとんどありません。

**ジョブ・フレーミング。**ユーザーは、ジョブを達成するためにプロダクトを雇います。ジョブとは、ユーザーが達成しようとしていることであり、ユーザーがどんな人物か、どんな機能をリクエストするかではありません。このフレーミングにより、苦労する瞬間（ユーザーが代替手段に惹かれるのはいつか）、採用の基準（何があればプロダクトを使い始めるか）、解約の基準（何があれば使うのをやめるか）が明らかになります。その結果、ユーザーの説明ではなく、ユーザーの動機に基づくプロダクトの意思決定が可能になります。

リトマス試験です。チームが議論しているプロダクトの意思決定を一つ取り上げます。JTBD はその意思決定の根拠になれますか？「機能 X を開発すべきでしょうか？」を言い換えると、「機能 X は、ユーザーがどんなジョブを達成するのに役立つでしょうか？これによって対処できる、現在うまくできていないジョブは何でしょうか？」となります。JTBD のフレーミングによって賛否双方の主張が明確になるなら、そのフレーミングには価値があります。議論が解決しないまま用語だけが増えるなら、そのフレーミングは形だけの儀式です。

---

ジョブステートメントの構造

標準的な構造は「[状況] のとき、[動機] を満たしたい。そうすれば [成果] を得られる。」です。

**状況。**ジョブが発生する背景、きっかけ、または瞬間です。人口統計ではなく、ある瞬間を指します。

• 「チームが新機能をリリースしていて、顧客にその内容を伝える必要があるとき……」
• 「四半期ごとの取締役会資料を準備しているとき……」
• 「営業時間外に顧客からエスカレーションを受けたとき……」

**動機。**その状況でユーザーがしようとしていることです。

• 「……何が変わったのか、なぜ重要なのかを説明する明確なお知らせを書きたい……」
• 「……収益とエンゲージメントのデータをまとめて、一貫したストーリーにしたい……」
• 「……夜の時間をあまり損なわずに、優先度を判断して対応したい……」

**成果。**成功がどのような状態か、つまりジョブを達成することでユーザーが実現しようとしていることです。

• 「……そうすれば、混乱した問い合わせでサポート窓口をいっぱいにすることなく、リリースを進められます。」
• 「……そうすれば、取締役会から質問される前に、聞かれそうな内容に答えられます。」
• 「……そうすれば、家で家族と過ごしながら、顧客の懸念に対処できます。」

この構造により、3つすべてのレベルで具体性が求められます。状況、動機、または成果が曖昧だと、何の推進力にもならないジョブステートメントになります。

詳細はreferences/job-statement-structure-patterns.mdをご覧ください。

---

苦労した場面を特定する

ユーザーが苦労した場面では、ジョブが明らかになります。現在の解決策がうまく機能していないとき、代わりに使っているツールでは不十分だと感じるとき、別の方法でそのジョブをこなしたいと強く思うときです。

シグナル。 ユーザーは現在のアプローチで感じている不便さを説明します。回避策を説明します。もっと良いものがあればと思う気持ちを説明します。現在のアプローチがうまくいかなかった具体的な場面を説明します。

方法論。 ディスカバリーインタビューでは、具体的な質問を通じて苦労した場面を掘り起こします。「Xをした最後のときのことを、順を追って教えてください」「その中で最も大変だったことは何ですか」「可能なら、どう違うやり方をしていましたか」。最近の具体的な場面を尋ねるほうが、「普段はどうしているか」という抽象的な説明よりも豊富なデータが得られます。

パターンの認識。 多くのユーザーの話を聞くと、苦労した場面には共通の傾向が見られます。同じ種類の不便さが繰り返し発生します。こうした傾向から、市場で現在うまくこなせていないジョブが明らかになります。

落とし穴。 具体的な場面に基づかずにインタビューを行うチームは、意思決定に活用できない抽象的なジョブの説明を作り出してしまいます。「ユーザーはもっと生産的になりたい」は、苦労した場面ではありません。「必要な切り口がどのダッシュボードにもなかったため、火曜日に3つの異なるダッシュボードから取締役会用の指標をまとめるのに1時間かかった」なら、苦労した場面です。

詳細はreferences/identifying-struggling-moments.mdを参照してください。

---

採用と解約の判断基準

ユーザーが製品を採用する理由（採用）と、製品から乗り換える理由（解約）。この2つの問いを通じて、ユーザーが実際に行う意思決定にこのフレームワークを結び付けます。

採用の判断基準。

• ユーザーが解決しようとしている苦労した場面。
• 最初に検討または試用した代替手段。
• 選んだ製品が答えとなった理由（代替手段と比べて）。
• 期待するジョブの成果：ユーザーが製品を使って何を達成しようとしていたか。

解約の判断基準。

• 選んだ製品を使っていても再発した苦労した場面。
• より良く見え始めた代替手段。
• 「乗り換えを検討している」状態から「乗り換える」状態へとユーザーの決断を促したもの。
• 選んだ製品が安定して提供できなかったジョブの成果。

採用と解約の判断基準が重要な理由。

• 採用の判断基準から、採用を勝ち取るために製品が優れた成果を出すべき点が明らかになります。
• 解約の判断基準から、ユーザーを維持するために製品が保つべき点が明らかになります。
• この2つは異なることがよくあります。採用を勝ち取る機能が、必ずしも解約を防ぐ機能とは限りません。

方法論。 顧客インタビューでは、具体的な質問を通じて採用と解約の判断基準を掘り起こします。「Xを採用する前は何をしていましたか」「乗り換えた理由は何ですか」「明日Xから乗り換えるとしたら、きっかけは何になりますか」。最近の乗り換えに関する決断からは、特に豊富な情報が得られます。ユーザーはその具体的な瞬間を覚えているためです。

詳細はreferences/hire-and-fire-criteria.mdを参照してください。

---

ジョブの機能的・感情的・社会的な側面

ジョブには3つの側面があります。優れた JTBD の取り組みでは、そのすべてが明らかになります。一方、取り組みが不十分だと、ジョブを機能的なものとしてしか捉えません。

機能的な側面。 ユーザーが実務上、何を達成しようとしているか。

• 「四半期ごとの取締役会資料をまとめる。」
• 「チームの OKR の進捗を追跡する。」
• 「新しいエンジニアがコードベースに慣れるよう支援する。」

感情的な側面。 ユーザーがそのジョブに取り組む際にどう感じているか、またはどう感じたいか。

• 「資料が取り繕った内容ではなく、チームの実際の進捗を表していると確信したい。」
• 「OKR の定期確認が遅れているのではなく、そのペースを自分で管理できていると感じたい。」
• 「新しいエンジニアを常時指導することなく、役に立ちたい。」

社会的な側面。 ユーザーがそのジョブに取り組む際、周囲からどう見られたいか。

• 「数字を把握している有能なリーダーとして、取締役会から見られたい。」
• 「約束を必ず果たす人として、直属の部下から見られたい。」
• 「オンボーディングに時間をかけてくれた先輩として、新しいエンジニアから見られたい。」

3つの側面が重要な理由。

• 機能面だけで勝負する製品は、感情面や社会面にも応える代替製品に負けることがよくあります。
• 製品に関する決定は、感情的な側面に左右されることがあります（「ユーザーは自分で管理できていると感じたい」）。機能面だけの分析では、こうした点を見落とします。
• 社会的な側面は、機能的な説明よりもポジショニングに役立ちます。

取り組み方。 ジョブの記述ごとに、3つの側面を明示的に問いかけます。初期のジョブの記述は、ほとんどが機能面だけを扱っています。感情面と社会面を加えることで、製品が実際に対処すべきことが明らかになる場合がよくあります。

詳細はreferences/functional-emotional-social-dimensions.mdをご覧ください。

---

JTBD が明確さをもたらす場面と、形式だけになる場面

率直に言えば、次のとおりです。

JTBD が真価を発揮する場面。

• ディスカバリー。 調査が、苦労する場面や製品を選ぶ・やめる判断に基づいていると、JTBD は、機能リストを使ったディスカバリーでは見落とされるユーザーの動機を明らかにします。ジョブを軸に構成したディスカバリーインタビューでは、機能の好みを軸にしたインタビューよりも豊かなデータが得られます。
• 優先順位付け。 チームがどの作業を優先すべきか議論しているとき、ジョブを用いることで、ユーザーが達成しようとしていることに基づいて議論できます。「この作業は、ユーザーが重要なジョブをよりうまくこなすのに役立つか？」と問えば、機能リクエストの優先順位付けをめぐる駆け引きを乗り越えられます。
• ポジショニング。 マーケティングやセールスで製品が何をするものか説明するとき、ジョブを用いれば、機能リストではなく、顧客が大切にしていることを達成する手段として製品を位置付けられます。

JTBD が形式だけになる場面。

• 成果物としてのジョブ記述ワークショップ。 チームがワークショップを実施して、ジョブの記述を壁一面に作り、その後の意思決定でその成果物に一度も触れません。ワークショップ自体が成果物になり、分析作業は行われていません。
• 分析の厳密さを欠いた、ペルソナの代わりとしてのジョブ記述。 「今は JTBD がある」と言いながら、チームがジョブの記述を分析ツールではなく、名前の付いた人物（ジョブ・ボブ、ジョブ・アリス）のように扱います。
• すべての製品に関する問いに JTBD を義務付けること。 すべての会議が「ジョブは何か？」という問いから始まります。その枠組みが役立たない問いに対してもです。方法論がツールではなく、負担になります。
• コンプライアンスとしての JTBD。 経営書や講演で推奨されたことを理由に組織が JTBD を導入し、チームはフレームワークを使っていると示すために成果物を作ります。しかし、誰も実際の意思決定にそのフレームワークを使いません。

率直な判断基準。 JTBD の分析によって最近の製品決定がどう変わったのかをチームが示せるなら、そのフレームワークは役立っています。チームが JTBD の用語を使っていても、意思決定と JTBD 分析のつながりをたどれないなら、そのフレームワークは形式だけになっています。

---

JTBD を発見、優先順位付け、ポジショニングに活用する

JTBD が真に貢献する 3 つの場面です。

発見。 最近困った場面、採用を決めた理由、利用をやめた理由を軸にインタビューを構成します。インタビュー後に、事前に用意するのではなく、データからジョブの記述を収集します。ユーザーをまたいでジョブを分類し、分類結果からジョブに名前を付けます。より広範な統合の手法については、discovery-research-synthesis と併用してください。

詳細は references/applying-jtbd-to-discovery.md を参照してください。

優先順位付け。 ロードマップ候補を評価する際は、各候補が対応するジョブを明確にします。次のように問いかけます。現在、プロダクトがうまく対応できていないジョブはどれでしょうか？候補のうち、それらのジョブに対応するものはどれで、隣接する領域や無関係な作業に対応するものはどれでしょうか？より広範な優先順位付けの手法については、roadmap-planning と併用してください。

詳細は references/applying-jtbd-to-prioritization.md を参照してください。

ポジショニング。 プロダクトが何のためのものかを伝える際は、機能ではなくジョブを前面に出します。「プロダクトチームがディスカバリーリサーチを意思決定に活用できるようにする」はジョブを軸にした表現です。「コラボレーションツールを備えた AI 搭載のリサーチ統合」は機能を軸にした表現です。より広範なポジショニングの取り組みについては、creative-direction と brand-discovery を併用してください。

詳細は references/applying-jtbd-to-positioning.md を参照してください。

---

よくある失敗パターン

よくある失敗をすばやく確認するには、references/common-jtbd-failures.md を参照してください。

• 「JTBD ワークショップを実施したのに、ロードマップが何も変わりませんでした。」成果物がジョブの記述を作成するワークショップだけになっており、ワークショップ後の分析作業がありません。
• 「ジョブの記述がどれも同じように聞こえます。」ジョブの記述が一般的で、具体的に困った場面に根差していません。インタビューデータに立ち戻りましょう。
• 「ジョブが機能リクエストのように見えます。」「プロダクト X を使っているとき、機能 Y が欲しい」はジョブではありません。ジョブとは、プロダクトに依存せず、ユーザーが達成しようとしていたことです。
• 「ペルソナとジョブがあり、互いに矛盾しています。」ペルソナは人口統計的な属性、ジョブは状況に基づくものです。両者が一致する必要はありません。矛盾する場合、通常はジョブのほうが意思決定において重視されます。
• 「JTBD によれば、すべてを作るべきということになります。」ジョブ間の優先順位付けがなければ、JTBD は多くの機会を特定しますが、どれを選ぶかは決めません。優先順位付けの手法と併用してください。
• 「JTBD が形だけの儀式になったのでやめました。」よくあることです。立て直すには、JTBD を儀式ではなく分析ツールとして使います。効果を発揮する場面でフレームワークを使い、あらゆる場面に無理に当てはめないでください。
• 「ジョブの記述が機能面だけになっています。」感情的な側面と社会的な側面も加えましょう。多くのプロダクトに関する意思決定は、後者の 2 つに左右されます。
• 「ジョブについて合意できません。」多くの場合、異なるジョブを持つセグメントがあることを示しています。セグメント間の違いを明らかにしましょう。
• 「マーケティングコピーでは JTBD の用語を使っていますが、プロダクトには反映されていません。」ポジショニングとプロダクトの間にギャップがあります。マーケティング上の主張が、プロダクトの意思決定を支えるものになっていません。

フレームワーク：JTBDのフレーミングに関する12の検討事項

JTBDを適用する場合や、JTBDの取り組みを監査する場合は、以下の12項目を確認してください。

1. **機能一覧やペルソナ劇場ではなく、ジョブをフレーミングします。**ユーザーはジョブを達成するために製品を選びます。
2. **ジョブステートメントの構造は、状況、動機、成果です。**3つすべてのレベルで具体的にします。
3. **ジョブの根拠となるのは、苦労した瞬間です。**抽象的なものではなく、最近の具体的な瞬間を特定します。
4. **採用基準を特定します。**ユーザーが代替手段ではなく、その製品を選ぶ理由を明らかにします。
5. **利用をやめる基準を特定します。**ユーザーが乗り換える理由（または乗り換える可能性がある理由）を明らかにします。
6. **機能的、感情的、社会的な側面を明らかにします。**機能面だけではなく、3つすべてを扱います。
7. **ジョブはワークショップの成果物ではなく、データから導き出します。**ジョブステートメントは、ホワイトボードでのセッションではなく、インタビューデータから導き出します。インタビューデータがない場合は、データの利用可能性に関するルールに従って不足を明記します。
8. **効果が得られる場面でJTBDを適用します。**ディスカバリー、優先順位付け、ポジショニングに活用し、形式的な儀式にはしません。
9. **セグメント間のジョブの違いを明らかにします。**異なるセグメントが同じ製品に異なるジョブを求める場合、その違いを特定します。
10. **意思決定をJTBD分析にたどれるようにします。**主要な意思決定は、それぞれジョブのフレーミングを通じて説明できるようにします。
11. **JTBDの用語で分析作業を代用しません。**分析を伴わない用語の使用は、形式的な儀式です。
12. **JTBDが役立たない場面を正直に評価します。**フレーミングを使っても役立たない問いはあります。無理に当てはめると、形式的な儀式になります。

このフレームワークの成果は、ユーザーの説明ではなくユーザーの動機を根拠とする製品上の意思決定です。明確さを高める場面ではフレーミングを適用し、形式的な儀式になってしまう場面では控えます。

---

必要なデータを利用できない場合

このスキルの出力は、それだけでは生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、認められる出力は、不足を明記した成果物です。何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを示します。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足を明記すれば、回答として完結します。

---

参考ファイル

• references/job-statement-structure-patterns.md - 状況／動機／成果の構造と、具体例を示します。よくある構造上の問題（曖昧な状況、機能リクエストとしての動機、機能の出力としての成果）も扱います。
• references/identifying-struggling-moments.md - 苦労した瞬間を明らかにするディスカバリー用の質問を示します。ユーザー間のパターン認識や、具体的な瞬間と抽象概念の違いも扱います。
• references/hire-and-fire-criteria.md - 採用基準と利用をやめる基準を明らかにする方法を示します。2つの基準が異なることが多い理由や、最近の乗り換えに関するインタビューの進め方も扱います。
• references/functional-emotional-social-dimensions.md - 各ジョブにおける3つの側面を説明します。機能面だけでは不十分な理由、各側面の具体例、社会的側面がポジショニングに与える影響も扱います。
• references/applying-jtbd-to-discovery.md - ジョブに基づくディスカバリーインタビューの構成を示します。ジョブのクラスタリングや、データからジョブに名前を付ける方法も扱います。discovery-research-synthesis と併用してください。
• references/applying-jtbd-to-prioritization.md - ジョブに基づいてロードマップ候補に優先順位を付ける方法を示します。どのジョブがうまく達成されていないかを特定します。roadmap-planning と併用してください。
• references/applying-jtbd-to-positioning.md - 機能主導のポジショニングとジョブ主導のポジショニングを比較します。製品がユーザーの達成を助けることを前面に出します。creative-direction と併用してください。
• references/common-jtbd-failures.md - 診断と対処法を含む、9つ以上の失敗パターンを示します。共通するパターンである、形式的な儀式としてのJTBDと分析ツールとしてのJTBDを扱います。

締めくくり：機能ではなくジョブを重視する

ジョブ理論（Jobs-to-be-Done）フレームワークは、厳密に適用すれば、利用できるプロダクト手法のなかでも特に有用なものの一つです。一方、儀式のように適用すれば、見せかけだけのものになりかねません。その違いは、フレームワークが意思決定を導いているか、それともドキュメントを飾っているだけかにあります。

機能ではなくジョブを重視することは、プロダクト思考における本質的な転換です。機能リストを基にしたニーズ探索では、ユーザーを好みの集合として扱います。ペルソナの類型では、ユーザーを人口統計上のカテゴリーとして扱います。ジョブを起点とする考え方では、ユーザーを何かを成し遂げようとしている人として扱い、プロダクトを、そのジョブのために雇う（または解雇する）ツールの一つと捉えます。

JTBDの恩恵を受けるチームは、分析作業に真剣に取り組んでいます。苦労している瞬間を基にジョブを定義し、採用・解雇の基準を特定し、機能的・感情的・社会的な側面を明らかにし、データからジョブを導き出し、その考え方が役立つ場面で適用します。分析作業を伴わずにJTBDの用語だけを取り入れるチームが生み出すのは、儀式です。

JTBDの適用が本物か、儀式にすぎないか判断に迷ったら、次のように問いかけてください。最近のプロダクト上の意思決定をJTBD分析までたどれますか。それとも、別の根拠で意思決定が行われる一方で、JTBDの作業も並行して行われていたのでしょうか。前者なら、JTBDは役割を果たしています。後者なら、フレームワークは飾りです。