完了の定義（DoD）とは？スクラムの品質基準を明確化する手法

完了の定義とは

完了の定義（Definition of Done、DoD）は、スクラムにおいてプロダクトバックログアイテムが「完了」と見なされるために満たすべき品質基準を、チェックリスト形式で明文化したものです。スクラムガイド（2020年版）では「インクリメントが利用可能であるために必要な品質基準の正式な記述」と定義されています。

DoDの本質は「完了」という言葉の解釈のズレを防ぐことにあります。開発者が「できました」と言ったとき、それが「コーディングが終わった」という意味なのか「テストも含めてリリース可能な状態」という意味なのかが曖昧だと、品質のばらつきや手戻りの原因になります。DoDはこの「完了」の定義をチーム全体で統一する契約です。

DoDは受け入れ基準（Acceptance Criteria）とは異なります。受け入れ基準は個々のユーザーストーリーに固有の機能要件であるのに対し、DoDはすべてのバックログアイテムに共通して適用される非機能的な品質基準です。

構成要素

DoDは一般的に3つのレイヤーで構成されます。

3つのレイヤー

コード品質: コードそのものの品質に関する基準です。コードレビューの完了、コーディング規約への準拠、静的解析ツールのパス、技術的負債の可視化などが含まれます。
テスト・検証: 動作確認に関する基準です。単体テストの作成とパス、結合テストの完了、受け入れ基準の充足、回帰テストへの影響確認などが含まれます。
リリース準備: デプロイ可能な状態に関する基準です。ドキュメントの更新、デプロイパイプラインの通過、セキュリティチェックの完了、パフォーマンス基準の充足などが含まれます。

DoDの具体例

ソフトウェア開発チームにおけるDoDの例は以下のとおりです。

カテゴリ	チェック項目
コード	コードレビューを1名以上が承認している
コード	コーディングスタイルガイドに準拠している
コード	新たな技術的負債がバックログに登録されている
テスト	単体テストのカバレッジが80%以上である
テスト	CI/CDパイプラインがすべてグリーンである
テスト	受け入れ基準をすべて満たしている
ドキュメント	APIドキュメントが更新されている
ドキュメント	リリースノートが作成されている
リリース	ステージング環境にデプロイされている
リリース	パフォーマンステストが基準値を満たしている

実践的な使い方

ステップ1: チーム全体でDoDを作成する

DoDはスクラムマスターやプロダクトオーナーが一方的に定めるものではなく、開発者を含むチーム全員で合意して作成します。ワークショップ形式で、以下の問いを議論します。

「完了」と言えるために最低限必要な条件は何か
過去に手戻りが発生した原因は何か
リリース後に発覚した品質問題の根本原因は何か

過去の失敗事例から逆算してDoDの項目を洗い出すと、実践的なチェックリストになります。

ステップ2: DoDを可視化し、日常的に参照する

作成したDoDはチームの作業スペース（物理的なボードまたはデジタルツール）に常に掲示します。スプリントレビューでインクリメントを確認する際に、DoDのチェック項目に沿って検証を行います。

JiraやAzure DevOpsなどのツールでは、各バックログアイテムにDoDのチェックリストを添付する機能を活用できます。

ステップ3: DoDを継続的に改善する

DoDは固定されたものではなく、チームの成熟度や組織の要求に応じて進化させます。レトロスペクティブで以下の観点からDoDの改善を検討します。

現在のDoDで防げなかった品質問題はあるか
形骸化している項目はないか
チームの技術力向上に伴い、追加すべき基準はあるか

ただし、DoDの基準を下げること（項目を削除すること）には慎重であるべきです。スプリントの計画がうまくいかないからといってDoDを緩めると、品質の低下を招きます。

活用場面

スプリントプランニング: DoDを考慮した上で各バックログアイテムの作業量を見積もります。DoDの基準が高いほど、1アイテムあたりの作業量は増えます
スプリントレビュー: インクリメントがDoDを満たしているかをステークホルダーに示すことで、品質への信頼を構築します
品質文化の醸成: DoDを明文化することで「品質とは何か」に対するチーム内の共通認識が形成されます
オンボーディング: 新しいメンバーがチームに参加した際、DoDが品質基準の教材として機能します
組織全体の標準化: 複数のスクラムチームが存在する場合、組織レベルの最低限のDoDを定め、各チームがそれを拡張する運用が可能です

注意点

DoDを形骸化させない

DoDがあっても、忙しさを理由にチェックを省略してしまうと意味がありません。「とりあえず完了にして後から直す」という運用が常態化すると、技術的負債が蓄積し、長期的にはベロシティの低下を招きます。DoDを満たさないアイテムは「未完了」として扱う厳格さが必要です。

受け入れ基準との混同を避ける

DoDは全アイテム共通の品質基準、受け入れ基準は個別アイテムの機能要件です。「ログイン画面にパスワードリセット機能がある」は受け入れ基準であり、DoDには含まれません。「単体テストのカバレッジが80%以上」のような、全アイテムに適用される基準がDoDです。

最初から完璧を目指さない

チームの初期段階では、まず実現可能な最低限のDoDから始めます。いきなり理想的な基準を設定すると、チームが圧倒されてDoDが有名無実化するリスクがあります。数スプリントごとに項目を追加・強化していくアプローチが現実的です。

まとめ

完了の定義（DoD）は、スクラムにおけるインクリメントの品質基準をチェックリスト形式で明文化した共通の契約です。コード品質、テスト、リリース準備の3つのレイヤーで構成され、「完了」の意味をチーム内で統一することで品質のばらつきと手戻りを防ぎます。チーム全体で合意して作成し、レトロスペクティブで継続的に改善することが、DoDを形骸化させず有効に機能させる鍵です。

参考資料

アジャイルにおける DoD (完了の定義) とは - Atlassian（DoDの定義、受け入れ基準との違い、作成のベストプラクティス）
スクラムにおける完了の定義（Doneの定義）とは？ - ABI Agile（スクラムガイドに基づくDoDの位置づけと運用方法の解説）
アジャイル・スクラム開発で品質保証に不安があるなら「完成の定義」を取り入れよう - やまねこ（品質保証の観点からDoDの重要性と具体的な項目例を解説）