requirements-user-story

star 86

ユーザーストーリーを作成し、優先順位付けを行う。SLCでスコープが決まった後、実装計画を立てる前に使用。「ユーザーストーリーを書きたい」「機能を整理したい」「優先順位をつけたい」「バックログを作りたい」などのリクエストで起動。

skanehira By skanehira schedule Updated 2/21/2026
play_arrow Run Skill in Manus View GitHub

name: requirements-user-story description: ユーザーストーリーを作成し、優先順位付けを行う。SLCでスコープが決まった後、実装計画を立てる前に使用。「ユーザーストーリーを書きたい」「機能を整理したい」「優先順位をつけたい」「バックログを作りたい」などのリクエストで起動。

ユーザーストーリー

概要

対話を通じてユーザーストーリーを作成し、以下を生成する：

  1. ユーザーストーリーリスト
  2. 受け入れ基準
  3. 優先順位付け（MoSCoW / ICE）

参照ドキュメント

  • ストーリー作成ガイド: references/story-guide.md
    • 読み込みタイミング: フェーズ2でストーリーを作成する時

ワークフロー

フェーズ1: コンテキストの確認

対象プロダクトと既存ドキュメントを確認する。

1.1 前提ドキュメントの読み込み

Read({ file_path: "docs/PRODUCT_SPEC.md" })
Read({ file_path: "docs/PROBLEM_DEFINITION.md" })

1.2 コンテキストの活用

ファイルが存在する場合:

  • PRODUCT_SPEC.md: プロダクトのスコープ、コア価値を把握
  • PROBLEM_DEFINITION.md: ターゲットユーザー、ジョブを把握

これらの情報を元に、フェーズ2のユーザータイプ特定を効率化。

遷移条件: フェーズ2へ

ファイルが存在しない場合: AskUserQuestionで対象プロダクトを確認。

AskUserQuestion({
  questions: [
    {
      question: "どのプロダクト/機能のユーザーストーリーを作成しますか？",
      header: "対象",
      options: [
        { label: "プロダクトを入力", description: "対象のプロダクトや機能領域" }
      ],
      multiSelect: false
    }
  ]
})

遷移条件: コンテキストが把握できたらフェーズ2へ

フェーズ2: ユーザータイプの特定

ストーリーの主語となるユーザータイプを洗い出す。

AskUserQuestion({
  questions: [
    {
      question: "このプロダクトを使うユーザータイプは誰ですか？（複数可）",
      header: "ユーザータイプ",
      options: [
        { label: "ユーザータイプを入力", description: "例: 開発者、管理者、ゲストユーザー" }
      ],
      multiSelect: false
    }
  ]
})

遷移条件: ユーザータイプが1-3個特定できたらフェーズ3へ

フェーズ3: ストーリーの作成

各ユーザータイプについてストーリーを洗い出す。

ストーリーフォーマット

As a [ユーザータイプ]
I want to [やりたいこと]
So that [得られる価値/理由]

質問パターン:

  • 「[ユーザータイプ]がこのプロダクトで最初にやりたいことは？」
  • 「それができたら、次に何をしたいですか？」
  • 「なぜそれをしたいのですか？」
  • 「それができないと何が困りますか？」
AskUserQuestion({
  questions: [
    {
      question: "[ユーザータイプ]として、何ができるようになりたいですか？\n\nフォーマット: [やりたいこと] → [得られる価値]",
      header: "ストーリー",
      options: [
        { label: "ストーリーを入力", description: "例: SQLを入力する → 改善案を得られる" }
      ],
      multiSelect: false
    }
  ]
})

ストーリーの粒度

  • エピック: 大きな機能群（複数ストーリーの親）
  • ストーリー: 1-3日で実装できる単位
  • タスク: ストーリーを分解した作業単位
エピック: クエリ最適化機能
├── ストーリー: SQLを入力できる
├── ストーリー: AIが改善案を生成する
├── ストーリー: ベンチマーク結果を比較できる
└── ストーリー: 結果をエクスポートできる

遷移条件: 主要なストーリーが10-20個出たらフェーズ4へ

フェーズ4: 受け入れ基準の定義

各ストーリーの完了条件を明確にする。

受け入れ基準フォーマット（Given-When-Then）

Given [前提条件]
When [アクション]
Then [期待結果]

例:

ストーリー: As a 開発者, I want to SQLを入力する, So that 改善案を得られる

受け入れ基準:
- Given ログイン済みの状態で
  When SQLを入力して送信ボタンを押す
  Then AIが改善案を3つ以上提案する

- Given 不正なSQLを入力した場合
  When 送信ボタンを押す
  Then エラーメッセージが表示される

AskUserQuestion({
  questions: [
    {
      question: "このストーリーが「完了」と言えるのはどんな時ですか？",
      header: "受け入れ基準",
      options: [
        { label: "基準を入力", description: "Given-When-Then形式で" }
      ],
      multiSelect: false
    }
  ]
})

遷移条件: 主要なストーリーに受け入れ基準がついたらフェーズ5へ

フェーズ5: 優先順位付け

ストーリーの優先順位を決定する。

MoSCoW法

カテゴリ 説明
Must なければリリースできない
Should 重要だが、なくてもリリース可能
Could あると嬉しい
Won't 今回はやらない 
AskUserQuestion({
  questions: [
    {
      question: "このストーリーの優先度は？",
      header: "MoSCoW",
      options: [
        { label: "Must", description: "必須。これがないとリリースできない" },
        { label: "Should", description: "重要だが、なくてもリリース可能" },
        { label: "Could", description: "あると嬉しい" },
        { label: "Won't", description: "今回はやらない" }
      ],
      multiSelect: false
    }
  ]
})

ICEスコアリング（代替手法）

要素 説明 スコア
Impact ユーザーへの影響度 1-10
Confidence 実現できる確信度 1-10
Ease 実装の容易さ 1-10

ICEスコア = Impact × Confidence × Ease

遷移条件: 全ストーリーに優先度がついたらフェーズ6へ

フェーズ6: ドキュメント生成

# ユーザーストーリー

## ユーザータイプ

| タイプ | 説明 |
|--------|------|
| 開発者 | DBA不在チームの開発者 |

## エピック一覧

1. クエリ最適化機能
2. 結果表示機能
3. ...

## ストーリー一覧

### Must（必須）

#### US-001: SQLを入力できる
- **As a** 開発者
- **I want to** SQLとスキーマを入力する
- **So that** 改善案を得られる

**受け入れ基準**:
- [ ] Given ログイン済み When SQL入力して送信 Then 改善案が表示される
- [ ] Given 不正SQL When 送信 Then エラー表示

**エピック**: クエリ最適化機能

---

### Should（重要）

#### US-002: ...

---

### Could（あると嬉しい）

...

---

### Won't（今回はやらない）

...

## 優先順位サマリー

| 優先度 | ストーリー数 |
|--------|-------------|
| Must | X |
| Should | X |
| Could | X |
| Won't | X |

出力ファイル

Write({
  file_path: "docs/USER_STORIES.md",
  content: userStoriesContent
})

フェーズ7: セルフレビュー（サブエージェント）

生成したドキュメントのレビューをサブエージェントに委譲する。

Task({
  description: "ユーザーストーリーレビュー",
  subagent_type: "general-purpose",
  prompt: `
以下のユーザーストーリードキュメントをレビューし、問題があれば修正してください。

## レビュー対象ファイル
- docs/USER_STORIES.md

## レビュー観点

1. **INVEST基準**: 各ストーリーがIndependent、Negotiable、Valuable、Estimable、Small、Testableか
2. **フォーマットの一貫性**: As a / I want to / So that の形式が守られているか
3. **受け入れ基準の具体性**: Given-When-Then形式で具体的に書かれているか
4. **優先度の妥当性**: MoSCoWの分類が適切か、Must項目が多すぎないか
5. **ストーリーの粒度**: 1-3日で実装可能なサイズか、大きすぎるものはないか

## 出力形式

1. 発見した問題のリスト（問題がない場合は「問題なし」）
2. 各問題の修正内容
3. 修正後のファイル更新（Editツールで修正）

問題がなくなるまでレビューと修正を繰り返すこと。
`
})

ストーリー作成のコツ

良いストーリーの条件（INVEST）

条件 説明
Independent 他のストーリーに依存しない
Negotiable 詳細は交渉可能
Valuable ユーザーに価値がある
Estimable 見積もり可能なサイズ
Small 小さい（1-3日で完了）
Testable テスト可能

避けるべきストーリー

❌ 「データベースを設計する」
   → ユーザー価値がない（技術タスク）

❌ 「ユーザーとしてすべての機能を使いたい」
   → 大きすぎる、具体性がない

❌ 「管理者としてバグを修正したい」
   → ストーリーではない

完了条件

  • ユーザータイプが特定されている
  • ストーリーが10-20個作成されている
  • 主要ストーリーに受け入れ基準がある
  • 全ストーリーに優先度がついている
  • USER_STORIES.mdが生成されている
  • セルフレビューが完了し、問題が解消されている

関連スキル

  • slc-ideation: ストーリー作成前にスコープを決める場合
  • usecase-description: ストーリーを詳細化する場合
  • planning-tasks: ストーリーを実装タスクに分解する場合
Install via CLI
npx skills add https://github.com/skanehira/dotfiles --skill requirements-user-story
Repository Details
star Stars 86
call_split Forks 4
navigation Branch main
article Path SKILL.md
More from Creator
skanehira
skanehira Explore all skills →