プラクティス名（別名）
ユーザーストーリー （ストーリーカード、３つのC、Role-Feature-Reason）
プラクティスの目的・狙い
- ユーザ要求とその価値を明確化する
- 要求事項を一件一葉に切り分ける
- ユーザとDEVの会話を促す
どんな時に使うか
- ユーザ要求を言語化する時
（もともとは物理的なカードに記載して整理していたが、近年はPBLの記入フォーマットとして用いられるケースが多い）
実施手順
ユーザのニーズを以下の記述形式で数行のシンプルな文章で表現する。
〈誰〉として〈何〉がしたい。なぜなら〈理由〉だからだ。
なおWho/What/Whyの3要素が含まれていれば、必ずしも上記の形式に沿わなくても構わない。書き手が誰であっても内容は常にユーザ視点で書かれていなければならない。またシステム知識がない人にも意味が通じるように書く。もちろん端的な文章だけで詳細な要件を伝えきることはできないため、ストーリーをきっかけにユーザとDEVが後日会話することが暗黙の前提となる。
ユーザーストーリーの重要な要素を「３つのＣ」という言葉で表現することがある。
| 英単語 | 和訳 | 特性 |
|---|---|---|
| Card | カード | 要求をカードに（書けるぐらいに）端的に表現する |
| Conversation | 会話 | 会話を通じて、ユーザからDEVに伝えられる |
| Confirmation | 確認 | DEVは何をもって完了となるのか確認する |
アレンジ例
- 受け入れ条件を明確化するための記述（AC：Acceptance Criteria）を追記する
- ユーザーストーリーとしては粗すぎる要求事項（エピック）も一旦カード化しておき、後日詳細化する
- 記述形式を5Wに拡張する（When/Where/Who/What/Why）
アンチパターン
- システム目線の機能一覧になってしまっている（ユーザにとっての価値が読み取れない）
- どうやって実現するか、という手段（How）を書いてしまっている
- 要求内容が抽象的すぎて何をもって完了となるのか判断がつかない
参考情報
ユーザーストーリーとユースケースの違い
https://agnozingdays.hatenablog.com/entry/2015/07/22/011732
ユーザストーリーとユーザシナリオの違い
https://archeco.co.jp/ux-design/user-scenario/
こぼれ話（私的コメント）
まったくの新規アプリならまだ分かりやすいのですが、システム再構築とかで、既存の要件定義書や機能一覧を元にシステム屋がPBLを書き起こしてたりすると、たいてい中身はユーザーストーリーになっていない。それならばと、ユーザさん（PO）に直接書いてもらおうと記入をお願いすると、今度はシステム屋さんに伝わるようにとシステム目線で書こうとしてしまって、やっぱりユーザーストーリーにならない。これまでの習慣を変えるのって難しいですね。