プラクティス名（別名）

完成の定義　（DoD、Definition of Done、Doneの定義、完了の定義、Cut-over Criteria、DONE-done）

プラクティスの目的・狙い

スプリントの成果物（インクリメント）を「完成」と見なす品質基準を揃える
（＝完成させるためにすべきことが明確化される）

どんな時に使うか

スクラムでは必須（スプリント0などで定義し、随時更新）
何をもって「完成」とするか、人によって認識が異なる状況を是正したい時

実施手順

プロダクトをリリースする際に満たしていなければならない条件をチームで話し合い、リスト化する
リストの内容はステークホルダーとも合意し、チームが常時参照できる場所に掲載する
スプリントプランニングでは「完成の定義」から逆算したタスクも含めるようにする
スプリントレビューでは「完成の定義」を満たしているものだけをインクリメントとして扱う
リストはレトロスペクティブなどで定期的に見直し、不足があれば随時更新する

「完成の定義」として例えば以下のような観点が挙げられる(どこまで定義に含めるかは現場による)

テスト完了条件（例：ユニットテスト完了、既存機能の自動テストパス）
非機能要件　　（例：パフォーマンステスト完了、セキュリティ基準合格）
ドキュメント化（例：設計書作成＆レビュー完了）
社内手続き　　（例：本番移行申請準備）
法令遵守　　　（例：関連法規に違反がないことを確認済み）
付帯作業　　　（例：ソースリポジトリにコミット済み、自動テスト作成済み）
引継ぎ　　　　（例：運用チームへの説明、リカバリ手順確立）
他チーム調整　（例：I/F先チームとの初回稼働フォロー体制）
ユーザ説明　　（例：ユーザアナウンス＆マニュアル提供済み）
残課題整理　　（例：暫定措置やバグの取り扱いに関する関係者合意）

アレンジ例

スプリント中には行えないが、リリースまでには行うこととした作業を別途「Undoneタスク」として一覧化する。

公式スクラムガイドでは上記の運用を認めていない。Undoneタスクを溜め込むとリリース不能に陥るリスクが増すため注意が必要。極力スプリント中に消化することが理想ではあるが、Undoneタスクを完全に無くすことは難しい。

アンチパターン

「完成の定義」の記述自体が曖昧で、人によって解釈が異なる
「完成の定義」を詳細かつ網羅的に書こうとして、長々としたチェックリストになってしまう
（＝項目が多すぎると、かえってルールは守られない）

参考情報

公式スクラムガイド(2020年日本語版)

こぼれ話（私的コメント）

チームは最初から完璧な「完成の定義」を持つことはできないので、やりながら定義を育てていくことが大切です。とはいえ、スプリントを重ねていくとリストがどんどん長くなる「育ちすぎ問題」が発生することも。個人的な意見としては、リストが長くなってきたら、もう当たり前になった項目を削除してダイエットした方が良いと思います。そもそも関係者間の認識齟齬防止が目的なので、認識が揃った後はただの備忘録でしかありません。もしもリストから項目を削ることにPOが難色を示す場合はそもそもベースとなる信頼関係が築けていない、ということかもしれません。

　アジャイルプラクティス一覧へ戻る