ユーザーストーリーの書き方（例とテンプレート付き）

ユーザーストーリーとは、それを使う人の視点から語られた機能の短い平易な説明です。ほとんどのアジャイルやScrumのBacklogの基盤となっており、うまく書かれたユーザーストーリーは開発チームを抽象的な技術要件ではなく、本当のユーザーのアウトカムに集中させます。

ユーザーストーリーとは何か？

ユーザーストーリーとは、エンドユーザーの視点から書かれたソフトウェア機能の短い非公式な説明です。技術仕様書ではありません。ユーザーが何を必要としているか、そしてその必要性がプロダクトにとってなぜ重要かについての会話のきっかけとなるプレースホルダーです。

このテンプレートは1990年代後半にExtreme Programming（XP）を通じて広く使われるようになり、後にMike Cohenが2004年の著書「User Stories Applied」で体系化しました。今日では、2人のスタートアップからエンタープライズのプロダクト部門まで、アジャイルチームにおける標準的な実践です。

ユーザーストーリーはチームを誠実に保ちます。技術的に面白そうだからという理由で機能を作るのではなく、作る対象であるユーザーとつながり続けるためにユーザーストーリーを書きます。ストーリー自体は意図的に短いものです。価値はそれが引き起こす会話、プロダクトオーナー、開発者、ステークホルダー間の対話から生まれます。

重要なポイント

• ユーザーストーリーは1990年代後半にKent BeckがExtreme Programming（XP）の一部として普及させ、後にMike Cohenが2004年の著書「User Stories Applied」で正式化しました。
• 第17回State of Agileレポート（Digital.ai、2023年）によると、アジャイルチームの83%が要件を把握する主なフォーマットとしてユーザーストーリーを使用しています。
• Scrum Alliance実践者調査（2022年）によると、ユーザーストーリーと共に構造化された受け入れ基準を使用するチームは、Sprint レビューでの欠陥が40%少ないと報告されています。

ユーザーストーリーのテンプレート

定番のユーザーストーリーフォーマットは3つのパーツで構成されています。どこでも見かけるでしょう。

As a [role], I want [goal], so that [benefit]. （「[ロール]として、[ゴール]がしたい。なぜなら[ベネフィット]だから。」）

各パーツには特定の役割があります。

まとめると：「初めて購入するバイヤーとして、ウィッシュリストにアイテムを保存したい。なぜなら、後で再び検索せずに戻れるようにしたいからです。」

このフォーマットが機能する理由は、チームに3つのことを同時に考えさせるからです。誰が、何を、なぜ。どれか1つを省くと、ストーリーの優先順位付けや見積もりがはるかに難しくなります。「so that」の句がないストーリーはただのタスクです。何の価値を生み出しているかがわからないため、Sprint 時にそれを作る価値があるかどうかを判断することがほぼ不可能になります。

ユーザーストーリー、エピック、タスクの違い

ユーザーストーリーは3段階の階層の中間に位置します。スプリントプランニングを実施する際、粒度を正しく設定することが非常に重要です。

エピックは1つの Sprint では大きすぎるため、チームがユーザーストーリーに分解します。ストーリーは Sprint 内に収まるようにサイズ設定されます。タスクは開発者がボード上でピックアップして追跡する実際の技術作業です。

よくある失敗は、エピックの範囲でストーリーを書き、何も完了しないと悩むことです。ストーリーが完了するのに1 Sprint 以上かかるなら、おそらく変装したエピックです。分解しましょう。

ユーザーストーリーの3つのC

Ron Jeffriesは、ユーザーストーリーが実際にどのように機能するかを説明するために3つのCフレームワークを提唱しました。カードはただの出発点です。

Card（カード）。 ユーザーストーリーは伝統的に物理的なインデックスカード（またはそのデジタル版）に書かれます。カードは意図的に短い：1文か2文です。完全な仕様書ではありません。会話が必要だということを思い出させるリマインダーです。

Conversation（会話）。 カードはProduct Owner、開発者、そして多くの場合ステークホルダーとの議論を引き起こします。この会話の中で実際の要件が明確になります。カードにすべての答えが載っているわけではありません。答えは人が持っています。

Confirmation（確認）。 会話が行われたら、チームは受け入れ基準を文書化します。ストーリーが完了と見なされるために満たすべき具体的な条件です。これらの基準がストーリーを閉じる前にテストされ検証されます。

ほとんどのチームはカードを書いてすぐコーディングに飛びつきます。それは逆です。会話のステップこそ、曖昧さが解消され、エッジケースが発見され、共通の理解が構築される場です。会話を省略したストーリーは手戻りのために戻ってくる傾向があります。

良いユーザーストーリーのINVESTの基準

Bill WakeはINVESTの頭字語を提唱し、ユーザーストーリーが適切に形成されているかを評価するための品質チェックリストをチームに提供しました。Sprint に取り込む前に、このリストで任意のストーリーを確認しましょう。

Backlog リファインメント中に素早く INVEST チェックを実施しましょう。ストーリーがいずれかの基準を満たしていない場合、まだプランニングには取り込まないでください。先に修正しましょう。最も多い失敗は「十分に小さくない」（エピックであるべき）と「テスト可能でない」（受け入れ基準がまだ書かれていない）です。

ユーザーストーリーの書き方

良いユーザーストーリーを書くにはテンプレートを埋めること以上のことが必要です。信頼性の高いプロセスを紹介します。

ステップ1：ユーザーペルソナを特定する

この機能を実際に使うのは誰ですか？具体的にしましょう。「ユーザー」はペルソナではありません。「まだ支払い方法を設定していない新規ユーザー」がペルソナです。ペルソナが具体的であるほど、そのニーズを本当に反映したストーリーを書きやすくなります。

まだ正式なペルソナがない場合は、カスタマーサポートチームとの20分程度の会話で最も一般的なユーザータイプが浮かび上がります。

ステップ2：ゴールを明確にする

ユーザーは何を達成しようとしているか？アクションとして書きましょう。「価格で検索結果をフィルタリングする」「データをCSVファイルとしてエクスポートする」「チェックアウト後に確認メールを受け取る」。1つのストーリーにつき1つのゴールに絞ります。ゴールに「and（かつ）」が出てきたら、おそらく2つのストーリーがあります。

ステップ3：ベネフィットを述べる

ユーザーはなぜそれを求めているか？求めているアウトカムは何か？これが「so that（なぜなら）」の句です。最もスキップされる部分でもあります。省略しないでください。ベネフィットはチームに成功がどのように見えるかを伝え、開発中にトレードオフが発生したときに重要になります。

ステップ4：受け入れ基準を追加する

機能が完了と見なされるために満たすべき条件を書きます。平易な言葉またはGiven/When/Then フォーマット（後述）を使いましょう。受け入れ基準はオプションではありません。それなしでは、チームの各開発者が「完了」の意味について若干異なるメンタルモデルを持ちます。

ステップ5：ストーリーを見積もる

チームと協力して、Story Point または同様の相対見積もり手法でストーリーをサイジングします。見積もりが高い場合（通常フィボナッチスケールで8または13以上）、ストーリーはおそらく大きすぎます。Sprint プランニングの前に小さな部分に分解しましょう。

ステップ6：優先順位付けとリファインメント

ストーリーをProduct Backlog に追加し、価値で順位付けします。Backlog リファインメントセッション中に、次の Sprint に向けて近づいているストーリーを見直し、まだ関連性があるか、サイズが正しいか、明確な受け入れ基準があるかを確認します。最近リファインメントされていないストーリーは、Sprint の準備が整う前に更新が必要なことが多いです。

ユーザーストーリーの例

よくある3種類のプロダクトタイプにわたる具体的な例を示します。各例は標準テンプレートに従い、簡単な受け入れのメモが含まれています。

各ストーリーは「ユーザー」という一般的な言い方ではなく、特定のユーザータイプを指名していることに注目してください。そして各ベネフィットの句はゴールの言い換えではなく、本当のモチベーションを説明しています。

受け入れ基準とDefinition of Done

受け入れ基準とは、チームがユーザーストーリーを完了と見なすために機能が満たすべき具体的な条件です。開発が始まる前、通常は会話のステップ中に書かれます。

最も一般的なフォーマットはGiven/When/Then（Gherkin 構文とも呼ばれる）です。

• Given（前提条件） 初期のコンテキストまたは前提条件
• When（操作） ユーザーが特定のアクションを行う
• Then（期待結果） 特定のアウトカムが発生する

ウィッシュリストストーリーの例：

Given ログイン済みのバイヤーが商品ページを閲覧している
When 「ウィッシュリストに追加」ボタンをクリックする
Then アイテムがウィッシュリストに追加され、確認のトーストが表示される。ボタンが「追加済み」に変わる。

**Definition of Done（DoD）**は受け入れ基準とは異なります。受け入れ基準は1つのストーリーに固有のものです。DoD はすべてのストーリーに適用されるチーム全体の基準です。ユニットテストが書かれていること、コードレビューが済んでいること、ステージング環境にデプロイされていること、重大なバグがないこと。ストーリーを閉じる前に両方を満たす必要があります。

混同しないでください。たとえばコードレビューが行われていない場合、ストーリーはすべての受け入れ基準を満たしていても DoD を満たしていない可能性があります。両方を追跡しましょう。

ユーザーストーリーを書く際のよくある失敗

ユーザーの視点ではなくシステムの視点で書く。 「システムはメールを送信する」は技術要件であり、ユーザーストーリーではありません。書き直しましょう。「新規ユーザーとして、登録後にウェルカムメールを受け取りたい。アカウントが正常に作成されたことを確認できるように。」

ベネフィットの句を省く。 「ユーザーとして、結果をフィルタリングしたい」では、優先順位や価値についてチームにほとんど何も伝わりません。なぜユーザーはフィルタリングしたいのか？フィルタリングされた結果でどんな判断をするのか？本当の情報は「so that」の句の中にあります。

エピックをストーリーと呼ぶ。 「ユーザーとして、完全なチェックアウト体験が欲しい」はストーリーではありません。機能領域です。具体的で見積もり可能な部分に分解しましょう。支払い方法の選択、注文確認、領収書メールなど。

開発が始まる前に受け入れ基準がない。 受け入れ基準のないストーリーは手戻りへのオープンな招待状です。開発者は曖昧さを構築しやすい方向に解釈しますが、それは必ずしもProduct Ownerが意図したものではありません。Sprint 開始前に基準を書きましょう。

1つの Sprint に多すぎるストーリー。 アジャイルチームは時々、チームが現実的に完了できる以上のストーリーをBacklog に詰め込みます。これにより半完成の作業が生まれ、ゼロに達しない膨れ上がった「バーンダウンチャート」が生まれます。Story Point と過去の Velocity を使って現実的な Sprint キャパシティを設定しましょう。

MoSCoW 優先順位付けのステップを無視する。 すべてのユーザーストーリーが等しいわけではありません。必須のものもあれば、あると嬉しいものもあります。明示的な優先順位付けなしでは、チームは高価値の作業を待たせながら、低価値のストーリーに Sprint の時間を費やします。

よくある質問

アジャイルにおけるユーザーストーリーとは何ですか？

ユーザーストーリーとは、「As a [role], I want [goal], so that [benefit]」（[ロール]として、[ゴール]がしたい。なぜなら[ベネフィット]だから）というフォーマットで書かれた、ユーザーの視点からの機能の短い平易な説明です。技術仕様ではなくユーザーの価値に焦点を当てた方法で要件を把握するために、アジャイルチームで使用されます。ユーザーストーリーは通常Product Backlog に保存され、優先度に基づいて Sprint に取り込まれます。

ユーザーストーリーとエピックの違いは何ですか？

エピックは1つの Sprint で届けるには大きすぎる作業のまとまりです。ユーザーストーリーはその作業の、より小さく届けられるスライスです。エピックがユーザーストーリーに分解されます。例えば「チェックアウト体験」はエピックです。「バイヤーとして、今後の購入のために支払い情報を保存したい」はその中の1つのユーザーストーリーです。

ユーザーストーリーを書くのは誰ですか？

Product Ownerが通常ユーザーストーリーを書いたり所有したりしますが、最良のユーザーストーリーはコラボレーションから生まれます。Product Ownerはビジネスとユーザーの視点をもたらします。開発者は技術的なコンテキストをもたらします。UXデザイナーはユーザー調査をもたらします。Backlog リファインメントセッションがこれらの視点を組み合わせ、適切に形成された見積もり可能なストーリーを生み出す場です。

Story Point とは何ですか？

Story Point とは、チームがユーザーストーリーをサイジングするために使用する相対的な見積もり単位です。時間単位で見積もる代わりに（個人によって異なり、しばしば不正確）、チームはフィボナッチ的なスケール（1、2、3、5、8、13）を使ってストーリーを互いに比較します。5ポイントのストーリーは2ポイントのストーリーのおよそ2倍の複雑さです。時間が経つにつれ、チームは安定した Velocity（Sprint あたりのポイント数）を発展させ、Sprint プランニングをより予測可能にします。

INVESTはユーザーストーリーで何を表しますか？

INVEST はユーザーストーリーの品質チェックリストです。Independent（他のストーリーに依存せずにビルドできる）、Negotiable（会話に基づいて詳細を変更できる）、Valuable（ユーザーに明確な価値を提供する）、Estimable（チームがサイジングできる）、Small（1つの Sprint に収まる）、Testable（検証可能な受け入れ基準がある）。いずれかが満たされていなければ、Sprint の準備ができていません。

---

良いユーザーストーリーは自然と書けるものではありません。しかし、時間をかけて正しく書くチーム、本当のユーザーペルソナを指定し、明確なベネフィットの句を書き、開発が始まる前にテスト可能な受け入れ基準を付けるチームは、手戻りに費やす時間が少なく、重要なものを届けることに多くの時間を使います。

現在の最優先 Backlog アイテムに対して1つのストーリーから始めましょう。テンプレートを適用し、INVEST チェックを実施し、2つか3つの受け入れ基準を書きましょう。それが習慣です。そこから積み重ねていきましょう。

関連するフレームワークとして、プロジェクトスコープを分解するための作業分解構成図（WBS）、ストーリーを Sprint に取り込むためのスプリントプランニング、そしてどのワークフローがチームに最適かを決める際のScrum vs Kanbanを参照してください。