ユーザーストーリーは利用者が達成する目的を書く
利用者、必要な行動、その理由を短く表したものをユーザーストーリーと言います。機能名の代わりに、利用者がどの場面で何を達成するのかを共有するために使います。
予約ボタンを追加する、という項目だけでは、そのボタンが解決する問題がわかりません。予約可能な日時を選ぶ目的を記し、実装後に満たす条件を別途定義します。
ユーザーストーリーとは？利用目的と受け入れ条件の書き方
概要
利用者、必要な行動、その理由を短く表したものをユーザーストーリーと言います。この記事では、利用目的の記述と受け入れ条件、検証する単位の選び方を解説します。具体例を通して、実際の仕事で使う際の判断基準と注意点も紹介します。
公開日
更新日
利用者と必要な行動と理由を記す
GOV.UKは、利用者、必要な行動、達成する目的をストーリーの要素として示しています。（GOV.UK: User stories） 例えば初回の利用者が、空いている日時を選び、電話せずに予約を申し込むという内容なら、利用場面と目的が伝わります。
複数の目的を詰め込むと、何を試すのかが曖昧になります。予約申込と予約変更は、それぞれの状況を記載してください。
受け入れ条件は結果で書く
条件には、利用可能な日時が表示される、必須情報が不足していれば該当項目を示す、申込後に受付状況がわかる、などを記載します。色や部品名だけでは目的を満たしたか判定できません。
受付と予約確定が別の処理なら、その違いも条件に含めます。利用者が申込完了を予約確定と誤解しない表示が必要です。
一つの目的を試せる大きさで進める
予約業務全体を一つの項目にせず、日時選択と申込受付のような一連の利用を試せる単位を選びます。画面の部品ごとに作業を細切れにすると、利用目的を達成できるか試せない場合があります。
実際の利用者に試してもらい、操作の結果を条件と照合します。機能を公開する際には、サービスページでもできることと申込後の流れを説明してください。
SpreadSite は、Googleスプレッドシートで内容を管理し、テンプレートを使ってホームページを作成・公開・更新できるノーコードツールです。
新しい機能の利用方法を説明するホームページの作成に、ぜひ使ってみてください！
よくある質問
Q: ユーザーストーリーには決まった書式がありますか？
A: 利用者、行動、目的が伝わることが大切です。定型文を使っても構いませんが、書式を埋めることだけを目的にしないでください。
Q: 利用者の要望をそのまま書いてよいですか？
A: 希望する機能の背景を聞き、解決する問題を記載します。要望された機能以外の方法も検討できます。
Q: 受け入れ条件は何個必要ですか？
A: 目的の達成と重要な例外を判定する条件を用意します。固定の個数より、判断に必要な内容を重視します。
Q: ストーリーを作った後は何をしますか？
A: 実装方法を検討し、成果物を受け入れ条件と照合します。利用者の試行で問題が見つかったら内容を更新します。
