ユーザーストーリーと受け入れ基準について

はじめに

開発本部所属QAエンジニアの塚山です。今回はユーザーストーリーと受け入れ基準について解説します。私が携わっているプロジェクトではスクラムを採用していませんが、ユーザーストーリーや受け入れ基準を作成しています。これらを定義することによってチーム内で同じ基準を用いてプロダクトの動作確認ができます。

なぜユーザーストーリーや受け入れ基準が必要なのか

私が今まで携わってきたプロジェクトではFigmaが仕様書代わりになっているケースが多かったです。Figma上で表現されていない細かい仕様があった時に、実装するエンジニアがプロダクトオーナー（PO）もしくはプロジェクトマネージャー（PM）に尋ねて確認するか、そのまま自分で解釈して実装してしまう場合がありました。それらが後々になって想定とは異なる仕様であったり、バグが発生してしまう原因になっていました。

Figmaはあくまでデザインツールでしかないと考えています。 正常系であるUIと画面遷移は表現できても、データのロード中や、タイムアウト時のエラーハンドリング、バリデーションエラー時の挙動といった「動的な振る舞い」 や細かい仕様を書くのは大変です。デザイナーさんに全て完璧に用意してもらうのも作業負荷を考えると大変ですし、こちらからお願いしにくいですよね。

そこで要件定義時や画面設計時にユーザーストーリーや受け入れ基準を合わせて作ることで、ステークホルダー間での仕様に対する認識ズレを防げます。また早期に仕様を固めてドキュメントに落とし込むことで、いつでも誰でも正しい仕様を確認できます。

ユーザーストーリー

ユーザーストーリーは、システムが実現する機能を「ユーザーの視点」で簡潔に記述したものです。 「何を作るか（What）」だけでなく、「誰が（Who）」「なぜ（Why）」その機能を必要としているのかを言語化するために用います。

仕様書やFigmaだけだと、どうしても「ボタンの配置」や「画面遷移」といった What（機能・見た目） に目が向きがちです。しかし、そこにユーザーストーリーを加えることで、 Why（ユーザーが得られる価値） をチーム全体で共有できるようになります。

基本的に下記のテンプレートに従って書きます。

As a（誰が）： ターゲットとなるユーザー（例：一般ユーザー、管理者、未登録ゲスト）
I want（何をしたい）： 実現したい機能や行動
So that（なぜ）： その機能を使う目的、得られるメリット

良いストーリーのコツは『Why（なぜ）』を重視すること

△ 良くない例
As a ユーザー 
I want ログイン画面にIDとPWを入力する
So that ログインボタンが押せる

これでは 「操作」 を書いているだけで 「価値」 が見えません。なぜログインしたいのか？という根本的な動機を書くことが重要です。

◎ 良い例
As a ユーザー
I want 自分のアカウントでログインする
So that ログイン後のダッシュボードでタスク状況を確認できる

ここが明確になると、「他人のデータが見えてしまったらクリティカルなバグだな」「ログイン後にダッシュボードが空っぽだったら価値がないな」といった、本質的なテスト観点を導き出しやすくなります。

作成例

今回はシンプルなタスク管理アプリのアカウント作成のストーリーを例に考えます。

As a ユーザー
I want 自分のアカウントを新規作成する
So that アカウントを持っていないと使えない機能を使えるようにしたい

私がテスト自動化フレームワーク（Cucumber等）で使われるGherkin記法を用いて、テストシナリオを書く時には『Descriptions（説明）』に書いています。
ユーザーストーリーを書くことでステップ等が何を表現しているかがわかりやすくなります。

Feature: アカウント作成
    As a ユーザー
    I want 自分のアカウントを新規作成する
    So that アカウントを持っていないと使えない機能を使えるようにしたい

    Example: アカウント作成する
        Given ...
        When ...
        Then ...

受け入れ基準（Acceptance Criteria, AC）

受け入れ基準（Acceptance Criteria、以下AC）とは、そのストーリーが「完了（Done）」したと判断するための具体的な条件リストです。 一言で言えば、「この条件をすべて満たせば、この機能は完成とみなす」という合否判定のラインです。

ユーザーストーリーが 「ユーザーの実現したいこと（Why/What）」 を表すのに対し、ACは 「システムが満たすべき振る舞いや制約（How/Rules）」 を定義します。

作成例

上記のユーザーストーリーに対してACを作成します。
ACに関しては特にフォーマットが存在しないので、読んで理解しやすいように書きます。
今回はわかりやすいようにだいぶ省略して書きます。

ID	項目	確認内容
1	アカウント作成	アカウント作成完了メッセージが表示されるか
2	メールアドレス	メールアドレス形式（@を含む）であるか
3	パスワード	間違ったパスワードで弾かれるか

AC増えすぎ問題

ACになんでも書いてしまうとどんどんACが肥大化してしまいます。回避するためにいくつかの対策が考えられます。

• バリデーション等の詳細な基準は別のシートで管理する
• 大きなストーリーを分割する

詳細な基準は別のシートで管理する

パスワード等のバリデーションをACで表現するときに確認内容が多岐にわたってしまいます。そこで別のシートにバリデーションルールを記載し、元のACではそちらを参照するようにリンクを貼ります。このようにすることでACの記述量を減らすことができます。また別のストーリー間でルールを共通化することで項目の抜け漏れや編集漏れを防ぐことができます。

作成例

別シートで管理する前

ID	項目	確認内容
1	アカウント作成	アカウント作成完了メッセージが表示されるか
2	メールアドレス	メールアドレス形式（@を含む）であるか
3	パスワードの文字数	16文字以上か
4	パスワードの文字種	小文字が使われているか
5		大文字が使われているか
6		記号が使われているか

別シートで管理した後

ID	項目	確認内容
1	アカウント作成	アカウント作成完了メッセージが表示されるか
2	メールアドレス	メールアドレスのバリデーションルールに従っているか
3	パスワード	パスワードのバリデーションルールに従っているか

パスワードバリデーションルールの例

ID	項目	確認内容
1	文字数	16文字以上か
2	文字種	小文字が使われているか
3		大文字が使われているか
4		記号が使われているか

NISTのガイドラインでは文字種のルールを設定しない方が良いとされていますが、今回は説明のためにあえて書いています

大きなストーリーを分割する

複数の機能を一つのストーリーに入れてしまうと、それに伴ってACも多くなってしまいます。出来る限り機能単位でストーリーを分割してACを書きます。

分割前

As a ユーザー
I want 自分のアカウントを新規作成してログインする
So that 自分のアカウントでログインしてダッシュボードを確認したい

ID	項目	確認内容
1	アカウント作成の項目	省略
2	ログインの項目	省略

分割後

アカウント作成

As a ユーザー
I want 自分のアカウントを新規作成する
So that 自分のアカウントで会員限定機能を使いたい

ID	項目	確認内容
1	アカウント作成の項目	省略

ログイン

As a ユーザー
I want 自分のアカウントでログインする
So that 自分のアカウントでログインしてダッシュボードを確認したい

ID	項目	確認内容
1	ログインの項目	省略

まとめ

ユーザーストーリーと受け入れ基準はQAエンジニアだけではなく、ビジネス開発や開発エンジニア視点でも役に立つものです。コードを実装する前に仕様の抜け漏れが無いか確認することで手戻りを防げます。いわゆるシフトレフトというものですね。正直ユーザーストーリーと受け入れ基準をしっかり準備するのは大変ですが、ユーザーに対してより良いプロダクト提供するためには欠かせないと思います。

▼新卒エンジニア研修のご紹介

レアゾン・ホールディングスでは、2025年新卒エンジニア研修にて「個のスキル」と「チーム開発力」の両立を重視した育成に取り組んでいます。 実際の研修の様子や、若手エンジニアの成長ストーリーは以下の記事で詳しくご紹介していますので、ぜひご覧ください！

▼採用情報

レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。 現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。