フレームワーク活用ガイドひとことで言うと#
「できました」と言ったときに、チーム全員が同じ基準で「完了」を判断できるようにする共通のチェックリスト。コードを書いただけ？テストも通った？ドキュメントも更新した？——その認識をチームで揃える。
押さえておきたい用語#
- DoD（Definition of Done）
- バックログアイテムを「完了」と認めるためのチーム全員が合意したチェックリストのこと。すべての条件を満たして初めて「Done」。
- インクリメント（Increment）
- スプリントで生み出されるリリース可能な成果物の積み重ねを指す。DoDを満たしたアイテムだけがインクリメントに含まれる。
- 技術的負債（Technical Debt）
- DoDを妥協して品質基準を下げた結果、後から修正が必要になる隠れたコストである。DoDの厳守は技術的負債の蓄積を防ぐ。
- コードカバレッジ（Code Coverage）
- テストコードが実装コードの何%をカバーしているかを示す指標のこと。DoDに「カバレッジ80%以上」のように定義されることが多い。
完了の定義（DoD）の全体像#
こんな悩みに効く#
- メンバーによって「完了」の基準がバラバラで、あとから修正が発生する
- スプリントレビューで「まだ動かない」機能が出てくる
- リリース直前に品質問題が噴出する
基本の使い方#
「このアイテムが完了と言えるために、何が満たされている必要があるか？」をチーム全員でブレストする。
- コードレビュー済み
- 単体テスト・結合テスト合格
- ドキュメント更新済み
- パフォーマンス基準クリア、など
ポイント: 開発者だけでなく、QAやプロダクトオーナーの視点も入れる。
理想を全部入れるのではなく、今のチームが毎スプリント確実に満たせるレベルに調整する。
- 「毎回必ずやる」ものだけをDoDに入れる
- 「できればやりたい」はDoDに入れない
- 現実的でないDoDは形骸化の元
ポイント: 最初は厳しくしすぎない。スプリントを重ねながら徐々に基準を上げていく。
DoDをチームの作業エリアやWikiに掲示し、毎スプリントで参照する。
- バックログアイテムを「完了」にする前にDoDを確認
- スプリントレビューでDoDを満たしていないアイテムはデモしない
- 「DoDを満たしていないけど、ほぼ完了」は認めない
ポイント: DoDは妥協しない。「95%完了」は「未完了」と同じ。
定期的にDoDを更新し、チームの成長に合わせて基準を引き上げる。
- 「毎回クリアできているなら、もう一段上げよう」
- 「この項目は現実的でないので変えよう」
- 組織のDoDとチームのDoDの整合性も確認
ポイント: DoDは生きたドキュメント。固定せず、チームと共に進化させる。
具体例#
状況: 従業員60名のSaaS企業。8名の開発チーム。スプリントレビュー後の手戻りが月平均5件発生しており、開発者のモチベーションが低下していた。
チームが合意したDoD（7項目）:
- コードがmainブランチにマージされている
- コードレビューで2名以上の承認を得ている
- 単体テストのカバレッジが80%以上
- 結合テストがCI上で全件パスしている
- UIがデザインカンプと一致している（デザイナー確認済み）
- APIドキュメントが更新されている
- パフォーマンス: レスポンスタイム200ms以内
運用: スプリントレビュー前にスクラムマスターが各アイテムのDoD達成状況を確認。7項目すべてを満たしたアイテムだけがデモの対象。
| 指標 | DoD導入前 | DoD導入3ヶ月後 |
|---|---|---|
| レビュー後の手戻り | 月5件 | 月0件 |
| リリース後のバグ報告 | 月8件 | 月2件 |
| テストカバレッジ | 52% | 83% |
DoDの7項目を厳守した結果、手戻りが月5件→0件に。「95%完了は未完了」のルールが品質文化をチームに定着させた。
状況: 創業1年目のヘルステックスタートアップ（エンジニア4名）。スピード重視でDoDなしに開発していたが、本番障害が月3回発生。投資家から品質改善を求められる。
段階的なDoD導入:
| 時期 | DoD内容 | 本番障害数/月 |
|---|---|---|
| 導入前 | なし | 3.2件 |
| Phase 1（1-2ヶ月目） | ①テスト合格 ②コードレビュー1名 | 1.8件 |
| Phase 2（3-4ヶ月目） | ＋③ステージング環境で動作確認 ④API仕様更新 | 0.6件 |
| Phase 3（5ヶ月目〜） | ＋⑤負荷テスト ⑥セキュリティチェック | 0.2件 |
この取り組みが示すように、最初から6項目のDoDを導入すると開発速度が激減するリスクがあった。Phase 1で最低限の2項目から始め、チームが慣れるごとに項目を追加する段階的アプローチが、スピードと品質を両立させた。
状況: 従業員45名の受託開発企業。月商600万円。過去1年で3件の検収トラブル（「思っていたのと違う」）が発生し、合計400万円の追加対応コストが発生。
DoDをクライアントと共同策定:
- プロジェクト開始時にクライアントとDoDを合意し、契約書の別紙に添付
- 各スプリントレビューでDoDに基づいてデモ → その場でクライアントが「Done」を確認
DoDの内容（クライアント合意版）:
- 機能が受入条件（AC）をすべて満たしている
- クロスブラウザテスト合格（Chrome, Safari, Edge）
- レスポンシブデザインが3端末で確認済み
- アクセシビリティ基本項目をクリア
- クライアントのステージング環境で動作確認済み
導入後の効果:
| 指標 | 導入前（年間） | 導入後（年間） |
|---|---|---|
| 検収トラブル | 3件 | 0件 |
| 追加対応コスト | 400万円 | 0円 |
| クライアント満足度 | 3.4/5.0 | 4.7/5.0 |
DoDをクライアントと事前合意することで「完了の認識のズレ」がゼロに。年間400万円の追加コストを完全に解消し、受注継続率も向上。DoDはチーム内だけでなく対外的にも強力な品質保証ツールになる。
やりがちな失敗パターン#
- DoDが曖昧すぎる — 「テスト済み」だけでは基準にならない。「単体テストカバレッジ80%以上、CI全件パス」のように具体的に定義する
- DoDを例外的に緩める — 「今回は時間がないから…」とDoDを妥協し始めると、基準が崩壊する。DoDは全員が守る約束事
- 一度作ったら放置する — チームのスキルが上がっても基準が変わらないと、DoDの意味がなくなる。レトロスペクティブで定期的に見直す
- DoDとAcceptance Criteriaを混同する — DoDはすべてのアイテムに共通の品質基準。ACは個々のアイテム固有の受入条件。両方を満たして初めて完了
まとめ#
完了の定義（DoD）は、「完了」の意味をチーム全員で揃える単純だが強力なプラクティス。曖昧な「できた」をなくし、品質の一貫性を保つ。最初は控えめに設定し、スプリントごとに育てていくのがコツ。DoDがしっかり機能しているチームは、手戻りが少なく、安心してリリースできる。