アジャイル開発の文脈において、明確さこそが成功のカギとなる。チームが新しい機能の作業を開始する際、基盤となるのはユーザーストーリーである。しかし、ユーザーストーリーは単なる会話のためのプレースホルダーにすぎない。その会話を実際に動作する製品に変えるためには、2つの重要なアーティファクトが必要となる：受入基準と完了定義。これらの概念は、品質、整合性、予測可能性を保証するためのガイドラインとして機能する。
多くのチームが、これらの2つの概念の違いを把握できていない。時として、両者は同一視され、テストやデプロイ時に混乱を招く。また、完全に無視されることもあり、範囲の拡大や未完成の機能が生産環境に流れ込む結果となる。このガイドでは、受入基準と完了定義の仕組み、目的、実装方法を検証し、チームが一貫して価値を提供できるように支援する。
ユーザーストーリーとは何か？ 📝
ストーリーの構成要素を分析する前に、ユーザーストーリーが実際に何であるかを思い出しておくことが不可欠である。アジャイルフレームワークにおいて、ユーザーストーリーとは、新しい機能を望む人物の視点から、機能の短くシンプルな説明である。通常、以下の形式に従う。
- ～として [ユーザーの種類]、
- 私は [ある目標] を望みます、
- それにより [ある利点] が得られる。
この形式は、価値ユーザーに提供される価値に焦点を当てるものであり、技術的な実装には注目しない。しかし、この形式だけでは開発を導くには不十分である。作業の範囲や完了に必要な基準を明確にしない。ここに受入基準と完了定義が登場する。
受入基準（AC）：完了の条件 ✅
受入基準とは、プロダクトオーナーの視点から見ると、ユーザーストーリーが完了したとみなされるために満たすべき条件の集合である。これらはストーリーの範囲を定義し、最終製品がどのようなものであるべきかを明確に理解する手がかりを提供する。
受入基準の目的
受入基準は開発ライフサイクル内で複数の役割を果たす：
- 明確化：曖昧さを排除する。開発者が「マウスオーバー時にボタンは緑色にするか青色にするか？」と尋ねた場合、受入基準がその答えを示すべきである。
- テスト：テストケースとして機能する。QAエンジニアはこれらの条件を使って機能の検証を行う。
- 合意形成：プロダクトオーナーと開発チームが、この特定のストーリーにおいて「完了」とされるべき内容について合意することを保証する。
優れた受入基準の特徴
効果的な受入基準は、具体的で、測定可能であり、曖昧さがないものである。「使いやすい」や「速い」といった曖昧な用語は、メトリクスを定義せずに避けるべきである。代わりに、正確な動作を明記する。
- 原子的：各基準は、単一の要件にのみ対応すべきである。
- 検証可能：基準の検証が、合格または不合格の結果で行えることが必要である。
- 独立性：検証には外部のストーリーに依存してはならない。
- 関連性：内部のコード構造ではなく、ユーザー価値に注目する。
受入基準の例
「パスワードを忘れた場合」の機能を追加するストーリーを考えてみよう。以下がACの例である。
- ユーザーがログインページにいる状態で、
「パスワードを忘れた場合」のリンクをクリックすると、
パスワード回復ページにリダイレクトされる。 - ユーザーが有効なメールアドレスを入力した状態で、
フォームを送信すると、
確認メッセージが表示される。 - ユーザーが無効なメールアドレスを入力した状態で、
フォームを送信すると、
エラーメッセージがメール形式が正しくないことを示す。
これらの例は、Given/When/Then構造（しばしばGherkin構文と関連付けられる）を採用しており、明確性を促進し、自動テストフレームワークと整合する。
完了の定義（DoD）：品質ゲート 🚧
受入基準は単一のユーザーストーリーに特化している一方、完了の定義はスプリントまたはリリース内のすべての作業に適用されるグローバルな基準である。どの作業のインクリメントも、潜在的にリリース可能な状態と見なされるためには、満たすべき要件のチェックリストを表している。
完了の定義の目的
DoDは品質ゲートとして機能する。技術的負債が蓄積されず、製品が常にリリース可能な状態を保つことを保証する。ストーリーが受入基準を満たしていても、完了の定義を満たさなければ、完了と見なせない。
完了の定義に含まれる一般的な要素には以下が含まれる：
- コードレビュー：すべてのコードは、少なくとも1人の同僚によるレビューを受ける必要がある。
- 単体テスト：新しいロジックに対して、自動テストが100％のカバレッジで合格しなければならない。
- ドキュメント： APIドキュメントまたはユーザーガイドが更新されています。
- パフォーマンス： この機能は最小ロード時間要件を満たしています。
- アクセシビリティ： この機能はWCAGガイドラインに準拠しています。
- セキュリティ： 知られている脆弱性は導入されていません。
DoDが重要な理由
定義された完了（DoD）がないと、チームは「技術的には完了しているが、実際には準備ができていない」という罠にはまってしまうことが多いです。機能は受入基準に従って意図した通りに動作しているかもしれませんが、システムの別の部分が壊れている、適切なドキュメントが不足している、またはセキュリティリスクを引き起こしている可能性があります。DoDは、バックログ全体にわたって品質の最低基準を強制することで、このような状況を防ぎます。
受入基準と完了の定義：主な違い 🆚
両者の概念が「完成度」に関わっているため、混乱が生じることが多いです。しかし、その範囲や所有権は大きく異なります。この違いを理解することで、開発者、テスト担当者、プロダクトオーナーの間で誤解が生じるのを防げます。
| 機能 | 受入基準 | 完了の定義 |
|---|---|---|
| 範囲 | 単一のユーザーストーリーに特化している | チーム全体またはプロジェクト全体にわたる |
| 所有権 | プロダクトオーナーと開発チーム | 開発チーム全体 |
| 柔軟性 | 要件に応じてストーリーごとに変更可能 | 安定しているが、時間とともに更新可能 |
| 目的 | 機能要件を定義する | 品質および非機能要件を定義する |
| 検証 | ユーザーのニーズに対する機能テスト | 技術的およびプロセスの検証 |
受入基準を特定の旅の目的地と考え、完了の定義を道路を走るすべての車両に必須の安全点検リストと考えてください。
効果的な受入基準を書く方法 📝
受入基準の作成は共同作業です。製品所有者が単独で行うべきではありません。ベストプラクティスは、「Three Amigos（三人の友人）」の概念を活用し、製品所有者、開発者、テスト担当者が仕様の洗練プロセスの初期段階で協力することです。
ステップ1：ユーザーの目的を特定する
まず、価値提案を再確認しましょう。ユーザーが解決しようとしている問題は何ですか？これにより、基準が技術的な詳細ではなく、ユーザー体験に焦点を当てるようになります。
ステップ2：ポジティブな状況とネガティブな状況を定義する
ハッピーパスだけを書くのではなく、問題が起きた場合の対応も検討しましょう。
- ハッピーパス： ユーザーは期待通りにアクションを実行する。
- エッジケース： 特殊文字、欠損データ、または遅い接続の場合、どうなるか？
- ネガティブパス： システムは無効な入力をどのように適切に処理するか？
ステップ3：明確な言葉を使う
可能な限り専門用語を避けること。技術用語が必要な場合は、必ず定義すること。能動態を使うこと。たとえば、「システムは検証するべきである…」よりも「ユーザーはエラーメッセージを受け取る…」の方が明確です。
ステップ4：優先順位をつける
ストーリーが大きい場合は、分割する。受入基準はスプリント内で達成可能でなければならない。基準がスプリント内で完了できない作業を示している場合は、ストーリーを分割する必要がある。
しっかりとした「完了の定義」を確立する方法 🛠️
完了の定義は固定された文書ではない。チームが成熟し、技術が変化するにつれて進化するものである。全員が見える場所に掲示されるべきであり、通常は物理的またはデジタルなボードに表示される。
ステップ1：チームに相談する
完了の定義（DoD）は作業を行うチームが責任を持つものである。開発者、テスト担当者、デザイナーがリストに貢献すべきである。開発者が要件を追加すれば、その要件を遵守する可能性が高くなる。
ステップ2：要件をカテゴリ別に分類する
DoDの項目を論理的なカテゴリに分類することで、チェックリストを管理しやすくする。
- コード品質： リンティングは通過、警告なし、同僚レビュー完了。
- テスト： ユニットテスト作成済み、統合テスト通過、手動テスト確認済み。
- デプロイ： ステージング環境にデプロイ済み、スモークテスト通過。
- ドキュメント： Readme更新済み、APIドキュメント同期済み。
ステップ3：ハードストップにする
ストーリーがDoDを満たさない場合、閉じることはできません。これには自制心が必要です。『後でドキュメントを修正する』と簡単に言う誘惑がありますが、それでは技術的負債が発生します。ストーリーはDoDを満たすまで『進行中』の状態のままです。
ステップ4：見直しと改善
リトロスペクティブの際にチームに尋ねましょう：『私たちのDoDは問題を発見しましたか？』または『常に見落としている要件はありますか？』これらの洞察に基づいてDoDを更新しましょう。
避けたい一般的なミス ⚠️
経験豊富なチームでさえ、これらの実践を導入する際につまずくことがあります。一般的な落とし穴を認識しておくことで、大幅な時間とストレスの節約が可能です。
1. 不明確な受入基準
『システムは安全でなければならない』といった基準を書くのは無意味です。テストできないからです。代わりに『システムは管理者アカウントに対して二要素認証を必須とする』と明確に指定しましょう。
2. DoDをチェックボックス作業として扱う
チームが実際に作業を行わずにDoDのチェックボックスだけを確認する（例：コードレビューを飛ばす）場合、DoDの意味は失われます。DoDは読みだけではなく、尊重されるべきものです。
3. DoDを複雑にしすぎること
DoDに50項目も含えると圧倒されてしまいます。重要な品質のゲートに焦点を当てましょう。要件がほとんど違反されない場合は、ハードなDoD項目ではなくガイドラインとして扱うべきかもしれません。
4. 非機能要件を無視すること
チームはしばしばAC（機能的）に注力し、DoD（非機能的）を無視します。パフォーマンス、セキュリティ、アクセシビリティはACではなくDoDの一部です。これらを無視すると、動作はするが遅い、または安全でない機能が生まれます。
5. チームの合意を得ずにDoDを作成すること
プロダクトオーナーが開発者の意見を無視してDoDを設定すると、チームが抵抗する可能性があります。DoDは共有された合意であるべきです。
ワークフローへの統合 🔄
受入基準と完了定義は開発ライフサイクルのすべての段階に統合されるべきであり、終わりにだけ適用するものではありません。
精査フェーズ
バックログ精査の段階で、プロダクトオーナーが受入基準を草案します。チームはそれらがテスト可能で実現可能であるかを確認します。質問はこの段階で出し合い、スプリント中に問うべきではありません。
スプリント計画
ストーリーにコミットする際、チームは受入基準が明確であることを確認します。明確でない場合は、そのストーリーはスプリント準備ができていません。
開発フェーズ
開発者はACを満たすコードを書きます。同時に、DoDを遵守すること（例：テストの記述、レビューの依頼）を確認します。
テストフェーズ
QAエンジニアは構築された機能に対してACを検証します。同時にDoDも検証します（例：コードカバレッジレポートの確認、アクセシビリティスキャン）。
レビューとクロージャー
ストーリーを『完了』に移す前に、チームはACとDoDの両方が満たされていることを確認します。満たされていない場合は、キューに戻ります。
成功の測定 📊
あなたの受入基準と完了定義が効果的に機能しているかどうかはどうやって知るのでしょうか？ 時間とともにメトリクスを追跡しましょう。
- 欠陥率：本番環境で発見されるバグは減少していますか？強固なDoDはリリース前に問題を発見できるべきです。
- 却下率：ストーリーが製品所有者によって頻繁に却下されていますか？これはACの定義が不十分であることを示しています。
- ベロシティの安定性：チームのベロシティは一貫していますか？DoDの項目が欠けているためにストーリーが頻繁に戻される場合、ベロシティは変動します。
- デプロイ頻度：明確なDoDがあれば、スムーズで頻繁なデプロイが可能になりますか？
よくある質問 ❓
これらの基準を導入する際にチームがよく質問する内容を以下に示します。
Q：スプリント中に受入基準を変更できますか？
A：理想的には、いいえ。ACが大幅に変更される場合は、ストーリーが精査段階で十分に理解されていなかった可能性があります。小さな説明の追加は許容されますが、大きな範囲の変更は新しいストーリーの作成、またはスプリント範囲の調整を要します。
Q：すべてのストーリーに独自の完了定義が必要ですか？
A：いいえ。DoDはグローバルなものです。ただし、特定の技術的ストーリーにはその項目に追加の要件をチェックリストに追加することがありますが、基本的なDoDはすべてのストーリーに適用されます。
Q：チームがDoDについて合意できない場合はどうすればよいですか？
A：議論を促進してください。目的は合意形成です。開発者がテスト担当者と異なる要件を主張する場合、リスクを検討してください。リスクが低い場合は除外し、高い場合は維持してください。
Q：受入基準はどのくらい詳細にすべきですか？
A：テスト可能な程度に詳細にします。QAエンジニアが受入基準から直接テストケースを書けるなら、十分に詳細です。質問が必要になる場合は、さらに詳細が必要です。
Q：自動テストはDoDにおける手動テストを置き換えることができますか？
A：状況によります。重要な論理処理については、はい。ユーザー体験や視覚的要素については、手動での検証がまだ必要になる場合があります。DoDは品質保証のベストプラクティスを反映すべきです。
品質と整合性についての最終的な考察 🌟
受入基準と完了定義を導入することは、官僚主義ではなく、尊重の問題です。動作する機能を期待するユーザーへの尊重、明確な要件を求める開発者への尊重、納品に対する信頼を得たい製品所有者への尊重です。
これらの2つの概念を正しく使用すれば、チームに共有言語を生み出します。常に説明会を開く必要が減ります。技術的負債の蓄積を防ぎます。そして何よりも、完了したすべてのストーリーが製品に実際の価値をもたらすことを保証します。
小さなステップから始めましょう。基本的なDoDを定義し、次のストーリーに対して明確なACを書きます。次のリトロスペクティブでそれらをレビューしましょう。時間とともに、これらの習慣はチームの文化に自然に根付きます。その結果、利用する人々のニーズを満たす、安定した高品質なソフトウェアの供給が可能になります。