英語でDefinition of Done(DoD)を整備するよう求められたとき、何をどの粒度で定義すればチームが使いやすいか迷った経験はないだろうか。
Definition of Done(DoD)はチームが「完了」と判断するための共通基準だ。コード品質・テスト・ドキュメント・デプロイ・レビューの5つのカテゴリを押さえれば、英語でも問題なく整備できる。
この記事では、英語DoDに必要な5つのカテゴリと、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに次のスプリント計画で活用できる。
Definition of Done(DoD)に必要な5つのカテゴリ
Definition of Done(DoD)はスクラムガイドで定義された「完了の定義」で、チームが毎スプリント・全ストーリーに適用する品質基準だ。受け入れ基準(Acceptance Criteria)がストーリー固有の条件であるのに対し、DoDはチーム共通の品質保証ラインとなる。以下の5つのカテゴリで整備するのが実務で使いやすい。
- コード品質(Code Quality)
- テスト(Testing)
- ドキュメント(Documentation)
- デプロイ・リリース準備(Deployment & Release Readiness)
- レビュー・承認(Review & Approval)
DoDと受け入れ基準の違い
受け入れ基準はユーザーストーリーごとに定義する「この機能が正しく動くこと」の条件だ。DoDはすべてのストーリーに共通して適用する「チームの品質基準」だ。DoDを満たさないストーリーはどれだけ機能が動いていても「完了」にはならない。
なぜ英語で書くのか
グローバルチームでは開発・QA・POが異なる拠点にいる。英語でDoDを整備することで、「これは完了したのか?」という判断基準が全員に明確に伝わり、スプリントレビューでの不毛な議論を防げる。
ユーザーストーリーとの連携は英語ユーザーストーリーの書き方でも確認してほしい。
テンプレートをダウンロード(Word)
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード(Word)
📥 Download English Template (Word)
日本語版テンプレート(コピペOK)
チーム情報
| 項目 | 内容 |
|---|---|
| チーム名 | (例:決済プラットフォームチーム) |
| 最終更新日 | (例:2026年9月1日) |
| 適用範囲 | (例:すべてのユーザーストーリー・バグ修正・技術的負債対応) |
| 除外対象 | (例:スパイク・PoC・実験的実装はこのDoDを適用しない) |
コード品質
| No. | 基準 | 確認方法 |
|---|---|---|
| 1 | (例:コードレビューが承認済みである(最低1名のApprove)) | (例:GitHub PRのApproveを確認) |
| 2 | (例:Lintエラーがゼロである) | (例:CIのLintチェックが通過) |
| 3 | (例:セキュリティスキャン(SAST)が合格している) | (例:CIのSASTジョブが通過) |
| 4 | (例:技術的負債を追加した場合、テクニカルデット登録に記録されている) | (例:Jiraのテクニカルデットチケットの存在確認) |
| 5 | (例:パフォーマンス基準(P95 500ms以内)を満たしている) | (例:負荷テスト結果の確認) |
テスト
| No. | 基準 | 確認方法 |
|---|---|---|
| 1 | (例:ユニットテストカバレッジが80%以上である) | (例:CIのカバレッジレポートを確認) |
| 2 | (例:統合テストが全件合格している) | (例:CIの統合テストジョブが通過) |
| 3 | (例:対象機能のE2Eテストが合格している) | (例:CIのE2Eテストジョブが通過) |
| 4 | (例:リグレッションテストが全件合格している) | (例:CIのリグレッションジョブが通過) |
| 5 | (例:QAによる手動確認(スモークテスト)が完了している) | (例:QAのサインオフコメントをPRで確認) |
ドキュメント
| No. | 基準 | 確認方法 |
|---|---|---|
| 1 | (例:APIの変更がAPI仕様書(Swagger/OpenAPI)に反映されている) | (例:APIドキュメントのバージョンを確認) |
| 2 | (例:READMEのセットアップ手順が最新の状態である) | (例:READMEのレビューと動作確認) |
| 3 | (例:重要な設計変更がADR(アーキテクチャ決定記録)に記録されている) | (例:ADRのファイルが追加・更新されている) |
| 4 | (例:CHANGELOGに変更内容が記載されている) | (例:CHANGELOGの記載確認) |
デプロイ・リリース準備
| No. | 基準 | 確認方法 |
|---|---|---|
| 1 | (例:ステージング環境へのデプロイが成功している) | (例:CIのデプロイジョブが通過) |
| 2 | (例:ステージング環境でのスモークテストが合格している) | (例:スモークテストの実行ログを確認) |
| 3 | (例:フィーチャーフラグが必要な場合、正しく設定されている) | (例:フィーチャーフラグ管理表を確認) |
| 4 | (例:ロールバック手順が確認されている(必要な場合)) | (例:インフラチームによる確認コメント) |
レビュー・承認
| No. | 基準 | 確認方法 |
|---|---|---|
| 1 | (例:POがストーリーを受け入れている(アクセプタンス)) | (例:POのJiraコメントまたはPRコメントを確認) |
| 2 | (例:セキュリティ要件を含む場合、セキュリティレビューが完了している) | (例:セキュリティチームの承認コメントを確認) |
| 3 | (例:アクセシビリティ基準(WCAG 2.1 AA)を満たしている(UI変更の場合)) | (例:アクセシビリティチェックツールの結果を確認) |
英語版テンプレート(コピペOK)
Team Information
| Item | Details |
|---|---|
| Team Name | (e.g., Payment Platform Team) |
| Last Updated | (e.g., September 1, 2026) |
| Applies To | (e.g., All user stories, bug fixes, and tech debt items.) |
| Exceptions | (e.g., Spikes, PoCs, and experimental implementations are exempt from this DoD.) |
Code Quality
| No. | Criterion | How to Verify |
|---|---|---|
| 1 | (e.g., Code review is approved by at least one reviewer.) | (e.g., Confirm Approve on GitHub PR.) |
| 2 | (e.g., No linting errors.) | (e.g., CI lint check passes.) |
| 3 | (e.g., Security scan (SAST) passes.) | (e.g., CI SAST job passes.) |
| 4 | (e.g., Any new technical debt is logged in the technical debt register.) | (e.g., Confirm tech debt Jira ticket exists.) |
| 5 | (e.g., Performance meets baseline (P95 under 500ms).) | (e.g., Load test results reviewed.) |
Testing
| No. | Criterion | How to Verify |
|---|---|---|
| 1 | (e.g., Unit test coverage is 80% or above.) | (e.g., CI coverage report reviewed.) |
| 2 | (e.g., All integration tests pass.) | (e.g., CI integration test job passes.) |
| 3 | (e.g., E2E tests for the target feature pass.) | (e.g., CI E2E test job passes.) |
| 4 | (e.g., All regression tests pass.) | (e.g., CI regression job passes.) |
| 5 | (e.g., Manual smoke test by QA is complete.) | (e.g., QA sign-off comment on PR.) |
Documentation
| No. | Criterion | How to Verify |
|---|---|---|
| 1 | (e.g., API changes are reflected in the API spec (Swagger/OpenAPI).) | (e.g., Confirm API doc version.) |
| 2 | (e.g., README setup instructions are up to date.) | (e.g., README reviewed and setup verified.) |
| 3 | (e.g., Significant design changes are recorded in an ADR.) | (e.g., ADR file added or updated.) |
| 4 | (e.g., CHANGELOG includes the change description.) | (e.g., CHANGELOG entry confirmed.) |
Deployment & Release Readiness
| No. | Criterion | How to Verify |
|---|---|---|
| 1 | (e.g., Deployment to staging is successful.) | (e.g., CI deploy job passes.) |
| 2 | (e.g., Smoke test in staging passes.) | (e.g., Smoke test execution log reviewed.) |
| 3 | (e.g., Feature flags are configured correctly if applicable.) | (e.g., Feature flag register reviewed.) |
| 4 | (e.g., Rollback procedure is confirmed if applicable.) | (e.g., Infra team confirmation comment.) |
Review & Approval
| No. | Criterion | How to Verify |
|---|---|---|
| 1 | (e.g., PO has accepted the story.) | (e.g., PO acceptance comment on Jira or PR.) |
| 2 | (e.g., Security review is complete for items with security requirements.) | (e.g., Security team approval comment.) |
| 3 | (e.g., Accessibility standards (WCAG 2.1 AA) are met for UI changes.) | (e.g., Accessibility checker results reviewed.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいポイントを解説する。
DoDの粒度の設定
DoDの項目は「確認できる」ものだけにする。「品質が高い」「十分にテストされている」では判断できない。「CIのテストジョブが通過している」「POが受け入れコメントを残している」のように、誰が見ても確認できる条件で書く。
| 日本語 | 英語 |
|---|---|
| 〇〇のCIチェックが通過している | CI check for [X] passes. |
| 〇〇のレビューが承認済みである | [X] review is approved. |
| 〇〇がドキュメントに記録されている | [X] is documented in [location]. |
| 〇〇のテストが全件合格している | All [X] tests pass. |
| 〇〇のサインオフが完了している | Sign-off for [X] is complete. |
DoDの更新タイミング
DoDはスプリントレトロで見直す。「守れていない項目」は基準を下げるのではなく、守れない原因を探る。「追加すべき項目」はチームが合意できる粒度で1〜2項目ずつ加える。
スプリントレトロとの連携は英語スプリントレトロの書き方でも確認してほしい。
DoDでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
DoDの基本用語
| 日本語 | 英語 |
|---|---|
| 完了の定義 | Definition of Done (DoD) |
| 受け入れ基準 | Acceptance Criteria |
| コードレビュー | Code Review |
| テストカバレッジ | Test Coverage |
| リグレッションテスト | Regression Test |
| E2Eテスト | End-to-End (E2E) Test |
| スモークテスト | Smoke Test |
| サインオフ | Sign-Off |
| アクセシビリティ | Accessibility |
| フィーチャーフラグ | Feature Flag |
スプリント計画・レビューでのフレーズ
| 日本語 | 英語 |
|---|---|
| このストーリーはDoDを満たしていますか? | Does this story meet our Definition of Done? |
| DoDのどの項目が未完了ですか? | Which DoD criteria are still outstanding? |
| DoDを更新しましょう | Let’s update our Definition of Done. |
| このストーリーはまだ完了していません | This story is not done yet — it doesn’t meet our DoD. |
| DoDを確認してからレビューを進めましょう | Let’s verify the DoD before we move to review. |
バックログリファインメントとの連携は英語バックログリファインメントの書き方でも確認してほしい。
まとめ:英語Definition of Doneは5つのカテゴリで完成する
英語Definition of Done(DoD)に必要な構成要素を整理した。
- コード品質はレビュー・Lint・セキュリティスキャンをCIで自動確認できる形で定義する
- テストはユニット・統合・E2E・リグレッション・手動スモークの5層で定義し、カバレッジ数値も明記する
- ドキュメントはAPI仕様書・README・ADR・CHANGELOGの最低4点を対象にする
- デプロイ準備はステージングデプロイとスモークテストを必須とし、フィーチャーフラグとロールバックも条件に含める
- レビュー・承認はPOアクセプタンスを必須とし、セキュリティ・アクセシビリティ要件がある場合は追加する
テンプレートをコピーして、まず「テスト」カテゴリのCIで自動確認できる項目から書き始めてほしい。自動化できる基準が固まれば、手動確認項目との役割分担が自然と整理される。


コメント