コンテンツにスキップ
Scrum Knowledge Graph

完成の定義 (Definition of Done)

概要

Section titled “概要”

完成の定義（Definition of Done: DoD）は、プロダクトバックログアイテムが完了し出荷・リリース可能な品質基準を満たしているかを客観的に判定する公式な共通基準である。インクリメントに対する確約として位置づけられ、チーム全員の合意に基づくチェックリストとして機能する。実装や各種テスト、レビューなどの必須品質活動を明確化して作業の透明性を担保し、未完了タスクの放置や技術的負債を防ぐ。スケーリング環境では複数チームの共通ベースラインとなる。

詳細

Section titled “詳細”

完成の定義（Definition of Done）とは、プロダクトバックログアイテムが完了し、出荷・リリース可能な品質基準を満たしているかを客観的に判定・宣言するための公式な共通基準である[1][2][3][4][5][6][7]。チーム全員の合意に基づくチェックリストとして機能し、実装や各種テスト、ドキュメント作成などの必須品質活動を明確にする[8][9]。作業の透明性を担保してステークホルダーとの信頼関係を築き、経験的プロセス制御を支えるインクリメントへの確約として位置づけられる[6]。定義を満たさない作業はレビューや出荷から除外され、未完了タスクの放置や完了の偽装を防ぐ防壁となる[10]。

スクラムチーム全体で共有され、作業が完了したと見なす客観的な判断基準を提供する[11]。プロダクトオーナーおよび開発者のコンセンサスに基づいて決定され、スプリント中に作成される成果物が品質基準に達しているかを客観的に判定する役割を担う[12]。プロダクトバックログの項目を作業中から「完了」したインクリメントへ変えるために満たすべき基準であり、プロダクトバックログアイテムが完成の定義を満たした瞬間にインクリメントが誕生する[6]。各スプリントの目的は、この定義を満たしたプロダクトオーナーが即座に導入・出荷・リリースを判断可能なクオリティを持つ機能のインクリメントを届けることである[1][3][5][7]。

具体的に含まれる作業要素には、分析、設計、実装（プログラミング）、コードレビュー、リファクタリング、ドキュメントの作成・更新、ならびに各種テスト（ユニットテスト、結合・統合テスト、パフォーマンス、セキュリティ検証、受け入れ条件に基づくテスト合格、リグレッションテストの通過など）といったものが含まれる[1][2][8][9]。コーディングだけでなく、単体テスト、統合テスト、ドキュメンテーション、非機能要件の検証などの品質活動がスプリント内に包含されるべきとされる[10]。さらに関係チーム（UIチーム等）の承認や社内デモでの実演可能性が基準として含まれることもある[8]。

透明性の確保と経験的プロセス制御の支えとして、どの作業が完了しており、どの品質チェック（テスト、レビュー、セキュリティ検証など）をパスしたかを明確にすることで、作業をする人と成果物を受け取る人の間で作業状態の透明性が担保される[1][2][3][4][5][7][8][9]。アイテムがどの品質レベルまで完了しているかについてチームとステークホルダー間の共通認識を確立する役割も果たす[10]。

未完了作業の管理と完了の偽装防止の観点から、完成の定義を満たしたインクリメントのみがスプリントレビューの対象となり、常に出荷・リリース可能な状態であることが要求される[1][2][3][5][7][8]。定義を満たせない作業はインクリメントとみなされず、スプリントレビューの対象にもならず、リリースも許可されない[1][2][7]。未完了のアイテムはプロダクトバックログに戻され、将来の再検討対象として再計上される[1][2][7]。

組織標準の準拠と策定主体については、開発組織の慣例や共通の品質標準が存在する場合は最低限それを適用・遵守する必要がある[4][5][6]。策定主体について、以前は開発チームが独自に定義するとされていたが[4][5][13]、最新の定義ではスクラムチームが独自に策定することとされている[6]。

複数チームでの共有とスケーリング環境の課題・ガバナンスについて、同一プロダクトを複数のスクラムチームで開発する場合、すべてのチームおよびメンバーが共通の完成の定義を作成し、適用・遵守しなければならない[4][6][7]。大規模開発のスケーリング環境においては、全チームが共通して遵守すべき統合品質の共通ベースラインをグループ合意によって確立することが不可欠とされる[11][12]。チーム間でシステムテストや統合テストを含むか否かなどの基準が異なると、成果物の品質や納品タイミングに不整合が生じ、チーム間での成果物の受け渡しやシステム統合の遅延を招く根本原因となる[11]。共通の完成の定義は、複数チームが並行開発する中で発生する技術的負債や統合不全を防ぎ、常にリリース可能な統合インクリメントを維持するためのガバナンスやガードレールとして機能する[12]。その一方で、全体共通の基準を満たすことを前提として、各チームが自チームの成熟度や専門性に合わせてさらに厳しい完成の定義を独自に採用・上乗せする裁量も認められている[12]。

プランニングと改善のベースラインとしても機能し、スプリントプランニングにおいてスクラムチームや開発チームが引き受ける作業量や選択するプロダクトバックログアイテムの数を決定する指針、および見積もりの前提条件として機能する[3][4][5][13]。また継続的改善のベースラインとしても機能し、スクラムチームの成熟度に応じてスプリントレトロスペクティブなどで随時完成の定義を強化・拡張し、より厳しい品質基準を適用することで、プロダクト品質の段階的な向上が図られる[3][5][13][9]。より小さな反復リリースを継続して提供するためには、厳格な品質基準と自動テストの導入が不可欠とされる[11]。

実務者を対象としたアンケート調査（137人）では、回答者の93%が完成の定義を自身の取り組みにおいて少なくとも価値のあるものと捉え、作業項目の完了、プロダクト品質の保証、必要な活動の確実な実行に役立つとした。一方で、2つに1つのプロジェクトが、実現不可能、不正確、利用不可、または肥大化する完成の定義に苦労していると指摘した[14]。

同じ調査によれば、完成の定義の作成・維持の最も一般的なステップは、(1) 提案、(2) 分析、(3) 調整、(4) 文書化・承認・公開、(5) 使用、(6) 評価・改善である。ほとんどの場合スクラムチームのメンバーが作成していたが、調査対象の22%近くのプロジェクトでは、開発者がそのプロセスに関与していなかった[14]。項目の大半は品質管理とプロセスマネジメントに関するもので、テスト、コードレビュー、ドキュメント、受け入れ基準に関するものが多い[14]。項目の不備（不明瞭・欠落・検証不能など）を防ぐ品質基準として、VIRUPCUSが提案されている[14]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Definition of Done Quality Inspection Increment
  • カテゴリー: Scrum Core

関連動画 (YouTube)

Section titled “関連動画 (YouTube)”

脚注

Section titled “脚注”

  1. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  6. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. Scrum Guide (LeSS Version)（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  9. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  10. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  11. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  12. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  13. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  14. On the Benefits And Problems Related to Using Definition of Done — A Survey Study — 「(1) DoDを提案する、(2) それを分析する、(3) 提案を調整する、(4) DoDを文書化し、承認して公開する、(5) それを使用する、(6) DoDを評価し改善する」（原文: “(1) propose a DoD, (2) analyze it, (3) adjust the proposal, (4) document, sign off and publish the DoD, (5) use it, (6) evaluate, and improve the DoD”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  15. The journey to technical excellence in agile software development — 「卓越性のコントロールのためのプラクティスには、完成の定義（Definition of Done）[40]（すなわち、成果物が完全であるかを判断するための一連の基準）、コーディング結果への準拠の徹底、規定されたプロセスの遵守の徹底、測定が含まれます。」（原文: “Practices for control of excellence include a Definition of Done [40] (i.e., a set of criteria to determine if a deliverable is complete), enforcing compliance with coding results, enforcing prescribed processes, and measurement.”）（訳）（ライセンス: CC BY 4.0） ↩