ユーザーストーリーの書き方（例と受け入れ基準付き）

ユーザーストーリーとは、ユーザーの視点から見た機能を短く記述したものです。「〔ユーザーの種類〕として、〔目的〕をしたい。それによって〔理由〕を得たい」という形になります。その下に受け入れ基準を書きます。受け入れ基準は、ストーリーが完了したとみなされるために満たされるべき、いくつかの具体的な条件です。各ストーリーは、ひとまとまりの作業で作成してテストできるほど小さく保ち、誰でも確認できるように基準を書いてください。

ユーザーストーリーは、アジャイル開発のチームによって広まりましたが、AIアプリビルダーを使って一人で作る場合にも同じように役立ちます。良いストーリーは、良いプロンプトでもあります。

形式

ユーザーストーリーは3つの部分からできています。

〔誰〕として、〔何〕をしたい、それによって〔なぜ〕を得たい。

• 誰とは、具体的な種類のユーザーのことです。初めて訪れた人、有料会員、クリニックの受付、管理者など。「ユーザー」とだけ書かないでください。
• 何とは、ユーザーがしたいことを、ユーザー自身の言葉で書いたものです。画面がどう動くかではありません。
• なぜとは、ユーザーが気にしている結果です。ここは飛ばされがちですが、間違ったものを作ってしまうのを防ぐ重要な部分です。

例：

ジムの会員として、スマートフォンからクラス予約をキャンセルしたい。それによってキャンセル待ちの人が自分の枠を取れて、無断キャンセル料を請求されないようにしたい。

「なぜ」は、「何」だけでは分からなかった2つのことを教えてくれます。スマートフォンで動く必要があること、そしてキャンセル待ちと料金のルールが関係していることです。

受け入れ基準

ストーリーは、何が求められているかを示します。受け入れ基準は、それがいつ完了したとみなされるかを示します。2人が読めば、それぞれの項目に合格しているかどうかで意見が一致するほど、具体的である必要があります。

よく使われる書き方はGiven／When／Thenです。

• Given（前提）：ある開始状況
• When（操作）：ユーザーが何かをする
• Then（結果）：その結果

ジム予約のストーリーの場合：

1. Given 12時間より先の予約がある、When キャンセルをタップして確定する、Then 予約が削除され、「予約をキャンセルしました」と表示される。
2. Given 予約をキャンセルし、そのクラスにキャンセル待ちがいる、When キャンセルが保存される、Then キャンセル待ちの先頭の人が枠を取得し、メールを受け取る。
3. Given 12時間以内に迫った予約がある、When キャンセルをタップする、Then 確定する前に、直前キャンセル料が適用されることが表示される。
4. Given スマートフォンの幅の画面を使っている、Then 横にスクロールしなくても、キャンセルボタンが見える。

テストできる項目であれば、単純なチェックリストでも構いません。「キャンセルは簡単」はテストできません。「予約一覧からキャンセルまで最大2回のタップで完了する」はテストできます。

手順：良いストーリーの書き方

ステップ1：実在のユーザーと、実際の問題から始める

ユーザーの種類を1つ選び、今その人が困っていることを決めます。顧客インタビューをしたことがあれば、その人たちの言葉を使ってください。「キャンセルを忘れて料金を取られてしまう」は、「キャンセル機能を追加する」よりも良い出発点です。

ステップ2：一行のストーリーを書く

テンプレートに当てはめます。説得力のある「それによって」が書けない場合は、そもそもその機能が必要かどうかを考え直してください。

ステップ3：受け入れ基準を3〜6個追加する

まず主な成功ケースを押さえ、次に重要なバリエーションを加えます。別の役割、データが空の状態、上限、エラーなどです。6個を超えて書いているなら、そのストーリーはおそらく大きすぎます。

ステップ4：対象外の内容を書き出す

1行書いておくだけで、多くのやり取りを省けます。「対象外：有料クラスの返金、管理者による会員の代理キャンセル」。これがあると、作っている途中でストーリーが膨らむのを防げます。

ステップ5：INVESTで確認する

INVESTは、良いストーリーを確認するための一般的なチェックリストです。ストーリーは次の条件を満たすべきです。

すべてのストーリーを採点する必要はありません。ストーリーがしっくりこないとき、その理由を知りたいときに最も役立ちます。

良い例と悪い例

大きすぎるストーリーの分割方法

プロジェクトが止まってしまうのは、大きなストーリーがあるときです。分割のよくある方法は次のとおりです。

• ユーザーの役割で分ける。 会員は自分の予約をキャンセルでき、スタッフは誰の予約でもキャンセルできる。
• 流れの段階で分ける。 クラスを閲覧する、クラスを予約する、リマインダーを受け取る。
• 単純なケースを先に作る。 無料クラスのキャンセルを今作り、料金と返金は後のストーリーで扱う。
• データの違いで分ける。 まず1つの拠点をサポートし、後で複数の拠点に対応する。
• 正常系を先に、エラーを後に。 まず動くものを作り、そのあとで満員のクラスや期限切れの回数券などの処理を追加する。

それぞれの部分も、ユーザーが使えて、その価値に気づけるものであるべきです。

ユーザーストーリーをプロンプトとして使う

受け入れ基準付きのユーザーストーリーは、AIアプリビルダーへの良いプロンプトにとても近いものです。誰が、何を、なぜ、そして完了の定義を、AIに伝えられるからです。1メッセージに1ストーリーを送ってください。

ジムの会員として、スマートフォンからクラス予約をキャンセルしたい。それによって、キャンセル待ちの人が自分の枠を取れるようにしたい。 受け入れ基準：

1. 「マイ予約」の各予約にキャンセルを表示し、確認のステップを設ける。
2. クラス開始の12時間より前にキャンセルした場合は、予約を削除するだけにする。
3. 12時間以内の場合は、確定する前に「直前キャンセル料5ドルが適用されます」と表示し、その料金を予約に記録する。
4. そのクラスにキャンセル待ちがいる場合は、先頭の人が枠を取得し、メールを受け取る。
5. スマートフォンの幅の画面で動作する。 対象外：返金、スタッフによる会員の代理キャンセル。 これを作ってから、プレビューで各基準を確認し、どれが合格しているかを教えてください。

また、大まかなアイデアからストーリーの下書きをAIに頼み、それを自分で編集することもできます。

私のアプリのアイデアは次のとおりです：〔2〜3文〕。最初のバージョン向けのユーザーストーリーを、ユーザーの種類ごとにまとめて書いてください。各ストーリーには、Given／When／Thenの受け入れ基準を3〜5個付けてください。公開に必須のものと、後回しにできるものを印をつけて示してください。

結果は必ず読んで、編集してください。AIはあなたのユーザーを知りません。知っているのはあなたです。

また、受け入れ基準はテスト計画としても使えます。ストーリーが作られたら、各基準を自分で確認してください。この考え方については、公開前のアプリのテスト方法のガイドで詳しく扱っています。

ユーザーストーリーが他の文書とどう関係するか

• プロダクト要件定義書はプロダクト全体を記述します。課題、ユーザー、スコープです。ユーザーストーリーは、その中の詳細な部品です。AIでPRDを書く方法を参照してください。
• バグレポートは、すでに作られたストーリーに対して、何かが壊れていることを記述します。良いバグレポートの書き方を参照してください。
• MVPは、中核となる価値を提供する、最小限のストーリーの集まりです。MVPとはを参照してください。

よくある間違い

• 「ユーザーとして…」で始めてしまう。 漠然としすぎています。実際のユーザーの種類を書いてください。
• 「それによって」を省く。 理由がないと、適切なトレードオフを判断できません。
• 必要性ではなく、解決策を書く。 「ドロップダウンがほしい」と書くと、誰も考えていないうちに設計を固定してしまいます。
• テストできない基準。 「簡単」「速い」「直感的」は願望であって、基準ではありません。
• 実際にはエピック（大きな機能群）であるストーリー。 「アカウントを管理する」は、10個のストーリーに相当します。
• すべてのストーリーを最初に書いてしまう。 次の数個だけを詳しく書き、残りは1行の概要のままにして、必要になったときに詳しく書いてください。

Mythexでのストーリー

Mythexでは、Planモードがアイデアをストーリーに変えるのに適しています。エージェントは、何かを編集する前にアプローチについて話し合います。ストーリーの準備ができたら、Buildに切り替えて貼り付けてください。1メッセージに1ストーリーです。それぞれの後で、/testでプレビュー上の操作を確認し、流れをチェックできます。もしうまくいかなかった場合は、どの返信でもこの時点に戻すで巻き戻せます。ドキュメントの効果的なプロンプトや、AIアプリビルダーへのプロンプトの書き方のガイドも参照してください。

ユーザーストーリーのチェックリスト

• 具体的な種類のユーザーを挙げている
• 設計ではなく、必要性を記述している
• 実際の「それによって」という理由がある
• テスト可能な受け入れ基準が3〜6個ある
• 少なくとも1つのエッジケースまたはエラーを扱っている
• 対象外の内容を明記している
• ひとまとまりの作業で作成してテストできるほど小さい
• 作成後に、基準を1つずつ確認している

よくある質問