pm-use-scenarios

使用シナリオ（実践的フレームワーク：計画 → 使用シナリオ）

ルール： ペルソナの視点から問題を明確に表現します。 使用シナリオは、市場の問題を文脈（現在の結果も含む）に沿った「ストーリー」として示すもので、要件の構成要素の一つです。../pm-copilot/references/framework.md を参照してください。ペルソナは事前に作成しておきます（pm-personas）。

問題カードの構成

疑問詞を各フィールドに対応付けます。

フィールド	疑問詞
[問題名]	どのような問題か
[ペルソナ]	誰が抱えているか
[使用シナリオ]がある	なぜ起きるのか
[頻度]で起きる	いつ起きるのか

問題を捉え直す文（機能リクエストを問題に置き換えるのに便利です）：

**[ペルソナ]は、[重要である理由]から、[状況]において[問題]**に悩まされています。

WHAT と HOW — WHAT に留める

WHAT = 問題 → PM → DEFINE	HOW = 解決策 → Team → DESIGN/BUILD
名前、ペルソナ、使用シナリオ、頻度、市場の証拠、影響	概要、フローチャート、ユースケース、UI、プロトタイプ、エラー条件

使用シナリオはユースケースとは異なります。使用シナリオは問題のストーリーを伝えます。一方、ユースケースは機能仕様におけるすべてのやり取りを列挙します（これはチームの仕事です）。

問題を明確に表現する際の3つの考慮事項

1. 曖昧な表現を避ける — 次の語句は使用しないでください：柔軟、適応可能、ユーザーフレンドリー、TBD、十分、迅速に／すばやく／速く、フォールトトレラント、スケーラブル、できるだけ早く、最大化／最小化／最適化（「-ize」で終わる語）、および／または、など。 それぞれを、具体的で観察可能な表現に置き換えてください。
2. エッジケース（「もし〜だったら？」） — ペルソナは実際にその行動を取るでしょうか？起こらない状況に備えた設計はしないでください。
3. 重要なのは誰か？ — U字曲線では、声の大きい両極端（初心者とエキスパート）は意見を聞く対象ですが、熟練した多数派こそが意見を聞くべき対象です。多数派に向けて書いてください。

ユーザーへのインタビュー（質問をまとめて行う）

1. このシナリオに該当するペルソナと市場の問題はどれですか？
2. これが起きる実際の状況を順を追って教えてください。何がきっかけで、現在はどのように対処し、どのような（望ましくない）結果になっていますか？
3. どのくらいの頻度で起きますか？
4. これが現実の問題であることを示す証拠は何ですか（入力全体での件数など）？また、その影響はどの程度ですか？

成果物テンプレート

# Use Scenarios — <Product / Release>

**Company:** <company>  ·  **Feature / Product:** <feature / product name>
**Author:** <author>  ·  **Date created:** <date>  ·  **Version:** 1.0

## Scenario 1 — <Problem Name>
**Problem Card**
- **Problem Name:** <what>
- **Persona:** <who>
- **Use Scenario:** <why — the situation that causes the problem>
- **Frequency:** <when / how often>

**Day in the life**
<A short first-person narrative: the persona's context, the trigger, what they do today,
and the frustrating current result. Concrete and specific — no ambiguous terms.>

**Market evidence:** <# of documented occurrences across inputs>
**Impact:** <1–5 on the impact scale (or 99999 if contractual)>

## Scenario 2 — <Problem Name>
…

成果物の作成

../pm-copilot/references/artifact-output.md に従ってください。入力内容を確認し、Markdown と .docx のどちらにするかを尋ねて、.md ファイルを作成します。希望があれば、環境に備わっているネイティブな文書作成機能を使って .docx に変換します。次の段階として、これらのシナリオを優先順位付けした pm-requirements にまとめるか、完全版の pm-prd を作成することを提案します。