Definition of Done：具体例と書き方ガイド

Definition of Done（DoD）は、チームが本番環境でのバグ、レビューの抜け漏れ、文書化の未実施など何かを出荷してから初めてその重要性に気づく概念の一つです。そのとき、それは緊急の課題になります。

Definition of Done（DoD）とは何か

Definition of Doneとは、チームが作業を完了したとみなす前に、作業項目が満たさなければならない基準の、チーム全体で合意された共有チェックリストです。「ほぼ完了」でも「自分の環境では動く」でもなく、本当に完了した状態を指します。

DoDは同じレベルのすべての作業の増分（Increment）に均一に適用されます。すべてのユーザーストーリー、すべてのSprint、すべてのリリースです。一人が書いて提示するものではありません。チーム全体で共同作成し、目に見える場所に掲示し、一貫して徹底します。作業がリスト上のすべての項目を満たせば完了です。満たさなければ完了ではありません。

Definition of Doneに関する主要なデータ

• DoDを明確に文書化したチームは、そうでないチームと比べて欠陥を28%少なく出荷するという研究結果が「Empirical Software Engineering」誌（2018年）に掲載されています。
• 「2023 State of Agile Report」（digital.ai）によると、一貫性のない慣行と不明確な基準がAgile変革の失敗の上位5つの原因の一つです。DoDは両方に直接対処します。
• Capers Jonesの調査によると、本番環境での欠陥修正は開発中に発見するよりも10〜100倍のコストがかかります。テストとレビューの要件を含むDoDは、最も低コストの欠陥防止ツールの一つです。

Definition of Doneと受け入れ基準の違い

この2つの用語は混同されることが多く、その混乱は実際の問題を引き起こします。両者は関連していますが、カバーする範囲が異なります。

受け入れ基準は「この機能は意図通りに動くか？」に答えます。DoDは「この増分をリリース可能と呼ぶためにチームが必要なことをすべてやり遂げたか？」に答えます。

ストーリーがすべての受け入れ基準を通過しても、たとえばドキュメントが更新されていなかったり、コードがレビューされていなければDoDを通過できません。両方のゲートを通る必要があります。

一部のチームは入口として**Definition of Ready（DoR）**も使います。チームがスプリントに取り込む前に作業項目が満たすべき条件のチェックリストです。DoDは出口側の仕組みを閉じます。両者を合わせることで、Sprintサイクル全体を品質の境界線で囲います。DORがSprintの準備にどう合うかはBacklogリファインメントを参照してください。

Definition of Doneが重要な理由

DoDがなければ、「完了」はチームの誰にとっても異なる意味を持ちます。開発者はコードがコンパイルできれば完了と考えます。QAエンジニアはテストが通れば完了と考えます。テックリードはコードがレビューされれば完了と考えます。Product Ownerはデプロイされれば完了と考えます。誰も間違っていません。しかし一つの基準に合意しなければ、チームは誰も予期しなかった形で部分的に完了した作業を出荷し続けます。

実際に何が起きるか見てみましょう。DoDのないチームは：

• ローカルでは動くがステージングで失敗するコードを出荷する（環境チェックが誰のメンタルチェックリストにもなかったため）
• 書いた本人がレビューした「レビュー済み」の作業をマージする
• 文書化負債を積み重ねる（誰も要件として書き留めていないため）
• スプリントレトロスペクティブの半分を、完了したばかりのストーリーで「完了」が何を意味するかの議論に費やす

DoDのあるチームは：

• 個人の解釈に依存しない、共有された妥協のない基準を持つ
• デプロイ後ではなく、Sprint中にギャップを発見する
• 始める前から終了基準を全員が把握しているため手戻りが少ない
• スプリントレビューでの驚きが減り、より速く動ける

DoDはまたプロダクトバックログを偽の完了から守ります。すべての基準を満たさずにストーリーが完了とマークされると、実際の作業（修正、レビュー、文書化）がどこかにBacklogに埋まり、後に計画外の作業として浮上します。

Doneのレベル

ほとんどのチームは3つのレベルのDoneで運営しています。各レベルに独自のチェックリストがあり、上位レベルのチェックリストは通常下位レベルのすべてを含みます。

ストーリーレベルの完了

これは個々のユーザーストーリーやタスクに適用されるチェックリストです。一つの増分を届けるために必要な具体的な作業をカバーします。

• コードが書かれ、セルフレビュー済み
• ユニットテストが書かれ、パスしている
• 少なくとも一人の他のチームメンバーによるコードレビュー済み
• 受け入れ基準が満たされ、検証済み
• フィーチャーブランチがmain（または合意された統合ブランチ）にマージ済み

Sprintレベルの完了

このチェックリストはSprintの増分全体、つまりSprintで完成したすべてのストーリーの合計に適用されます。統合とデプロイの基準が加わることが多いです。

• Sprint内のすべてのストーリーについてストーリーレベルのDoD項目がすべて満たされている
• フルビルドに対する統合テストがパスしている
• ステージング環境にデプロイ済み
• Sprintゴールが達成されているか明示的に評価されている
• リリースノートまたは変更ログが更新済み

リリースレベルの完了

これは増分が本番ユーザーに届く前に必要なすべてをカバーします。コンプライアンス、パフォーマンス、承認の基準が通常ここに入ります。

• 本番に近い環境でエンドツーエンドテストがパスしている
• パフォーマンスベンチマーク（ロード時間、エラーレートなど）が満たされている
• セキュリティスキャンが完了し、重大な発見事項がない
• ドキュメントが更新・公開済み
• ステークホルダーの承認を取得済み
• ロールバック計画が文書化済み

スプリントプランニングを行うチームは、各Sprintの成果物にどのレベルのDoneが適用されるかを明確にしておくべきです。すべてのSprintが本番リリースで終わるわけではありませんが、開始前に基準がどこにあるかをチームは知っておく必要があります。

Definition of Doneの具体例

以下に3つの一般的なチームタイプの具体的なDoDチェックリストを示します。そのままコピーするテンプレートではなく、出発点です。チームのDoDは実際の基準、ツール、ワークフローを反映すべきです。

ソフトウェア開発チーム（ストーリーレベル）

• コードが書かれ、エラーなしでコンパイルできる
• 新しいロジックのユニットテストが書かれており、変更ファイルのカバレッジが少なくとも80%
• 著者以外の開発者少なくとも1人によるコードレビューと承認
• CIパイプラインですべての自動テストがパス
• 新しいリンティングエラーが発生していない
• ステージング環境にデプロイ済みで、スモークテスト済み
• 受け入れ基準が開発者またはQAによって検証済み
• 新しいAPIや設定変更がチームのwikiに文書化済み
• フルロールアウトの準備ができていない場合、機能フラグまたはトグルが設定済み

マーケティング・コンテンツチーム（ストーリーレベル）

• 合意した文字数とトーンガイドラインに合わせてコンテンツが書かれている
• 正確さとブランドボイスについて別のライターまたは編集者によるレビュー済み
• SEOチェックリスト完了（タイトルタグ、メタディスクリプション、H1にターゲットキーワード）
• すべての内部リンクが確認済みで機能している
• 画像が最適化され、代替テキストが追加済み
• コンテンツカレンダーに従ってCMSで予約投稿または公開済み
• 配信タスクが完了（ソーシャル投稿の予約、ニュースレターへの掲載確認）
• アナリティクストラッキングが確認済み（UTMパラメータ、イベントタグが設定済み）

デザインチーム（ストーリーレベル）

• デザインが承認済みのブリーフまたはユーザーストーリーの要件と一致している
• リードデザイナーと関連するステークホルダーによるレビュー済み
• アクセシビリティガイドラインが確認済み（カラーコントラスト、文字サイズ、インタラクティブ要素のキーボード操作）
• すべての状態が文書化されている：デフォルト、ホバー、フォーカス、エラー、空、ローディング
• 必要な形式でアセットが書き出され、共有デザインライブラリにアップロード済み
• 開発チームへの引き継ぎノートが書かれている
• レビューからの未解決フィードバックが解決済み、または理由付きで明示的に延期済み

Definition of Doneの書き方

ステップ1：チームを集める

DoDは全員が信じるときだけ機能します。つまり、一緒に作成する必要があります。開発者、デザイナー、QA、Product Owner、作業をする人全員で。60分のワークショップで初稿を作るのに通常は十分です。Scrum Masterやチームリードが一人で書いて「承認」を求めないようにしましょう。共同作成こそが重要です。

ステップ2：完了が実際に何を必要とするかをリストアップする

チームに問いかけてみましょう。「出荷後に問題が発覚した最後の作業を思い出してください。どのステップが省略されていましたか？」失敗から遡って重要なチェックリスト項目を見つけます。そして前向きに考えます。出荷時の良い状態はどのようなものか？忘れたら恥ずかしいことは何か？

項目をカテゴリーにまとめます。コード品質、テスト、ドキュメント、デプロイ、レビューです。これによりSprintの途中でDoDをスキャンしやすくなります。

ステップ3：すべての項目を検証可能なものにする

各DoD項目は検証できるものでなければなりません。完了しているかどうかが明確です。「コード品質が良い」はDoD項目ではありません。「著者以外のチームメンバー少なくとも1人によるコードのレビューと承認」は項目になります。テスト：この項目が完了したという証拠を示せますか？示せるなら、DoDに含める価値があります。判断が必要なら、ガイドラインに変えるか、より具体的な基準に分解します。

ステップ4：合意して目立つ場所に掲示する

チームが草案を作成したら、明示的な合意を得ます。「反対意見なし」ではなく、実際の賛同が必要です。DoDをチーム全員が毎日目にする場所に掲示します。スプリントボード、チームのwiki、Slackのチャンネル説明などです。誰も開かないフォルダに埋もれた文書であってはなりません。チームが見えなければ使われません。

ステップ5：レビューして進化させる

DoDは永続的なものではありません。チームがギャップを露呈した何かを出荷するたびに、スプリントレトロスペクティブでレビューすべきです。チームが新しいツール（例えば自動セキュリティスキャナー）を追加したら、DoDに追加します。チェックリスト項目が完全に習慣として定着して誰も省略しなくなったら、書き留め続ける必要があるか、もはやチームの習慣になったかを検討します。

変わらないDoDは完璧（ありそうにない）か、無視されている（より可能性が高い）かのどちらかです。

よくある失敗

長すぎる。 30項目のDoDは使われません。本当の品質のギャップをカバーする8〜12項目を目指します。網羅的な理想ではなく。1週間後にDoDを暗唱できなければ、長すぎます。

チームレベルではなく組織レベルで書く。 上層部から降りてくるDoDはポリシーをカバーしますが、実践をカバーしません。各チームには実際のワークフロー、ツール、基準を反映したDoDが必要です。

理想として扱う。 チームが通常のSprintですべてのDoD項目を現実的に満たせないなら、そのDoDは理想的なものであって実用的なものではありません。チームが実際にコミットできるところまで削り、キャパシティとツールが改善するにつれて徐々に基準を上げます。

プレッシャー下でスキップする。 「今Sprintはタイトだから文書化をスキップしよう」はDoDが何も意味しなくなる瞬間です。部分的な例外が積み重なると一貫した例外になります。プレッシャー下でDoDを停止できるなら、それは真の基準ではありませんでした。

非機能要件を忘れる。 機能的な振る舞いは受け入れ基準でカバーされます。DoDはパフォーマンス、セキュリティ、アクセシビリティ、ドキュメントの基準が入る場所です。これらをDoDから外すと、機能はするがシステムを時間とともに劣化させる機能を出荷することになります。

よくある質問

Definition of Doneを所有するのは誰ですか？

チームが集団で所有します。Product Owner（リリース可能性を気にする）は影響を与えることができ、Scrum Masterは作成とレビューをファシリテートできます。しかしScrumでは、すべての増分においてDoDを満たすことを約束するのはDevelopersです。誰もSprint中に一方的に変更することはできません。

Definition of Doneとチェックリストはどう違いますか？

DoDはチェックリストの一種ですが、特定の目的と背後にある特定の契約を持つものです。チェックリストはツールです。DoDは、チームが完了と呼ぶ前にすべての増分がこの基準を通過しなければならないという合意です。この違いが重要なのは、共有の所有権と結果を意味するからです。DoDを満たさない作業はスプリントゴールにカウントされません。

すべてのチームにDefinition of Doneが必要ですか？

はい、チームが他の人が依存する作業を出荷するなら。DoDは「完了」が全員に同じ意味を持つようにする仕組みです。DoDのないチームは暗黙の基準を作り（共有されず強制もされない）、最悪のタイミング（通常はSprintの終わり）に完了度について議論します。

Definition of Doneは作業の種類によって異なることができますか？

はい、ただし慎重に。多くのチームにはストーリーレベルのDoDとSprintレベルのDoDがあります（前述のレベルセクション参照）。バグ修正と新機能でわずかに異なる基準を持つチームもいます。しかし断片化に注意してください。DoDに例外や特別なケースが増えるほど、認知負荷が増し、適用の信頼性が低下します。

Definition of Doneはストーリーポイントとどのように関連していますか？

ストーリーポイントは相対的な工数を見積もります。DoDは品質基準を定義します。両者は関連しています。DoDはストーリーの見積もりに考慮すべきです。DoDを満たすことで3時間余分にかかるなら、その時間はストーリーポイントの見積もりに反映されるべきで、急ぎのときに省略されるオーバーヘッドとして扱ってはなりません。チームがDoDの要件を考慮せずにストーリーを過小見積もりすると、まさにDoDの手抜きにつながる種類のプレッシャーに直面します。

---

うまく作られたDefinition of Doneはチームの速度を落としません。チームの速度を落とす曖昧さを取り除きます。誰もが始める前から「完了」が何を意味するかを正確に知っていれば、驚きが少なく、手戻りのループが減り、スプリントレビューでの議論がなくなります。シンプルなものから始め、一貫して徹底し、チームとともに進化させましょう。

関連記事

• プロダクトバックログ
• Backlogリファインメント
• ユーザーストーリー
• ストーリーポイント
• スプリントレトロスペクティブ
• スプリントプランニング
• Scrumとは何か