User Story Writing

ユーザーストーリー作成スキル

目的

アジャイル／ハイブリッド環境で要件を伝え、開発チームを導く、明確で価値のあるユーザーストーリーを作成します。

使用する場面

• アジャイルまたはハイブリッドのプロジェクト
• スプリント計画とバックログのリファインメント
• 機能を実装可能な単位に分割する
• 開発チームに要件を伝える

ユーザーストーリーの形式

基本テンプレート

As a [user role]
I want [goal/desire]
So that [benefit/value]

拡張テンプレート（推奨）

Title: [Short, descriptive title]

As a [user role]
I want [goal/desire]
So that [benefit/value]

Acceptance Criteria:
- [Criterion 1]
- [Criterion 2]
- [Criterion 3]

Notes:
[Additional context, wireframes, business rules]

Definition of Done:
- [ ] Code complete and peer reviewed
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Acceptance criteria met
- [ ] Documentation updated

INVEST 基準

すべてのユーザーストーリーは、次の条件を満たす必要があります。

• Independent（独立性）：独立して開発・提供できます
• Negotiable（交渉可能性）：詳細を話し合い、改善できます
• Valuable（価値）：ユーザーまたはビジネスに価値をもたらします
• Estimable（見積もり可能性）：チームが必要な作業量を見積もれます
• Small（小規模）：1つのスプリント内に完了できます
• Testable（テスト可能性）：テスト用の受け入れ基準が明確です

ドメイン別の例

Eコマースの例

ストーリー 1：ゲストチェックアウト

Title: Guest Checkout Without Account Creation

As a first-time customer
I want to complete my purchase without creating an account
So that I can checkout quickly without friction

Acceptance Criteria:
- Given I have items in my cart
  When I click "Checkout as Guest"
  Then I can enter shipping and payment info without login
- Given I complete guest checkout
  When I receive order confirmation
  Then I see an option to create an account
- Given my order total is over $5000
  When I try to checkout as guest
  Then I am required to create an account for security

Business Rules:
- Guest checkout not available for orders > $5000
- Email required for order confirmation
- Guest orders linked to email for future reference

Story Points: 8
Priority: Must Have
Sprint: Sprint 3

ストーリー 2：リアルタイムの送料計算

Title: Real-time Shipping Cost Display

As a customer
I want to see shipping costs before entering payment information
So that I know the total cost upfront and avoid surprises

Acceptance Criteria:
- Given I enter a valid shipping address
  When I proceed to shipping method selection
  Then I see all available shipping options with costs
- Given I select a shipping method
  When I view the order summary
  Then the shipping cost is included in the total
- Given the shipping API is unavailable
  When I try to calculate shipping
  Then I see a fallback message with estimated costs

Technical Notes:
- Integrate with ShipStation API
- Cache shipping rates for 5 minutes
- Timeout after 5 seconds, show fallback

Story Points: 5
Priority: Must Have
Sprint: Sprint 3

CRM の例

ストーリー 3：リードの自動スコアリング

Title: Automatic Lead Scoring Based on Behavior

As a sales manager
I want leads to be automatically scored based on their activities
So that my team focuses on the most qualified prospects

Acceptance Criteria:
- Given a lead visits the pricing page
  When the activity is tracked
  Then 15 points are added to their score
- Given a lead's score reaches 60
  When the score is updated
  Then the lead is automatically marked as MQL
- Given a lead's score reaches 75
  When the score is updated
  Then the lead is assigned to a sales rep and rep is notified
- Given I view a lead record
  When I look at the lead score
  Then I can see the scoring breakdown (why this score)

Scoring Rules:
- Demographic: Job title (0-20), Company size (0-15), Industry (0-5)
- Behavioral: Pricing page (15), Whitepaper (10), Webinar (15), Demo request (25)

Story Points: 13
Priority: Must Have
Sprint: Sprint 5

モバイル／Web の例

ストーリー 4：オフラインでの注文表示

Title: View Orders Offline in Mobile App

As a mobile app user
I want to view my order history when offline
So that I can check order details without internet connection

Acceptance Criteria:
- Given I have previously viewed orders while online
  When I open the app offline
  Then I can see my cached order history
- Given I am offline
  When I try to view order details
  Then I see the last synced information with "offline" indicator
- Given I regain internet connection
  When the app detects connectivity
  Then order data is automatically refreshed in background

Technical Notes:
- Cache last 50 orders in local storage
- Use SQLite for offline storage
- Sync on app foreground if connected

Story Points: 8
Priority: Should Have
Sprint: Sprint 7

ERP の例

ストーリー 5：複数レベルの購買承認

Title: Multi-level Purchase Order Approval Workflow

As a procurement manager
I want purchase orders to route through appropriate approval levels
So that spending is controlled according to company policy

Acceptance Criteria:
- Given a PO is created for $1K-$10K
  When the PO is submitted
  Then it routes to department manager for approval
- Given a PO is created for $10K-$50K
  When the PO is submitted
  Then it routes to department manager, then finance director
- Given a PO is created for >$50K
  When the PO is submitted
  Then it routes to department manager, finance director, then CFO
- Given an approver is out of office
  When a PO requires their approval
  Then it automatically routes to their designated backup
- Given an approver rejects a PO
  When the rejection is submitted
  Then the requester is notified with rejection reason

Approval Matrix:
- $0-$1K: Auto-approved
- $1K-$10K: Department Manager
- $10K-$50K: Department Manager → Finance Director
- >$50K: Department Manager → Finance Director → CFO

Story Points: 13
Priority: Must Have
Sprint: Sprint 4

CDP の例

ストーリー 6：顧客 ID の解決

Title: Unify Customer Profiles Across Channels

As a marketing analyst
I want customer data from web, mobile, and CRM to be unified
So that I have a complete view of each customer

Acceptance Criteria:
- Given a customer logs in on web and mobile with same email
  When identity resolution runs
  Then both profiles are merged into single customer record
- Given a customer has multiple emails
  When I manually link the profiles
  Then all activities are consolidated under primary profile
- Given profiles are merged
  When I view the customer record
  Then I see all touchpoints across channels in timeline
- Given a merge conflict occurs (different names, addresses)
  When the system detects conflict
  Then it flags for manual review

Matching Rules:
- Email (exact match) - High confidence
- Phone + Name (fuzzy match) - Medium confidence
- Cookie ID + Email domain - Low confidence

Story Points: 21
Priority: Must Have
Sprint: Sprint 2-3 (2 sprints)

ストーリーの階層

エピック → 機能 → ユーザーストーリー → タスク

エピック：大規模な作業（複数のスプリント）

Epic: Mobile App Customer Self-Service
Goal: Enable customers to manage accounts via mobile app
Timeline: Q1 2026
Stories: 25-30 stories

機能：関連するストーリーのグループ（1～3スプリント）

Feature: Order Management in Mobile App
Stories: View orders, Track shipments, Initiate returns
Sprint: Sprint 5-6

ユーザーストーリー：単一の機能（1スプリント）

Story: View Order History
Tasks: API integration, UI development, Offline caching
Sprint: Sprint 5

タスク：技術的な実装手順（数時間～数日）

Task: Implement order list API endpoint
Estimate: 4 hours

受け入れ基準の形式

Given-When-Then（Gherkin）

Given [context/precondition]
When [action/event]
Then [expected outcome]

例：

Given I am a logged-in customer
When I click "View Orders"
Then I see a list of my orders sorted by date (newest first)

チェックリスト形式

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

例：

- [ ] Order list displays order number, date, total, status
- [ ] Orders are paginated (20 per page)
- [ ] User can filter by status (All, Processing, Shipped, Delivered)
- [ ] User can search by order number
- [ ] Clicking an order opens order details

シナリオベース

Scenario 1: [Happy path]
Scenario 2: [Alternative path]
Scenario 3: [Error case]

ストーリーの分割手法

ストーリーが大きすぎる場合（13ポイント超）、次の観点で分割します。

1. ワークフローのステップ

• 元のストーリー：「ユーザーがチェックアウトを完了できる」
• 分割例：「配送先情報を入力する」「配送方法を選択する」「支払い情報を入力する」「注文内容を確認する」

2. ビジネスルール

• 元のストーリー：「送料を計算する」
• 分割例：「通常配送」「速達配送」「国際配送」

3. CRUD 操作

• 元のストーリー：「商品を管理する」
• 分割例：「商品を作成する」「商品を更新する」「商品を削除する」「商品を表示する」

4. データの種類

• 元のストーリー：「顧客データをインポートする」
• 分割例：「CSV からインポートする」「Excel からインポートする」「API からインポートする」

5. プラットフォーム

• 元のストーリー：「モバイルアプリでチェックアウトする」
• 分割例：「iOS でチェックアウトする」「Android でチェックアウトする」

6. シンプル／複雑

• 元のストーリー：「商品を検索する」
• 分割例：「基本的なキーワード検索」「詳細フィルター」「ファセット検索」

ストーリーの見積もり

ストーリーポイント（フィボナッチ数列：1、2、3、5、8、13、21）

• 1ポイント：ごく小さな変更（数時間）
• 2ポイント：シンプルな機能（半日）
• 3ポイント：わかりやすい機能（1日）
• 5ポイント：中程度の複雑さ（2～3日）
• 8ポイント：複雑な機能（3～5日）
• 13ポイント：非常に複雑（5～8日）— 分割を検討する
• 21ポイント以上：大きすぎるため、分割が必要

Tシャツサイズ（代替方式）

• XS：1～2ポイント
• S：3～5ポイント
• M：8ポイント
• L：13ポイント
• XL：21ポイント以上（分割が必要）

レディの定義（DoR）

ストーリーは次の条件を満たすと、スプリントに着手できる状態です。

• ユーザーストーリーが INVEST 基準を満たしている
• 受け入れ基準が明確で、テスト可能である
• 依存関係が特定され、解決されている
• ワイヤーフレーム／モックアップが用意されている（UI 作業の場合）
• ビジネスルールが文書化されている
• チームによるストーリーの見積もりが完了している
• 優先度が割り当てられている
• 技術的なアプローチが話し合われている

完了の定義（DoD）

ストーリーは次の条件を満たすと完了です。

• コードが完成し、ピアレビューが完了している
• 単体テストが作成されている（カバレッジ 80％超）
• 統合テストに合格している
• すべての受け入れ基準を満たしている
• 手動テストが完了している
• ドキュメントが更新されている
• ステージング環境にデプロイされている
• プロダクトオーナーの承認を得ている

ベストプラクティス

✅ 推奨事項：

• ユーザーの視点で書く
• 実装ではなく価値に焦点を当てる
• ストーリーを小さく、焦点を絞ったものにする
• 明確な受け入れ基準を含める
• ストーリーの作成にチームを参加させる
• スプリント計画の前にストーリーを洗練させる
• ストーリーをエピックや機能に関連付ける

❌ 避けること：

• 技術的なタスクをユーザーストーリーとして書く
• ストーリーを大きくしすぎる（13ポイント超）
• 受け入れ基準を省略する
• 曖昧なストーリーを書く
• 実装の詳細を含める
• 同じスプリント内のストーリー間に依存関係を作る

ツール

Lark

• バックログ管理にLark Baseを使用する
• カスタムフィールドを含むストーリーテンプレートを作成する
• ストーリーをエピックやスプリントに関連付ける
• ストーリーのステータスと進捗を追跡する

Notion

• ユーザーストーリーデータベースを作成する
• スプリント計画にカンバンボードを使用する
• ストーリーを要件やテストケースに関連付ける
• 一貫したストーリー形式のテンプレートを用意する

よくあるパターン

Eコマース

• 顧客として、[ショッピング／チェックアウト機能]を利用したい
• 管理者として、[商品／注文管理]を行いたい
• マーチャントとして、[分析／レポート機能]を利用したい

CRM

• 営業担当者として、[リード／商談管理]を行いたい
• マネージャーとして、[パイプライン／予測]を確認したい
• マーケターとして、[キャンペーン／自動化]を利用したい

ERP

• ユーザーとして、[プロセスの自動化]を行いたい
• 承認者として、[ワークフロー管理]を行いたい
• 管理者として、[設定／セットアップ]を行いたい

モバイル／Web

• モバイルユーザーとして、[外出先で利用できる機能]を使いたい
• ユーザーとして、[レスポンシブ／アクセシブルなUI]を利用したい
• ユーザーとして、[オフライン機能]を利用したい

次のステップ

ユーザーストーリーを作成した後：

1. バックログのグルーミングでチームと一緒に洗練させる
2. 受け入れ基準を作成する（acceptance-criteriaスキルを参照）
3. プランニングポーカーで見積もる
4. 技術的なタスクに分割する
5. UAT用のテストケースに関連付ける

参考資料

• Mike Cohn - User Stories Applied
• INVEST Criteria - Bill Wake
• Agile Alliance - User Story Guidelines
• Scrum Guide - Product Backlog Management