Definition of Ready（DoR）の例とチェックリスト｜DoDとの違い

Definition of Ready（DoR、着手の定義・準備完了の定義）は、プロダクトバックログアイテムを「スプリントに入れて作り始めてよい」と判断するための条件を、チームで合意して書いた一覧です。 スクラムガイド（2020年版）には「Definition of Ready」という語は出てきません。公式の用語は「完成の定義（Definition of Done、DoD）」だけで、DoR はチームが任意で使う取り決めです。

確認環境：スクラムガイドの記述は、scrumguides.org の 2020年版（英語の HTML 版と日本語版 PDF、訳：角征典・荒本実・和田圭介）の原文で、「Definition of Ready」の語がないことを確かめました。INVEST は Bill Wake の記事（2003年）、DoR の注意点は InfoQ の記事（2014年）と Scrum.org のブログ（2024年）の原文で確かめています。GitHub の Issue フォームのテンプレートは、PyYAML 6.0.3 と jsonschema 4.26.0（Python 3.11.15、Linux）で SchemaStore の github-issue-forms スキーマに通し、図は Mermaid 12.1.0（@mermaid-js/mermaid-cli 12.0.0）で描画できることを確かめました（確認日 2026年10月13日）。

スクラムガイドでの位置づけ

スクラムガイド 2020年版は、「準備ができている（ready）」状態を、DoR という名前の一覧ではなく、1文で説明しています。 日本語版の原文です。

• 「1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。」
• 「スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。」

英語版でも、この箇所は "deemed ready for selection in a Sprint Planning event" で、"Definition of Ready" という語はページのどこにもありません。

つまり、スクラムガイドの「Ready」の条件は「1スプリントで完成できること」と、そのための透明性だけです。 それ以上の条件をチームで書き出したものが DoR です。

Scrum.org のブログ記事（Ciprian Banica、2024年）も、DoR を「スクラムガイドに書かれていない補助的なやり方（a complementary practice not mentioned in the Scrum Guide）」とし、副題で「スクラムの一部なのは DoD だけ」と書いています。そのうえで、チームの作業の取り決め（working agreements）として DoR を使うことはでき、バックログの透明性を上げるために使うチームもある、としています。

完成の定義（DoD）は公式の用語

DoD のほうは、スクラムガイドに節があります。

• 「完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。」
• 「プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。」

ガイドでは、DoD を満たさないアイテムはリリースできず、スプリントレビューで見せることもできず、プロダクトバックログに戻すとしています。DoD の作り方は、関連記事「完成の定義（DoD）の例とチェックリスト｜受け入れ基準との違い」で扱っています。

DoR・リファインメント・DoD の関係

flowchart LR
  PB["プロダクトバックログ<br>（大きく粗いアイテム）"] --> RF["リファインメント<br>分割・説明・並び順・サイズ"]
  RF --> Q{"DoR を<br>満たすか"}
  Q -- まだ --> RF
  Q -- 満たす --> SP["スプリントプランニング<br>（選択の準備ができている）"]
  SP --> SB["スプリント<br>作る・テストする"]
  SB --> D{"DoD を<br>満たすか"}
  D -- 満たす --> INC["インクリメント<br>レビューで見せる"]
  D -- 満たさない --> PB

DoR はリファインメントの「目標地点」、DoD はスプリントの「目標地点」です。 スクラムガイドはリファインメントを、アイテムを小さく詳細になるように分割・定義する活動とし、「これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。」と書いています。リファインメントでどこまで詳しくすれば十分かを、チームで書き出したものが DoR、と考えると位置づけがはっきりします。

サイズについては、ガイドに「作業を行う開発者は、その作業規模の評価に責任を持つ。」とあります。DoR の「見積もりがある」は、開発者が見積もったかどうかで確かめます。

INVEST（よいストーリーの6つの条件）

DoR の項目は、INVEST を下敷きにすると作りやすくなります。 INVEST は Bill Wake が2003年の記事「INVEST in Good Stories, and SMART Tasks」で示した、よいユーザーストーリーの条件です。

Wake は「S」について、ストーリーはふつう数人週以内の作業で、数人日に収めるチームもある、と書いています。

N（交渉できる）は、DoR を厳しくしすぎないための歯止めにもなります。 着手前にすべての詳細を決めることは、INVEST の考え方とは逆向きです。ストーリーの書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。

チェックリストのテンプレート

最初は5項目ほどの短い一覧から始めます。 「基本」はどのチームにも当てはまりやすい項目、「必要に応じて」はチームの事情で足す項目です。

基本の5項目

必要に応じて足す項目

参考として、Microsoft が公開している「Code With Engineering Playbook」の DoR の例でも、実装に必要な詳細と入力値、明確で完全な受け入れ基準、事業上の必要、測れる受け入れ基準、短期間で終わる大きさ、ほかの作業や他チームの成果物で止まっていないこと、が挙げられています。

Markdown のテンプレート

## Definition of Ready（着手の定義）　版：1.0（YYYY-MM-DD）

スプリントプランニングで選ぶアイテムは、次をすべて満たしていること。
満たさないアイテムを選ぶときは、理由をスプリントバックログに書く。

- [ ] 価値（なぜ）が書かれていて、プロダクトオーナーが説明できる
- [ ] 受け入れ基準があり、チームが同じ理解をしている
- [ ] 1スプリントで DoD を満たせる大きさに見積もられている（目安：<N> ポイント以下）
- [ ] 着手を止める依存がない（あれば解消の見通しがある）
- [ ] 必要な情報（画面の案・API の仕様など）が手に入る

見直し：スプリントレトロスペクティブで、増やすより減らせる項目がないかを先に話す。

記入例：会議室予約システムのアイテム

社内の会議室予約システムを作るチームの、リファインメントでの判定の例です。このチームは「8ポイント以下なら1スプリントで終わる」と決めています（チームごとに決める値です）。

PBI-11 の受け入れ基準は次のとおりです。

Given 14:00 開始の会議室の予約があり、チェックインされていない
When 14:15 になる
Then 予約は取り消され、その枠は空きとして表示される
And 予約した人に、取り消しのメールが届く

機械で拾える項目を調べるスクリプト

DoR の項目のうち「受け入れ基準が空」「見積もりがない・大きい」「依存が書かれている」は、バックログを CSV に書き出せば機械で拾えます。価値の説明や「同じ理解をしているか」は、人が話して確かめる項目です。

import csv, sys
MAX_POINTS = 8          # このチームで「1スプリントで終わる」とみなす上限（チームで決める値）

for r in csv.DictReader(open(sys.argv[1], encoding="utf-8")):
    why = []
    if not r["受け入れ基準"].strip():
        why.append("受け入れ基準がない")
    if not r["見積もり"].strip():
        why.append("見積もりがない")
    elif int(r["見積もり"]) > MAX_POINTS:
        why.append(f"{r['見積もり']}pt は大きい（分割を検討）")
    if r["依存"].strip():
        why.append(f"依存：{r['依存']}")
    print(r["ID"], "Ready" if not why else "要リファインメント", " / ".join(why))

上の4件で動かした結果です。

$ python3 ready.py backlog.csv
PBI-11 Ready 
PBI-12 要リファインメント 受け入れ基準がない
PBI-13 要リファインメント 13pt は大きい（分割を検討）
PBI-14 要リファインメント 依存：PBI-20（SSO連携）が未完了

このスクリプトは、リファインメントで話すアイテムを先に拾う道具です。 「Ready」と出ても、価値や受け入れ基準の理解がそろっているかは、チームで確かめます。見積もりの付け方は、関連記事「ストーリーポイントの見積もり方｜基準表とプランニングポーカー手順」で扱っています。

GitHub の Issue フォームに DoR を入れる例

GitHub の Issue フォーム（.github/ISSUE_TEMPLATE/ に置く YAML）にすると、アイテムを作るときに DoR の項目が目に入ります。

name: ユーザーストーリー
description: プロダクトバックログアイテム（DoR のチェックつき）
title: "[Story] "
labels: ["story", "not-ready"]
body:
  - type: textarea
    id: story
    attributes:
      label: ストーリー
      description: 「〇〇として、〜したい。なぜなら〜」の形で書く
      placeholder: 総務担当として、使われなかった予約を手作業なしで解放したい。毎朝の確認に30分かかっているから
    validations:
      required: true
  - type: textarea
    id: acceptance
    attributes:
      label: 受け入れ基準
      description: Given-When-Then などで、合否が出せる形で書く
      placeholder: |
        Given 14:00開始の予約がチェックインされていない
        When 14:15になる
        Then 予約が取り消され、空きとして表示される
    validations:
      required: true
  - type: input
    id: estimate
    attributes:
      label: 見積もり（ストーリーポイント）
      placeholder: "3"
  - type: textarea
    id: dependencies
    attributes:
      label: 依存・前提
      description: 他チーム・外部の API・デザインなど、着手前にそろっている必要があるもの
      placeholder: なし
  - type: checkboxes
    id: dor
    attributes:
      label: Definition of Ready（着手の定義）
      description: リファインメントで確かめる。すべて満たしたら not-ready ラベルを外す
      options:
        - label: 価値（なぜ）が書かれていて、プロダクトオーナーが説明できる
        - label: 受け入れ基準があり、チームが同じ理解をしている
        - label: 1スプリントで完成の定義（DoD）を満たせる大きさに見積もられている
        - label: 着手を止める依存がない（あれば解消の見通しがある）
        - label: 画面・API などの必要な情報が手に入る

SchemaStore の github-issue-forms のスキーマで検証した結果です。

$ python3 v.py
story.yml OK 5 要素 / 5 項目のチェック

試しに type: checkboxes を checkbox と書き間違えると、次のように止まりました。

NG: 'checkbox' is not one of ['checkboxes', 'dropdown', 'input', 'markdown', 'textarea', 'upload'] ['body', 4, 'type']

• DoR のチェックボックスには required を付けていません。 アイテムを作る時点では、まだ Ready でないのが普通だからです。Ready になったら not-ready のラベルを外す運用にしています。
• GitHub のドキュメントでは、required は「Only for public repositories」（公開リポジトリだけで効く）と書かれています。非公開のリポジトリでは、必須の欄も入力を強制しません。

チケットの書き方は、関連記事「チケットの書き方｜タスク・課題のテンプレートと良い例・悪い例」で扱っています。

使い方の流れ

1. チームで最初の DoR を作る：過去のスプリントで「着手してから止まったアイテム」を挙げ、止まった理由を項目にします。5項目ほどに絞ります。
2. リファインメントで使う：並び順が上のアイテムから DoR に照らし、足りない点をその場で埋めるか、次の一手を決めます。
3. スプリントプランニングで使う：Ready のアイテムから選びます。Ready でないアイテムを選ぶときは、理由と、スプリント中に何を確かめるかを書いておきます。
4. レトロスペクティブで見直す：「この項目のせいで待ちが出なかったか」「この項目がなくても困らなかったか」を話します。

スプリントプランニングの進め方は関連記事「スプリントプランニングの進め方｜アジェンダとスプリントゴール例」で、バックログの並べ方は「プロダクトバックログの書き方と例｜優先順位の付け方とテンプレート」で扱っています。

注意：厳しすぎる DoR は流れを止める

DoR は、着手を助けるための道具です。項目が増えすぎると、作り始める前の「関門（ゲート）」になり、流れが止まります。 InfoQ の記事（2014年）では、Stefan Roock の指摘として次の言葉が紹介されています。

• 「Readyの定義はプロダクトオーナと開発チームのコラボレーションの障害となるような，過剰に管理されたプロセスの作成に使用される可能性もあります。」
• 他のプロダクトオーナやアーキテクトによる事前チェックが定期的に求められるようになると、「これはもう，スクラムでもアジャイルでもありません。」
• Roock は、DoR は時間とともに大きくするのではなく、小さくしていくべきだとしています。

Scrum.org のブログも、DoR は「ゲートキーピング（gatekeeping、門番のように通さないこと）」のような有害な振る舞いにつながりうる、と書いています。

厳しすぎるサインと直し方

「Ready でないものは絶対に選ばない」より、「Ready でないものを選ぶなら、何が分かっていないかを書いて選ぶ」のほうが、流れを止めずに済みます。 調査が目的のアイテム（スパイク）は、調査の問いと終わりの条件があれば Ready とみなす、という決め方もあります。

よくある質問

Q. DoR は作るべきですか。 A. スクラムガイドは求めていません。リファインメントが機能していて、着手後に止まるアイテムが少ないなら、なくても進められます。「着手してから受け入れ基準の確認で止まる」「依存が着手後に分かる」ことが続くときに、その理由を項目にして作ると効果が出やすくなります。

Q. DoR と受け入れ基準はどう違いますか。 A. 受け入れ基準は、アイテムごとに違う「このアイテムの合格の条件」です。DoR は、どのアイテムにも共通する「着手してよい条件」で、その1つに「受け入れ基準がある」が入ります。

Q. DoR はカンバンでも使えますか。 A. 使えます。カンバンでは「準備完了」の列に入れる条件（列の出入りの決まり）として書くことが多くあります。列の決め方は、関連記事「カンバン方式のやり方 列の例とWIP制限の決め方・計算例」で扱っています。

Q. 誰が DoR を決めますか。 A. スクラムガイドには決まりがありません。Microsoft の Playbook の例では、プロダクトオーナーが開発チームなどと合意して書くとしています。チーム全員で合意し、全員が見られる場所に置くのが一般的です。

まとめ

• DoR（着手の定義）は、アイテムを作り始めてよい条件をチームで書いた一覧。スクラムガイド2020には出てこない任意の取り決め
• スクラムガイドの「Ready」は、1スプリントで完成できることと、リファインメントで得る透明性
• DoD は公式の用語で、インクリメントの品質の基準。DoR は入口、DoD は出口
• 項目は INVEST を下敷きに、5項目ほどから始める
• 厳しすぎる DoR はゲートになり流れを止める。レトロスペクティブで、増やすより減らすことを先に考える

参考・出典

確認日はいずれも 2026年10月13日です。

• Ken Schwaber・Jeff Sutherland「The 2020 Scrum Guide」：https://scrumguides.org/scrum-guide.html
• 「スクラムガイド 2020年11月」日本語版（訳：角征典・荒本実・和田圭介）：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
• Bill Wake「INVEST in Good Stories, and SMART Tasks」（XP123、2003年）：https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
• InfoQ「"Readyの定義"を使う」（Ben Linders、2014年）：https://www.infoq.com/jp/news/2014/06/using-definition-of-ready/
• Scrum.org「What Is the Difference Between the Definition of Done (DoD) and the Definition of Ready (DoR)?」（Ciprian Banica、2024年）：https://www.scrum.org/node/80590
• Microsoft「Code With Engineering Playbook：Definition of Ready」：https://microsoft.github.io/code-with-engineering-playbook/agile-development/team-agreements/definition-of-ready/
• GitHub Docs「Syntax for GitHub's form schema」：https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
• SchemaStore「github-issue-forms.json」：https://json.schemastore.org/github-issue-forms.json

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