---
title: 'Definition of Done (DoD)'
description: 'Definition of Doneは、チームが品質、チェック、タスクの完了時点を統一して理解できるように、作業の一般的な完了条件を定めます。'
type: knowledge-card
locale: ja
canonical: 'https://yoseno.com/ja/docs/knowledge/definition-of-done'
---

# Definition of Done (DoD)

Definition of Doneは、チームが品質、チェック、タスクの完了時点を統一して理解できるように、作業の一般的な完了条件を定めます。

- **テーマ:** プロセスの透明性, プロダクトへの誇り, チームの信頼性

## これは何か

Definition of Done（DoD）とは、それが満たされなければ作業が完了したと見なされない条件をまとめた短いリストです。チームは、完成した成果物に必要な確認、文書化、承認、修正をあらかじめ決めておきます。このプラクティスは、タスクのステータスに関する意見の相違を減らし、既知の重大な欠陥がある状態でのリリース防止に役立ちます。特に、チームが定期的に成果物を顧客、ユーザー、関係者に引き渡す場面で最も有効です。

## 役立つ場面

- タスクのクローズ方法が統一されておらず、チーム内で「完了」の定義について意見が分かれる。
- 成果物が、承認後や関係者への引き渡し後に、しばしば手直しのために差し戻される。
- 重要なチェックが、修正コストが高くなる作業終盤になってから思い出される。
- 小さな欠陥ややり残しのために、チームが製品に対する誇りを失っている。

## 始め方

1. 完了したはずが手直しに戻された直近のタスクの例を集めます。
2. 必須の完了条件を5～7個選びます：チェック、品質、文書化、承認、重大な欠陥がないこと。
3. プロセス変更後もリストが陳腐化しないよう、DoD更新の責任者を任命します。
4. チームが実際に作業を計画しクローズする場所に、DoDを作業タスクとともに掲示します。
5. 新しいタスクを1つ、そのリストに照らしてテストし、完了判断に役立たない項目は削除します。

## 期待できるメリット

チームは共通の完了基準を得て、再承認に費やす時間を減らせます。マネージャーは、作業が実際に完了している場所と、形式的にのみクローズされ差し戻しのリスクがある場所をより簡単に見分けられます。

## よくある間違い

- リストが長すぎると、チームは日常業務でそれを使わなくなります。
- 一部の基準は作業タイプに共通であるべきなのに、DoDと特定のタスク要件が混同されます。
- 完了条件を、作業を実行・承認する人たちと話し合うことなく、一人のマネージャーが決めてしまいます。
- 製品、ツール、品質管理ルールの変更後も、チームがDoDを更新しません。

## 参考資料

- 参考資料：『Scrum Guide』の「Definition of Done」と「Increment」のセクション
- 書籍：Jeff Sutherland、『Scrum：The Art of Doing Twice the Work in Half the Time』
- 書籍：Gojko Adzic、『Specification by Example』

## よくある質問

### Definition of Doneの責任者は誰が務めるべきですか？

通常は、プロセスオーナーまたはチームのマネージャーがリストを最新に保つ手助けをしますが、完了条件は、チームが成果物の受領者とともに合意します。

### タスクごとに個別のDoDを作る必要はありますか？

いいえ。DoDは、作業タイプに共通する完了条件を記述します。特定のタスクで成果物に特別な要件がある場合は、受け入れ基準を追加できます。

### アジャイルプロセスなしで始められますか？

はい。このプラクティスはシンプルな作業チェックリストとして機能します：タスクをクローズする前に必ず確認すべきことを合意し、そのリストを受け入れ時に使用します。

### DoDが役立っているかどうかをどう判断しますか？

手直しに戻されるケース、クローズに関する意見の相違、チェック漏れが減ったかどうかを見ます。リストが意思決定に影響を与えていない場合は、簡素化または明確化が必要です。