pm-problem-statement

問題定義スキル

このスキルの動作（最初にお読みください）

これは生成型のスキルであり、問題定義はほとんどのプロダクト作業が静かに失敗する場所です。Claude のデフォルトの動作は、リクエストを問題として言い換えて先に進むことです。その結果、4 つの典型的な失敗が生じます。解決策の変装（「ユーザーにはより良い検索が必要だ」）、曖昧さ（「UX が悪い」「プロセスが非効率だ」）、問題を装ったビジネス成果（「売上を伸ばす必要がある」）、そして原因と誤認された症状（解約率が上昇 →「解約を修正する」）です。いずれも、チームを間違った対象の解決に、上手に閉じ込めてしまいます。優れた問題定義とは、実際のユーザーが経験するギャップであり、文脈に沿い、エビデンスに基づき、測定可能で、いかなる解決策の名前も含まないものです。そこでこのスキルは次のようにゲートします。

1. 実際に手元にあるものを明確にする — 検証済みの問題か、あるいは問題に見えるだけのプロンプト / シグナル / リクエスト / 指標か。
2. 常に真である核心を適用する — 問題を解決策・症状・目標から切り離し、真の原因を見つけ、具体的かつ測定可能にし、エビデンスに基づかせ、ユーザーとビジネスを橋渡しする。
3. 文脈依存の意思決定を明らかにする（どの定義ツールを使うか、今どれだけ測定可能にするか、推論による原因かエビデンスで検証された原因か、スコープ）をトレードオフとともに示す。

その後、検証のために pm-okr-metric-validity-audit（測定可能な要素）と pm-assumption-rigor-audit（想定された根本原因）に引き継ぎます。

スコープ: このスキルは問題定義の成果物を担います。より広範な問題発見プロセスは pm-discovery に、仮説 / 実験の設計は pm-assumption-testing に、定義を完全な仕様にすることは pm-product-spec（pm-spec-quality-audit による監査）に、どの問題に取り組むかの順位付けは pm-prioritization-rigor-audit / pm-prioritization に、ペルソナの深掘りは pm-personas-jtbd に、ユーザーストーリーは pm-user-story に委ねます。

---

ステップ 0 — 定義を書く前に文脈を確立する

不明な場合は尋ねてください。回答なしで進める場合は前提を明記してください:

• 実際に手元にあるものは何ですか？ 動いている指標、機能リクエスト（「X を追加する」）、または曖昧な指示（「オンボーディングを改善する」）は、シグナルまたは解決策であり、問題ではありません。まず、指標・ツール・望ましい成果を除いて言い換えてください。テストはこれです: その文は、問題を経験している本人が言いそうなものですか？
• 誰の問題で、どのような文脈ですか？ 問題には、特定の集団、瞬間、困難が必要です。「エンゲージメントを改善する」は、「新規ユーザーが、必須ステップが不明確なためにセットアップを中断する」として初めて扱えるものになります。
• それを裏付けるエビデンスは何で、原因は既知ですか、それとも想定ですか？ 検証済みのことと推論していることを区別してください。この段階での根本原因は通常、証明された主張ではなく推論による主張です。
• その定義は何に使われますか？ 仕様、ディスカバリー作業、OKR、またはインタビュー / ケースの回答 — これによって、どれだけ測定可能でフォーマルである必要があるかが決まります。

---

常に適用される核心（どのような課題定義にも当てはまる）

• 課題とはギャップであり、決して機能ではない。 課題は、ユーザーの視点から見た現状と望ましい状態との距離を表すものであり、解決策は名指ししません。「〜を追加する必要がある / 〜を構築すべきだ / 製品には〜が欠けている」といった表現を、何が難しく、遅く、混乱を招き、あるいはリスクがあるのかという中立的な記述に置き換えます。テスト: 解決策が1つしかあり得ないなら、それは変装した解決策です — 本当の課題は複数の余地を残します。
• 課題を症状・目標・制約から切り離す。 変動する指標（離脱率、低い採用率）は症状です。「継続率 / 収益を高める」は目標またはビジネス成果です。予算とスケジュールは制約です。課題はそれらの下に位置します — 症状を引き起こすユーザーの困難です。「収益を増やす必要がある」が課題になることは決してありません。
• 表面ではなく真の原因を見つける。 5 Whys / 推論を用いて、症状から根本原因へとたどります。原因は症状を論理的に説明できるものでなければならず、反証に耐える必要があります（「その機能はすでにオンボーディングで示されているので、『ユーザーはそれが存在することを知らない』は成り立たない — むしろ間違ったタイミングで表示されている可能性が高い」）。原因は、問い詰められても一貫性を保つ必要がある説明として扱います。
• 具体的かつ事実に基づく。 「ユーザーは不満だ」では原因も影響も隠れてしまいます。誰が影響を受け、いつ・どこで起こり、具体的な障害は何で、測定可能な結果はどうなるのかを明示します。❌「アプリを再設計する必要がある。」 ✅「商品ページとチェックアウトページ間のナビゲーションが不明瞭なため、ユーザーが購入を完了できない。」
• 測定可能にする。 成功が検証可能で範囲が限定されるように指標を含めます（「1か月以内にカート放棄率を15%減少させる」）。測定可能な要素は、将来の主要な結果（キーリザルト）としても機能します。これがなければ、成功したかどうかを知ることはできません — ただし、見せかけの数値ではなく本物の成果に保ちましょう。
• 社内の思い込みではなく、証拠に基づかせる。 ユーザーシグナル — インタビュー、サポートチケット、分析、セッションリプレイ — に対して課題を検証し、パターンを統合します。定性的なフィードバックを定量的な知見にコード化する（「レポートの45%がチェックアウトエラーに言及している」）ことで、意見が証拠に変わります。チームが信じていることだけに基づいて組み立てられた記述は、まさに失敗のパターンです。
• ユーザーとビジネスをつなぐ。 ユーザーの困難をそのビジネス上の影響（失われたコンバージョン、離脱、コスト、リスク）に結びつけ、注目を集められるようにします — ただし、ユーザーニーズとビジネス目標を競合するものとして扱うことなく。ビジネス上の課題を、その下にあるユーザー課題に翻訳します。「サインアップが足りない」→ なぜユーザーはサインアップしないのか（価値が不明瞭？フローが複雑？信頼？）。
• 使用する前に記述をテストする。 デザイン、エンジニアリング、リーダーシップのそれぞれが、追加の説明なしに、そして解決策を織り込むことなく、誰が影響を受け、なぜそれが重要で、何が問題なのかを理解できるでしょうか。解釈し直す必要が繰り返し生じるなら、それは完成していません。

実用的な構造: 課題 + 結果/影響 + 意図する目標、これに誰が / いつ・どのような文脈で / 測定可能な要素を伴わせる — あるいはユーザー中心の枠組みには4つのW（Who、What、Where、Why）を用います。

---

文脈依存の判断（可視化し、自動適用しない）

それぞれをトレードオフと Step 0 に結びつけた推奨事項とともに提示し、ユーザーに選ばせます。あらゆるプロンプトですべてのフレームワークを実行するのが失敗パターンです — 特定のギャップを埋めるツールに手を伸ばしてください。

判断	適用する場面	避ける／適応させる場面	デフォルトの推奨
どの定義ツールを使うか	ギャップに合わせる: ペルソナ／エンパシーマップ（誰が、どんな感情かが不明確）、ジャーニーマップ（フローのどこか）、5 Whys／親和図（原因が不明確）、前提マッピング（チームの信念が未検証）	すべてのフレームワークを儀式として実行すること。それは問題を成果物の中に埋もれさせます	5 Whys の実施 + Who/What/Where/Why のフレーミング。特定のギャップが残る場合にのみ他を追加する
今どの程度の測定可能性が必要か	仕様に引き渡す、またはリソースをコミットする場合 — 指標を含め、OKR に結びつける	どんな数値も推測になってしまう最も初期のフレーミング	問題が検証された時点で測定可能な要素を追加する。虚栄ではなく反証可能に保つ
推論された原因か、証拠で検証された原因か	インタビュー、ケースワーク、または初期の低リスクなフレーミングでは推論された原因で十分	ユーザーに対して一度も検証されていない原因に実際の構築リソースをコミットすること	まず推論し、仕様の前にユーザー証拠で検証する。 rigor はリスクの大きさに合わせて調整する
曖昧さ: 仮定するか尋ねるか	フレーミングを変えるであろう 1〜2 の質問だけを尋ねる。それ以外は根拠のある仮定を述べる	すべての不明点について尋ねる（停滞する）、または黙って推測する（隠れたリスク）	明示的な仮定を述べる。フレーミングを動かすものだけを尋ねる
スコープ／粒度	分析を進められるよう、特定のセグメント + 瞬間に絞る	広すぎる（「UX を改善する」）または恣意的に狭すぎる	1 つの明確なグループ、状況、困難 — 複数の解決策にとって十分広く、行動するのに十分狭く

---

結果を検証する（オーケストレーション）

ハンドオフでは各レンズをそのインストール可能なスキル name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合、このスキル自体のコアがすでにこれらのルールを備えているため、ブロックせずにそのまま進めてください。

生成または改訂した後、完了と宣言するのではなく、監査レンズに引き渡します。これらは候補レンズです — 姿勢は docs/orchestration-policy.md に従うか、成果物全体を pm-product-review 経由でルーティングしてください。ここでは assumption-rigor が常に関連するレンズ（自動実行） です。その他は成果物に実際に含まれる内容に結びつけて提示されます。ユーザーがこのスキルを特定の 1 つの目的で呼び出した場合は、そのスコープを尊重してください。

• pm-assumption-rigor-audit (自動実行) — 根本原因は検証されるまで仮定です。最もリスクの高い原因の主張は正直に名付けられていますか、そしてその背後にある証拠は単一の逸話や内部の信念ではなく実際のもの（情報源をまたぐパターン）ですか？
• pm-okr-metric-validity-audit (提示 — 測定可能な要素を挙げている場合) — 測定可能な要素: それはユーザーの成功を反映する真の成果であり、反証可能で、虚栄やゲーム可能な数値ではないですか？（これはおそらく主要な結果になる指標でもあります。）

構成（docs/orchestration-policy.md §9 に準拠）: ディスカバリーがまだ基盤となる問題を浮かび上がらせていない場合、その作業（pm-discovery）は上流の入力です。そのステートメントのために設計されたテスト（pm-assumption-testing）とそれがなる仕様（pm-product-spec）は下流です（次に生成することを提案し、自動生成しないでください）。監査が矛盾を浮かび上がらせた場合（例: 利用可能な唯一の指標が虚栄の数値である、または原因が証拠付けられない）、目的に向けて解決してください: 問題ステートメントはチーム全体を正しい問題に向けるために存在します — 便利ではなく、真実で、具体的で、証明可能に保ってください。 アイデアから計画までの完全な構築には、pm-idea-to-plan がこのステップをラダーの残りと順序付け、仕様の前に証拠を強制する構成的なフロントドアです。

---

よくある do/don't パターン

❌ しないほうがよい	✅ するべき
「ユーザーにはもっと優れた検索機能が必要だ」	「新規ユーザーはカテゴリが自分の考え方と一致しないため、関連商品を見つけられず、40% が購入せずに離脱している」
「UX が悪い」/「プロセスが非効率だ」	誰が、いつ、どんな具体的な障害に直面しているのか、そして測定可能な影響を明示する
「収益を増やす必要がある」(ビジネス上の成果)	その下にあるユーザー課題に翻訳する(「ユーザーは支払い前にチェックアウトを離脱している」)
症状(解約)を問題として扱う	5 Whys で原因までたどる。症状はシグナルであり、問題そのものではない
問題に解決策を織り込む	複数の解決策で対処できるようにギャップを記述する
測定不能なままにする	反証可能な指標を含める。それがキーリザルトになる
チームの思い込みに基づいて組み立てる	ユーザーのエビデンスに基づかせる。定性フィードバックを定量調査結果に組み込む
理由づけられた原因を証明済みとして受け入れる	まず推論し、実際のリソースを投入する前に検証する
範囲が広すぎる(「オンボーディングを改善する」)	特定のグループ、瞬間、困難に絞り込む
ステートメントを未確認のまま出荷する	okr-metric-validity + assumption-rigor に引き継ぐ

---

出典レッスン(Uxcel)

• 真の問題を特定する
• 効果的な仕様のための問題定義
• 問題定義ツール
• 問題を仮説にフレーミングする