受け入れ基準の書き方：注文確認の具体例で学ぶ

受け入れ基準は、あるストーリーが合意した範囲を満たすために実現すべき動作を示します。確認する人が観察できる条件として、何が表示されるか、どの操作ができるか、操作に失敗したらどうなるかを書きます。注文内容を確認するストーリーなら、支払いに進む前の金額表示、配送方法の変更、エラー状態を明確にします。

共有のプロダクト計画用ワークスペース（英語）があれば、プロダクト担当、デザイン、開発、QAが条件を一緒に検討できます。以下では購入手続きを例に、少数の基準を組み立て、Given–When–Thenのシナリオにし、「完成の定義」や範囲外の作業と区別します。

目的と範囲から考える

利用者が実現したいことを表すストーリーを使います。「以前に購入したことのある顧客として、誤りを直せるように、支払いの前に注文を確認したい」という例です。顧客はログイン済みで、カートに商品があり、配送先の住所も保存しています。対象は既存の購入手続きにある注文確認の段階であり、アカウント作成や新しい決済サービスとの連携ではありません。

この段階で、どの修正を可能にするかを決めます。ここでは利用可能な配送方法を選べ、カートや住所の編集に戻れます。確認画面から直接商品を削除する機能、プロモーションコードの追加、決済サービスとの連携の作り直しは別の判断です。境界がなければ、「誤りを直す」に複数の機能が含まれると、それぞれが違う想定をしかねません。

「顧客がすべて確認できる」という基準案では、こうした判断が隠れてしまいます。「すべて」を具体的な項目と操作に置き換えてください。デザインでは表現すべきものが、QAでは確認すべきことが分かり、開発側のデータ保存方法まで指定せずに済みます。

曖昧な表現を観察できる条件にする

「購入手続きを簡単にする」は目標ですが、確認する人によって解釈が変わります。このストーリーでは次の条件を合意します。

1. 注文の概要：支払いに進む前に、各商品の名前、数量、価格に加え、小計、配送料、税額、通貨、合計が表示される。
2. 配送方法の変更：ほかの利用可能な配送方法を選ぶと、先に進む前に配送料と合計が更新される。
3. 住所の不足・配送不可：住所の必須情報が不足している場合や、選択した方法でその住所に配送できない場合は、問題と住所または配送方法の変更手段が表示され、支払いへ進めない。
4. 金額の更新：配送料の取得中や取得失敗時には、古い合計のまま先へ進めない。失敗時は再試行でき、カートの内容は保持される。
5. 修正のための経路：カートや住所の編集に戻っても、注文のほかの情報は保持される。確認画面へ戻ると、変更後のデータが概要に反映される。

これは、この例で意図している動作です。対応する配送方法、税額の計算、住所ごとの配送可否は、引き続きプロダクト側が決めます。基準は合意済みのルールを参照するものであり、新しい税や配送の方針を勝手に定めるものではありません。

計算の解釈をそろえるため、具体的なテストデータを使います。例として、20米ドルの商品2点で小計40米ドル、通常配送は5米ドル、テストデータが返す税額は4米ドルとすると、表示する合計は49米ドルです。速達配送のデータは配送料9米ドル、税額4米ドルを返し、合計は53米ドルになります。これらは例の固定値であり、税率のルールではありません。確認画面が受け取った金額を整合する形で表示するかを確かめるための値です。

受け入れ基準、完成の定義、対象外を分ける

受け入れ基準は、いま話し合っている特定の動作に適用されます。一方、スクラムにおける「完成の定義」は、プロダクトのインクリメントに求められる品質を示します。Scrum.orgもストーリー固有の受け入れ基準と完成の定義を区別しています。必要な機能を定めても、チーム共通の品質基準の代わりにはなりません。

対象外の項目はストーリーの近くに置きますが、それを満たした受け入れ基準として数えません。「決済サービスの再設計は対象外」という記述では、注文確認が動くことを示せません。同様に、「データベースにフィールドを作る」はタスクにはなりますが、顧客から何が見えるべきかを説明していません。

配送方法が利用できない状態は、対象外の機能とは異なります。選んだ操作の流れの中にあるエラー状態なので、どう動くかを決める必要があります。「対象外」に移すだけでは、顧客の操作経路が未定義になります。ストーリーが大きすぎるなら、利用できる経路を保ちながら作業を分割し、新しい境界を明示的に合意します。

Given–When–Thenでシナリオを書く

特定の状態と操作に依存する条件には、Given–When–Thenの形式が役立ちます。CucumberのGherkinリファレンスでは、開始時の状況、出来事、観察できる結果を分けています。自動テストにつなげる前の話し合いでも、この構造を使って認識をそろえられます。

シナリオ1：現在の注文を確認する

• 前提（Given）：顧客のカートは例の内容で、保存済み住所に不足がなく、通常配送が選ばれている。
• 操作（When）：顧客が注文確認画面を開く。
• 結果（Then）：商品、住所、配送方法、小計40米ドル、配送料5米ドル、税額4米ドル、合計49米ドルが表示される。

シナリオ2：配送方法を変更する

• 前提（Given）：顧客は通常配送が選ばれた例の注文を確認している。
• 操作（When）：速達配送を選び、金額の取得に成功する。
• 結果（Then）：支払いに進めるようになる前に、配送料9米ドル、合計53米ドルが表示される。

シナリオ3：不足している住所情報を修正する

• 前提（Given）：住所の必須項目が入力されていない。
• 操作（When）：顧客が確認画面から次へ進もうとする。
• 結果（Then）：不足している項目が示され、住所を編集する操作が用意される。カートを保持したまま、支払い前の段階にとどまる。

シナリオ4：金額更新の失敗から復帰する

• 前提（Given）：顧客が配送方法を変更し、新しい合計を待っている。
• 操作（When）：金額の取得に失敗する。
• 結果（Then）：合計を更新できなかったことが表示され、再試行できる。以前の配送料のまま支払いに進むことはできない。

一つのシナリオで一つの問いに答えます。カート編集、住所変更、割引適用、支払いを一つの長いシナリオにまとめると、失敗したときにどのルールが関係するのか分かりにくくなります。別のルールを話し合う必要がある場合に例を追加し、顧客名だけを変えて同じ条件を繰り返すことは避けます。

実装前に未決の問いを解く

プロダクト担当には意図した範囲を表せているか、デザイン担当には各状態がどう伝わるか、開発者にはどの依存関係が動作を変えうるか、QAには結果をどう確認するかを聞きます。「保存済みの住所が配送対象外になったらどうするか」は、想像でテストの期待値を決めるのではなく、プロダクト側で判断すべき問いです。

未決の問いは、合意済みの基準と分けて書きます。たとえば「以前の配送方法が使えなくなったら、別の方法を事前選択するか、顧客に選び直してもらうか」です。答えによって画面もテストも変わります。決定後は、関係する基準とシナリオを一緒に更新します。

新しい情報で範囲が変わる場合は、難しい条件を黙って削除せず、判断を記録します。住所編集を別のストーリーに分けても、注文確認のストーリーには、その機能へ進んで戻るための明確な経路が必要です。また、受け入れ基準を満たしても、チームの完成の定義は引き続き適用されます。

Boardmixでストーリーと例を整理する

Boardmixのボード上部にストーリーを置き、その下を「合意した基準」「具体例」「未決の問い」「対象外」の4つに分けます。各基準にIDを付け、配送方法の変更ならAC-2などとし、隣に対応するシナリオを置きます。ルールに例があるか、未決の問いが合意済みの条件に影響するかを見つけやすくなります。

共通の完成の定義は専用の参照領域に置き、各シナリオへ繰り返しコピーしません。話し合いの後、合意した基準を作業管理の記録へ移し、ボードにはルール、例、判断のつながりを残せます。

Boardmixのボードを開き、購入手続きのストーリーと4つのシナリオを並べてみてください。配送方法の変更から始めると、「合計が更新される」という言葉を全員が同じ意味で使っているかを早い段階で確認できます。