problem-statement

目的

ユーザーの視点に立ち、誰が、何をしようとしていて、何に阻まれているのか、それはなぜか、そしてどのように感じているのかを捉える、共感を重視したフレームワークを使って問題を明確にします。解決策に飛びつく前に、関係者間で問題への認識をそろえ、機能の要望ではなくユーザーが得たい成果を中心にプロダクトの取り組みを組み立てるために活用します。

これは要件定義書ではありません。解決する価値のある問題に取り組めるようにする、人間中心の問題を描いたものです。

入力

特に役立つ情報： ユーザーが誰で、何に苦労しているのか。 あると役立つ情報： 何に阻まれているのか、それが重要な理由、ユーザーがどう感じているのか、裏付けとなる証拠。

呼び出し時に提示された内容（スキル名の後に入力されたテキスト、貼り付けられたコンテキスト、または末尾に追加された ARGUMENTS: の行など）は、すでに得られた回答として扱います。それらを活用し、内容が重複する質問は省略してください。

手ぶらでも大丈夫です。 このスキルでは、まずユーザーとその目標について尋ねます。具体的な「誰」が定まっていない問題の記述は、隠れ蓑を探している解決策にすぎません。

呼び出し例： 問題の記述：診察室の設備の空き状況がカレンダーに表示されないため、クリニックの予約担当者が診察室を二重予約してしまう。

主な概念

問題を捉えるフレームワーク

Jobs-to-be-Done と共感マッピングに基づき、このフレームワークでは次のように問題を整理します。

問題を捉えるストーリー：

• 私は：［問題を経験しているペルソナを記述します］
• しようとしている：［ペルソナが重視する望ましい成果］
• しかし：［成果を妨げている障壁］
• なぜなら：［問題の根本原因］
• そのため、私はこう感じます：［感情への影響］

背景と制約：

• ［地理的、技術的、時間的、人口統計的な要因］

最終的な問題の記述：

• ［簡潔で共感を示す、単一の要約］

この構成が有効な理由

• ペルソナ中心： ユーザーの視点から問題を見ることを促します
• 成果に焦点を当てる： 「しようとしている」により、タスクではなく望ましい成果が重視されます
• 根本原因の分析： 「なぜなら」により、表面的な症状を越えて根本的な課題を掘り下げます
• 感情への配慮： 「そのため、私はこう感じます」により、問題を人間味のあるものとして捉え、共感を育みます
• 背景を考慮： 制約を記述することで、現実の制限を認識できます

アンチパターン（これは何ではないか）

• 解決策を隠したものではありません： 「AI を活用した分析機能がないことが問題です」は、解決策をこっそり持ち込んでいます
• ビジネス上の問題ではありません： 「売上が下がっている」はユーザーの問題ではなく、症状です
• 機能の要望ではありません： 「ユーザーにはダッシュボードが必要です」は問題ではありません（ユーザーは何をしようとしているのでしょうか？）
• 漠然としたものではありません： 「ユーザーはより良い UX を求めている」では、行動につなげるには曖昧すぎます

使用する場面

• ディスカバリーや問題検証の取り組みを開始するとき
• 解決策の検討に入る前に関係者間の認識をそろえるとき
• エンジニアリング、デザイン、経営チームに問題を共有するとき
• 機能の要望はあるものの、その背景にある問題が不明確なとき
• その問題を解決する価値がある理由を提案するとき

使用しない場面

• ユーザー調査をまだ行っていないとき（推測せず、まずインタビューを行ってください）
• 社内の運用上の問題に取り組むとき（これはユーザー向けの問題を対象としています）
• PRD の代わりとして使うとき（これは問題を捉えるもので、PRD は解決策を定義します）

---

適用

全項目を記入できる構成については、template.md を使用してください。

ステップ 1：ユーザーの背景を把握する

下書きを作成する前に、次の情報がそろっていることを確認してください。

• ユーザーインタビューや調査： 直接の発言、観察された行動、課題
• Jobs-to-be-Done の知見： ユーザーが自分の仕事をさせるために「雇っている」プロダクトとは何か（skills/jobs-to-be-done/SKILL.md を参照）
• ペルソナの明確化： 具体的に誰がこの問題を経験しているのか（skills/proto-persona/SKILL.md を参照）
• 制約に関するデータ： 地理的、技術的、時間的、人口統計的な制限

背景情報が不足している場合： ディスカバリーインタビュー、コンテキスト調査、またはユーザーへの同行観察を行ってください。問題を捏造しないでください。

---

ステップ 2：問題の捉え方を文章にする

ペルソナの視点からテンプレートを記入します。

## Problem Framing Narrative

**I am:** [Describe the key persona, highlighting 3-4 key characteristics]
- [Key pain point or characteristic 1]
- [Key pain point or characteristic 2]
- [Key pain point or characteristic 3]

**Trying to:**
- [Single sentence listing the desired outcomes the persona cares most about]

**But:**
- [Describe the barriers preventing the persona from achieving outcomes]
- [Job-to-be-done or outcome obstruction 1]
- [Job-to-be-done or outcome obstruction 2]
- [Job-to-be-done or outcome obstruction 3]

**Because:**
- [Describe the root cause empathetically]

**Which makes me feel:**
- [Describe the emotions from the persona's perspective]

品質チェック：

• 「私は〜です」の具体性： この人物を思い描けますか？ それとも「多忙なビジネスパーソン」のように漠然としていますか？
• 「〜しようとしている」の明確さ： 測定可能な成果ですか？ それとも作業（活動）ですか？
• 「しかし」の掘り下げ： 本当の障壁ですか？ それとも単なる不便さですか？
• 「なぜなら」の正直さ： 根本原因ですか？ それとも単なる症状ですか？
• 「その結果、〜と感じる」の確かさ： こうした感情は調査に基づいていますか？ それとも思い込みですか？

---

ステップ 3：背景と制約を記録する

## Context & Constraints

- [Enumerate geographic, technological, time-based, or demographic factors]
- [e.g., "Must work offline in rural areas with limited connectivity"]
- [e.g., "Used by non-technical users unfamiliar with complex software"]
- [e.g., "Time-sensitive: decisions must be made within 24 hours"]

品質チェック：

• 関連性： これらの制約は問題に直接影響しますか？
• 具体性： 設計上の判断に役立つほど具体的ですか？

---

ステップ 4：最終的な問題文を作成する

内容を一文にまとめ、力強い問題文にします。

## Final Problem Statement

[Single, concise statement that provides a powerful and empathetic summary]

公式： [ペルソナ] は [望む成果] を実現する方法を必要としています。なぜなら [根本原因] があり、そのため現在 [感情面／実務面への影響] が生じているからです。

例： 「企業の IT 管理者は、ユーザーアカウントを 5 分以内にプロビジョニングする方法を必要としています。現在のプロセスでは手動承認に 2 時間以上かかり、プロジェクトの遅延とエンドユーザーの不満につながっているからです。」

品質チェック：

• 一文であること： 複数の文が必要なら、問題はまだ十分に明確ではありません
• 測定可能であること： 解決できたかどうかを判断できますか？
• 共感を呼ぶこと： 感情に響きますか？
• 共有しやすいこと： 会議で話したとき、関係者がうなずく内容ですか？

---

ステップ 5：検証し、関係者と共有する

• ユーザーに試す： この問題を経験している人に声に出して読んでみましょう。「そう、それです！」という反応が返ってきますか？
• 関係者と共有する： プロダクト、エンジニアリング、デザイン、経営陣と共有しましょう。全員の認識が一致しますか？
• フィードバックを基に反復する： 「それが本当の問題だとは思いません」と言う人がいたら、さらに深掘りしましょう。

---

例

良い問題文と悪い問題文の詳しい例は、examples/sample.md をご覧ください。

短い例：

**I am:** A software developer on a distributed team
**Trying to:** Communicate in real-time with my team without losing context
**But:** Email is too slow and IM is ephemeral
**Because:** No tool combines real-time chat with searchable history
**Which makes me feel:** Frustrated and disconnected

---

よくある落とし穴

落とし穴 1：解決策を忍び込ませる

症状： 「問題は、［特定の機能］がないことです」

結果： 問題を検証する前に、解決策を決めつけてしまいます。

対処法： 機能ではなく、ユーザーが望む成果を中心に捉え直します。「何を実現しようとしているのか？」と尋ねましょう。

---

落とし穴 2：ユーザーの問題に見せかけたビジネス上の問題

症状： 「ユーザーは当社の収益を増やしたい」または「問題は解約率です」

結果： これらは会社の問題であり、ユーザーの問題ではありません。ユーザーはあなたの指標を気にしません。

対処法： ユーザーがなぜ解約するのか、または何があればより多くのお金を使うのかを掘り下げます。ユーザーの視点から捉えましょう。

---

落とし穴 3：ペルソナが漠然としている

症状： 「私は、生産性を高めようとしている多忙なビジネスパーソンです」

結果： 行動につなげるには範囲が広すぎます。どのプロダクトも「多忙なビジネスパーソン」を支援すると謳っています。

対処法： 具体的にします。「私は、スプレッドシートで 50 件以上の見込み客を手作業で管理している営業担当者です。価値の高い商談機会を逃さずに、フォローアップの優先順位を決めようとしています。」

---

落とし穴 4：根本原因ではなく症状を示す

症状： 「UI が分かりにくいから」

結果： 根本にある問題ではなく、症状を説明しています。

対処法： 「なぜ UI が分かりにくいのか？」と尋ねます。根本原因に行き着くまで「なぜ」を問い続けましょう（例：「ユーザーがシステムの仕組みを理解するためのメンタルモデルを持っていないから」）。

---

落とし穴 5：感情をでっち上げる

症状： 「その結果、力が湧き、喜びを感じます」

結果： 実際のユーザーの感情ではなく、マーケティング文句のように聞こえます。

対処法： ユーザーインタビューで実際に聞いた言葉を使います。実際の感情には、「いら立ち」「圧倒される」「不安」「行き詰まり」などがあります。

---

参考資料

関連スキル

• skills/jobs-to-be-done/SKILL.md — 「〜しようとしている」と「しかし」のセクションに役立ちます
• skills/proto-persona/SKILL.md — 「私は〜です」にあたるペルソナを定義します
• skills/positioning-statement/SKILL.md — 問題文がポジショニングの基礎になります
• skills/user-story/SKILL.md — 問題文がストーリーの優先順位付けを導きます

外部フレームワーク

• Clayton Christensen、『Jobs to Be Done』— 成果重視の問題設定の起源
• Osterwalder & Pigneur、『Value Proposition Canvas』— 顧客のペイン／ゲイン／ジョブ
• Dave Gray、『Empathy Mapping』— 感情を捉える手法

Deanの著作

• [該当する場合は、Dean Petersの関連するSubstack記事へのリンク]

出典

• https://github.com/deanpeters/product-manager-promptsリポジトリ内のprompts/framing-the-problem-statement.mdを基にしています。

---

スキルの種類： コンポーネント 推奨ファイル名： problem-statement.md 推奨配置先： /skills/components/ 依存関係： skills/jobs-to-be-done/SKILL.md、skills/proto-persona/SKILL.mdを参照します