第5章：Definition of Ready / Done（入口と出口の統一）

この章で学ぶこと

• 入口条件（DoR）で「着手できる状態」を統一する
• 出口条件（DoD）で「終わった状態」を統一する
• 曖昧タスク・終わらないタスクを抑止する

成果物（書けるようになるもの）

• DoR/DoD をテンプレで運用できる（付録: DoR/DoD）
• Issue の入口/出口を宣言できる

本文

DoR がないと、調査不足のまま着手し、手戻りが増える。DoD がないと、完了の判定が曖昧になり、品質がばらつく。

最小のDoR/DoD

• DoR: 背景/目的/受け入れ条件/依存/リスク
• DoD: 受け入れ条件を満たしたこと/ロールバック定義/必要な転記

注意点（運用のコツ）

• DoR/DoD は「チームの合意」であり、形骸化させない（満たせない場合は不足情報と期限を明記する）
• DoR を厳格にしすぎると停滞するため、種別（不具合/改善/作業）に応じて最小条件を調整する
• DoD は実装だけで閉じず、必要に応じてテスト/運用手順/監視/FAQ などまで含める

具体例（悪い例→良い例）

悪い例

DoD: 終わったら終わり
DoR: とりあえず着手

良い例

DoR: 受け入れ条件と検証方法が合意済み
DoD: 受け入れ条件PASS、ロールバック手順あり、FAQに転記済み

チェックリスト

• DoR が満たされてから着手している
• DoD が満たされてから完了にしている
• 転記/ナレッジ化の条件がある

まとめ

• DoR/DoD で「着手できる状態」と「終わった状態」を統一し、曖昧タスクを減らす
• DoD にロールバックと転記（ナレッジ化）を含め、運用まで閉じる

次章への接続

• 次章: 第6章