英語でユーザーストーリーを書くよう求められたとき、何をどの形式で記述すればいいか迷った経験はないだろうか。
ユーザーストーリー（User Story）はユーザーの視点から機能要件を記述するアジャイル開発の基本文書だ。ストーリー本文・受け入れ基準・見積もり・優先順位の4つの構成要素さえ押さえれば、英語でも問題なく書ける。
この記事では、英語ユーザーストーリーに必要な4つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のスプリント計画やバックログリファインメントで活用できる。
ユーザーストーリーに必要な4つの構成要素
ユーザーストーリー（User Story）はXP（エクストリームプログラミング）が起源で、スクラムのプロダクトバックログ管理に広く使われている。以下の4つが実務で使いやすい構成要素になる。
- ストーリー本文（Story Statement）
- 受け入れ基準（Acceptance Criteria）
- 見積もり（Estimation）
- 優先順位・追加情報（Prioritization & Context）
ユーザーストーリーとタスクの違い
タスクは「APIエンドポイントを実装する」のように技術作業を記述する。ユーザーストーリーは「ユーザーが何を達成したいか」というビジネス価値を記述する。ひとつのユーザーストーリーを実現するために複数のタスクが生まれる。
なぜ英語で書くのか
グローバルチームでは、POが日本在住でエンジニアが海外拠点という構成が珍しくない。英語でユーザーストーリーを書くことで、「誰のどんな課題を解決するか」が全員に正確に伝わり、実装のズレを防げる。
バックログリファインメントとの連携は英語バックログリファインメントの書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
ストーリー本文
| 項目 | 内容 |
|---|---|
| チケットID | （例：PAY-120） |
| ストーリータイトル | （例：Apple Pay決済を完了する） |
| ユーザーストーリー | （例：モバイルユーザーとして、Apple Payで決済を完了したい。なぜなら、カード番号を毎回入力する手間を省いて、より速くチェックアウトできるようにしたいからだ。） |
| ペルソナ | （例：スマートフォンで週1回以上購入するECユーザー） |
| ビジネス価値 | （例：モバイル決済の離脱率を現状12%から5%以下に改善する） |
| 前提条件 | （例：ユーザーがiOSデバイスを使用している / Apple Payが設定済みである） |
ストーリーの3要素（3C）：
- カード（Card）： 1〜2行でストーリーを表現できているか
- 会話（Conversation）： チームが詳細を議論できる情報量か
- 確認（Confirmation）： 受け入れ基準でDoneの定義が明確か
受け入れ基準
Given-When-Then形式（またはチェックリスト形式）で記述する。
Given-When-Then形式：
| No. | Given（前提） | When（操作） | Then（期待結果） |
|---|---|---|---|
| 1 | （例：iOSユーザーがApple Payを設定済みの場合） | （例：決済ページにアクセスした場合） | （例：Apple Payボタンが表示される） |
| 2 | （例：Apple Payボタンが表示されている場合） | （例：Apple Payをタップして認証した場合） | （例：決済が完了し、注文確認画面に遷移する） |
| 3 | （例：Apple Pay認証に失敗した場合） | （例：決済ボタンをタップした場合） | （例：エラーメッセージが表示され、別の決済方法を選択できる） |
| 4 | （例：AndroidユーザーまたはApple Pay非対応ブラウザの場合） | （例：決済ページにアクセスした場合） | （例：Apple Payボタンが表示されない） |
完了の定義（DoD）： （例：コードレビュー完了 / ユニットテスト合格 / ステージング環境での動作確認 / アクセシビリティチェック完了）
見積もり
| 項目 | 内容 |
|---|---|
| ストーリーポイント | （例：8） |
| Tシャツサイジング | （例：M） |
| 見積もり根拠 | （例：Apple Pay JS APIの調査2日・統合実装3日・テスト2日。類似チケットPAY-108（5pt）より複雑なため8ptに設定。） |
| 不確実性 | （例：中。決済プロバイダーのApple Pay APIドキュメントが古い可能性があり、調査コストが変動する可能性がある。） |
| スプリントに収まるか | （例：はい。1スプリント（10営業日）で完了見込み。） |
優先順位・追加情報
| 項目 | 内容 |
|---|---|
| 優先度 | （例：高） |
| MoSCoW分類 | （例：Must Have） |
| 依存関係 | （例：PAY-108（Apple Pay APIキー取得）が完了していること） |
| 関連チケット | （例：PAY-121（Google Pay対応）/ PAY-115（エラーメッセージ日本語化）） |
| 実施スプリント候補 | （例：Sprint 44） |
| ステークホルダー | （例：PMの山田が承認済み / デザイナーの田中がUIレビュー中） |
英語版テンプレート（コピペOK）
Story Statement
| Item | Details |
|---|---|
| Ticket ID | (e.g., PAY-120) |
| Story Title | (e.g., Complete a payment with Apple Pay) |
| User Story | (e.g., As a mobile user, I want to complete a payment using Apple Pay so that I can check out faster without entering my card number every time.) |
| Persona | (e.g., E-commerce shopper who makes purchases on a smartphone at least once a week) |
| Business Value | (e.g., Reduce mobile checkout drop-off rate from 12% to under 5%.) |
| Preconditions | (e.g., User is on an iOS device / Apple Pay is already configured on the device.) |
The 3 Cs of a User Story:
- Card: Can the story be expressed in 1–2 lines?
- Conversation: Does it give enough context for team discussion?
- Confirmation: Do the acceptance criteria clearly define “Done”?
Acceptance Criteria
Using the Given-When-Then format (or checklist format):
Given-When-Then:
| No. | Given | When | Then |
|---|---|---|---|
| 1 | (e.g., An iOS user has Apple Pay configured) | (e.g., They visit the checkout page) | (e.g., The Apple Pay button is displayed.) |
| 2 | (e.g., The Apple Pay button is displayed) | (e.g., The user taps Apple Pay and authenticates) | (e.g., Payment completes and the user is redirected to the order confirmation screen.) |
| 3 | (e.g., Apple Pay authentication fails) | (e.g., The user taps the payment button) | (e.g., An error message is displayed and the user can select another payment method.) |
| 4 | (e.g., The user is on Android or an unsupported browser) | (e.g., They visit the checkout page) | (e.g., The Apple Pay button is not displayed.) |
Definition of Done (DoD): (e.g., Code review complete / Unit tests passing / Verified in staging / Accessibility check complete)
Estimation
| Item | Details |
|---|---|
| Story Points | (e.g., 8) |
| T-Shirt Size | (e.g., M) |
| Rationale | (e.g., 2 days for Apple Pay JS API research, 3 days for integration, 2 days for testing. Sized at 8 pts — slightly more complex than PAY-108 (5 pts).) |
| Uncertainty | (e.g., Medium. Payment provider’s Apple Pay API docs may be outdated, which could increase research time.) |
| Fits in One Sprint? | (e.g., Yes. Estimated to complete within 10 business days.) |
Prioritization & Context
| Item | Details |
|---|---|
| Priority | (e.g., High) |
| MoSCoW | (e.g., Must Have) |
| Dependencies | (e.g., PAY-108 (Apple Pay API key provisioning) must be complete.) |
| Related Tickets | (e.g., PAY-121 (Google Pay support) / PAY-115 (Japanese error message localization)) |
| Target Sprint | (e.g., Sprint 44) |
| Stakeholders | (e.g., PM Yamada approved / Designer Tanaka reviewing UI) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
ユーザーストーリー本文の書き方（3要素テンプレート）
ユーザーストーリーは「As a [誰が]、I want to [何をしたい]、so that [なぜ・どんな価値]」の3要素で書く。「なぜ」の部分を省略するとビジネス価値が伝わらず、実装の優先度判断ができなくなる。
| 日本語 | 英語 |
|---|---|
| 〇〇として | As a [role / persona] |
| 〇〇したい | I want to [action / feature] |
| なぜなら〇〇だから | so that [benefit / business value]. |
悪い例（NGパターン）：
“As a user, I want to use Apple Pay.” → なぜ使いたいのかが不明で、優先度の根拠がない。
良い例（OKパターン）：
“As a mobile user, I want to complete a payment using Apple Pay so that I can check out faster without re-entering my card details.”
受け入れ基準の書き方（Given-When-Then）
Given-When-Thenはテスト可能な条件をBDD（振る舞い駆動開発）形式で記述する方法だ。「前提・操作・期待結果」の3セットで書くことで、QAがテストケースに直接変換できる。
| 日本語 | 英語 |
|---|---|
| 〇〇の場合（前提） | Given [precondition] |
| 〇〇したとき（操作） | When [action] |
| 〇〇になる（期待結果） | Then [expected result]. |
スプリント計画での活用は英語スプリント計画書の書き方でも確認してほしい。
ユーザーストーリーでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
ユーザーストーリーの基本用語
| 日本語 | 英語 |
|---|---|
| ユーザーストーリー | User Story |
| 受け入れ基準 | Acceptance Criteria |
| 完了の定義 | Definition of Done (DoD) |
| MoSCoW優先度 | MoSCoW Prioritization |
| ストーリーポイント | Story Points |
| Tシャツサイジング | T-Shirt Sizing |
| Given-When-Then | Given-When-Then (GWT) |
| エピック | Epic |
| スパイク | Spike |
| バックログ | Backlog |
リファインメントセッションでのフレーズ
| 日本語 | 英語 |
|---|---|
| このストーリーの「なぜ」を教えてください | Can you explain the “why” behind this story? |
| 受け入れ基準を明確にしましょう | Let’s clarify the acceptance criteria. |
| このストーリーはエピックに分割できますか？ | Can this story be broken down into smaller stories? |
| ビジネス価値はどれくらいですか？ | What is the business value of this story? |
| このストーリーはスプリントに収まりますか？ | Does this story fit within a single sprint? |
技術ロードマップとの連携は英語技術ロードマップの書き方でも確認してほしい。
ユーザーストーリーの「so that」フレーズをそのままスプリントゴールに昇華する方法は英語スプリントゴールの書き方で確認してほしい。ストーリーのビジネス価値をゴール文に集約することでスプリントの焦点が明確になる。
ユーザーストーリーの受け入れ基準とDoDの違いを理解するには英語DoDの書き方も参照してほしい。ストーリー固有の条件とチーム共通の品質基準を分けて管理することでレビューの議論がスムーズになる。
ユーザーストーリーの見積もりに不確実性がある場合は英語テクニカルスパイクの書き方でスパイクを先行させることを検討してほしい。スパイクで得た調査結果をストーリーポイントの根拠として記録することで見積もりの精度が上がる。
まとめ：英語ユーザーストーリーは4つのセクションで完成する
英語ユーザーストーリーに必要な構成要素を整理した。
- ストーリー本文は「As a / I want to / so that」の3要素で書き、「なぜ」を省略しない
- 受け入れ基準はGiven-When-Then形式でテスト可能な条件として書き、完了の定義まで合意する
- 見積もりはストーリーポイントと根拠・不確実性をセットで記録し、スプリントの計画精度を高める
- 優先順位はMoSCoW分類と依存関係を明記し、実施スプリントとステークホルダーの承認まで確認する
テンプレートをコピーして、まず「ユーザーストーリー本文」の「so that（なぜ）」から書き始めてほしい。この1フレーズが明確になれば、受け入れ基準と優先度の議論が自然と固まる。
コメント