要件定義書やバックログには機能名が並んでいるのに、いざ開発が始まると「これは誰のための機能で、何を解決するためのものだったか」がチームの中で共有されていない、という状況に心当たりはないでしょうか。仕様の詳細は把握していても、それを実装するエンジニアやデザイナーに「なぜ必要か」までを一文で伝えられていないと、出来上がったものが少しずつ意図とずれていきます。
ユーザーストーリーは、機能を「誰が・何をしたくて・なぜそれが必要か」という短い一文に落とし込み、チーム全員が同じ目的意識を持って開発に取り組めるようにするための道具です。書式自体はシンプルですが、書き方を誤ると「テンプレートを埋めただけの文章」になり、結局は機能一覧と変わらないものになってしまいます。本記事では、要件をユーザー視点の一文に変換するための考え方と、そのまま使えるテンプレート、実践ステップを解説します。
ユーザーストーリーとは何か、なぜ必要か
ユーザーストーリーとは、「As a(誰が)」「I want(何をしたいか)」「So that(なぜそれが必要か)」の3要素で構成された、機能に対する短い説明文です。もともとはアジャイル開発の文脈で生まれた書式ですが、開発手法にかかわらず、要件を「実装すべき仕様」ではなく「利用者にとっての価値」として言語化する手段として広く使われています。
一人、あるいは少人数でプロダクトの意思決定を担っている体制では、要件を思いついた本人の頭の中には「なぜこの機能が必要か」の背景が十分にあります。しかし、それをそのままエンジニアに伝えると、仕様の詳細だけが独り歩きし、背景にある目的が抜け落ちたまま実装が進んでしまうことがあります。ユーザーストーリーを書くという作業は、自分の頭の中にある「なぜ」を明文化し、チームに正しく引き継ぐための工程だと捉えると分かりやすいでしょう。
要件定義の内容を土台にユーザーストーリーへ落とし込む流れになるため、要件定義そのものの進め方に不安がある場合は、以下の記事も参考にしてください。
ユーザーストーリーが機能しなくなる、よくある3つの失敗
具体的な書き方に入る前に、ユーザーストーリーを書いてはいるものの、実際の開発現場で機能していないケースによく見られる失敗を整理します。
失敗1：「So that(なぜ)」を省略し、仕様の説明だけになってしまう。 「ユーザーはCSVをダウンロードできる」のように、実装したい機能をそのまま文章にしただけで終わってしまうケースです。これは要件を言い換えただけであり、なぜその機能が必要かという判断材料が抜け落ちています。優先順位を検討する場面や、実装方法に複数の選択肢がある場面で、目的に立ち返って判断ができなくなります。
失敗2：「As a(誰が)」が曖昧で、複数の利用者像が1つのストーリーに混ざってしまう。 「ユーザーは〜したい」のように主語を曖昧にしたまま書くと、実際には管理者と一般利用者では求めていることが異なるにもかかわらず、1つのストーリーとして扱われてしまいます。誰にとっての価値かが曖昧なストーリーは、実装の優先度も受け入れ条件も定めにくくなります。利用者像を具体的に描く方法については、以下の記事で詳しく解説しています。
失敗3：受け入れ条件(Acceptance Criteria)がなく、「完成」の基準がすり合っていない。 ストーリー本文だけを書いて満足し、「何を満たせば完成と言えるか」を明文化しないまま開発が始まってしまうケースです。この状態で実装が進むと、レビューの段階になって「これは意図と違う」という手戻りが発生しやすくなります。
ユーザーストーリーを書く実践5ステップ
ここからは、要件を実際にユーザーストーリーへ落とし込むための実践ステップを解説します。
ステップ1：対象とする利用者を1人に絞る
最初に、そのストーリーが「誰のためのものか」を1人の利用者像に絞り込みます。「初めてプロダクトに触れる利用者」「日常的に管理画面を操作する管理者」など、行動や目的が異なる利用者が複数想定される場合は、それぞれ別のストーリーとして分けて書きます。1つのストーリーに複数の利用者像を詰め込まないことが、後の受け入れ条件を具体的にするための前提になります。
ステップ2：「As a / I want / So that」で一文に落とし込む
利用者を絞り込んだら、以下のテンプレートに沿って一文にまとめます。
- As a(誰が)：対象とする利用者像を具体的に書く
- I want(何をしたいか)：実現したい行動・操作を書く
- So that(なぜそれが必要か)：その行動によって得たい結果・解決したい課題を書く
例えば「CSVダウンロード機能」であれば、「As a 経理担当者として、I want 月次の取引データをCSVでダウンロードしたい、So that 手元の会計ソフトに手作業で転記する時間をなくしたい」のように書きます。同じ機能でも「なぜ」を明文化することで、CSV出力という手段以外に、会計ソフトとの直接連携という選択肢も検討対象になることが見えてきます。
🔗 ユーザーストーリーテンプレート(Notion)：As a / I want / So that の3要素と、受け入れ条件の記入欄をまとめたテンプレートを用意しました。ユーザーストーリーテンプレートのページを開き、右上のメニューから「複製(Duplicate)」すると、ご自身のNotionワークスペースにコピーしてすぐにご利用いただけます。
ステップ3：受け入れ条件(Acceptance Criteria)を書く
ストーリー本文の下に、「何を満たせば完成と言えるか」を箇条書きで書き添えます。受け入れ条件は「〜の場合、〜できる」という形式で、具体的な条件と期待される結果をセットで書くと、実装者・レビュー担当者の間で解釈のズレが生じにくくなります。
先ほどのCSVダウンロードの例であれば、「対象月を選択した場合、その月の取引データのみが出力される」「取引データが0件の場合、その旨を示すメッセージが表示される」のように、正常系だけでなく例外的なケースも含めて書き出しておくと、テスト観点の抜け漏れも減らせます。
ストーリー1件あたりの粒度を適切に保つ考え方として、INVEST(独立している・交渉可能・価値がある・見積り可能・小さい・テスト可能)という基準がよく参照されます。特に「小さい」「テスト可能」の2点は、受け入れ条件を具体的に書けるかどうかと直結するため、ストーリーを分割する際の目安にすると判断しやすくなります。
ステップ4：バックログに乗せ、優先順位をつける
書き上げたユーザーストーリーは、単体で管理するのではなくバックログに載せ、他のストーリーと並べて優先順位を検討します。「So that」に書いた目的が、今取り組んでいる課題とどれだけ強く結びついているかが、優先順位判断の主な材料になります。バックログ全体の優先順位付けの考え方については、以下の記事で詳しく解説しています。
ステップ5：開発着手前にエンジニアとすり合わせる
ストーリーと受け入れ条件を書いたら、実装に入る前に必ずエンジニアと内容を一緒に確認する時間を取ります。「So that」に書いた目的を共有した上で、「この実装方法でも目的は達成できるか」をエンジニア側の視点で検討してもらうと、想定していなかったより簡易な実装方法が見つかることもあります。ストーリーを一方的に渡すのではなく、目的を共有した上で実装方法を一緒に考える工程として位置づけることが、認識のズレを防ぐ最も確実な方法です。
具体例：BtoB SaaSスタートアップにおけるユーザーストーリー活用
従業員12名規模のBtoB SaaSスタートアップを例に、ステップの流れを確認します。
このプロダクトでは、利用企業の管理者から「メンバーの権限を一括で変更したい」という要望が複数寄せられていました。要件を「権限一括変更機能」とだけ書いて開発チームに渡していたときは、実装後に「一括変更はできるが、変更前の状態に戻せない」という仕様になり、利用企業から「間違えて変更した場合が怖くて使えない」という指摘を受けてしまいました。
そこで、次の機能改修では要件をユーザーストーリーに書き直しました。「As a 複数メンバーを管理する企業管理者として、I want メンバーの権限をまとめて変更したい、So that 組織変更のたびに1人ずつ設定を変更する手間と、変更漏れによる事故をなくしたい」という一文にした上で、受け入れ条件に「一括変更の実行前に、変更内容の確認画面が表示される」「実行後、直前の状態に戻す操作ができる」を明記しました。
この受け入れ条件をエンジニアと共有した結果、実装段階で「確認画面と変更履歴を残す設計にすれば、個別の取り消し機能を作らなくても目的は達成できる」という代替案が提案され、当初の想定より少ない工数で、かつ利用企業が安心して使える形で機能をリリースできました。目的を一文で共有したことが、実装方法の選択肢を広げた事例です。
よくある質問(FAQ)
Q1. ユーザーストーリーとPRD(プロダクト要求仕様書)は、どちらを先に書くべきですか?
プロダクト全体の方針や背景を整理する段階ではPRDを先に書き、その中の個々の機能を実装可能な単位に分解する段階でユーザーストーリーを書く、という順序が扱いやすい場合が多いです。PRDの書き方は以下の記事で解説しています。
Q2. 1つの機能に対して、ユーザーストーリーはいくつ書けばよいですか?
決まった数はありませんが、1つのストーリーの中に「そして」「かつ」で複数の操作が含まれている場合は、分割のサインです。受け入れ条件が3〜5個程度に収まる粒度を目安にすると、見積りやテストがしやすくなります。
Q3. 社内向けの管理画面など、エンドユーザーが限られる機能でもユーザーストーリーは必要ですか?
利用者が社内の特定担当者であっても、「誰が・何のために」を明文化する効果は変わりません。むしろ利用者が少なく声を直接聞きやすい分、「So that」の記述を本人へのヒアリングで具体化しやすいという利点があります。
Q4. ユーザーストーリーは誰が書くべきですか?エンジニアが書いても良いですか?
利用者の目的を最もよく把握している人が書くのが基本ですが、エンジニアが実装の過程で気づいた技術的な制約や代替案をもとに、受け入れ条件を一緒に更新していく運用は問題ありません。むしろストーリーを固定文書として扱わず、対話の中で更新していく前提で運用する方が実務に合います。
Q5. アジャイル開発ではないチームでも、ユーザーストーリーの書式は使えますか?
問題なく使えます。ユーザーストーリーはアジャイル開発特有の書式ではなく、要件を利用者視点で整理するための考え方です。ウォーターフォール型の要件定義書の中に、機能ごとの補足として「As a / I want / So that」の一文を添える形でも、目的の共有という効果は得られます。
まとめ
ユーザーストーリーを機能させる鍵は、対象とする利用者を1人に絞り、「As a / I want / So that」の形式で目的まで含めて一文に落とし込み、受け入れ条件で完成の基準を明確にした上で、実装着手前にエンジニアと目的を共有することにあります。
書式自体は難しいものではありません。まずは今バックログに並んでいる機能の中から1つを選び、「なぜそれが必要か」を一文で書き添えるところから始めてみてください。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「社長が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
