ユーザーストーリーとは？アジャイル開発における活用例や書き方を解説

ユーザーストーリーとは、「誰が（ユーザー）」「何をしたいか（要望）」「なぜ（価値）」という形式で、ユーザーの要求を簡潔に記述するアジャイル開発の要求整理手法です。ユーザー視点で機能の目的と価値を明確にし、開発チームの共通認識をつくるために用いられます。

開発するプロダクトのユーザーニーズを整理するために有効な手法であるユーザーストーリーは、アジャイル開発において要求の整理に活用できます。

ユーザーストーリーとは具体的にはどのように作成していくべきものなのでしょうか。

この記事では、アジャイル開発のプロフェッショナルとして多くの企業を支援してきた弊社スパイスファクトリーが、アジャイル開発におけるユーザーストーリーの書き方や、そのまま使える例文テンプレート、受け入れ条件（Acceptance Criteria）の実例、具体的な利用イメージをご紹介します。

ユーザーストーリーとは

ユーザーストーリーとは、システムを開発する際にユーザーが求めている機能を整理するためのフォーマットです。
具体的には「誰が」「なぜ」「何をしたいか」という形でユーザーの要求を整理していきます。

ユーザーストーリーはアジャイル開発手法（新しいタブで開きます）の一つであるXP（エクストリームプログラミング）のプラクティスとして提唱されたアプローチです。

ユーザーストーリーはアジャイル開発の文脈で生み出されたものであり、当然ながらアジャイル開発と相性が良いものですが、アジャイル開発のみならずシステム開発全般において活用できる可能性がある手法です。

ユーザーストーリーはユースケースとは異なる概念

「誰が」「なぜ」「何をしたいか」をまとめるという考え方を聞いたとき、システム開発の経験がある方であれば「ユースケースと何が違うの？」という疑問を持つのではないでしょうか。

ユースケースとは、ユーザーがシステムを利用して実現できることを整理する方法であり、ソフトウェア開発において一般的に用いられるものです。
実際に、ユーザーストーリーという概念が生み出された時点では “with user stories, which are like use cases ”（ユースケースのようにユーザーストーリーを用いる）という表現がみられるなど、両者は近しいものという認識でした。

一方で、その後アジャイル開発が洗練されていく中で、ユーザーストーリーはユースケースとは異なる概念であると定義されるようになります。

両者の違いを端的に言うと、要求を整理する際の視点の違いです。

ユーザーのニーズを満たすために「システムが実行しなければならないこと」を整理するシステム視点のユースケースに対して、ユーザーの視点から「ユーザーが達成したい目標」を整理するユーザー目線のユーザーストーリーという違いがあります。

よって、ユーザーストーリーにおいては「どの画面やデータを利用するか」といった技術的な要素はあまり含まれず、代わりに「なぜユーザーはそのような行動をしたいか」や「そうすることでユーザーはどのようなメリットがあるのか」といったユーザー側の意識を重視して要求を整理します。

ユーザーストーリーを作成する理由

ユーザーストーリーは、ユーザーの要求を可視化してチームで共有するために作成します。
ユーザーのニーズを明確化することで、チームメンバーによる認識ずれを防ぐことにつながります。
また、複数の要求のうち、どれを優先して開発するかといった優先順位付けにも利用することができます。

特に、ユースケースではなくユーザーストーリーという形で要求を整理することにより、システムに詳しい方でなくても理解しやすい表現になるというメリットもあります。

これにより、ビジネスサイド・ITサイドに関わらず、共通認識を持ちやすくなります。

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

以下では、具体的なユーザーストーリーの書き方をご紹介します。

ユーザーストーリーの基本フォーマット

上述しましたが、ユーザーストーリーの基本フォーマットは「誰が」「なぜ」「何をしたいか」という形でユーザーの要求を整理していくものです。

例えば、ECサイトにおけるユーザーストーリーであれば以下のような内容が挙げられるでしょう。

• ユーザーは自分が求めている分野の商品を探しやすくするため、商品カテゴリーにより商品を絞り込む
• 調達担当は在庫切れを防ぐために、商品ごとに将来的な在庫切れを予想した結果を確認する
• マーケターはロイヤルカスタマーを発見しやすいように、ユーザーごとの購買頻度や購買額を確認する

ユーザーストーリーは、シンプルかつ小さい範囲で整理することが良いとされています。

これは、開発のしやすさにもつながるポイントです。

そのまま使えるユーザーストーリーの例文テンプレート（ECサイト・業務システム・SaaS）

ユーザーストーリーを書く際は、「〈ユーザーの種類〉として、〈実現したいこと〉をしたい。なぜなら〈得られる価値〉だからだ」という定型文（テンプレート）に当てはめると書きやすくなります。

以下に、ECサイト・業務システム・SaaSといった異なるドメインでの例文をまとめました。自社のプロダクトに合わせて言葉を置き換えることで、そのままユーザーストーリーの叩き台として利用できます。

ユーザーストーリー例	対象ユーザー	価値
ECサイトの購入者として、商品カテゴリーで商品を絞り込みたい。なぜなら目当ての商品を素早く見つけたいからだ	ECサイトの購入者	商品を探す手間の削減
ECサイトのリピーターとして、前回の配送先と支払い方法を使って注文を確定したい。なぜなら毎回の入力の手間なく購入を完了したいからだ	ECサイトのリピーター	購入手続きの時間短縮
経理担当者として、当月の経費申請を一覧でCSV出力したい。なぜなら月次の締め処理にかかる集計時間を短縮したいからだ	業務システムを使う経理担当者	月次業務の効率化
調達担当者として、在庫が発注点を下回った商品の通知を受け取りたい。なぜなら在庫切れによる販売機会の損失を防ぎたいからだ	業務システムを使う調達担当者	欠品による機会損失の防止
SaaSの管理者として、メンバーごとに閲覧権限を設定したい。なぜなら機密情報へのアクセスを必要な範囲に限定したいからだ	SaaSを導入する企業の管理者	情報漏えいリスクの低減

重要なのは、機能そのもの（何を作るか）だけでなく、「なぜなら」以降にユーザーが得たい価値を明記することです。価値が言語化されていれば、開発チームは目的に照らして、より良い実現方法を提案できるようになります。

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

ユーザーストーリーは「Card」「Conversation」「Confirmation」の3つの「C」でまとめていきます。それぞれのCの意味は以下のとおりです。

• Card（カード）：ユーザーの要求をカードや付箋に簡潔にまとめていく。カードにはすべての情報が含まれているわけではなく、ストーリーを思い出すために十分な情報が書かれる
• Conversation（会話）：開発者に対しては、会話を通じて詳細にストーリーを伝えていく
• Confirmation（確認）：開発された機能を確認する。一般的に受入テストと呼ばれる工程に相当する

※参考：Essential XP: Card, Conversation, Confirmation（新しいタブで開きます）

INVESTチェックリスト

ユーザーストーリーの品質を評価する際に有効なのが「INVEST」と呼ばれるチェックリストによる確認です。INVESTはそれぞれ以下の要素の頭文字をとったものです。

• • I：Independent（独立）：他の要素から独立しており、他の要素と重複する内容がないこと
  • N：Negotiable（交渉可能性）：ユーザーや開発者などで話し合いができること
  • V：Valuable（価値）：ユーザーにとって価値があること
  • E：Estimable（見積可能性）：開発に必要な作業量が見積もりやすいこと
  • S：Small（小ささ）：記述範囲が小さくアジャイル開発のサイクルに収まること
  • T：Testable（テスト可能性）：テストを行える内容であること

※参考：What does INVEST Stand For?（新しいタブで開きます）

ユーザーストーリーマッピング

ユーザーストーリーを整理する際に有効なのが、ユーザーストーリーマッピングです。ユーザーストーリーマッピングとは、それぞれのユーザーストーリーを「時間軸」と「優先順位軸」の2軸で整理する方法です。

たとえば、ECサイトで商品を購入するに至るまでを想像すると、以下のようなユーザーストーリーが挙げられるでしょう。

• • • ユーザーは自身が求めている商品をキーワード検索で探す
    • ユーザーは購入する商品を選択し、カートに入れる
    • ユーザーは支払情報や配送先を選択し、購入を確定する
    • ユーザーは購入したい商品をお気に入り登録して管理する
    • ユーザーは自分が求めている分野の商品を探しやすくするため、商品カテゴリーにより商品を絞り込む

これらを時間軸と優先順位軸で整理すると以下のようなまとめ方ができます。

このようにユーザーストーリーをマッピングすることで、たとえば最低限必須となる優先順位高の機能を最初のリリースまでに開発し、残りの機能は2回目のリリースに開発するといった整理がしやすくなります。

なお、「まず必要最小限の機能でリリースし、ユーザーの反応を検証しながら拡張していく」というこの考え方は、MVP開発の進め方とも共通するものです。

受け入れ条件（Acceptance Criteria）の書き方と実例

ユーザーストーリーとセットで定義したいのが「受け入れ条件（Acceptance Criteria）」です。ここでは、受け入れ条件の考え方と書き方、具体例をご紹介します。

受け入れ条件とは

受け入れ条件（Acceptance Criteria）とは、そのユーザーストーリーが「完成した」と判断するために満たすべき条件を、開発前に具体的に定義したものです。

ユーザーストーリー自体はあえて簡潔に書くため、そのままでは「どこまでできれば完成なのか」が人によって解釈が分かれてしまいます。受け入れ条件を定義しておくことで、開発者・ビジネスサイド・テスト担当者が同じゴールを共有でき、開発後の手戻りを防げます。

前述の3Cにおける「Confirmation（確認）」を具体化したものが受け入れ条件であり、受入テストのテスト観点の基礎にもなります。また、INVESTの「T：Testable（テスト可能性）」を満たしているかどうかは、受け入れ条件が書けるかどうかで判断できます。

受け入れ条件の書き方

受け入れ条件を書く際のポイントは以下のとおりです。

• 実装方法ではなく、ユーザーから観察できる「振る舞い」や「結果」を書く
• 合格・不合格の判定が人によってブレない、具体的で検証可能な表現にする
• 正常系だけでなく、入力ミスや権限がない場合などの異常系も含める

書き方のフォーマットとしてよく使われるのが、振る舞い駆動開発（BDD）で用いられる「Given（前提）／When（操作）／Then（期待する結果）」形式です。「どのような状態で」「何をしたら」「どうなるべきか」を分けて書くことで、条件の抜け漏れや曖昧さに気付きやすくなります。

なお、受け入れ条件はストーリー作成時にすべて完成させる必要はありません。バックログリファインメントの場で、開発チームとの会話を通じて具体化していくのが一般的です。

Given/When/Then形式の受け入れ条件の具体例

先ほどの例文テンプレートに対応させた、Given/When/Then形式の受け入れ条件の例を3つご紹介します。

例1：「ECサイトの購入者として、商品カテゴリーで商品を絞り込みたい」

• Given（前提）：商品一覧に複数カテゴリーの商品が表示されている
• When（操作）：購入者がカテゴリー「家電」を選択する
• Then（期待する結果）：家電カテゴリーの商品のみが一覧に表示され、該当する商品の件数が表示される

例2：「経理担当者として、当月の経費申請を一覧でCSV出力したい」

• Given（前提）：当月分の経費申請が10件登録されている
• When（操作）：経理担当者が対象月を指定してCSV出力を実行する
• Then（期待する結果）：10件すべての申請データを含むCSVファイルがダウンロードされる

例3：「SaaSの管理者として、メンバーごとに閲覧権限を設定したい」

• Given（前提）：閲覧権限のないメンバーがログインしている
• When（操作）：権限のないページのURLに直接アクセスする
• Then（期待する結果）：コンテンツは表示されず、閲覧権限がない旨のメッセージが表示される

例3のように、「正しく操作した場合」だけでなく「してはいけないことができないこと」も受け入れ条件として明記しておくと、セキュリティや業務ルールに関わる仕様の抜け漏れを防げます。

よくある落とし穴：曖昧な受け入れ条件と改善例

受け入れ条件でつまずきやすいのが、テストの合否を判定できない曖昧な表現です。よくある曖昧な条件と、その改善例を挙げます。

【×】検索が速いこと
【〇】検索結果が表示されるまでの時間が3秒以内であること

【×】エラーが出ないこと
【〇】必須項目が未入力のまま送信した場合、対象項目の近くにエラーメッセージが表示され、入力済みの内容は保持されること

【×】誰でも使いやすい画面であること
【〇】マウスを使わずキーボード操作のみで、入力開始から送信完了までの操作ができること

いずれの改善例も、「観察できる振る舞い」と「判定基準」が明確になっている点がポイントです。曖昧な条件をゼロにすることは難しいため、気付いた時点で3Cの「Conversation（会話）」を通じて具体化していきましょう。

ユーザーストーリーを活用した開発イメージ

最後に、ユーザーストーリーを実際の開発の場面で活用する際のイメージをご紹介します。

カードへの書き出し

ここまでご紹介した通り、ユーザーの要求をカードや付箋などへと書き出します。カードに記載する内容はシンプルなものとし、開発者との会話によって補足します。

このとき、ひとつひとつの要求はできるだけ小さいものとし、依存関係を持たせないことがポイントです。たとえば、以下の例はひとつの要求が大きくなってしまい、そのままでは開発しにくいと考えられ、より小さい要求に分割していく必要があります。

【×】

• ユーザーは自分が求めている商品を探す

【〇】

• ユーザーは自分が求めている商品を探すために商品名や価格を基に検索する
• ユーザーは自分が求めている商品を探すために新商品をチェックする
• ユーザーは自分が求めている商品を探すために口コミ情報を確認する

一方で、ユーザーの要求を十分小さく、また依存関係を排除するのは簡単ではありません。
アジャイル開発に精通したメンバーのサポートも重要となります。

ユーザーストーリーマッピング

挙げられたユーザーストーリーをマッピングしていきます。
マッピング作業は一人で実施するのではなく、チームで実施すべきものです。
ユーザー自身に参加してもらうことがベストですが、難しい場合はユーザーに詳しいステークホルダーなどにも参加を要請します。

まず、時間軸としてユーザーの行動フローを定義します。このとき、できるだけ広くユーザーの行動を想定することがポイントです。
開発するプロダクトを実際に利用する場面だけではなく、その前後の行動も含めて検討することで、よりユーザー行動を深堀できます。複数のユーザータイプが存在するのであれば、無理に一つにまとめず、複数のマッピングを行ってもよいでしょう。

次に、ユーザーストーリーの優先度に応じて各行動に対するストーリーをマッピングしていきます。
個々のユーザーストーリーを書いた付箋を利用すると、議論を通して優先度の入れ替えがしやすくなります。

最後に、リリースラインとしてどこまでの機能を初期の開発対象とするかを決定します。

スプリントの実施と優先度の見直し

スクラムをはじめとするアジャイル開発では、スプリントと呼ばれる短い固定期間で開発を繰り返していきます。
ユーザーストーリーマッピングで定義したリリースラインに向けて、実際に機能を開発していきます。
このとき重要となるのが、上述した3つのCのうちの「Conversation（会話）」です。開発者が認識齟齬なく機能を開発できるようにコミュニケーションを行います。
開発途中において、開発すべき機能の見直しを行うべき場面もあるでしょう。

機能の見直しがしやすいことはアジャイル開発のメリットです。

見直しを行う場合、ユーザーストーリーマッピングとして作成したものも必要に応じて更新していくことで、チームメンバーでの情報共有もしやすくなります。

まとめ

この記事では、アジャイル開発において活用できるユーザーストーリーについてご紹介しました。

アジャイル開発によりプロダクトを開発していく際には、ユーザーストーリーとして「ユーザー視点により」「アジャイル開発に適した小さい単位で」要求を整理していくことが有効です。
ユースケースとは少し異なった視点で要求をまとめていくことで、よりアジャイル開発にフィットした要求整理を実現することができます。
あわせて受け入れ条件（Acceptance Criteria）を定義しておくことで、「どこまでできれば完成か」の認識をチームでそろえることができます。
一方で、ユーザーストーリーによるユーザー要求の整理は、慣れていないと実施が難しいケースもあります。

当社では、これまで多数のお客さまに対してアジャイル開発を支援してまいりました。
豊富な実績を持ち、これらのプロセスを効率的に進めるためのサポートを提供いたします。

ご相談はお問い合わせフォームからお気軽にご連絡ください。