From sumik
Guides effective user story creation for software projects covering story templates (As a.../I want.../So that...), common mistakes, technical requirements to story conversion, acceptance criteria writing, and story splitting techniques. Use when writing user stories, converting technical requirements to stories, or improving backlog quality. For product management practices (PRD, roadmap, prioritization), use practicing-product-management instead.
npx claudepluginhub sumik5/sumik-claude-plugin --plugin sumikThis skill uses the workspace's default tool permissions.
ユーザーストーリーとは、**ユーザーがシステムに求めるシンプルな説明**である。詳細な技術仕様書ではなく、「会話のプレースホルダー」として機能する。
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
ユーザーストーリーとは、ユーザーがシステムに求めるシンプルな説明である。詳細な技術仕様書ではなく、「会話のプレースホルダー」として機能する。
| 観点 | 正しい理解 | よくある誤解 |
|---|---|---|
| 目的 | ユーザーのニーズを表現する「ターゲット」 | 開発チームへの「タスクリスト」 |
| 詳細度 | ユーザーが望む結果（What） | 実装方法（How） |
| 対象読者 | 技術者・非技術者の全員が理解できる | 開発者向けの技術仕様 |
| 柔軟性 | 会話を通じて深める出発点 | 変更不可能な契約 |
As a [ユーザーの種類]
I want [実現したいこと]
So that [得られるメリット]
✅ ユーザー視点で記述されている（ユーザーインターフェースではなくユーザーの目標） ✅ 自然言語で書かれており、非技術者にも理解できる ✅ 実装の詳細を含まない（データベース・フィールド・ボタン名を記述しない） ✅ ユーザーが視認できる結果を表現している ✅ 適切なサイズ（1スプリント、理想的には1〜2日で完了できる規模）
| 良いストーリー | 避けるべき記述 |
|---|---|
| クレジットカードで支払う | コンポーネントXと決済プロバイダYを統合する |
| 本を購入する | ホームページに「購入」ボタンを追加する |
| 注文が却下された場合に通知を受け取る | 注文却下時に「このテキスト」のエラーダイアログを追加する |
| 検索結果を素早く受け取る | システムを100ユーザー対応にスケールする |
問題を理解する前に実装を定義してしまう。まず「何を解決したいか」を明確にしてから、「どう解決するか」を考える。
「データを入力する」「ボタンをクリックする」は操作手順（How）。「商品を見つける」「注文する」がユーザーの目標（What）。
開発チームに「どのコードを書くか」を指定してしまう。チームは問題を深く理解した上で、最良の解決策を自律的に選択できるべき。
ストーリーは創造的なコラボレーションを促すもの。PO（プロダクトオーナー）と開発者の壁になってはいけない。
詳細な文書よりも対話と会話の方が誤解を防ぐ。ストーリーは会話を始めるきっかけであり、終着点ではない。
1スプリントで完了できないほど大きなストーリーは分割が必要。
「データベースカラム追加」「API統合」は技術タスクであってストーリーではない。「クレジットカード支払い」と「データベースカラム追加」を優先順位比較するのは不可能（リンゴとカエルの比較）。
技術要件の中には必ずユーザー価値が隠れている。掘り出して表現する。
| 技術要件 | ユーザーストーリーへの変換 |
|---|---|
| システムをスケールして、より多くのユーザーに対応する | 注文結果をすばやく受け取れるようにしてほしい |
| ディザスタリカバリを実装する | システム障害中でも注文を続けられるようにしてほしい |
| 最新バージョンにアップデートする | ハッキングされるリスクを最小化してほしい |
変換のメリット: ユーザーニーズ同士を比較して優先順位を決められるようになる。技術タスクとユーザー機能を混在させると優先順位付けができなくなる。
受入条件は、ストーリーが「完了した」と判断するための基準。
Given [前提条件]
When [ユーザーのアクション]
Then [期待される結果]
| 状況 | 対応 |
|---|---|
| 1スプリント（1〜2週間）で完了できない | 分割が必要 |
| 1〜2日で完了できる | 適切なサイズ |
| 「データベースカラム追加」「APIエンドポイント追加」が並んでいる | 技術タスク化している。ユーザー価値に変換を |
| 複数の独立したユーザー目標が1つに混在している | 分割が必要 |
このストーリーの粒度について教えてください:
1. 1スプリント（1〜2週間）で完了できますか?
2. この中に複数の独立したユーザー目標が含まれていますか?
3. ユーザーが実際に価値を感じるのは、この全体ですか? 一部ですか?
| 分割軸 | 説明 | 例 |
|---|---|---|
| ワークフローステップ | ユーザーの操作フローを分割 | 「本を探す」→「カートに追加する」→「購入する」 |
| ポジティブ/ネガティブ | 正常系と異常系を分割 | 「在庫ありで購入」→「在庫なしで通知受信」 |
| ユーザーの種類 | ロールごとに分割 | 「一般ユーザーとして注文」→「管理者として注文確認」 |
| データの変化 | 扱うデータパターンで分割 | 「1冊購入」→「複数冊一括購入」 |
| シンプルから複雑へ | 最小限の機能から始め、段階的に追加 | 「1種類の支払い方法」→「複数の支払い方法に対応」 |
ストーリー作成はプロダクトオーナーだけの仕事ではない。コラボレーションが重要。
| 関係者 | 役割 |
|---|---|
| プロダクトオーナー / 顧客 | ビジョンと優先順位を持つ |
| ドメインエキスパート | 問題領域を深く理解している |
| 開発者 | 技術的な実現可能性と代替案を知っている |
| QA / テスター | エッジケースと品質基準を考える |
| 種類 | 説明 | ストーリーへの影響 |
|---|---|---|
| 必須複雑性 | ユーザーが抱える本質的な問題（例: 税金計算、フライトの乱気流対応） | ストーリーはこちらにフォーカスする |
| 偶発的複雑性 | コンピュータで実装するときの技術的な副産物（UI設計、API、データ保存） | ストーリーには含めない。実装の詳細 |
Good User Stories focus on essential complexity from the user's perspective.