インタビューからユーザーストーリーを書く：テンプレートと受け入れ基準

ユーザーストーリーには利用者が得る価値を書く

ユーザーストーリーは、製品を使う人の視点から望ましい結果を短く記したものです。よく使われる形式は「［役割］として、［利点］を得るために［行動］したい」です。ニーズを話し合うきっかけになります。要件と結果の検証方法は別途決めます。

インタビューでの「緑色のボタンを追加してほしい」という発言は、解決策の提案です。ストーリーを書くには、何をしようとしているのか、今の手順で何に困っているのかを調べます。解釈を確かめられるように元の発言を残します。

インタビューをもとにストーリーを書く手順

1. 具体的な出来事を選ぶ

   直近で実際に起きた出来事を探します。誰がどんな資料を使い、どんな結果を求めて行動しましたか。「誰もがレポートを必要としている」という一般論だけでは、独立したストーリーを書く根拠として不十分です。

2. 正確な発言と前後の文脈を控える

   タイムコードと前後の発言を残します。話し手の言葉と自分の結論を分けます。例外的な状況は、日常的な作業として扱わずに記録します。

3. 役割、行動、利点を明確にする

   役割には「利用者」とだけ書かず、状況が分かる呼び方を使います。行動は観察できるように書き、利点は本人にとってその行動が必要な理由を示します。

4. 対象範囲を確認する

   個別に議論し、検証できる一つの有用な結果を選びます。登録から年次報告までの全工程を一つのストーリーに含めるのは避けます。

5. 受け入れ基準を加える

   望ましい動作が実現したかを判断できる条件を書きます。主なケースと重要な例外を含めます。一つの発言を顧客の要件と見なす前に、基準をチームで合意します。

6. 未解決の点を議論に戻す

   アクセス権限、データ量、出力形式が不明なら、質問として明記します。よくある実装で空白を埋めるのは避けます。

調整担当者の発言をストーリーカードにする

架空のメモ管理システムの例で、Transkribatorの既存機能の説明ではありません。ニーズは余計な情報を含めずに選んだ部分を共有することです。ボタンの色は実装時の選択肢です。

出典はありますが、大半の顧客にとって重要かどうかはまだ分かりません。一つの録音が示すのは一つの体験です。他の根拠、製品の目標、実装コストを考慮し、開発の優先順位を別途決めます。

ストーリーと技術タスクの一覧を見分ける

「データベースにテーブルを作る」「イベントハンドラーを追加する」は技術タスクです。実装の一部にはなりますが、利用者にとっての利点は示していません。また、テンプレートどおりの文章だけでは、チームがすべての制約を理解したとはいえません。

画面部品の名称を使わずにテスト担当者へストーリーを説明します。変更前後に人が行うことを説明できなければ、インタビューを見直します。データが未選択、権限が不足、再試行といったケースも検証します。重要な例外に絞り、カードが製品全体の仕様書になるのを避けます。

出典と未解決の質問を含むカード

ストーリーのタイトル：
役割と作業状況：
［誰］として、［理由］のために［行動］したい。

出典：インタビュー／日付／タイムコード：
元の発言：
チームの解釈：

受け入れ基準：
1. ［条件］のとき、［行動］ができ、［結果］が得られる。
2. ［重要な例外］のとき、［想定する動作］になる。

このストーリーの対象外：
確認が必要な点：
記述を確認した人と日付：

• 役割が具体的で、利点が明確になっている。
• 引用とチームが選ぶ解決策が区別されている。
• 基準を観察によって検証できる。
• 質問は質問として明示されている。