はじめに
皆さんはユーザーストーリーをどのように書いていますか？
実際の現場では、「長すぎる」「付箋に入りきれず文字が切れてしまう」「逆にシンプルすぎて目的がわからない」といった課題に直面することがあると思います。
そのため、万能なテンプレは存在せず、目的に応じて使い分けることが大事になります。
この記事では、そもそもユーザーストーリーとは何か、代表的なユーザーストーリーのテンプレートと、それをどう使い分ければよいかについて解説します。
ユーザーストーリーとは何か
顧客価値に基づき、ソフトウェアで何を達成するかを示す短い記述のことです。
フィーチャーの詳細を書かず、フィーチャーの核心となるキーワードを利用して記述します。
詳細をストーリーに表現しない理由としては以下の通りです。
- 詳細を顧客から聞き出すという会話のきっかけになる
- ストーリーを着手する時には環境や条件が大きく変わり、フィーチャーが最初に書いた内容通りに実装できないことがある
大事なことは、必要になったタイミングで必要な分だけ詳細を議論するということです。
典型的なフォーマット
Connextra形式
よく使われるのは「Connextra形式」と呼ばれる書き方です：
As a [役割]
I want [機能や行動]
So that [目的や価値]
例：
-
読者として、気になる記事をブックマークできるようにしたい。なぜなら、あとでまとめて読み返すことができるようにするためだ。
-
購入者として、気になる商品をリストに保存できるようにしたい。なぜなら、後でまとめて購入する際に忘れずに確認できるようにするためだ。
-
メリット
- 「なぜなら」という記述で時間が経ったとしても目的を思い出しやすい
- 目的の共通認識が取れるので、議論がスムーズになったり優先度判断がしやすくなる
-
デメリット
- 文字数が多く、ユーザーストーリーを記述している付箋に文字が収まり切らず、文字が途切れて表示されてしまう可能性がある
- ユーザーストーリーを小さく分割するというトリガーが働きにくくなる
シンプル形式
ooはxxできるというシンプルな形式です。
-
読者は記事をブックマークできる
-
学生は授業資料をダウンロードできる
-
メリット
- 簡潔な記述で、付箋に収まりやすく管理がスッキリする
- パッとみた時の認知負荷が少ない
- ユーザーストーリーを小さく分割するトリガーが働きやすくなる
-
デメリット
- 時間が経つと目的を忘れてしまう
- 新メンバーがユーザーストーリーを見た際に、目的を把握できず理解に苦しむ可能性がある
著者の所感
私の現場では、基本的にシンプル形式でユーザーストーリーを運用していました。
その理由は、ユーザーストーリーをできるだけ小さく分割して管理したいという目標があったからです。
しかし、シンプル形式には課題もありました。
新しくチームにジョインした際、ストーリーだけを見ても「なぜこの作業をするのか」という目的が把握しづらく、理解に苦しむことがありました。
また、数ヶ月後にストーリーを振り返った際にも、目的を忘れてしまいがちです。
アジャイル開発では、詳細までみっちり書かれたドキュメントを作ることは少ないため、目的をチーム全員が失念してしまうと非常に困るというリスクがあります。
テンプレートの使い分け
-
一ヶ月以内にほぼ確実に行うストーリー
→ シンプル形式を使用
短く書くことで付箋やカンバン上で管理しやすく、スピーディに着手できます。 -
優先度が未定で、数ヶ月後に行う可能性のあるストーリー
→ Connextra形式を使用
「誰のために」「何を」「なぜ行うのか」を明確にしておくことで、後から見返しても目的を理解しやすくなります。必要に応じて付箋にストーリーに関する情報が載っているドキュメントやSlackのリンクを貼っておき、後から確認できるようにしまう。 -
新規メンバーがチームに参加した場合
→ Connextra形式を使用
背景や目的が分かる形でストーリーを書いておくと、理解が早くスムーズにジョインできます。
まとめ
ユーザーストーリーは「誰のために、何を実現したいか」を簡潔に示すツールです。
正しいテンプレにこだわるよりも、チームで価値を共有し、意思決定に活かせるかどうかが重要です。
現場では状況や目的に応じて書き方を柔軟に変えることを意識しましょう。