Definition of DoneとDefinition of Readyとは｜Scrumにおける品質と準備の基準

Definition of DoneとDefinition of Readyとは、Scrumやアジャイル開発において、チームが「いつ作業を始められるのか」「いつ作業が完了したと言えるのか」を明確にするための基準です。Definition of Readyは開発を始める前の準備基準であり、Definition of Doneは開発が完了したと判断するための品質基準です。

この2つのDefinitionを適切に運用することで、Scrumチームは作業の曖昧さを減らし、見積もり精度を高め、未完成作業や品質のばらつきを防ぎやすくなります。本記事では、Definition of DoneとDefinition of Readyの意味、違い、具体例、Scrumフローでの位置づけ、Product BacklogやSprint Planningとの関係、AI時代における活用までを体系的に解説します。

1. なぜDefinitionが必要なのか

Scrumでは、チームが短い期間で価値あるIncrementを作り続けることが重要です。しかし、何をもって「準備できている」と判断するのか、何をもって「完了した」と判断するのかが曖昧なままだと、開発中に認識のズレが起きやすくなります。

Definitionは、そのズレを防ぐための共通基準です。作業開始前にはDefinition of Readyで準備状態を確認し、作業完了時にはDefinition of Doneで品質と完成度を確認します。これにより、チームは同じ基準で会話し、同じ品質を目指しやすくなります。

1.1 共通認識を作るため

Definitionが必要な理由の一つは、チーム内で共通認識を作るためです。プロダクトオーナー、開発者、スクラムマスター、ステークホルダーがそれぞれ違う基準で「準備完了」や「作業完了」を理解していると、スプリント中に誤解が生まれます。

たとえば、プロダクトオーナーは「要件を説明したからReady」と考えていても、開発者は「受け入れ条件がないため見積もれない」と感じる場合があります。同じように、開発者が「実装が終わったからDone」と考えていても、チームの基準ではレビューやテストが未完了ならDoneとは言えません。

1.2 品質基準を統一するため

Definition of Doneは、チームの品質基準を統一するために重要です。あるメンバーは単体テストまで行うが、別のメンバーは実装だけで完了とするような状態では、成果物の品質が安定しません。

品質基準が統一されていれば、誰が担当しても一定の完成度を保ちやすくなります。コードレビュー、テスト、セキュリティ確認、ドキュメント更新など、チームが必要と考える項目を明文化することで、品質を個人の経験や判断だけに依存しない運用ができます。

1.3 作業の曖昧さを減らすため

Definition of Readyは、作業を始める前の曖昧さを減らすために役立ちます。要件、受け入れ条件、依存関係、制約、優先度が不明確なままスプリントに入ると、開発中に確認作業が増え、チームの集中力が下がります。

作業開始前に必要な情報が整理されていれば、開発者は実装や検証に集中しやすくなります。もちろん、すべてを完璧に決める必要はありませんが、少なくともスプリント内で取り組める程度には明確になっていることが重要です。

1.4 予測可能性を高めるため

Definitionは、Scrumチームの予測可能性を高めるためにも重要です。Readyの基準が明確であれば、Sprint Planningで選ぶProduct Backlog Itemの品質が安定し、見積もりやスプリント計画の精度が高まりやすくなります。

また、Doneの基準が明確であれば、スプリントの最後に「実装は終わったがテストは未完了」という状態を減らせます。結果として、チームはどれくらいの作業を安定して完了できるのかを把握しやすくなり、今後の計画にも活かしやすくなります。

2. Definition of Done（DoD）とは

Definition of Done、略してDoDとは、Product Backlog ItemやIncrementが「完了した」と判断されるための共通基準です。Scrumにおいては、Doneの状態を明確にすることで、チームが同じ品質レベルの成果物を作れるようにします。

DoDは単なるチェックリストではなく、品質を守るための合意です。実装が終わっただけではなく、レビュー、テスト、統合、ドキュメント、リリース準備など、チームが必要とする条件を満たして初めてDoneと判断されます。

2.1 完了の定義

Definition of Doneは、「この作業は本当に完了したのか」を判断するための定義です。Scrumでは、Incrementが利用可能で価値を提供できる状態になっていることが重要であり、そのためにDoneの意味をチームで明確にします。

たとえば、単にコードを書き終えただけでは完了とは言えません。コードレビューが終わり、テストが成功し、必要なドキュメントが更新され、既存機能への影響が確認されている状態になって初めて、チームのDoDを満たしたと判断できます。

2.2 品質基準のチェックリスト

DoDは、品質基準をチェックリストとして整理する形で運用されることが多いです。チェックリストにすることで、作業ごとに確認漏れを防ぎ、チーム全体で同じ観点から品質を確認できます。

ただし、DoDは単なる形式的なチェック欄ではありません。チェック項目は実際の品質に関係している必要があります。たとえば、「テスト済み」とだけ書くのではなく、「単体テストが成功している」「受け入れ条件を満たしている」「CIでエラーがない」のように確認可能な形にすることが大切です。

2.3 Incrementの完成条件

Scrumでは、各スプリントの終わりに価値あるIncrementを作ることが求められます。Definition of Doneは、そのIncrementが完成しているかどうかを判断するための基準になります。

IncrementがDoneであるということは、少なくともチームが定めた品質基準を満たし、利用可能な状態に近いことを意味します。リリースするかどうかはビジネス判断によりますが、技術的にはリリース可能な品質に近づけることがDoDの重要な役割です。

2.4 リリース可能状態を保証する仕組み

DoDは、成果物をリリース可能な状態に近づけるための仕組みです。実装だけでなく、レビュー、テスト、自動ビルド、セキュリティ確認、ドキュメント更新などを含めることで、リリース前の手戻りを減らせます。

リリース可能状態を意識したDoDを持つことで、チームはスプリントごとに実際に使える価値を積み上げやすくなります。逆に、DoDが弱いと、スプリント中に完了したように見えても、後から統合不具合や品質問題が表面化しやすくなります。

3. DoDが重要な理由

DoDが重要なのは、Scrumチームの成果物の品質を安定させるためです。Doneの基準が曖昧だと、完了した作業の中に未レビュー、未テスト、未統合のものが混ざり、プロダクト全体の信頼性が下がります。

DoDを明確にすれば、チームは作業の終わり方を統一できます。結果として、未完成作業が見えやすくなり、技術的負債の蓄積を防ぎ、ステークホルダーに対しても透明性の高い進捗報告ができるようになります。

3.1 品質のばらつきを防ぐ

DoDは、メンバーごとの品質のばらつきを防ぐために重要です。各メンバーが自分の感覚で完了を判断していると、成果物の品質に差が出やすくなります。

チーム全体で同じDoDを使えば、誰が担当しても同じ確認項目を満たす必要があります。これにより、品質が個人の経験だけに依存しにくくなり、チームとして安定した成果を出しやすくなります。

3.2 未完成作業を減らす

DoDがない、または曖昧な場合、スプリント終了時に「ほぼ完了」「あと少し」「テストだけ残っている」といった未完成作業が増えやすくなります。このような作業は、次のスプリントに持ち越され、計画の精度を下げる原因になります。

DoDを明確にすると、Doneではない作業をDoneとして扱うことを防げます。未完成であれば未完成として可視化し、次に何が必要なのかを明確にできます。これはチームの透明性を高めるうえでも重要です。

3.3 技術的負債を抑制する

DoDは、技術的負債の蓄積を抑えるためにも役立ちます。テスト不足、レビュー不足、ドキュメント未更新、設計上の妥協などが繰り返されると、短期的には進んでいるように見えても、長期的には開発速度が落ちます。

DoDに品質項目を含めることで、チームは毎回一定の品質確認を行うようになります。これにより、後から修正が必要になる問題を早い段階で減らし、継続的に変更しやすいプロダクトを維持しやすくなります。

3.4 チームの透明性を高める

DoDは、作業の状態を透明にするための基準でもあります。Doneの意味が明確であれば、ステークホルダーやプロダクトオーナーは、完了した作業がどの程度信頼できる状態なのかを理解しやすくなります。

透明性が高まると、Sprint Reviewでの会話も具体的になります。単に「完了しました」と報告するのではなく、「チームのDoDを満たしており、レビューとテストも完了しています」と説明できるため、成果物への信頼が高まります。

4. DoDの代表的な項目

DoDの項目は、チームやプロダクトの性質によって変わります。Webアプリ、業務システム、モバイルアプリ、AIプロダクト、組込みシステムでは、必要な品質基準が異なるためです。

ただし、多くのScrumチームで共通して含まれやすい項目もあります。ここでは、DoDに含められる代表的な項目を整理します。

4.1 コード実装完了

コード実装完了は、DoDの基本項目の一つです。対象機能が設計や受け入れ条件に沿って実装され、必要なコード変更が完了している状態を指します。

ただし、コードを書き終えただけではDoneではありません。実装完了はDoDの一部であり、その後にレビュー、テスト、統合確認などの品質確認が必要です。

4.2 コードレビュー完了

コードレビュー完了は、品質を高めるために重要なDoD項目です。別のメンバーがコードを確認することで、バグ、設計上の問題、可読性の低さ、セキュリティ上の懸念などを早期に発見できます。

コードレビューは、単なる承認作業ではありません。チームの知識共有、設計方針の統一、保守性の向上にもつながります。そのため、DoDに含める場合は、レビュー観点や承認条件を明確にしておくと効果的です。

4.3 テスト成功

テスト成功は、DoDの中心的な品質項目です。単体テスト、結合テスト、受け入れテスト、回帰テストなど、チームが必要とするテストが成功していることを確認します。

テストが成功していない状態でDoneと判断すると、後から不具合が見つかり、手戻りが増えます。DoDにテスト成功を含めることで、チームは実装完了だけでなく、期待される動作が確認された状態をDoneとして扱えます。

4.4 ドキュメント更新

ドキュメント更新も、DoDに含められることが多い項目です。仕様書、APIドキュメント、ユーザーガイド、運用手順、リリースノートなど、変更に応じて必要な情報を更新します。

ドキュメントが古いままだと、将来の開発や運用で誤解が生じます。特に複数チームや外部関係者が関わるプロダクトでは、ドキュメント更新をDoDに含めることで、知識の属人化を防ぎやすくなります。

4.5 CI/CDパイプライン通過

CI/CDパイプラインの通過は、現代的な開発チームにとって重要なDoD項目です。自動ビルド、自動テスト、静的解析、セキュリティチェックなどをパイプラインに組み込み、問題がないことを確認します。

CI/CDをDoDに含めることで、人手による確認漏れを減らせます。また、変更が既存機能に悪影響を与えていないかを早く確認できるため、継続的に安全な変更を行いやすくなります。

4.6 本番リリース可能状態

DoDの理想的な状態は、成果物が本番リリース可能な品質に近いことです。リリースするかどうかはプロダクトオーナーやビジネス側の判断ですが、技術的にはいつでもリリースできる状態を目指します。

本番リリース可能状態をDoDに含めると、スプリントの最後に大量の未完了作業が残るリスクを減らせます。結果として、リリース直前の混乱を防ぎ、継続的に価値を届けやすくなります。

5. Definition of Ready（DoR）とは

Definition of Ready、略してDoRとは、Product Backlog Itemが開発を始められる状態になっているかを判断するための準備基準です。スプリントに入れる前に、要件や受け入れ条件、依存関係、見積もり可能性などを確認します。

DoRは、開発前の混乱を減らすために役立ちます。ただし、ScrumにおいてDoRはDoDほど公式に中心的な概念ではなく、チームが必要に応じて運用する実践的な補助基準として扱われることが多いです。

5.1 開発開始の定義

Definition of Readyは、「このBacklog Itemは開発を始められる状態か」を判断するための定義です。要件が明確で、受け入れ条件があり、依存関係が整理され、チームが見積もれる状態であればReadyと判断しやすくなります。

Readyの基準があることで、Sprint Planningで不明確な項目を無理に選ぶリスクを減らせます。開発中に何度も仕様確認が発生する状態を避け、スプリント内で実際に完了できる可能性を高めることができます。

5.2 バックログ項目の準備基準

DoRは、Product Backlog Itemの準備状態を確認するための基準です。たとえば、ユーザーストーリーが明確である、受け入れ条件が書かれている、関連するデザインやAPI仕様が用意されている、外部依存が解消されているといった条件が考えられます。

準備基準があると、Product Backlog Refinementの質が上がります。チームは単に項目を並べるだけでなく、次のスプリントで取り組める状態まで具体化することを意識できます。

5.3 Sprint Planning前の品質管理

DoRは、Sprint Planning前の品質管理として機能します。Sprint Planningでは、チームがどのProduct Backlog Itemをスプリントに入れるかを決めますが、その項目が不明確だと計画自体が不安定になります。

DoRを使えば、Planning前に項目の準備状態を確認できます。結果として、Planningの場で要件確認に時間を取られすぎることを防ぎ、スプリントゴールや実行計画に集中しやすくなります。

5.4 不確実性を減らす仕組み

DoRは、開発前の不確実性を減らす仕組みです。アジャイル開発では変化を受け入れることが重要ですが、何も分からない状態で作業を始めることとは違います。

必要な情報が最低限そろっていれば、チームはより正確に見積もり、実装方針を考え、リスクを把握できます。DoRは、すべてを固定するためのものではなく、スプリント内で進められる程度に不確実性を下げるための基準です。

6. DoRが重要な理由

DoRが重要なのは、スプリントに入る前の準備不足を減らせるからです。準備不足のBacklog Itemをスプリントに入れると、開発中に確認待ち、仕様変更、依存関係の未解決などが発生しやすくなります。

DoRを適切に使えば、チームはより安定したスプリント計画を立てやすくなります。見積もりの精度が上がり、スプリント中の混乱が減り、開発者が価値提供に集中できる状態を作りやすくなります。

6.1 開発中の混乱を防ぐ

DoRは、開発中の混乱を防ぐために役立ちます。要件が曖昧なまま開発を始めると、実装途中で何度も確認が必要になり、作業が止まりやすくなります。

Readyな状態で作業を始めれば、チームは何を作るのか、どの条件を満たせばよいのかを理解したうえで進められます。これにより、手戻りや待ち時間を減らし、スプリント内の流れを安定させやすくなります。

6.2 見積もり精度を高める

DoRは、見積もり精度を高めるためにも有効です。要件や受け入れ条件が不明確なままでは、作業量を正確に見積もることが難しくなります。

項目がReadyな状態になっていれば、チームは実装範囲、技術的難易度、依存関係、テスト範囲を考慮して見積もりやすくなります。結果として、スプリントに入れる作業量の判断も安定しやすくなります。

6.3 スプリント失敗を減らす

準備不足の項目をスプリントに入れると、スプリント中に作業が止まり、スプリントゴールが達成できない原因になります。DoRは、このような失敗を減らすための予防策として機能します。

もちろん、DoRを満たしていても予想外の問題は起こります。しかし、少なくとも事前に確認できる曖昧さや依存関係を整理しておくことで、スプリント失敗のリスクを下げることができます。

6.4 チームの集中力を維持する

DoRがあると、開発者はスプリント中に不要な確認や調整に追われにくくなります。必要な情報がそろっているため、実装、テスト、レビューに集中しやすくなります。

集中力が維持されると、チームの生産性だけでなく、品質にも良い影響があります。頻繁な中断や不明点の確認が減ることで、より深く考えながら設計や実装に取り組めるようになります。

7. DoRの代表的な項目

DoRの項目は、チームの開発スタイルやプロダクトの性質によって変わります。重要なのは、開発を始めるために本当に必要な情報を明確にすることです。

DoRは厳しすぎても問題になります。すべての情報が完全にそろうまで開始できない状態にすると、アジャイルの柔軟性が失われます。そのため、必要十分な準備基準にすることが重要です。

7.1 要求が明確である

DoRの基本項目は、要求が明確であることです。誰のために、何を実現し、どのような価値を提供するのかが分からなければ、開発者は正しい実装判断ができません。

要求が明確であるということは、詳細な仕様書がすべて完成しているという意味ではありません。少なくとも、チームが目的を理解し、実装に必要な会話を進められる程度に整理されていることが重要です。

7.2 ビジネス価値が定義されている

Product Backlog Itemには、なぜその作業が必要なのかというビジネス価値が必要です。価値が不明確な項目は、優先順位を判断しにくく、スプリントゴールとの関係も曖昧になります。

ビジネス価値が定義されていれば、チームは単に機能を作るのではなく、何のために作るのかを理解できます。これにより、実装上の判断やスコープ調整もしやすくなります。

7.3 受け入れ条件が存在する

受け入れ条件は、Backlog Itemが期待どおりに完了したかを判断するための条件です。DoRに受け入れ条件を含めることで、開発者とプロダクトオーナーの認識をそろえやすくなります。

受け入れ条件がないまま開発を始めると、完了後に「期待と違う」となるリスクが高まります。事前に受け入れ条件を整理しておけば、実装、テスト、レビューの観点も明確になります。

7.4 依存関係が整理されている

DoRでは、他チーム、外部システム、API、デザイン、法務確認、インフラ準備などの依存関係が整理されていることも重要です。依存関係が未解決のままスプリントに入ると、作業が止まる原因になります。

依存関係があること自体は問題ではありません。問題は、それが見えていないことです。事前に依存関係を明確にすれば、スプリントに入れるかどうか、先に調整すべきかを判断できます。

7.5 見積もり可能である

ReadyなBacklog Itemは、チームが見積もり可能な状態である必要があります。見積もれない項目は、範囲が大きすぎる、要件が曖昧、技術的な不確実性が高いなどの問題を含んでいる可能性があります。

見積もり可能であることは、正確な数字を出せるという意味ではありません。チームが相対的な大きさや複雑さを話し合える程度に情報がそろっていることが重要です。

7.6 十分に小さい単位になっている

DoRでは、Backlog Itemがスプリント内で完了できる程度に小さい単位になっていることも重要です。大きすぎる項目は、途中で作業が分割できず、スプリント終了時に未完了になりやすくなります。

小さく分割された項目は、進捗を確認しやすく、レビューもしやすくなります。また、価値を段階的に届けやすくなるため、アジャイル開発のメリットを活かしやすくなります。

8. DoDとDoRの違い

DoDとDoRの違いは、簡単に言えば「始めるための基準」と「終わらせるための基準」の違いです。DoRは開発前に使い、DoDは開発後に使います。

この違いを理解していないと、チームは準備不足の作業を始めたり、未完成の作業を完了扱いしたりしやすくなります。DoRとDoDは役割が異なるため、混同せずに運用することが大切です。

8.1 目的の違い

DoRの目的は、開発を始められる状態を作ることです。要件、価値、受け入れ条件、依存関係、見積もり可能性などを確認し、スプリント中に不要な混乱が起きないようにします。

一方、DoDの目的は、開発が完了した状態を明確にすることです。実装、レビュー、テスト、ドキュメント、リリース準備などを確認し、成果物が一定の品質を満たしていることを保証します。

8.2 適用タイミング

DoRは、Sprint Planning前や開発開始前に適用されます。Product Backlog Refinementの中で項目を整理し、次のスプリントで選べる状態になっているかを確認します。

DoDは、開発後やIncrement完成前に適用されます。作業が完了したと判断する前に、チームが定めた品質基準を満たしているかを確認します。

8.3 管理対象

DoRの主な管理対象は、Product Backlog Itemです。つまり、スプリントに入れる候補となる個別の作業項目が、開発可能な状態になっているかを見ます。

DoDの主な管理対象は、Product Backlog Itemの完了状態やIncrementです。チームが作った成果物が品質基準を満たし、利用可能な状態になっているかを確認します。

8.4 成果への影響

DoRは、チームの予測性に大きな影響を与えます。Readyな項目をスプリントに入れることで、見積もりや計画が安定し、スプリント中の不確実性を減らせます。

DoDは、成果物の品質に大きな影響を与えます。Doneの基準を満たすことで、未完成作業や品質問題を減らし、信頼できるIncrementを作りやすくなります。

9. Scrumフローでの位置づけ

DoRとDoDは、Scrumフローの中で異なる場所に位置づけられます。DoRはBacklog RefinementからSprint Planningにかけて重要になり、DoDは開発、テスト、Increment完成にかけて重要になります。

この流れを理解すると、DoRとDoDを単独のチェックリストではなく、Scrum全体の品質と予測性を支える仕組みとして運用しやすくなります。

9.1 Backlog Refinement

Backlog Refinementでは、Product Backlog Itemを整理し、将来のスプリントで扱いやすい状態にします。この段階でDoRを意識することで、要件、受け入れ条件、依存関係、優先順位を確認できます。

Refinementの目的は、すべてを詳細に決めることではありません。チームが次に取り組む可能性のある項目を理解し、必要な会話を前もって行うことで、Sprint Planningをスムーズにすることです。

9.2 DoRチェック

DoRチェックでは、Backlog Itemが開発開始可能な状態かを確認します。要件が明確か、受け入れ条件があるか、依存関係が整理されているか、見積もり可能かなどを確認します。

このチェックは、チームを縛るためのものではありません。むしろ、準備不足の項目を早めに見つけ、Product Ownerや関係者と追加確認を行うためのきっかけになります。

9.3 Sprint Planning

Sprint Planningでは、ReadyなProduct Backlog Itemをもとに、スプリントで何を達成するかを決めます。DoRを満たした項目がそろっていれば、チームはより現実的なスプリント計画を立てやすくなります。

Planningの場で要件確認ばかりに時間を使うと、スプリントゴールや実行計画の議論が弱くなります。DoRは、Planningを計画の場として機能させるための土台になります。

9.4 開発・テスト

スプリント中は、チームがBacklog Itemを実装し、テストし、レビューしていきます。この段階では、最終的にDoDを満たすことを意識しながら作業を進める必要があります。

DoDを最後に確認するだけではなく、開発途中から品質基準を意識することが大切です。たとえば、テストを後回しにせず、実装と並行して品質確認を進めることで、スプリント終盤の負荷を減らせます。

9.5 DoDチェック

DoDチェックでは、作業が本当に完了しているかを確認します。コードレビュー、テスト、ドキュメント、CI/CD、受け入れ条件など、チームが定めた項目を満たしているかを確認します。

このチェックで重要なのは、未完了のものをDoneとして扱わないことです。基準を満たしていない場合は、残作業として明確にし、必要に応じて優先順位やスコープを調整します。

9.6 Increment完成

DoDを満たした作業は、Incrementの一部として扱われます。Incrementは、スプリントごとに積み上がる価値ある成果物であり、チームの品質基準を満たしている必要があります。

Incrementが完成しているという状態は、単に作業が終わったという意味ではありません。チームが合意した品質基準を満たし、次の判断やリリースに使える状態になっていることを意味します。

10. Product Backlogとの関係

DoRとDoDは、Product Backlogの品質にも大きく関係します。Product Backlogが整理されていなければ、Readyな項目を選ぶことが難しくなり、スプリント計画の精度も下がります。

また、DoDが明確であれば、Backlog Itemを作る段階でも、最終的にどのような完成状態を目指すべきかを意識できます。つまり、DoRとDoDはBacklog管理の入口と出口を支える基準です。

10.1 Refinement品質向上

DoRを使うことで、Backlog Refinementの品質が向上します。Refinementでは、単に項目を説明するだけでなく、開発可能な状態まで内容を具体化することが重要です。

DoRがあると、チームは何を確認すべきかを判断しやすくなります。受け入れ条件、価値、依存関係、サイズ、リスクなどを整理することで、Backlog Itemの品質が安定します。

10.2 優先順位管理支援

Product Backlogでは、価値やリスクに基づいて優先順位を管理します。DoRにビジネス価値や目的の明確化を含めることで、優先順位を判断しやすくなります。

価値が不明確な項目は、優先度を高くすべきか低くすべきか判断しにくくなります。DoRを通じて価値を明確にすれば、Product Ownerはより納得感のある優先順位付けを行いやすくなります。

10.3 開発準備の可視化

DoRは、Product Backlogの中でどの項目が開発可能な状態にあるかを可視化します。Readyな項目と準備不足の項目を区別できれば、次のスプリントに向けた準備状況が分かりやすくなります。

開発準備が可視化されていると、チームは早めに不足情報を補えます。たとえば、デザイン待ち、API仕様待ち、依存チームの確認待ちなどを見える化することで、スプリント直前の混乱を減らせます。

10.4 リスク削減

Product Backlogの段階でリスクを把握できれば、スプリント中の問題を減らせます。DoRは、要件の曖昧さや依存関係、見積もり不能な要素を早めに見つけるための基準になります。

リスクを完全になくすことはできませんが、見えているリスクと見えていないリスクでは対応のしやすさが大きく異なります。DoRを使えば、少なくとも事前に議論できるリスクを明確にできます。

11. Sprint Planningとの関係

Sprint Planningでは、チームがスプリントで取り組む内容を決めます。このとき、DoRを満たしたBacklog Itemが用意されているかどうかは、計画の質に大きく影響します。

また、Planningで選んだ項目は、スプリント中にDoDを満たすことを目指します。つまり、Sprint PlanningはDoRからDoDへつながる出発点になります。

11.1 Readyな項目のみ選択

Sprint Planningでは、原則としてReadyな項目を選ぶことが望ましいです。準備不足の項目を選ぶと、スプリント中に確認待ちや手戻りが発生しやすくなります。

ただし、DoRを絶対的な門番として扱いすぎると、柔軟性が失われる可能性があります。重要なのは、Readyでない項目を入れる場合、そのリスクをチームが理解し、対策を決めたうえで選択することです。

11.2 計画精度向上

DoRを満たした項目が多いほど、Sprint Planningの計画精度は高まりやすくなります。要件や受け入れ条件が明確であれば、作業量やリスクを見積もりやすくなるためです。

計画精度が高まると、チームはスプリントゴールを達成しやすくなります。無理な計画や不明確な作業を減らせるため、スプリント中の調整も行いやすくなります。

11.3 スコープ安定化

DoRは、スプリント中のスコープ変更を減らすためにも役立ちます。開発開始前に範囲や受け入れ条件が明確になっていれば、途中で「実はこれも必要だった」という追加が起きにくくなります。

スコープが安定すれば、チームはスプリントゴールに集中できます。もちろん、重要な変更があれば対応する必要がありますが、事前に整理できる曖昧さはできるだけPlanning前に解消しておくことが望ましいです。

11.4 見積もり改善

Readyな項目は、チームにとって見積もりやすい状態です。要求、価値、受け入れ条件、依存関係、サイズが明確であれば、ストーリーポイントや作業量の見積もりが安定しやすくなります。

見積もり改善は、一度で完璧になるものではありません。DoRを使いながら、どのような情報があると見積もりやすいのかをチームで学習し、継続的に改善していくことが重要です。

12. 品質保証との関係

DoDとDoRは、品質保証にも深く関係します。DoRは品質問題を未然に防ぐための入口管理であり、DoDは成果物が品質基準を満たしているかを確認する出口管理です。

品質保証をテスト工程だけに閉じ込めるのではなく、要件定義、Backlog Refinement、開発、レビュー、リリース準備まで広げることで、チーム全体の品質意識が高まります。

12.1 品質の左シフト

品質の左シフトとは、品質確認を開発の後半だけでなく、より早い段階から行う考え方です。DoRはこの左シフトに役立ちます。開発前に受け入れ条件やリスクを確認することで、後から発生する欠陥を減らせます。

DoDも左シフトに関係します。Doneの基準を早い段階から意識して開発すれば、テストやレビューを最後にまとめて行うのではなく、作業の流れの中で品質を作り込めます。

12.2 欠陥流出防止

DoDは、欠陥が後工程や本番環境に流出することを防ぐために重要です。レビューやテスト、CI/CDチェックをDoneの条件に含めることで、問題を早い段階で見つけやすくなります。

欠陥流出を防ぐには、単にテスト項目を増やすだけでは不十分です。受け入れ条件が明確であること、実装方針が共有されていること、レビュー観点があることなど、DoRとDoDの両方が品質に影響します。

12.3 テスト戦略統合

DoDには、チームのテスト戦略を反映できます。単体テスト、結合テスト、E2Eテスト、回帰テスト、パフォーマンステスト、セキュリティテストなど、プロダクトに応じた確認項目を含めます。

重要なのは、すべてのテストを毎回同じ重さで実施することではありません。リスクや変更内容に応じて必要なテストを定義し、DoDとして実際に運用できる形にすることが大切です。

12.4 継続的改善

DoDとDoRは、一度作って終わりではありません。チームの成熟度、プロダクトの成長、技術環境、顧客要求の変化に合わせて更新する必要があります。

たとえば、不具合が頻発しているならDoDに新しい品質項目を追加する、Planningで混乱が多いならDoRを見直すといった改善が考えられます。Definitionは、チームの学習に合わせて育てるものです。

13. Kanbanとの関係

DoDとDoRはScrumだけでなく、Kanbanの運用にも応用できます。Kanbanでは、作業項目がどの列に移動できるか、どの条件を満たせば次の工程に進めるかを明確にすることが重要です。

そのため、DoRはReady列の定義に、DoDはDone列や完了条件の定義に活用できます。これにより、チームのフローが安定し、作業の滞留や品質のばらつきを減らしやすくなります。

13.1 Ready列の定義

KanbanボードにReady列を置く場合、その列に入る条件を明確にする必要があります。ここでDoRの考え方が役立ちます。Ready列にある項目は、チームがすぐに着手できる状態であるべきです。

Ready列の定義が曖昧だと、作業をPullした後に要件確認や依存関係の問題が発生します。Readyの条件を明確にすることで、次に着手する作業の品質を安定させられます。

13.2 Pull条件の明確化

Kanbanでは、チームが作業をPullするタイミングが重要です。Pull条件が曖昧だと、準備不足の作業を始めたり、優先度が不明確な作業を選んだりする可能性があります。

DoRを使えば、「この項目はPullしてよい状態か」を判断しやすくなります。結果として、作業開始後の待ち時間や手戻りを減らし、フロー全体を滑らかにできます。

13.3 フロー安定化

DoRとDoDは、Kanbanのフロー安定化にも役立ちます。入口でReadyの条件を確認し、出口でDoneの条件を確認することで、作業が不安定な状態で流れることを防げます。

フローが安定すると、リードタイムやサイクルタイムのばらつきも減りやすくなります。チームは、どこで作業が詰まっているのか、どの工程で品質問題が起きているのかを把握しやすくなります。

13.4 WIP管理との連携

Kanbanでは、WIP制限によって同時進行中の作業量を管理します。DoRとDoDをWIP管理と組み合わせることで、作業の量だけでなく、作業の状態も管理しやすくなります。

たとえば、Readyでない作業を無理に開始しない、Doneでない作業を完了扱いしないというルールがあれば、WIPの中身の品質が安定します。これは、単に作業数を制限するよりも実践的なフロー管理につながります。

14. よくあるDoDの失敗

DoDは非常に有効な基準ですが、作り方や運用を誤ると効果が弱くなります。特に、抽象的すぎる、守られない、品質項目が不足している、定期的に見直されないといった失敗がよくあります。

DoDはチームが実際に使えるものでなければ意味がありません。理想を並べるだけではなく、現在のチームが運用でき、かつ品質向上につながる内容にすることが重要です。

14.1 抽象的すぎる

DoDの失敗例として多いのが、項目が抽象的すぎることです。たとえば、「品質が良いこと」「テスト済み」「問題がないこと」といった表現では、何を確認すればよいのか分かりません。

DoDは、測定可能で確認可能な表現にする必要があります。「単体テストが成功している」「コードレビューで承認されている」「受け入れ条件を満たしている」のように、判断に迷わない形にすることが大切です。

14.2 チームが守らない

DoDを作っても、チームが守らなければ意味がありません。スプリント終盤に時間が足りなくなり、テストやレビューを省略してDoneにしてしまうと、DoDは形だけのものになります。

DoDを守るには、現実的な項目にすることが重要です。チームの能力や自動化の状況に合わない過剰な基準を作ると、守れないルールになってしまいます。まずは守れる基準から始め、徐々に改善する方が効果的です。

14.3 品質項目不足

DoDに品質項目が不足していると、完了したように見えても不具合や手戻りが発生しやすくなります。実装完了だけをDoDにしている場合、レビューやテストが抜け落ちる可能性があります。

必要な品質項目はプロダクトによって異なります。セキュリティが重要なプロダクト、パフォーマンスが重要なプロダクト、法規制が関係するプロダクトでは、それぞれDoDに含めるべき項目も変わります。

14.4 定期的に更新しない

DoDは、チームやプロダクトの変化に合わせて更新する必要があります。最初に作ったDoDを何年も見直さないまま使い続けると、現在の開発環境や品質要求に合わなくなることがあります。

Sprint Retrospectiveなどで、DoDが今のチームに合っているかを定期的に確認するとよいでしょう。不具合の傾向やリリース時の問題をもとに、必要な項目を追加・修正していくことが重要です。

15. よくあるDoRの失敗

DoRにもよくある失敗があります。代表的なのは、要件が曖昧なまま開始すること、逆に準備条件を厳しくしすぎること、見積もれない項目を無理に入れること、Refinementが不足することです。

DoRは、開発を止めるためのルールではありません。チームがスプリント内で価値を届けやすくするための準備基準です。そのため、厳しさと柔軟性のバランスが重要です。

15.1 要件が曖昧なまま開始

DoRが機能していないチームでは、要件が曖昧なまま開発を始めてしまうことがあります。誰のための機能なのか、何を満たせばよいのか、どの範囲まで作るのかが不明確な状態です。

この状態で作業を始めると、開発中に確認作業が増え、実装後に認識違いが見つかる可能性が高くなります。DoRを使って、少なくとも作業開始に必要な情報を事前に整理することが重要です。

15.2 過剰な準備要求

DoRを厳しくしすぎると、すべての詳細が決まるまで開発を始められなくなります。これはアジャイルの柔軟性を損なう原因になります。

DoRは、完璧な仕様書を求めるものではありません。スプリント内で取り組める程度に明確で、チームが見積もり、実装、検証できる状態を目指すものです。過剰な準備要求は避けるべきです。

15.3 見積もり不能な状態

Backlog Itemが見積もれない状態でスプリントに入ると、計画の精度が大きく下がります。技術的な調査が必要なのか、要件が大きすぎるのか、依存関係が未整理なのかを確認する必要があります。

見積もり不能な場合は、無理に実装項目として扱うのではなく、調査タスクや分割作業として整理することが有効です。DoRは、このような状態を早めに発見するためにも役立ちます。

15.4 Refinement不足

DoRがあっても、Backlog Refinementが不足しているとReadyな項目は増えません。Refinementは、Product Ownerだけの作業ではなく、チーム全体で項目を理解し、準備するための活動です。

Refinementが不足すると、Sprint Planningで初めて不明点が表面化します。これによりPlanningが長引いたり、準備不足の項目をスプリントに入れざるを得なくなったりします。

16. 成熟したチームの運用

成熟したScrumチームは、DoDとDoRを固定的なルールではなく、継続的に改善する基準として扱います。チームの状況に合わせて見直し、必要な項目を追加・削除しながら、実際に価値を生む運用にします。

また、成熟したチームはDefinitionを個人管理の道具として使いません。DoDとDoRは、チーム全体の品質文化、透明性、予測性を高めるための共通基盤として運用されます。

16.1 DoDを継続改善する

成熟したチームは、DoDを定期的に見直します。不具合が増えている、レビューで同じ指摘が多い、リリース時に手戻りが発生している場合、DoDに改善の余地があるかもしれません。

DoDの改善は、チームの品質成熟度を上げる重要な活動です。最初から完璧なDoDを作る必要はありません。実際の問題をもとに、少しずつ基準を強化していくことが現実的です。

16.2 DoRをシンプルに保つ

成熟したチームは、DoRをシンプルに保ちます。DoRが複雑すぎると、Backlog ItemをReadyにするための負担が大きくなり、スピードが落ちる可能性があります。

DoRは、開発開始に本当に必要な条件に絞ることが重要です。チームがよく迷うポイント、スプリント中に問題になりやすいポイントを中心に設計すると、実用的なDoRになります。

16.3 品質文化を共有する

DoDとDoRを効果的に運用するには、チーム全体で品質文化を共有する必要があります。品質はQA担当者だけの責任ではなく、プロダクトに関わる全員の責任です。

品質文化があるチームでは、DoDやDoRは押し付けられたルールではなく、より良いプロダクトを作るための合意として機能します。チーム全員が意味を理解していることが重要です。

16.4 自動化を積極活用する

成熟したチームは、DoDやDoRの一部を自動化します。たとえば、テスト実行、静的解析、セキュリティチェック、ビルド確認、ドキュメント生成などは自動化しやすい領域です。

自動化により、確認漏れを減らし、チームの負担を軽くできます。特にDoDでは、CI/CDと組み合わせることで、品質基準を継続的に満たしやすくなります。

17. AI時代のDoDとDoR

AI時代には、DoDとDoRの運用も進化しています。AIは、要件の曖昧さの検出、受け入れ条件の生成、テストケース作成、コード品質チェック、リスク分析などを支援できます。

ただし、AIはチームの判断を置き換えるものではありません。DoDとDoRの意味を理解したうえで、AIを補助ツールとして使うことが重要です。

17.1 AIによる要件レビュー

AIは、Product Backlog Itemの要件レビューを支援できます。ユーザーストーリーが曖昧でないか、受け入れ条件が不足していないか、依存関係や例外ケースが抜けていないかを確認する補助として使えます。

これにより、DoRチェックの精度が高まりやすくなります。特に、Product Ownerやチームが見落としがちな観点をAIが提示することで、Refinementの議論が深まりやすくなります。

17.2 自動品質チェック

AIは、DoDに含まれる品質チェックの一部も支援できます。コードの可読性、潜在的なバグ、セキュリティリスク、テスト不足、設計上の懸念などを検出する用途が考えられます。

ただし、AIの指摘は常に正しいとは限りません。チームはAIの結果をそのまま採用するのではなく、レビューの補助として活用し、最終判断は人間が行う必要があります。

17.3 テスト生成支援

AIは、受け入れ条件や仕様からテストケースを生成する支援にも活用できます。単体テスト、境界値テスト、例外ケース、ユーザーシナリオなどを提案することで、テスト観点の抜け漏れを減らせます。

DoDにテスト成功を含めるチームにとって、AIによるテスト生成は大きな支援になります。ただし、生成されたテストが本当に価値ある確認になっているかは、チームがレビューする必要があります。

17.4 Ready判定支援

AIは、Backlog ItemがReadyかどうかの判定支援にも使えます。要件の明確さ、受け入れ条件の有無、依存関係、見積もり可能性などをチェックし、不足している情報を提案できます。

Ready判定をAIが支援すれば、Refinementの準備が効率化されます。ただし、Readyかどうかの最終判断はチームが行うべきです。AIは会話のきっかけを作る補助として位置づけるのが適切です。

18. スケール環境での運用

複数チームが同じプロダクトを開発するスケール環境では、DoDとDoRの運用がさらに重要になります。チームごとに品質基準が大きく異なると、統合時に問題が発生しやすくなるためです。

一方で、すべてのチームに完全に同じDoRを強制すると、各チームの状況に合わなくなることもあります。共通化すべき基準と、チームごとに調整すべき基準を分けることが重要です。

18.1 複数チーム共通DoD

複数チームで一つのプロダクトを作る場合、共通DoDが必要になることがあります。共通DoDがあれば、どのチームが作ったIncrementでも一定の品質基準を満たしている状態にできます。

共通DoDには、コードレビュー、テスト、セキュリティ、CI/CD、統合確認など、プロダクト全体に関係する品質項目を含めることが多いです。これにより、統合時の品質問題を減らしやすくなります。

18.2 チーム別DoR

DoRは、チームごとに調整されることが多いです。担当領域、技術スタック、外部依存、顧客との関係、作業の性質が異なるため、Readyの条件も変わる可能性があります。

ただし、完全にバラバラにすると組織全体のBacklog管理が難しくなります。基本的な考え方は共通化しつつ、具体的なDoR項目はチームごとに調整する運用が現実的です。

18.3 組織標準化

大規模な組織では、DoDやDoRを標準化することで、品質と開発プロセスのばらつきを減らせます。標準化により、新しいチームやメンバーも共通の考え方を理解しやすくなります。

ただし、標準化は現場の柔軟性を奪うものであってはいけません。組織として最低限守るべき基準を定め、その上で各チームが実情に合わせて追加・調整できる形が望ましいです。

18.4 ガバナンスとの両立

DoDとDoRは、ガバナンスとも関係します。特に金融、医療、公共、セキュリティ要件の高い領域では、品質基準や記録、承認プロセスが重要になります。

アジャイル開発とガバナンスは対立するものではありません。DoDやDoRに必要な確認項目を組み込むことで、スピードを保ちながら、組織として求められる品質や監査性を確保しやすくなります。

19. 成功するDefinition設計

成功するDefinition設計には、明確さ、測定可能性、理解しやすさ、運用可能性、継続的改善が必要です。どれだけ立派なDefinitionを作っても、チームが使えなければ意味がありません。

DoDとDoRは、チームの働き方を支える実践的な基準です。現実の開発フローに組み込み、チーム全員が意味を理解し、改善し続けることで効果を発揮します。

19.1 明確で測定可能

Definitionは、明確で測定可能である必要があります。曖昧な表現では、人によって判断が変わり、共通基準として機能しません。

たとえば、「十分にテストする」ではなく、「受け入れ条件に対するテストが完了している」「CIが成功している」のように書くと、確認しやすくなります。測定可能な表現は、チームの会話を具体的にします。

19.2 チーム全員が理解している

Definitionは、チーム全員が理解している必要があります。Product Ownerだけ、スクラムマスターだけ、QAだけが理解していても、日々の開発では機能しません。

チーム全員が意味を理解していれば、作業中の判断がそろいやすくなります。新しいメンバーが入った場合も、DoDとDoRを共有することで、チームの品質基準や準備基準を早く理解できます。

19.3 実際に運用可能

Definitionは、実際に運用可能であることが重要です。理想を詰め込みすぎると、毎回守れない基準になり、形骸化します。

運用可能なDefinitionを作るには、現在のチームの能力、ツール、時間、プロダクトのリスクを考慮する必要があります。まずは小さく始め、運用しながら改善する方が成功しやすくなります。

19.4 継続的に改善される

Definitionは、継続的に改善されるべきものです。プロダクトが成長すれば品質要求も変わり、チームが成熟すればより高い基準を扱えるようになります。

Sprint Retrospectiveや品質分析の結果をもとに、DoDとDoRを見直すことが大切です。Definitionを改善し続けることで、チームはより高い品質と予測性を実現できます。

まとめ

Definition of DoneとDefinition of Readyは、Scrumチームが品質と準備状態を明確にするための重要な基準です。DoRは開発を始めるための基準であり、Product Backlog Itemがスプリントに入れられる状態かを確認します。一方、DoDは作業を完了したと判断するための基準であり、Incrementが一定の品質を満たしているかを確認します。

DoRは予測性やスプリント計画の安定に貢献し、DoDは品質向上や未完成作業の削減に貢献します。どちらもチームの共通認識を作り、作業の曖昧さを減らすために有効です。ただし、DoRを過剰に厳しくしたり、DoDを形だけのチェックリストにしたりすると効果は弱くなります。

成功する運用には、明確で測定可能な基準、チーム全員の理解、現実的に守れる設計、継続的な改善が必要です。DoDとDoRを正しく使えば、Scrumチームはより安定して価値を届け、品質とスピードの両方を高めやすくなります。