user-story

目的

Mike Cohn のユーザーストーリー形式と Gherkin 形式の受け入れ条件を組み合わせ、明確で簡潔なユーザーストーリーを作成します。これを使ってユーザーのニーズを実行可能な開発作業に落とし込み、成果に焦点を当て、プロダクトとエンジニアリングの共通理解を確保し、テスト可能な成功基準を定めます。

これは機能仕様書ではありません。誰が恩恵を受けるのか、何をしようとしているのか、なぜそれが重要なのか、そして機能したとどうすればわかるのかを捉える、会話のきっかけです。

入力

最適な情報： ストーリーで扱う機能またはユーザーニーズ。 あると役立つ情報： ユーザーの役割、望む成果、受け入れ条件で扱う必要があるエッジケース。

呼び出し時に指定された内容（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追加された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。内容を活用し、該当する質問は繰り返しません。

何も決まっていなくても大丈夫です。 このスキルでは、ストーリーと Gherkin 形式の条件を作成する前に、ユーザーが誰で、何を達成しようとしているのかを確認します。

呼び出し例： Write user stories for password reset via SMS for our banking app — include the lockout edge case.

主な概念

Mike Cohn 形式 + Gherkin 形式

ユーザーストーリーは、次の要素を組み合わせます。

ユースケース（Mike Cohn 形式）：

• 〜として： [ユーザーのペルソナ／役割]
• 〜したい： [成果を達成するための行動]
• その結果： [望ましい成果]

受け入れ条件（Gherkin 形式）：

• シナリオ： [シナリオの簡単な説明]
• 前提： [初期コンテキストまたは事前条件]
• 前提： [追加の事前条件]
• もし： [アクションを引き起こすイベント]
• ならば： [期待される成果]

この構成が有効な理由

• ユーザー中心： 誰が恩恵を受け、なぜそれが重要なのかに焦点を当てます
• 成果重視： 「その結果」によって、行動だけでなく提供する価値を強調します
• テスト可能： Gherkin 形式の受け入れ条件は具体的で検証可能です
• 対話的： ストーリーは議論のきっかけであり、最終仕様ではありません
• 共通の言語： プロダクト、エンジニアリング、QA の全員が形式を理解できます

アンチパターン（これは該当しません）

• タスクではありません： 「開発者として、データベースをリファクタリングしたい」（これは技術タスクであり、ユーザー価値ではありません）
• 機能の一覧ではありません： 「ダッシュボード、レポート、分析機能がほしい」（範囲が広すぎるため、分割が必要です）
• 曖昧ではありません： 「より良い体験がほしい」（測定できず、明確な成果がありません）
• 契約ではありません： ストーリーは対話のための仮置きであり、確定した仕様ではありません

使用する場面

• ユーザーのニーズを開発作業に落とし込むとき
• バックログの整理やスプリント計画
• エンジニアリングやデザインに価値を伝えるとき
• 開発前にテスト可能な受け入れ条件を確保するとき

使用しない場面

• 純粋な技術的負債やリファクタリングの場合（代わりにエンジニアリングタスクを使ってください）
• ストーリーの規模が大きすぎる場合（まず分割してください。skills/user-story-splitting/SKILL.md を参照）
• ユーザーの問題を理解する前（まず問題ステートメントを作成してください）

---

適用

ステップ 1：コンテキストを集める

ストーリーを作成する前に、次の情報を確認してください。

• ユーザーのペルソナ： 誰を対象としていますか？（skills/proto-persona/SKILL.md を参照）
• 問題の理解： どのようなニーズに対応しますか？（skills/problem-statement/SKILL.md を参照）
• 望ましい成果： 成功とはどのような状態ですか？
• 制約： 技術、時間、または範囲に関する制限

コンテキストが不足している場合： まず、探索的インタビューまたは問題の検証を行ってください。

---

オプションのヘルパースクリプト（テンプレート生成ツール）

一貫した Markdown のひな形が必要な場合は、CLI 入力から生成できます。このスクリプトは決定論的に動作し、データの取得やファイルの書き込みは行いません。

python3 scripts/user-story-template.py --persona \"trial user\" --action \"log in with Google\" --outcome \"access the app without creating a new password\"

---

ステップ 2：ユースケースを記述する

全項目を記入するには、template.md を使用します。

テンプレートに記入します：

### User Story [ID]:

- **Summary:** [Brief, memorable title focused on value to the user]

#### Use Case:
- **As a** [user name if available, otherwise persona, otherwise role]
- **I want to** [action user takes to get to outcome]
- **so that** [desired outcome]

品質チェック：

• 「As a」の具体性： 特定のペルソナ（例：「トライアルユーザー」）ですか、それとも「ユーザー」のように一般的ですか？
• 「I want to」の明確さ： ユーザーが行うアクションですか、それとも構築する機能ですか？
• 「So that」の成果： ユーザーの動機を説明していますか？ それともアクションを言い換えているだけですか？

よくある間違い：

• ❌ 「ユーザーとして、ログインボタンがほしい。ログインできるようにするため」（アクションの言い換え）
• ✅ 「トライアルユーザーとして、新しいパスワードを作成せずにアプリにアクセスするため、Google でログインしたい」

---

ステップ 3：受け入れ条件を記述する

テンプレートに記入します：

#### Acceptance Criteria:

- **Scenario:** [Brief, human-readable scenario describing value]
- **Given:** [Initial context or precondition]
- **and Given:** [Additional context or preconditions]
- **and Given:** [Additional context as needed]
- **and Given:** [UI-focused context ensuring 'When' can happen]
- **and Given:** [Outcomes-focused context ensuring 'Then' is delivered]
- **When:** [Event that triggers the action—aligns with 'I want to']
- **Then:** [Expected outcome—aligns with 'so that']

品質チェック：

• 複数の Given は問題ありません： 前提条件は積み重ねられます（例：「Given ログインしている」＋「Given カートに商品が入っている」）
• When は 1 つだけ： 複数の「When」が必要なら、複数のストーリーに分ける必要がある可能性があります
• Then は 1 つだけ： 複数の「Then」が必要なら、複数のストーリーに分ける必要があります
• 整合性： 「When」は「I want to」と一致していますか？ 「Then」は「so that」と一致していますか？

注意すべき兆候：

• 複数の When／Then： スコープが広がりすぎている兆候です。ストーリーを分割します（skills/user-story-splitting/SKILL.md を参照）
• 曖昧な Then： 「Then パフォーマンスが向上している」（測定できません。具体的にします）

---

ステップ 4：概要を追加する

ストーリーの価値を表す、短くて覚えやすい概要を記述します：

- **Summary:** [Brief, human-readable title]

例：

• ✅ 「トライアルユーザーが Google でログインできるようにして、登録時の手間を減らす」
• ✅ 「上級ユーザーが時間を節約できるよう、項目を一括削除する」
• ❌ 「削除ボタンを追加する」（機能中心であり、価値中心ではありません）

---

ステップ 5：検証して改善する

• チームに声に出して読み上げる： 誰が、何を、なぜ行うのか、全員が理解できますか？
• 受け入れ条件をテストする： QA がこれをもとにテストケースを作成できますか？
• 分割が必要か確認する： ストーリーが大きすぎると感じたら、skills/user-story-splitting/SKILL.md を使用します
• テスト可能性を確認する： 「Then」が起きたことを証明できますか？

---

例

良い例、悪い例、分割が必要なストーリーの詳しい例は、examples/sample.md を参照してください。

短い例の抜粋：

### User Story 042:

- **Summary:** Enable Google login for trial users to reduce signup friction

#### Use Case:
- **As a** trial user visiting the app for the first time
- **I want to** log in using my Google account
- **so that** I can access the app without creating and remembering a new password

#### Acceptance Criteria:
- **Scenario:** First-time trial user logs in via Google OAuth
- **Given:** I am on the login page
- **and Given:** I have a login account
- **When:** I click the "Sign in with Google" button and authorize the app
- **Then:** I am logged into the app and redirected to the onboarding flow

---

よくある落とし穴

落とし穴 1：ユーザーストーリーを装った技術タスク

症状： 「開発者として、コードをよりきれいにするために API をリファクタリングしたい」

結果： これはエンジニアリングタスクであり、ユーザーストーリーではありません。ユーザーに価値を提供していません。

対処法： ユーザーにとっての成果がないなら、ユーザーストーリーではありません。代わりに、エンジニアリングタスクまたは技術的負債のチケットを使用します。

---

落とし穴 2：「ユーザーとして」（抽象的すぎる）

症状： どのストーリーも「ユーザーとして」で始まる

結果： ペルソナが明確になりません。ユーザーによってニーズは異なります。

対処法： 「トライアルユーザーとして」「有料会員として」「管理者として」など、具体的なペルソナを使用します（skills/proto-persona/SKILL.md を参照）。

---

落とし穴 3：「So that」が「I want to」を言い換えている

症状： 「保存ボタンをクリックしたい。作業を保存できるようにするため」

結果： ユーザーがなぜそれを重視するのかがわかりません。アクションを言い換えているだけです。

対処法： 動機を掘り下げます。「ページがクラッシュしても作業の進捗を失わないように」（実際の成果）。

---

落とし穴 4：複数の When／Then

症状： 「When」が 5 つ、「Then」が 5 つある受け入れ条件

結果： ストーリーが大きすぎます。複数の機能がまとめられている可能性があります。

対処法： skills/user-story-splitting/SKILL.md を使用してストーリーを分割します。それぞれの When／Then の組み合わせを個別のストーリーにするか、少なくとも分割が必要か評価します。

---

落とし穴 5：テストできない受け入れ条件

症状： 「Then ユーザーの体験が向上する」または「Then より速くなる」

結果： QA が成功を検証できません。「完了」の定義が曖昧です。

対処法： 測定可能にします。「Then ページが 2 秒未満で読み込まれる」または「Then ユーザーに成功確認メッセージが表示される」のようにします。

---

参考資料

関連スキル

• skills/user-story-splitting/SKILL.md — 大きなストーリーをより小さなものに分割する方法
• skills/proto-persona/SKILL.md — 「[ペルソナ]として」セクションを定義します
• skills/problem-statement/SKILL.md — ストーリーは検証済みの問題に対処する必要があります
• skills/epic-hypothesis/SKILL.md — エピックはユーザーストーリーに分解されます

オプションのヘルパー

• skills/user-story/scripts/user-story-template.py — 決定論的な Markdown スタブジェネレーター（ネットワークアクセスなし）

外部フレームワーク

• Mike Cohn, User Stories Applied (2004) — 「As a / I want / so that」形式の起源
• Gherkin (Cucumber) — 「Given/When/Then」受け入れ基準形式
• INVEST 基準（Independent, Negotiable, Valuable, Estimable, Small, Testable）

Dean の作品

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

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/user-story-prompt-template.md から改変。

---

スキルの種類: コンポーネント 推奨ファイル名: user-story.md 推奨配置場所: /skills/components/ 依存関係: skills/proto-persona/SKILL.md、skills/problem-statement/SKILL.md を参照 使用元: skills/user-story-splitting/SKILL.md、skills/epic-hypothesis/SKILL.md