完成の定義（DoD）の例とチェックリスト｜受け入れ基準との違い

完成の定義（Definition of Done、DoD）とは、「この状態になったら完成と呼ぶ」という品質の基準を、チーム全員が同じ言葉で持つための取り決めです。受け入れ基準が1つのバックログ項目だけに当てはまる条件であるのに対し、完成の定義はすべての項目に共通して当てはまります。

この記事では、Web API・画面・バッチ・インフラ変更・ドキュメントの種類別DoDチェックリストを、プルリクエストテンプレートにそのまま貼れる Markdown のチェックボックスで用意しました。完成の定義・受け入れ基準・準備完了の定義（DoR）の違いは1枚の比較表にまとめ、同じバックログ項目を3つに書き分けた記入例と、初期版から段階的に厳しくするレベル別DoDも載せています。

確認環境：スクラムの記述はスクラムガイド2020（日本語版PDF）、プルリクエストテンプレートの置き場所は GitHub Docs を2026年10月に開いて確認。チェックボックスを数えるスクリプトは Ubuntu 24.04、Python 3.11.15 で実行。

完成の定義・受け入れ基準・準備完了の定義の違い早見表

項目が完成したと言えるのは、「その項目の受け入れ基準をすべて満たし、かつ、完成の定義をすべて満たしたとき」です。受け入れ基準と準備完了の定義はスクラムガイド2020に出てこない語で、多くのチームでよく使われるやり方として広まっているものです。

スクラムガイド2020に書かれている完成の定義

完成の定義は、スクラムガイド2020でインクリメントに対する確約（コミットメント）として定められています。日本語版の記述と、そこから読み取れることを対応させます。

ガイドは完成の定義に何を入れるか（レビューやテストの種類）までは定めていません。この先のチェックリストは、ガイドの枠組みの上でよく使われる項目を整理したものです。

準備完了の定義については、ガイドに「1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。」という一文があります。この「準備ができている」状態をチェックリストにしたものが、一般に DoR と呼ばれています。

同じバックログ項目を3つに書き分ける

架空の備品予約システムの項目「予約を取り消す」を例に、3つを並べます。同じ項目について、何をどこに書くかがわかります。

バックログ項目：

社員として、利用開始前の自分の予約を取り消したい。
予定が変わったときに、他の人がその備品を使えるようにするためだ。

準備完了の定義（着手の前に確かめる）

- [x] 誰の、何のための項目かが書いてある
- [x] 受け入れ基準が書いてあり、開発者が内容を質問し終えた
- [x] 1スプリントで完成できる大きさである（見積もり：3ポイント）
- [x] 画面の案がある（予約一覧に「取り消す」ボタンを追加）
- [x] 他の項目への依存がない、または順序が決まっている
- [x] 確かめるためのデータが用意できる（予約済みの備品が2件以上）

受け入れ基準（この項目だけの条件）

- [ ] 利用開始の前であれば、自分の予約を取り消せる
- [ ] 取り消した時間帯は、すぐに他の社員が予約できる
- [ ] 利用開始の時刻を過ぎた予約には「取り消す」ボタンを表示しない
- [ ] 他の社員の予約は取り消せない（APIを直接呼んでも 403 を返す）
- [ ] 承認待ちの予約を取り消すと、上長への承認依頼も取り下げられる
- [ ] 取り消しの前に確認の表示を出し、取り消した後に結果を表示する

完成の定義（すべての項目に共通の条件）

- [ ] コードレビューで1名以上の承認を得た
- [ ] 単体テストを追加し、すべて通っている
- [ ] 結合テストが通っている
- [ ] 静的解析とフォーマットの指摘が0件である
- [ ] API仕様書・画面仕様など、関係する文書を更新した
- [ ] 検証環境にデプロイして動作を確認した
- [ ] プロダクトオーナーが受け入れ基準を確認した

書く場所に迷ったときの判断表

「次の項目でも同じことを書くか」と自分に問い、答えが「はい」なら完成の定義に移します。同じ条件を受け入れ基準に毎回書いているなら、完成の定義に入れる合図です。

段階的に厳しくするレベル別DoD（3段階）

最初から項目を多くすると、守りきれずに形だけになりがちです。いま毎回守れている項目から始め、振り返りで1〜2項目ずつ足すと定着します。3段階の例を示します。

レベル1のDoD（最初の版としてそのまま使える形）：

## 完成の定義（レベル1）
- [ ] 1名以上がコードレビューで承認した
- [ ] 変更した処理に単体テストがあり、通っている
- [ ] 主要な流れを手で動かして確認した
- [ ] 受け入れ基準をすべて満たしている
- [ ] 変更点と確認方法をプルリクエストに書いた
- [ ] 残した作業があれば、チームに共有した

完成の定義を厳しくすると、1項目にかかる作業は増えます。その分、スプリントの後に残る「完成していない作業」が減り、リリース前にまとめて行っていた確認が毎スプリントに分かれていきます。

種類別DoDチェックリスト

共通の項目に、変更の種類ごとの項目を足して使います。どれも Markdown のチェックボックスなので、課題管理ツールやプルリクエストにそのまま貼れます。当てはまらない項目は消さずに「（対象外：理由）」と書くと、見落としではないことが伝わります。

共通（すべての変更）

## 完成の定義：共通
- [ ] 受け入れ基準をすべて満たしている
- [ ] 1名以上がコードレビューで承認した
- [ ] 単体テストを追加・更新し、すべて通っている
- [ ] CI（ビルド、テスト、静的解析）が通っている
- [ ] 秘密情報（パスワード、APIキー）がコードとログに含まれていない
- [ ] 関係する文書を更新した
- [ ] 検証環境で動作を確認した
- [ ] 残した作業をバックログに登録した

Web API

## 完成の定義：Web API
- [ ] API仕様書（OpenAPI など）を更新し、実装と一致している
- [ ] 正常系と、入力エラー・権限なし・対象なしの応答をテストした
- [ ] ステータスコードとエラー応答の形式が共通ルールどおりである
- [ ] 入力値を検証している（必須、型、桁、範囲）
- [ ] 認証と権限の確認がある（他の利用者のデータを操作できない）
- [ ] 既存の利用側に影響する変更がない。ある場合は移行の方法を書いた
- [ ] 一覧を返すAPIに、件数の上限とページ分けがある
- [ ] 応答時間が目標値以内である（例：95%が500ミリ秒以内）
- [ ] ログに、追跡に必要な情報（リクエストID、利用者、結果）が出ている
- [ ] 同じリクエストを2回送ったときの動きを確かめた

画面

## 完成の定義：画面
- [ ] 画面の案（デザイン）と見比べて、差がない
- [ ] 対象のブラウザーと画面幅（PC・スマートフォン）で表示を確認した
- [ ] 読み込み中・0件・エラーのときの表示がある
- [ ] 入力エラーの文言が、項目のそばに表示される
- [ ] キーボードだけで操作でき、フォーカスの位置がわかる
- [ ] 画像に代替テキストがあり、入力欄にラベルがある
- [ ] ボタンを続けて押しても、処理が二重に行われない
- [ ] 画面の文言が用語集と一致している
- [ ] 権限のない利用者には、操作のボタンを表示しない
- [ ] 画面のテスト（コンポーネントのテスト、または主要な流れの自動テスト）がある

バッチ

## 完成の定義：バッチ
- [ ] 起動の条件（時刻、前の処理）と、想定する処理時間を書いた
- [ ] 0件、1件、想定する最大件数で動作を確認した
- [ ] 途中で止まった場合に、再実行して同じ結果になる
- [ ] 同じ処理が重なって起動しないようにしている
- [ ] 入力の不備がある行の扱い（とばす／止める）を決め、テストした
- [ ] 処理件数と、成功・エラーの件数をログに出している
- [ ] 異常終了を検知して通知する設定がある
- [ ] 再実行の手順と、データを元に戻す手順を書いた
- [ ] 想定する件数で、時間内に終わることを確認した
- [ ] 他の処理との実行順とロックの影響を確認した

インフラ変更

## 完成の定義：インフラ変更
- [ ] 変更がコード（構成管理のファイル）になっており、レビューを受けた
- [ ] 適用前の差分（追加・変更・削除されるもの）を確認した
- [ ] 検証環境に適用し、動作を確認した
- [ ] 元に戻す手順を書き、検証環境で確かめた
- [ ] 作業中のサービスへの影響（停止の有無と時間）を書いた
- [ ] 権限は必要な範囲だけにしている
- [ ] 秘密情報は、専用の保管場所から読み込んでいる
- [ ] 監視とアラートを追加・更新した
- [ ] 費用への影響を確認した
- [ ] 構成図と運用手順書を更新した
- [ ] 作業の日時と担当を関係者に伝えた

ドキュメント

## 完成の定義：ドキュメント
- [ ] 誰が、何のために読む文書かを冒頭に書いた
- [ ] 手順は、書いたとおりに別の人が実行して確かめた
- [ ] コマンドと設定例は、実際に動かしたものを貼った
- [ ] 画面の名前・用語が、製品と用語集に一致している
- [ ] リンクが開ける
- [ ] 版数と更新日、変更の要約を書いた
- [ ] 1名以上がレビューした
- [ ] 置き場所が決まっており、関連する文書から辿れる
- [ ] 以前の版の文書を、置き換えたか、案内を付けた

種類別の項目数と重点

プルリクエストテンプレートに入れる

完成の定義は、毎回の作業で目に入る場所に置くと守りやすくなります。GitHub では、リポジトリに次のいずれかのファイルを置くと、プルリクエストの本文にその内容が入ります（GitHub Docs の記載）。

.github/pull_request_template.md の例：

## 変更内容
<!-- 何を、なぜ変えたか -->

## 対応するバックログ項目
<!-- 項目のURLまたは番号 -->

## 確認方法
<!-- レビューする人が動かして確かめる手順 -->

## 受け入れ基準
<!-- バックログ項目から貼り付けて、確認できたものにチェック -->
- [ ] 

## 完成の定義：共通
- [ ] 受け入れ基準をすべて満たしている
- [ ] 単体テストを追加・更新し、すべて通っている
- [ ] CI（ビルド、テスト、静的解析）が通っている
- [ ] 秘密情報（パスワード、APIキー）がコードとログに含まれていない
- [ ] 関係する文書を更新した
- [ ] 検証環境で動作を確認した
- [ ] 残した作業をバックログに登録した

## 完成の定義：変更の種類（当てはまるものを残す）
<!-- Web API・画面・バッチ・インフラ変更・ドキュメントのチェックリストを貼る -->

## レビューする人へ
<!-- 特に見てほしい点、迷った点 -->

種類ごとにテンプレートを分ける場合は、.github/PULL_REQUEST_TEMPLATE/ に api.md、batch.md のようにファイルを置きます。GitHub Docs では、プルリクエストを作るURLに template クエリパラメーターを付けて、使うテンプレートを指定する方法が案内されています。

「1名以上がコードレビューで承認した」はテンプレートから外しています。承認はプルリクエストの画面で確認できるため、チェックボックスにするより、仕組みの側で確かめるほうが確実です。機械で確かめられる項目はCIや設定に任せ、チェックリストには人が判断する項目を残すと、リストが短く保てます。

チェックの残りをスクリプトで数える

プルリクエストの本文から、チェックの付いていない項目を取り出すスクリプトです。「（対象外：理由）」と書いた項目は数えません。

"""プルリクエスト本文のチェックボックスを数え、残っている項目を表示する。"""
import re
import sys

ITEM = re.compile(r"^\s*[-*] \[( |x|X)\] (.+)$")


def check(text):
    done, todo, skipped = [], [], []
    for line in text.splitlines():
        m = ITEM.match(line)
        if not m:
            continue
        mark, label = m.group(1), m.group(2).strip()
        if "対象外" in label:            # 例: - [ ] 画面の確認（対象外：APIのみの変更）
            skipped.append(label)
        elif mark == " ":
            todo.append(label)
        else:
            done.append(label)
    return done, todo, skipped


if __name__ == "__main__":
    body = open(sys.argv[1], encoding="utf-8").read()
    done, todo, skipped = check(body)
    print(f"完了 {len(done)} 件 / 残り {len(todo)} 件 / 対象外 {len(skipped)} 件")
    for label in todo:
        print(f"  残り: {label}")
    sys.exit(1 if todo else 0)

確かめる本文（pr_body.md）：

## 変更内容
予約の取り消しAPIを追加しました。

## 完成の定義
- [x] コードレビューで1名以上の承認を得た
- [x] 単体テストを追加し、すべて通っている
- [ ] 結合テストが通っている
- [x] API仕様書を更新した
- [ ] 画面の表示を確認した（対象外：APIのみの変更）
- [ ] 検証環境にデプロイして動作を確認した

実行結果（python3 dod_check.py pr_body.md の後に echo "終了コード: $?" を実行）：

完了 3 件 / 残り 2 件 / 対象外 1 件
  残り: 結合テストが通っている
  残り: 検証環境にデプロイして動作を確認した
終了コード: 1

残りの2項目にチェックを付けて、もう一度実行した結果：

完了 5 件 / 残り 0 件 / 対象外 1 件
終了コード: 0

残りがあると終了コードが 1 になるので、CI のステップに組み込めば、チェックの残ったプルリクエストに気づけます。

完成の定義の作り方と見直し方

確かめられる文に直す

つまずきやすい点と直し方

よくある質問

Q. 完成の定義は誰が決めますか？ A. スクラムガイド2020では、組織の標準になっている場合はすべてのスクラムチームが最低限それに従い、標準になっていない場合はスクラムチームがプロダクトに適した完成の定義を作る、とされています。開発者だけでなく、プロダクトオーナーも含めたチーム全員で合意するのがよく使われるやり方です。

Q. 受け入れ基準を満たしていれば、完成と言えますか？ A. 受け入れ基準に加えて、完成の定義も満たしたときに完成と言えます。受け入れ基準は「求めた動きをするか」、完成の定義は「品質の基準を満たすか」を確かめるもので、役割が違います。

Q. スクラムを採用していないチームでも使えますか？ A. 使えます。「レビュー済み」「テストが通っている」「文書を更新した」といった共通の条件を書いて共有するだけで、作業の終わりの認識がそろいます。プルリクエストテンプレートへのチェックリストの追加から始めると取り入れやすくなります。

Q. 項目はいくつくらいが適切ですか？ A. 共通の項目は5〜8個から始めるのが目安です。種類別を足しても、1回のプルリクエストで人が確かめる項目は15個前後に収めると、毎回読まれるリストになります。

まとめ

• 完成の定義（DoD）は、すべての項目に共通する品質の基準です。スクラムガイド2020ではインクリメントの確約として定められています。
• 受け入れ基準はその項目だけの条件、準備完了の定義は着手の前の条件です。この2つの語はスクラムガイド2020にはなく、よく使われるやり方として広まっています。
• 完成と言えるのは、受け入れ基準と完成の定義の両方を満たしたときです。
• 書く場所に迷ったら、「次の項目でも同じことを書くか」で判断します。
• 完成の定義は守れる項目から始め、振り返りで1〜2項目ずつ足して3段階で厳しくします。
• チェックリストは共通＋種類別（Web API・画面・バッチ・インフラ変更・ドキュメント）に分け、プルリクエストテンプレートに置きます。
• 機械で確かめられる項目はCIへ移し、人が判断する項目だけをリストに残します。

参考・出典

• スクラムガイド2020 日本語版（Ken Schwaber、Jeff Sutherland）：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
• GitHub Docs「リポジトリ用のプルリクエストテンプレートの作成」：https://docs.github.com/ja/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。