アジャイル開発において、ユーザーストーリーは顧客に価値を提供するための基本的な構成要素です。必要な機能の簡潔な記述は、機能や要件の「誰が」「何を」「なぜ」必要としているかを捉えます。しかし、ユーザーストーリーが実行可能かつ検証可能であることを保証するため、アジャイルチームはしばしば「与える／時に／それから」（GWT）という受け入れ基準の手法を採用します。この方法により、ユーザーストーリーの期待される動作を明確かつ曖昧さのない形で定義できます。
受け入れ基準とは何ですか？
受け入れ基準とは、ユーザーストーリーが完了と見なされるために満たすべき条件やルールです。製品オーナーのビジョンと開発チームの実装の間をつなぐ橋渡しの役割を果たします。本質的に、各ユーザーストーリーの範囲と期待を定義します。明確に定義された受け入れ基準がないと、ユーザーストーリーは解釈の余地が生じ、誤解や再作業の原因となる可能性があります。
「与える／時に／それから」受け入れ基準の構造
「与える／時に／それから」は、行動駆動開発（BDD）から借用された受け入れ基準の作成フォーマットです。ユーザーストーリーの期待される動作をより構造的で理解しやすい形で表現することを促進します。このフォーマットは3つの部分から構成されています：
- 与える：このセクションでは、システムの初期状態や文脈を記述します。説明するシナリオの舞台を設定します。本質的に、シナリオを理解するために必要な背景情報を提供します。
- 時に：このセクションは、ユーザーストーリーで記述された動作を引き起こすアクションやイベントを表します。ユーザーが実行する具体的なイベント、またはシステム内で発生するイベントです。
- それから：このセクションでは、『時に』セクションで記述されたアクションやイベントの期待される結果や成果を示します。アクションの結果として何が起こるべきかを定義し、システムやアプリケーションにおける観察可能な変化の観点から記述されることが多いです。
「与える／時に／それから」受け入れ基準の利点
- 明確さ：GWTフォーマットは、ユーザーストーリーの期待される動作を構造的で理解しやすい形で表現する方法を提供します。これにより曖昧さが減少し、開発チームの全員（開発者、テスト担当者、製品オーナーを含む）が何をすべきかを明確に理解できるようになります。
- 検証可能性：このフォーマットはテストケースに自然に適しています。各『与える』『時に』『それから』の要素は、具体的なテストシナリオに変換でき、ユーザーストーリーが正しく実装されたことを確認しやすくなります。
- 整合性：GWT受け入れ基準は、チームメンバー間の協力を促進します。製品オーナー、開発者、テスト担当者が一緒に基準を定義・改善することで、ストーリーの範囲や期待について全員が同じ理解を持つことを保証できます。
「与える／時に／それから」受け入れ基準の例
オンラインショッピングサイトの簡単な例を検討しましょう：
ユーザーストーリー：顧客として、後で購入できるように、商品をショッピングカートに追加できるようにしたい。
受け入れ基準（GWT）:
- 与える私は商品ページにいる
- 時に私は商品の「カートに追加」ボタンをクリックする
- それから 商品をショッピングカートに追加する必要があります
- そしてナビゲーションバー内のカートアイコンは、更新されたアイテム数を表示するべきです
- そして商品がカートに追加されたことを示す確認メッセージを表示するべきです
この例では、受容基準がユーザーストーリーから期待される内容を明確に理解できるようにし、実行可能でテスト可能な状態にしています。
問題の説明 ケーススタディ：
Uberのような人気のあるライドシェアリングアプリを対象にケーススタディを検討しましょう。現在の課題は、乗客が特定の日時に対して予約を事前に設定できる機能を導入することで、ユーザー体験を向上させることです。
GWT受容基準付きユーザーストーリー：
ユーザーストーリー1：事前に乗車を予約する
乗客として、特定の日時に対して事前に乗車を予約できるようにしたいこれにより、自分の旅行をより良く計画できるようにするため.
受容基準（GWT）：
- 前提条件ライドシェアリングアプリをインストールしており、ログインしている
- 動作アプリを開き、目的地、日付、時間の乗車情報を入力する
- 結果アプリは、選択した日時に対応する利用可能なドライバーを表示するべきです
- そして乗車の確認と予約ができるべきです
- そして予約された乗車の詳細を含む確認通知を受け取るべきです
ユーザーストーリー2：予約済みの乗車を編集またはキャンセルする
乗客として、予約済みの乗車を編集またはキャンセルできるようにしたい計画が変更された場合のため.
受入基準（GWT）：
- 前提として私は予約済みの乗車がある
- もしアプリを開いて予約済みの乗車に移動する
- ならば私は今後の予約済み乗車の一覧を表示するべきである
- そして日時を編集するかキャンセルするため、乗車を選択できるべきである
- そして乗車を編集した場合、アプリは更新された日時における利用可能なドライバーを表示すべきである
- そして変更が行われた場合、確認通知を受け取るべきである
ユーザーストーリー3：予約済み乗車のドライバーに通知する
ドライバーとして、乗客が私と乗車を予約したときに通知を受け取りたいそうすることで、自分の利用可能時間を計画できる.
受入基準（GWT）：
- 前提として私は乗車シェアアプリを起動したアクティブなドライバーである
- もし乗客が特定の日時で私と乗車を予約した場合
- ならば私は予約済み乗車の詳細を含むリアルタイム通知を受け取るべきである
- そしてアプリは予約済み乗車を私のドライバーダッシュボードに表示すべきである
- そして合理的な時間枠内で予約済み乗車を受け入れたり断ったりできるべきである
ユーザーストーリー4：予約済み乗車のフィードバックを提供する
乗客として、予約済みの乗車についてフィードバックを提供し、ドライバーの評価を行うことができるようになりたい。サービス品質の維持を支援するため.
受入基準（GWT）：
- 前提条件予約済みの乗車を完了した
- 条件乗車が完了した後にアプリを開く
- 結果ドライバーの評価とフィードバックを提供するオプションがあるべきである
- そしてドライバーの評価は、私のフィードバックに基づいて更新されるべきである
- そしてフィードバックを提供したことに感謝のメッセージを受け取るべきである
これらのユーザーストーリーと関連する「前提条件／条件／結果」の受入基準は、ライドシェアリングアプリに乗車予約機能を導入する問題に対処しています。この構造化されたアプローチに従うことで、開発チームは要件と新機能の期待される動作について明確な理解を確保でき、最終的により良いユーザー体験を実現できます。
結論
「前提条件／条件／結果」の受入基準は、アジャイル開発におけるユーザーストーリーの期待される動作を定義するための構造化されたアプローチを提供します。基準を「前提条件」「条件」「結果」という3つの明確なセクションに分けることで、チームはより明確な理解、検証可能性、整合性を達成でき、最終的により成功した製品開発につながります。このフォーマットをアジャイルプロセスに取り入れることで、チームはユーザーの期待に応える高品質なソフトウェアを提供できるようになります。