要件やユーザーストーリーは書けるようになった。開発チームに渡す言葉も、以前よりだいぶ整ってきた。それでも、実装が上がってくると「思っていたものと少し違う」というズレが毎回どこかで起きる——プロダクトマネジメントを兼務する経営者から、よく聞く悩みです。
原因の多くは、ストーリーに「何を満たせば完成と言えるか」が書かれていないことにあります。ストーリー本文は「誰が」「何を」「なぜ」を伝えますが、それだけでは開発者が細部の判断を自分で埋めることになり、その判断があなたの想定とずれます。この「完成の条件」を明文化したものが受け入れ基準です。
本記事では、ユーザーストーリーに受け入れ基準を持たせるための書き方を、5つのステップで解説します。特別なツールは必要なく、ストーリーの下に数行書き足すだけで、手戻りは目に見えて減ります。
受け入れ基準とは何か——PdMの言葉で整理する
受け入れ基準とは、「このストーリーが完成したと、依頼した側が受け入れられる条件」を、実装前に文章で決めておくものです。英語ではAcceptance Criteriaと呼ばれ、ユーザーストーリーとセットで書くのが一般的です。
役割は3つあります。
- 完成の定義をそろえる：あなたと開発者とテスト担当者が、同じゴールを見て作業できる。
- 設計判断の指針になる：開発者が実装中に迷ったとき、「この基準を満たすか」で判断できる。
- 確認の手順になる：上がってきたものが基準を1つずつ満たしているかを見れば、レビューが感覚的な指摘の応酬にならない。
似た言葉と切り分けておきます。
- 要件・要求：何を、なぜ作るか。受け入れ基準は、その要件が「満たされたと言える状態」を条件の形にしたものです。要件が上流、受け入れ基準がその直下にあります。
- 完成の定義（Definition of Done、DoD）：すべてのストーリーに共通で適用するチェック項目（テストを書いた、レビューを通した、ドキュメントを更新した、など）。受け入れ基準は、ストーリー1本ごとに固有の中身を書きます。両者は別物で、どちらも必要です。
- テストケース：受け入れ基準を、具体的な入力値と手順まで細かくしたもの。基準は「何を確かめるか」、テストケースは「どう確かめるか」です。基準は経営者でも書けますが、テストケースの詳細化は開発チームの仕事です。
要件と受け入れ基準の関係は、要件定義そのものの進め方とあわせて見ると位置づけがはっきりします。
なぜ受け入れ基準が曖昧なまま進んでしまうのか
書いたほうがいいと分かっていても抜けてしまうのは、意志の問題ではなく、いくつかの構造的な理由があります。
1つ目は、ストーリー本文を書き終えた時点で「伝えた」気になることです。 「ログインしているユーザーとして、請求書をダウンロードしたい。経理処理に使うため」——これで意図は伝わったように見えます。しかし「どの期間の請求書か」「複数月をまとめてダウンロードできるのか」「PDFかCSVか」「未確定の月はどう扱うか」は何も決まっていません。本文の一文には、完成の条件を書ききれる情報量がありません。
2つ目は、正常系しか思い浮かばないことです。 「請求書をダウンロードできる」という成功パターンは誰でも書けます。一方、「該当する請求書が1件もないとき」「ダウンロード中に通信が切れたとき」「権限のないユーザーがURLを直接叩いたとき」といった例外は、意識して洗い出さないと出てきません。そして手戻りの多くは、この洗い出されなかった例外で起きます。
3つ目は、書く時間がないことです。 兼務の経営者は、ストーリーを量産すること自体に精一杯で、1本ずつ基準を練る余裕がない。結果、基準なしのストーリーが積み上がり、開発者が都度確認に来るか、確認せずに推測で作るかのどちらかになります。どちらも、後からまとめて直すより遅いのですが、その場では気づきにくい。
4つ目は、開発チーム側も「基準がないのが普通」に慣れていることです。 これまで基準なしで回してきたチームでは、基準を求めること自体が新しい習慣です。最初は面倒がられますが、数本やってみると、質問の往復が減ることをチームが実感し、定着していきます。
受け入れ基準を書く5ステップ
STEP1：ストーリーの「完成」を、まず一文で言ってみる
条件を箇条書きにする前に、「このストーリーは、何ができたら完成か」を自分の言葉で一文にします。
完成とは：ログイン中のユーザーが、確定済みの月の請求書を、月を選んでPDFでダウンロードできること。
この一文を書くだけで、「確定済みの月だけが対象」「月単位で選ぶ」「形式はPDF」という3つの判断が言語化されます。ここが曖昧なままステップを進めても、条件がぼやけます。まず自分の中の完成像をはっきりさせる工程です。
STEP2：正常系のシナリオを「Given-When-Then」で書く
一文にした完成像を、成功する流れとして分解します。おすすめは、次の3点セットで書く形式です。
- Given（前提）：どういう状態のときに
- When（操作）：ユーザーが何をすると
- Then（結果）：何が起きるべきか
例：
- Given：確定済みの請求書が3ヶ月分ある状態で
- When：ユーザーが「8月」を選んでダウンロードを押すと
- Then：8月分の請求書がPDFでダウンロードされる
この形式の利点は、「状態」「操作」「期待結果」が必ずそろうことです。「請求書をダウンロードできる」という書き方だと、どの状態で・何をしたときの話なのかが抜けますが、Given-When-Thenだと構造上抜けません。1つのストーリーに対して、主要な成功パターンを2〜4個書けば十分です。
ユーザーストーリー本文と受け入れ基準をどう並べて書くかは、ストーリーの書き方の記事で具体例を示しています。
STEP3：例外・境界・エラーを洗い出す
ここが、手戻りを減らすうえで最も効くステップです。正常系のシナリオそれぞれについて、「うまくいかない場合」を3つの角度から考えます。
- データがない・少ない・多い：対象の請求書が0件のとき。1件だけのとき。5年分あって一覧が長くなるとき。
- 権限・状態の境界：ログインしていないとき。無料プランで機能対象外のとき。退会手続き中のとき。
- 操作の失敗：ダウンロード中に通信が切れたとき。同じボタンを連打したとき。生成に時間がかかって画面を離れたとき。
それぞれに「Then」を決めます。
- Given：確定済みの請求書が1件もない状態で
- When：ユーザーがダウンロード画面を開くと
- Then：「ダウンロードできる請求書がまだありません」と表示され、ボタンは押せない状態になる
すべての例外を潰す必要はありません。「起こりうるか」と「起きたときの影響」で絞り込み、影響の大きいものから基準に入れます。この絞り込みの考え方は、優先順位付けの発想と同じです。
STEP4：非機能の条件を、必要な分だけ加える
機能の動きとは別に、「どのくらいの速さ・品質で動くべきか」に関わる条件を、そのストーリーで本当に重要なものだけ書き添えます。
- 速度：「請求書の生成は5秒以内に始まる。それを超える場合は生成中の表示を出す」
- 対応環境：「スマートフォンのブラウザでも同じ操作でダウンロードできる」
- 記録：「誰がいつどの請求書をダウンロードしたかを操作ログに残す」
注意点は、すべてのストーリーに非機能条件を機械的に足さないことです。DoD（完成の定義）で全体に担保できるものは、そちらに任せます。ここに書くのは、「このストーリーに固有で、外すと事業上まずい」ものだけです。
STEP5：開発着手前に、エンジニアと読み合わせる
書いた基準は、実装が始まる前にエンジニアと一度読み合わせます。目的は、レビューではなく「認識合わせ」です。この場でよく出てくるのが、次のような指摘です。
- 「この例外、実は既存の別画面と挙動を合わせる必要があります」
- 「Thenの条件、技術的には実現できますが、この基準だと工数が3倍になります。ここまでで十分ですか」
- 「前提にある『確定済み』の判定、いまのデータ構造だと即時には出せません」
こうした情報が着手前に出てくるだけで、実装後の作り直しが大きく減ります。読み合わせは15〜30分で終わります。この時間を惜しむと、後で数日単位の手戻りになります。
Given-When-Then形式と、シンプルな箇条書きの使い分け
受け入れ基準の書き方には、大きく2つのスタイルがあります。
Given-When-Then形式は、STEP2で示した「前提・操作・結果」の3点セットです。状態によって挙動が変わるストーリー、フローが複数あるストーリーに向いています。抜け漏れが起きにくい反面、単純な要件だと少し冗長になります。
箇条書き（チェックリスト）形式は、「〜できること」「〜が表示されること」を条件として並べる形です。
- 請求書一覧に、確定済みの月だけが新しい順で表示される
- 各行に「ダウンロード」ボタンがある
- ダウンロードしたPDFに、会社名・登録番号・金額が記載されている
状態遷移が少なく、「あるべき状態」を列挙すれば伝わるストーリーは、こちらのほうが速く書けます。
使い分けの目安は、「状態によって結果が変わるか」です。変わるならGiven-When-Then、変わらず「これとこれが満たされていればよい」ならチェックリスト。1つのストーリーで両方混ぜても構いません。大事なのは形式の統一より、完成の条件が誰にでも同じ意味で読めることです。
要求を検証可能な条件へ翻訳する流れ全体は、要求定義の記事とあわせて読むと理解しやすくなります。
よくある落とし穴
実装の指示を書いてしまう。 「ボタンは画面右上に青色で配置する」といった実装方法は、受け入れ基準ではありません。基準に書くのは「ユーザーがダウンロード操作にすぐ気づける位置にある」まで。どう実現するかは開発チームの領域です。基準に実装を書き込むと、より良い作り方の余地を奪い、かつ本質的でない指摘でレビューが長引きます。
測れない言葉で書く。 「使いやすいこと」「レスポンスが速いこと」「違和感がないこと」は、受け入れられたかどうかを判定できません。「3タップ以内で完了する」「2秒以内に結果が表示される」のように、満たしたかどうかを誰が見ても同じに判断できる言葉にします。
1つのストーリーに基準を詰め込みすぎる。 受け入れ基準が15個も20個も並ぶときは、ストーリーが大きすぎるサインです。基準が多すぎると、レビューが重くなり、いつまでも完成しません。ストーリーを分割し、それぞれに3〜7個程度の基準がつく粒度に整えます。
PRDに基準を書いたから、と省略する。 PRD（プロダクト要求仕様書）に大枠の受け入れ条件を書いていても、開発チームが日々見るのは個々のストーリーです。ストーリー側に、そのストーリー固有の基準を書き直す手間を惜しまないことが、結局は近道になります。
PdMを兼務する経営者が現実的に回すには
限られた時間で受け入れ基準を書き続けるための、現実的な進め方をまとめます。
すべてのストーリーで完璧を目指さない。 影響範囲の大きい機能、決済やアカウントに関わる機能、外部に見える機能から基準を丁寧に書きます。社内向けの管理機能や、後で直しやすい表示まわりは、箇条書き数行で十分なことが多いです。
「正常系2つ・例外2つ」を最低ラインにする。 迷ったら、成功パターンを2つとよく起きる例外を2つ、Given-When-Thenで書く。これだけでも、基準なしの状態からは大きく前進します。
読み合わせをストーリー着手のルールにする。 「基準の読み合わせをしていないストーリーは着手しない」を開発チームと合意しておくと、基準を書く習慣が自動的に維持されます。
テンプレートを1つ用意する。 ストーリー本文・完成の一文・Given-When-Then欄・非機能欄・DoDチェックの並びを固定したひな形を作り、毎回そこに書き込む形にすると、書く負荷が下がり、抜けも減ります。
受け入れ基準を書くことは、開発チームに渡す判断を「言葉にして手放す」練習でもあります。何を任せ、どこまでを自分で決めるかを整理する流れの一部として捉えると、続けやすくなります。
まとめ
受け入れ基準は、ユーザーストーリーに「何を満たせば完成か」を持たせるための、実装前に書く条件です。これがないと、開発者が細部を推測で埋め、その推測が経営者の想定とずれて手戻りになります。
書き方は、(1)完成を一文で言い、(2)正常系のシナリオをGiven-When-Then形式で分解し、(3)例外・境界・エラーを影響の大きいものから洗い出し、(4)非機能の条件を必要な分だけ加え、(5)着手前にエンジニアと読み合わせる、という5ステップです。
形式はGiven-When-Thenとチェックリストを使い分け、実装方法や測れない言葉は書かず、基準が多すぎるときはストーリーを分割します。すべてを完璧にする必要はなく、「正常系2つ・例外2つ」を最低ラインに、影響の大きい機能から丁寧に書けば、限られた時間でも手戻りは着実に減っていきます。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
