「できました」という言葉が、ある人には実装完了、別の人にはレビュー完了、利用者には公開済みを意味することがあります。このずれは、終盤の手戻り、確認漏れ、公開できない成果物を生みます。チームで完了の意味をそろえる仕組みがDefinition of Doneです。
完了とは作業者の感覚ではなく、成果物が満たしたことをチームで確認できる品質状態です。
定義と結論
Scrum GuideではDefinition of Done（DoD）を、インクリメントがプロダクトに必要な品質基準を満たした状態の正式な記述としています。基準を満たさない作業はインクリメントの一部とは見なされません。
平たく言えば、DoDは多くの変更に共通する「これを満たして初めて完了と呼ぶ」という約束です。コードを書いただけではなく、レビュー、テスト、文書、セキュリティ、アクセシビリティ、運用準備など、提供可能な品質へ到達したことを含めます。
結論は、少数の重要項目から始め、自動化できる項目はCIへ移し、実際の失敗から継続的に見直すことです。長い理想一覧を掲げるだけでは機能しません。
なぜ必要なのか
完了の定義が暗黙だと、Pull Requestをマージした後にテスト不足、手順漏れ、計測不能が発覚します。未完了作業が見えないまま積み上がり、進捗は実態より良く見えます。
DoDがあると、見積もり時点から必要な作業を考えられます。レビュー担当者は共通の観点で確認でき、プロダクト責任者は「公開可能な成果がどこまで増えたか」を把握できます。新人だけに厳しい、担当者によって品質が違う、といった属人性も減らせます。
DoDは最後の検査表ではなく、最初から品質作業を計画へ含めるための共通認識です。
誰が関わるか
開発者だけで閉じず、プロダクト責任者、デザイナー、QA、運用、セキュリティなど、成果物の品質に責任を持つ人が合意します。Scrum Teamでは、組織標準があれば最低基準として従い、なければチームが適切なDoDを作ります。
作業者は各項目を満たすための証拠を用意し、レビュー担当者はコードと振る舞いを確認します。プロダクト責任者は受け入れ条件を確認しますが、品質を一人で保証する役ではありません。品質はチーム全体の責任です。
似た概念との違い
| 概念 | 対象 | 例 |
|---|---|---|
| Definition of Done | 多くの成果物に共通する品質 | テスト、レビュー、文書更新が済む |
| 受け入れ条件 | 特定の機能が満たす振る舞い | 未入力なら氏名欄の近くにエラーを出す |
| Definition of Ready | 着手前の準備条件として使われることがある | 目的と依存関係が明確 |
| タスク一覧 | 実施する具体作業 | API実装、文言変更、テスト追加 |
たとえばログイン機能の「誤ったパスワードではログインできない」は受け入れ条件です。「主要な成功・失敗経路に自動テストがある」はDoDです。機能固有の正しさと、チーム共通の品質基準を混ぜないことが保守しやすさにつながります。
DoDを作る流れ
1. 過去の「完了後に見つかった作業」を集める
リリース直前の手戻り、障害、レビュー差し戻し、文書漏れを振り返ります。一般論より、自分たちが実際に困ったことから始めると定着します。
2. 共通項目と機能固有項目を分ける
ほぼすべての変更に必要ならDoDへ、特定機能だけなら受け入れ条件や個別チェックリストへ置きます。データベース移行や決済のような高リスク変更には追加条件を設けます。
3. 観測可能な言葉にする
「品質が高い」「十分にテストした」では判定できません。「lint・型検査・対象テスト・ビルドが成功」「主要なエラー表示を確認」のようにします。
4. 実行責任と証拠を決める
誰が、いつ、何で確認し、どこに結果が残るかを決めます。CI結果、Pull Requestのレビュー、スクリーンショット、監視ダッシュボードなどが証拠になります。
5. 小さく導入する
最初から数十項目にせず、重大な漏れを防ぐ5〜8項目程度から始めます。守れない項目は、能力・時間・環境の不足を示しています。単にチェックを付ける運用にしません。
基本となる主要パターン
コード品質
レビュー済み、lint・型検査・ビルド成功、不要なデバッグコードがないことなどです。自動化可能なものはCIで必須にします。
振る舞いとテスト
受け入れ条件を満たし、主要な成功経路と失敗経路を確認します。すべてをE2Eにするのではなく、単体・統合・E2Eを変更リスクに応じて選びます。
非機能品質
アクセシビリティ、セキュリティ、性能、互換性です。すべての変更に同じ重さを課さず、共通最低基準と高リスク時の追加条件を分けます。
文書と運用
README、API仕様、移行・ロールバック手順、監視、アラート、問い合わせ対応情報を更新します。利用者向け変更ならリリースノートも候補です。
具体例：課題提出機能
受け入れ条件が「PDFを一件提出でき、完了画面に受付時刻が表示される」だとします。チームのDoDは次のようにできます。
- [ ] 受け入れ条件を満たした
- [ ] コードレビューを完了した
- [ ] lint、型検査、対象テスト、ビルドが成功した
- [ ] 未選択、サイズ超過、通信失敗の表示を確認した
- [ ] キーボードだけで提出でき、エラーが通知される
- [ ] ログにファイル内容や個人情報を出していない
- [ ] 運用手順と問い合わせ案内を更新した
- [ ] 公開後に成功率とエラー率を確認できる
この例では「PDFを提出できる」は機能固有、「テストや個人情報の確認」は共通品質です。ファイル上限値そのものは受け入れ条件や仕様で定義し、DoDにはその境界を確認することを書きます。
チームや変更による調整
単一チームでは一つのDoDを共有できます。複数チームが一製品を作る場合は、統合可能な共通最低基準が必要です。チームごとに「完了」の品質が違うと、結合時に不足が現れます。
一方、文言修正と認証方式変更を完全に同じ手順にする必要はありません。共通DoDに加え、変更リスクに応じた追加チェックを用意します。ただし「急ぎだからDoDを無視する」を通常運用にすると基準は崩れます。緊急時の例外手順、承認者、後追い作業、期限を決めます。
よくある誤解
「チェックを付ければ完了」
チェックボックスは証拠ではありません。CIのURL、テスト結果、レビュー、確認環境など、必要に応じて追跡可能にします。
「QAが最後に品質を作る」
最後の検査だけでは設計上の欠陥を安く直せません。実装前からテスト可能性や失敗時の振る舞いを考えます。
「項目は多いほど安全」
読まれない一覧は儀式になります。頻繁に必要な基準をDoDへ置き、特定領域の詳細はリンクしたチェックリストへ分けます。
「一度決めたら固定」
技術、組織、リスクは変わります。障害や手戻りから更新し、不要になった項目は削除します。
注意点とベストプラクティス
- 否定できる具体的な文にする
- Pull Requestテンプレートから最新版へリンクする
- 自動化した検査を手作業で重複させない
- セキュリティやアクセシビリティを最後の一項目に押し込めない
- スパイクや試作品は「製品の完了」と区別する
- 未達項目を隠さず、作業として見えるようにする
- 基準変更の理由と適用日を記録する
守れないDoDは個人の怠慢と決めつけず、環境、技能、納期、依存関係の問題を発見する信号として扱います。
デバッグ・確認方法
DoDが機能しているかは、チェック率ではなく結果で確認します。完了後の差し戻し件数、リリース直前に見つかる作業、障害原因、文書漏れ、手動確認時間を振り返ります。同じ漏れが繰り返されるなら、項目が曖昧、証拠がない、実行時期が遅い、または自動化不足です。
定期的に一つの完了済み変更を抽出し、第三者が証拠を追えるか監査します。CIが通っていてもテスト対象が不足していないか、レビュー済みでも受け入れ条件を確認したか、監視があっても実際に信号が届くかを確かめます。
公開後確認では、主要操作、エラー率、ログ、監視、ロールバック判断を見ます。DoDに「監視を追加」と書くだけでなく、どの値を誰がいつ見るかまで運用へ接続します。
まとめ
Definition of Doneは、成果物を完了と呼べる共通の品質状態です。機能固有の受け入れ条件とは分け、観測可能な項目、担当、証拠を決めます。少数の重要基準から始め、自動化し、実際の手戻りや障害を材料に更新することで、完了の見かけではなく提供可能な成果をそろえられます。
