「予約を変更できる」だけでは、何ができれば完成なのか判断できません。本人以外でも変更できるのか、空きがなくなったらどうするのかで、必要な振る舞いは変わります。
受け入れ条件は、利用者にとって必要な結果を、確かめられる形で書くものです。 この記事では、要望を仕様に落とす人向けに、架空の会議室予約を使って書き方を整理します。以下のルールや文面は作例で、特定サービスの仕様や実測結果ではありません。
作業の一覧と、完成の条件を分ける
GOV.UKの説明では、受け入れ条件はサービスが利用者のニーズに応えたかを確認するための、結果の一覧です。Writing user stories
「変更ボタンを置く」「更新処理を作る」は開発の作業です。それだけでは、利用者が予約を正しく変更できたかまでは分かりません。
この作例では、目的を「予約した社員が、予定の変更に合わせて会議室の利用時間を変えたい」と置きます。そのうえで、まず次のルールを仮に決めます。
- 変更できるのは予約した本人だけ。
- 変更先の時間帯に空きがあれば、予約を変更できる。
- 変更を受け付けられないときは、元の予約を残す。
これは合意のための出発点です。管理者による代理変更や、開始後の変更を認めるかは、別の論点として残します。担当者が想像で補って、決まった仕様にしないことが大切です。
前提・操作・結果の3つで書く
CucumberのGherkinリファレンスでは、例を初期の状況（Given）、出来事（When）、期待する結果（Then）で表します。また、結果には画面や通知など、外から観察できるものを使うよう説明しています。Gherkin reference
ここではその分け方を参考に、日本語の確認メモとして書きます。Cucumberの導入や、この書式の採用が必須という意味ではありません。
作例：空いている時間へ変更する
前提：予約した本人がログインしている。会議室Aの10:00〜11:00の予約があり、11:00〜12:00は空いている。
操作：利用時間を11:00〜12:00へ変更する。
結果：予約詳細に11:00〜12:00が表示され、予約が重複して作られない。予約一覧へ戻っても変更後の時間が表示される。
前提には、権限やデータの状態を書きます。操作には利用者が何をするか、結果には何を見て判断するかを書きます。この例なら、予約詳細と一覧を確認することで、完了メッセージだけを見て合格にすることを避けられます。
表示時刻のタイムゾーン、日付をまたぐ予約などが必要なサービスでは、その条件も決めます。一つの例で予約機能全体を確認できるわけではありません。
失敗したとき「何が残るか」も決める
成功する場合を書いたら、前提を一つ変えてみます。以下は、同じ予約変更に対する確認案です。
作例：操作中に、変更先の空きがなくなった
前提は、時間を選んだ時点では空いていたものの、確定する前に別の予約が入った状態です。この作例では、変更を受け付けず、元の10:00〜11:00の予約を維持します。「指定した時間は予約できなくなりました」と伝え、別の時間を選べるようにします。
ここで必要なのは、エラー文の確認だけではありません。「元の予約が消えていない」「同じ部屋・時間帯に予約が重なっていない」ことを、利用可能な確認画面や出力で確かめます。内部の整合性を保証する方法は、開発側の設計・検証でも扱います。
作例：終了時刻が開始時刻より前になっている
変更を受け付けず、元の予約を維持します。時刻の入力欄には「終了時刻は開始時刻より後にしてください」と表示する案です。直すべき項目が分かり、入力を修正して再度確定できるところまでを確認します。
作例：変更の応答を受け取れなかった
通信が途切れた場合、画面からは変更できたか判断できないことがあります。ここを「変更に失敗したので元の予約のまま」と決めつけません。この作例では、まず予約詳細を取得し直して現在の状態を確認する案にします。再取得もできない場合の案内と、再送信による重複をどう防ぐかは、仕様として詰める必要があります。
これらは、サービスに合わせて判断する設計上の論点です。すべての画面に同じ処理を当てはめるためのルールではありません。
曖昧な言葉を見つけたら、確認方法を隣に書く
「分かりやすい」「正しく」「問題なく」は、そのままでは人によって判断が変わります。この記事では、次の問いをレビューに使う案を勧めます。
| 曖昧な条件 | 打ち合わせで確かめること |
|---|---|
| 予約を問題なく変更できる | 誰が、どの状態から、何を変更できるか |
| エラーを分かりやすく表示する | どの問題で、どこに、何を直すよう伝えるか |
| 変更が正しく反映される | 詳細・一覧・通知のどこで、何を確認するか |
| 素早く変更できる | 誰のどの操作を、どの環境・負荷で測るか |
時間の条件に「2秒以内」などの数値を入れるなら、期待値の根拠と測定条件を合わせて決めます。数字を付けただけで、実際の使い勝手を確認できるわけではありません。利用者が操作を見つけられるかと、システムの応答時間も別に確かめます。
チケットに残す確認メモ
次は、この作例を整理した記入済みメモです。仕様の雛形としてコピーし、対象の機能に合わせて書き換えられます。自動実行するテストコードではありません。
対象：会議室予約の利用時間変更
目的：予約した本人が、予定変更に合わせて利用時間を変えられる
受け入れ条件の例
前提：本人の予約があり、変更先の時間帯が空いている
操作：利用時間の変更を確定する
期待する結果：詳細と一覧に変更後の時間が表示され、予約が増えない
確認方法：変更前後の予約を詳細画面と一覧画面で比較する
追加で確認する場面
・確定前に別の予約が入った場合は、元の予約を維持する
・終了時刻が開始時刻より前なら、変更せず修正方法を示す
・応答が不明な場合は、現在の予約状態を確認できる経路を用意する
未決事項
・管理者の代理変更：運用担当に確認
・開始後の変更：受付ルールを確認
・応答不明時の再送信：重複防止の方法を開発担当と確認
合意前に記入するもの：各確認の担当者、期限、回答と決定理由
未決事項が残っている範囲を、完成済みとは扱いません。まず一つの要望に対して成功する例を書き、条件を変えたときの結果を関係者で比べてみてください。書式を埋めることより、同じ結果を見て同じ判断ができるかが確認の要点です。
目的や範囲がまだ曖昧なら要件定義の始め方、修正方法の文面を考えるならフォームのエラー表示につなげて読めます。