pm-user-story

ユーザーストーリーのスキル

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

これは生成型のスキルです。ユーザーストーリーでは、要件がいつの間にかタスクリストに戻ってしまいがちです。デフォルトの対応は、機能をストーリーとして言い換えることです。「ログイン機能を追加する」や、内容のない「ユーザーとして、送信できるようにボタンがほしい」のように、誰が何を必要としているのか、なぜ必要なのかではなく、何を作るかを説明してしまいます。本当のユーザーストーリーとは、実在するペルソナのニーズに根ざした、小さくテスト可能なユーザー価値の単位であり、チームで「誰が／何を／なぜ」を共有できるようにするとともに、仕様にすでに書かれている内容に何も付け加えないなら、ストーリーを書かないという規律ももたらします。そのため、このスキルでは次の点を確認します。

1. このニーズが誰のもので、実在するものか、ストーリーが何に使われるのかを確認する — ユーザーの実情に根ざしていないストーリーは、仮定を装ったものです。
2. 常に有効な基本原則を適用する — ユーザー価値を起点にし、ストーリーを小さく保って詳細は受け入れ基準に委ね、INVEST に沿ってテスト可能にし、ユーザージャーニー全体にストーリーを対応付け、明確さを何も加えないストーリーは削除します。
3. 状況に応じた判断事項を明らかにする（厳密な定型か自由形式か、そもそもストーリーを書くか、受け入れ基準の詳細度、マップへの分割、コミュニケーション上の表現）と、それぞれのトレードオフを示します。

その後、pm-spec-quality-audit（タスクをストーリーとして記述したもの、テストできないストーリー、追跡可能性の欠如を指摘します）と、pm-assumption-rigor-audit（ユーザーニーズに根拠があるか、仮定にすぎないかを確認します）に引き継ぎます。

対象範囲：このスキルが担当するのはユーザーストーリーの成果物です。ペルソナの作成はpm-personas-jtbdに、根本的な問題の定義はpm-problem-statementに、仕様書／PRD全体と受け入れ基準の詳細度はpm-product-spec（pm-spec-quality-auditが監査）に委ねます。アジャイルのセレモニー、バックログの整理、スプリントの進め方は対象範囲外です。

---

ステップ 0 — ストーリーを書く前にコンテキストを確認する

不明な点は質問します。回答なしで進める場合は、前提を明示します。

• このニーズは誰のもので、実在するものですか？ ストーリーは、調査に基づくペルソナと検証済みのニーズから始まります。「設定を構成する時間がないMaria」のような具体的な説明は、「ユーザーは自動化を好む」よりも適切です。ペルソナやニーズが仮定にすぎない場合は、そのことを明示します。根拠のないストーリーは、その仮定をバックログに持ち込みます。（ペルソナはpm-personas-jtbdで作成します。）
• ニーズの複雑さはどの程度ですか？ 単一で明確なニーズには「[ペルソナ]として、[メリット]を得るために[アクション]したい」という形式が適しています。複数のユーザータイプや段階的なメリットにまたがる機能は、分割するか、自由形式で記述する必要がある場合があります。
• ストーリーを書くことで、PRD／仕様書にすでにある内容以上の明確さが得られますか？ チームが別の場所で十分なコンテキストを得られるなら、ストーリーを書くこと自体が目的になってしまいます。書く価値がある場合にのみ記述します。
• ストーリーは何に使われますか？ バックログ、仕様書、または直近のスプリントのいずれかによって、現時点で追加する受け入れ基準の詳細度が決まります。

---

常に適用する基本原則（どのユーザーストーリーにも当てはまります）

• タスクではなく、ユーザーの価値を軸に考えます。「[ペルソナ]として、[メリット]を得るために[アクション]したい」という表現は、技術的なTODOではなく、意図と価値を示します。❌「ログイン機能を追加する」／「ダッシュボードのパフォーマンスを改善する」。✅「リピーターのユーザーとして、保存したデータにアクセスできるよう、すばやくログインしたい」。各ストーリーは、リリースする機能ではなく、解決すべき問題です。
• **各ストーリーを、実在するペルソナとニーズに基づかせます。**ペルソナからストーリーへと進めます。複雑な問題や初期段階の問題では、まずユーザーの不満を掘り下げ、想定上の障害ではなく、実際の障害を反映したストーリーにします。都合のよさではなく、インサイトを起点に組み立てます。
• **定型文は出発点であり、ルールではないと考えます。**複数のユーザータイプ、複数のアクション、または段階的なメリットを伴う機能は、一文では表現しきれません。誰が、何を、なぜが明確であれば、分割したり自由形式で記述したりしてかまいません。
• **ストーリーは小さな価値の単位にとどめ、詳細は受け入れ基準に記載します。**ストーリーではニーズを示し、フィルターの種類、エッジケース、インタラクションのルールなどの詳細は、後に続く受け入れ基準と仕様に記載します。ストーリーを小さな仕様書のように膨らませないでください。
• **INVESTの原則に沿い、テスト可能にします。**独立していること（Independent）、交渉可能であること（Negotiable）、価値があること（Valuable）、見積もり可能であること（Estimable）、小さいこと（Small）、テスト可能であること（Testable）が重要です。受け入れ基準で「完了」の定義を示し、デザイン、エンジニアリング、QAで成功の定義を共有します（「ユーザーが保存した目的地を追加、表示、削除できる」など）。
• **ユーザージャーニー全体でストーリーを対応づけます。**ストーリーマッピングでは、問題 → 機能 → ユーザーストーリー → タスクという4つのブロックをつなぎ、すべての要件を実際のユーザーニーズに結びつけます。ストーリーごとに仕様を整理すれば、作業の軸を明確に保てます。マップ自体も、正式に文書化する前に共通理解を築くためのツールです。
• **弱いストーリーを見つけて修正します。**背景が不足している、技術的すぎる表現になっている、測定可能な目標がない場合は、タスクをストーリーに見せかけている可能性があります。「誰が・何を・なぜ」に立ち返り、ペルソナに照らして見直し、修正します。
• **明確さを加えないストーリーは書きません。**すべての機能にストーリーが必要なわけではありません。PRDや仕様ですでにチームに必要な背景が伝わっているなら、ストーリーを加えても価値ではなくノイズになります。判断基準は常に、「ほかに記載されていない明確さが加わるか」です。
• **ストーリーを明確に伝えます。**デザインや機能の説明ではなく、平易なプロダクトの言葉で、ユーザー価値と判断を最初に伝えます（「よく使われるフィルターを優先し、選択肢が多すぎる状態を解消する」ではなく、「フィルターコンポーネントを追加した」）。方向性を一つにまとめ、ノイズを取り除いて、関係者が意図をすばやく理解できるようにします。

---

状況に応じて判断する項目（提示するだけで、自動適用しない）

それぞれについて、トレードオフと Step 0 に基づく推奨事項を示し、ユーザーに選んでもらいます。すべてのチケットを機械的に「ユーザーとして……」のテンプレートに当てはめるのは、失敗につながります。

判断項目	適用する場合	避ける／調整する場合	デフォルトの推奨事項
厳密な定型文か、自由形式か	単一のペルソナによる明確なニーズを定型文にする場合	複数のユーザーや複層的な機能を、無理に一文に押し込める場合	デフォルトでは定型文を使います。誰が／何を／なぜ、を一行に収められない場合は、分割するか自由形式にします
そもそもストーリーを書くか	仕様に欠けている、共通認識となる「誰が／何を／なぜ」を補える場合	形式的なドキュメント作成として、チケットごとにストーリーを生成する場合	ほかの場所では得られない明確さを加えられる場合に限り、記述します
現時点での受け入れ条件の詳細度	現在の段階で「完了」を定義するのに十分な受け入れ条件が必要な場合。スプリントや仕様に渡す場合は、より詳細な受け入れ条件を用意します	初期の構想段階で網羅的な受け入れ条件を先回りして作る場合や、受け入れ条件のないストーリーを出す場合	完了を定義する受け入れ条件を付けます。テスト可能性の詳細度や構成は pm-product-spec ／ spec-quality に委ねます
単一のストーリーか、マップに分割するか	複数のアクションやペルソナにまたがる場合、またはスプリント内に完了できないほど大きい場合は分割します（INVEST：Small）	巨大なエピックを一つのストーリーにする場合や、技術タスクのストーリーに過剰に分割する場合	ユーザー価値 に基づいて分割します。問題 → 機能 → ストーリー → タスクをマッピングします
コミュニケーションの枠組み	ステークホルダーへの説明で、意思決定とユーザー価値を先に示す場合	意思決定が埋もれる、デザイン用語や機能一覧を中心にした説明をする場合	まずユーザー価値を述べ、流し読みしやすい構成にし、余計な情報を取り除きます

---

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

引き継ぎでは、各観点をインストール可能なスキルの name で指定します。そのスキルがインストールされている場合に限り呼び出してください。インストールされていない場合、このスキル自体に必要なルールが含まれているため、処理を止めずに続行します。

作成または改訂した後は、完了と宣言するのではなく、監査の観点に渡してください。これらは候補となる観点です。docs/orchestration-policy.md に従って対応するか、成果物全体を pm-product-review に回してください。ここでは assumption-rigor が常に関連する観点（自動実行）であり、その他は成果物の内容に応じて提案されます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。

• pm-assumption-rigor-audit (自動実行) — 各ストーリーの根拠となるペルソナとニーズは、証拠に基づいているか、それとも仮定にすぎないかを確認します。ユーザーが誰で何を必要としているかについて、検証されていない思い込みに基づくストーリーにフラグを立てます。
• pm-spec-quality-audit (提案 — 仕様につながるストーリーを作成する場合) — ここで中心となる仕様チェックです。タスクストーリー（機能をユーザー価値のないストーリーとして言い換えただけのもの）、受け入れ条件がなくテストできないストーリー、要件とユーザーニーズの間でトレーサビリティが崩れている箇所を指摘します。また、ストーリー自体が後続工程に委ねている、受け入れ条件の詳細度とフロー全体の網羅性も担当します。

構成（docs/orchestration-policy.md §9 に準拠）： ストーリーは上流の作業を受けて作られるものであり、それを監査するものではありません。ペルソナ（pm-personas-jtbd）と問題（pm-problem-statement）は上流の入力です。監査の結果、ストーリーが実際にはタスクだったり、想定上のユーザーに依存していたりする場合は、本来の目的に立ち返って解決します。ユーザーストーリーは、実在する人の現実のニーズにチームが応える開発を続けられるようにするものです。誰が恩恵を受けるのか、その理由が書かれていないなら、それはストーリーの服を着たタスクです。 アイデアから計画までを一貫して作成する場合、pm-idea-to-plan が構成全体の入口となり、このステップをほかの段階と順序立てて実行し、仕様作成前の証拠確認を徹底します。

よくあるよい例・悪い例

❌ 悪い例	✅ よい例
「ログイン機能を追加する」／「ダッシュボードのパフォーマンスを改善する」	「継続して利用しているユーザーとして、保存したデータにアクセスできるよう、すばやくログインしたい」
「ユーザーとして、送信できるようにボタンがほしい」	実在するペルソナ、具体的な行動、そしてその行動による価値を明示する
ストーリーの対象となるユーザーをでっち上げる	調査に基づくペルソナと、検証済みのニーズを土台にする
すべての機能を「〜として、…したい」という1文に無理に当てはめる	この形式は基本として使い、複雑なニーズは分割するか、自由形式で記述する
フィルターの種類や例外的なケースをストーリーに詰め込む	ストーリーは小さく保ち、詳細は受け入れ条件に記載する
テストできないストーリーを残す	INVEST に沿って記述し、デザイン、エンジニアリング、QA にとっての「完了」を受け入れ条件で定義する
関連のないストーリーが並ぶだけのバックログ	問題 → 機能 → ストーリー → タスクの関係を整理し、それぞれのニーズを追跡できるようにする
いつもの習慣で、すべてのチケットにストーリーを書く	仕様ですでに十分な背景が示されている場合は、ストーリーを省く
デザインや機能の用語で解決策を説明する	ユーザーにとっての価値を先に示し、プロダクトの意思決定を平易な言葉で伝える
チェックせずにストーリーをリリースする	仕様の品質と前提の厳密さを確認してから引き継ぐ

---

参考資料（Uxcel）

• ユーザーを理解し、ユーザーストーリーを構成する
• 解決策を明確に伝える