ユーザーストーリーとは？「誰が・何を・なぜ」を伝える
目次
ユーザーストーリーは、利用者が何をしたいかと、その理由を短く表し、チームで話し合うための記述です。作業指示や詳細な仕様を、その一文だけで置き換えるものではありません。
「確認ボタンを追加してほしい」とだけ書かれていると、開発担当は何を作るかを考えられても、なぜ必要なのかを判断しにくいことがあります。誰が、何のために確認したいのかを添えると、別の方法も含めて話し合えます。
この記事では、ユーザーストーリーの意味と、目的を共有するための基本的な書き方を説明します。開発作業の細かな分割や、チケット全体の完成までは扱いません。
- 「誰が・何を・なぜ」で、利用者の目的を伝えます。
- 元の要望と根拠を残し、理由を推測だけで埋めません。
- 一文を書いたあとに、対象範囲や受入条件を話し合います。
「誰が・何を・なぜ」で、目的を共有する
ユーザーストーリーの書式には、次のような形があります。
［利用者］として、［したいこと］をしたい。［理由・目的］のためです。
この順序や語尾を厳密にそろえることより、読んだ人が利用者と目的を理解できることを優先します。英国政府のユーザーストーリーの解説も、利用者・したいこと・目的を簡潔に含め、書式は変えてよいと説明しています。
| 要素 | 考えること | 避けたい書き方 |
|---|---|---|
| 誰が | その操作や仕事をする利用者は誰か | 関係者全員を「ユーザー」でひとまとめにする |
| 何を | その人ができるようになりたいことは何か | 機能名やボタン名だけを書く |
| なぜ | 何を終えたり、何を避けたりするためか | 「便利になるから」だけで終える |
同じ「一覧を見たい」でも、本人の予約を確かめたい人と、施設全体の利用状況を調整したい人では、必要な情報が異なります。まず、どちらの目的を話しているのかをそろえます。
架空の予約サービスで、一文を読み比べる
以下は説明用の架空例です。実際の顧客要望や、アーコレ！の提供機能を表すものではありません。
会議室を予約した人から、「予約を確認するボタンがほしい」と言われたとします。話を聞き、「予約した日時を確かめ、予定に合わせて来場したい」という目的が分かった場合、次のように整理できます。
予約者として、自分が予約した日時を確認したい。予定に合わせて来場するためです。
この一文には、画面の場所やボタンの色は含まれていません。まず、利用者が達成したいことを共有するためです。
「ボタンを追加」だけでは利用目的が分からない
「確認ボタンを追加する」は、実装する手段の案です。一方で、予約日時を知る方法には、既存画面の案内を変える、確認メールに必要な情報を載せるなど、別の案も考えられます。
どの案がよいかは、この一文だけでは決まりません。今はどこで日時を確認しているのか、何が足りないのか、どのタイミングで確かめたいのかを聞く必要があります。
また、「日時を確認したい」の背景が、来場ではなく、同僚へ予定を伝えることかもしれません。その場合は理由も変わります。要望の言い換えだけで終わらせず、背景が分からなければ未確認として残してください。考え方は、要望と課題の違いにもつながります。
元の「ボタンがほしい」という言葉は消さずに残します。短くまとめたストーリーと元の記録を行き来できれば、あとで意図を確かめやすくなります。
一文で共有することと、後で確認すること
ユーザーストーリーが書けても、すぐに実装を始められるとは限りません。「予約を確認する」だけでは、キャンセル済みの予約を含めるか、誰の予約まで見られるかなどが分からないためです。
一文は、話し合いの入口として使います。対象範囲、具体的な動作、権限などは、関係者と確認して詳しくしていきます。ユーザーストーリーと仕様を対立させる必要はありません。目的を短く共有する記述と、実装・確認に必要な詳細では、役割が違うということです。
受入条件と対象範囲は、あとで具体化する
受入条件は、その改善が期待した状態になっているかを確かめるための条件です。架空の予約サービスなら、「ログインした本人が自分の有効な予約を開くと、予約日時を確認できる」といった条件が候補になります。
ただし、これは説明用の一例で、これだけで十分という意味ではありません。本人以外の予約へのアクセスや、予約がない場合の表示なども、対象範囲に応じて検討します。
| 記録するもの | 役割 |
|---|---|
| ユーザーストーリーの短い記述 | 誰の、何の目的を扱うか共有する |
| 対象範囲・受入条件など | 今回の改善で必要な動作や確認方法を具体化する |
| 元の要望・調査記録 | その目的を考えた根拠へ戻れるようにする |
詳細をそろえる段階では、改善要望を開発チケットにする方法を参照できます。チケットは作業を管理する記録で、その中にユーザーストーリーを含める運用もあります。すべてのチケットを、同じストーリー形式へ無理に書き換える必要はありません。
最初は一つの要望に、利用者と理由を添える
手元の要望を一件選び、次のひな形に書いてみてください。本記事で提案する整理用の表です。
| 項目 | 記入すること | 自分の記入欄 |
|---|---|---|
| 利用者 | 誰の作業か | ［記入］ |
| したいこと | その人が達成したいこと | ［記入］ |
| 理由 | なぜ、それが必要なのか | ［記入］ |
| 元の根拠 | 要望や確認記録への参照 | ［記入］ |
| 未確認 | まだ分からないこと | ［記入］ |
埋められたら、利用者・したいこと・理由を短くつなぎます。理由が分からないなら、もっともらしい文章を作るより、「その操作を、どんな仕事のために使いますか」と聞く準備をしましょう。
最後に、一文を関係者と読み合わせます。「誰のことか同じように想像できるか」「理由は元の記録で確かめられるか」「希望された機能だけでなく、したいことまで書けているか」を見ます。言い回しを直すだけで解決できない疑問は、確認事項として残します。
なお、ストーリーを書いたことは、採用や実装の約束ではありません。候補を整理し、何から取り組むかを考える一覧については、バックログの基本で説明しています。
まとめ
ユーザーストーリーは、利用者がしたいことと理由を短く伝えるための記述です。「誰が・何を・なぜ」が見えると、実装案だけではなく、その案で何を達成したいのかを話し合えます。
まずは一件の要望に、利用者と理由を添えてみましょう。元の言葉を残し、未確認の理由は創作しないことが大切です。受け取った声を整理し、判断や対応につなぐ全体像は、機能要望管理の基本で確認できます。
参考資料
- GOV.UK：Writing user stories — 利用者・したいこと・目的を含める考え方、書式の柔軟性、受入条件と後の話し合いを参照。英国政府向けの必須規則を、すべての開発チームへ一般化していません。
