フレームワーク活用ガイドひとことで言うと#
「完了とは何を満たした状態か」をチーム全体で具体的な条件リストとして合意する仕組み。「できた」の基準を揃えることで、品質のバラつきと手戻りを構造的に防ぐ。
押さえておきたい用語#
- DoD（Definition of Done）
- 成果物やユーザーストーリーが「完了」と見なされるために満たすべき条件の一覧。チーム全体の共通基準として機能する。
- 受入基準（Acceptance Criteria）
- 個々のユーザーストーリーやタスクに固有の機能的な完了条件。DoDがチーム共通の品質基準なのに対し、受入基準はストーリー個別の仕様を指す。
- インクリメント
- スプリント終了時に提供される動作する成果物の増分。DoDを満たして初めてインクリメントと呼べる。
- 技術的負債
- DoDを緩くして先送りした品質課題が将来の開発速度を下げるコストとして蓄積したもの。
完了の定義フレームワークの全体像#
こんな悩みに効く#
- 「できました」と言われたのにテストされていなかった
- メンバーによって「完了」の基準が違い品質がバラつく
- レビューで毎回同じ指摘（テスト不足、ドキュメント未更新）が出る
- 技術的負債が溜まるが「いつやるか」が決まらない
基本の使い方#
具体例#
エンジニア6名のWebアプリ開発チーム。リリース後のバグ報告が月平均 18件 と多く、ユーザーからの信頼を損ないつつあった。
DoDとして以下の8項目を定義し、全ストーリーに適用。
- ユニットテストカバレッジ80%以上
- コードレビュー1名以上完了
- CI/CDパイプラインのテスト全通過
- 受入基準をすべて満たす
- ブラウザテスト（Chrome, Safari, Firefox）完了
- エラーハンドリングのテスト完了
- APIドキュメント更新
- 本番同等環境でのスモークテスト通過
3か月運用した結果、リリース後のバグ報告は月平均 18件→7件 に減少。特にブラウザ互換性のバグがほぼゼロになった。
産業機器メーカー（従業員250名）の設計部門。図面の承認後に「寸法公差の記載漏れ」「部品表との不整合」が頻繁に発見され、手戻りが年間 120件 に達していた。
ソフトウェア開発のDoDを参考に、図面のDoDを10項目で策定。「寸法公差の全記載」「部品表との照合」「3D CADとの整合性チェック」などを含めた。
チェックリスト形式でExcelに実装し、設計者が自己チェックした後に検図者がダブルチェックする運用にした。手戻り件数は年間 120件→35件 に減少し、設計部門の残業時間が月平均 15時間 削減された。
BtoB SaaS企業のマーケティングチーム（8名）。ブログ記事やホワイトペーパーの品質が執筆者によってバラバラで、公開後に誤字脱字や事実誤認の指摘を受けることがあった。
コンテンツのDoDを以下の6項目で定義した。
- 構成レビュー（公開前に別メンバーが通読）完了
- ファクトチェック（数字・引用の出典確認）完了
- SEOチェック（タイトル・メタ・見出し最適化）完了
- OGP画像の設定完了
- CTA（Call To Action）の設置完了
- 公開スケジュールの登録完了
導入後6か月で公開後の修正依頼は月平均 8件→1件 に激減。「レビュー済みだから安心して公開できる」というチームの心理的安全性も向上した。
やりがちな失敗パターン#
- DoDを一度作って見直さない ─ チームの成熟度やプロジェクトの性質は変わる。レトロスペクティブのたびにDoDの過不足を確認する
- 最初から完璧なDoDを目指す ─ 20項目のDoDは重すぎて形骸化する。5〜10項目から始め、チームが習熟してから項目を追加する
- DoDに違反しても「今回は特別」で通す ─ 例外を1回認めると基準の意味がなくなる。DoDを満たさないものは完了にしない原則を守る
- DoDと受入基準を混同する ─ DoDはチーム共通の品質基準、受入基準はストーリー固有の機能条件。両方満たして初めて完了
まとめ#
完了の定義フレームワークは、「完了」の基準をチーム全体で具体的な条件リストとして合意する仕組み。コード品質・機能品質・ドキュメントの3層で条件を設定し、すべて満たして初めて完了と見なす。最初は5〜10項目から始め、レトロスペクティブで継続的に育てていくことで、品質のバラつきと手戻りを構造的に防ぐ。