Definition of Done: Scrumにおける例、チェックリスト、ワークショップ

先日、私は同僚と一緒にワークショップを準備した。内容についてはすぐに合意できたが、唯一欠けていたのは適切なパワーポイントのプレゼンテーションだった。できるだけ効率的にプレゼンテーションに取り組めるように、私たちはテーマごとに分けた。完成した原稿について話し合う席で、大きな問題が明らかになった。何が「完成した原稿」を特徴づけるのかについて、私たちの考えはまったく異なっていたのだ。

この問題は、アジャイルスクラムチームでも起こりうる。2週間後、チームはスプリントの終わりに到達するが、製品インクリメントがすでに完成しており、「進行中」から「完了」に移行できるかどうかについて意見の相違がある。この意見の相違は議論につながり、ひいてはチームの風土に悪影響を及ぼす。このような議論を防ぎ、効果的なチームワークを守るために、スクラムの世界には「完了の定義」（DoD）と呼ばれるアーティファクトがある。

ScrumにおけるDefinition of Doneとは何ですか？

Definition of Doneとは、Scrumチームにおける共通の品質合意です。インクリメントが完了し、利用可能であると見なされるために満たすべき条件を示します。これは個人のタスクリストでも、特定の役割による追加の承認でもなく、チーム全体にとって透明な基準です。

文字通り、Definition of Doneは「完成の定義」を意味する。つまり、ある機能が完成したとみなされるためには何をしなければならないかについて、チームが合意することを意味する。実際には、Definition of Doneは一種のチェックリストとして表現することができ、スプリント中、特に終了時に、特定の完了基準が満たされているかどうかをチェックするために使用される。ソフトウェア開発チームの場合、これらの基準は例えば以下のようなものになる：

Definition of Doneの例：Scrumチーム向けチェックリスト

実践的なDefinition of Doneには、ソフトウェア製品に対してたとえば次のような基準を含めることができます：

受け入れ基準と機能要件が満たされている。
文書が作成された。
コードは完全に実装され、コメントも付けられている。
コードレビューが行われた。
自動テストが正常に実行され、関連する不具合とセキュリティリスクが対応済みである。
変更は統合されており、本番に近い環境で確認できる。
モニタリング、ロギング、必要に応じてリリースノートが考慮されている。
そのインクリメントは利用可能であり、製品の品質基準を満たしている。
…

この一覧は一例であり、普遍的なテンプレートではありません。良いDoDは品質を守り、各スプリントでチームが使える状態を保ち、製品・リスク・技術的な条件が変化したときには見直されます。

Definition of Doneは製品効果と同じではない

Definition of Doneは重要な問いに答えます。そのインクリメントは合意された品質基準を満たし、利用可能か？しかし、それだけで変更が市場や顧客に望ましい効果をもたらしたかどうかまでは自動的には答えません。

実務では、そのために3つのレベルを区別すると役立ちます：

Done： そのインクリメントはDefinition of Doneを満たしており、利用できます。
Done-Done： 変更は統合され、リリースされ、運用上で観測可能である。
製品効果： 実際の顧客フィードバックによって、その変更が重要な課題を解決し、製品価値を高めているかがわかります。

John Cutlerは、そのためソフトウェアを継続的に進化するサービスシステムとして説明しています。機能は完成した建物ではなく、顧客価値を生み出すための一時的な手段にすぎません。彼の視点は以下で読めます The Work Is Never Done.

さらにGil Zilberfeldは、「Done」の意味をいくつかに分けています。たとえば、開発、テスト、リリース、顧客フィードバックがそれぞれ異なる完了段階を示す場合です。彼の整理は以下で確認できます The Definition of Done, Done-Done and Really Done.

重要：「製品効果」を単に追加のDoD基準として定式化すべきではありません。Scrumチームは利用可能なインクリメントを届ける必要があり、その変更が望ましい効果をもたらしたかどうかは、その後のスプリントレビュー、利用、さらなる学習サイクルを通じて明らかになります。まさにこの切り分けが、Definition of Doneが達成不可能な総まとめリストになることを防ぎます。

Definition of Doneが他の有効なScrumプラクティスとどう連携するかは、私たちの記事で紹介しています Scrum Best Practices 2026.

なぜ「完了の定義」が重要なのか？

目標設定がパフォーマンスにとって非常に重要であることは、新しい知見ではない。目標設定は心理学でよく研究されているテーマである（参照）。 Locke & Latham, 2006).目標は、達成不可能と思われることなく、できるだけ具体的で挑戦的なものであるとき、パフォーマンスが最も高くなることが示されている。しかし、Doneの定義は目標設定の方法ではない（しかし、使うとすれば目標設定の方法である）。目標設定をサポートするもし助けが必要なら、喜んでお手伝いします）。むしろ、目標を達成するために満たさなければならない基準の問題なのだ。

これらの基準は、チーム内に共通の理解を生み出すために重要である。共通のゴールに到達するために、各メンバーが何を達成しなければならないかを理解することだ。つまり、個人のパフォーマンスが最終的にチームのパフォーマンスにつながるということだ。

プロダクトオーナーの視点からDoDの問題を見ると、全く異なる問題が明らかになる。製品インクリメントがいつ完成とみなされるかが明確に定義されていないと、製品を顧客に提示する際に顧客との意見の相違を招く可能性がある。そうなって未完成の製品が提示されると、顧客からのフィードバックの可能性が閉ざされてしまう。

継続的改善

Done定義は固定的な概念ではなく、常に進化または変化しうるものであり、また変化すべきものである。スプリントの終了時に、チームが「完了定義」の基準を満たせなかったことに気づいた場合、チームメンバーは「完了定義」を実際のパフォーマンスに合わせて調整するか、チームが次のスプリントのために結論を出し、自身の作業方法を変更することができる。

今すぐEchometerを無料で試して、レトロスペクティブの新しいインスピレーションを得よう！

Echometerを無料でテストする

Doneの定義に関するこれらの振り返りは、チームがレトロスペクティブの間に行うべきである。可能なこと Echometerアイテム準備のための質問は以下の通りである。

われわれの要求には明確な定義がある。

共通の目標を達成するために、私たちがどのような立場にいるのか、私はたいてい知っている。

目標私の目標は同僚の目標と一致している。

チームは目標を達成するために必要なスキルをすべて網羅している。

彼らは、チーム内に “Doneの定義 “があるかどうかだけでなく、チーム内の透明性、自主性、役割の明確さにも疑問を呈する。

全アイテムはレトロツール.

私たちのチームは、どうすれば「やるべきこと」を定義できるのか？ワークショップの例

ここまで、DoD（Definition of Done）とは何か、そしてスクラムチームにおける効果的なコラボレーションのためになぜDoDが重要なのかを説明してきた。しかし、もしあなたのチームがまだDoDを作成していないのであれば、それがどのように機能するのか不思議に思うだろう。

原則として、チームが時間をかけて文書を作成することは重要である。最終的には、チームメンバー全員が共感でき、単なる必要悪とみなされない文書が出来上がるはずである。そのため、スクラムマスターをモデレーターとするワークショップのような形式を推奨する。各チームメンバーは、製品を完成させるためにどの基準が重要かを考え、チームはそれらの考えをまとめることができる。同様に、目標設定のためのワークショップ形式も開発した。見てみようワークショップのアイデアを得る！

完成したDoDは、例えばDefinition-of-Doneトラフィックライトの形で、レトロスペクティブで使用することができる：

Doneの定義に対する基準を、それぞれの下に書く。
それぞれの横に赤、黄、緑の正方形を描く。
Doneの定義」の各項目について、各チームメンバーは、前回のスプリントでそれがうまく実施されたか、中程度に実施されたか、あるいはうまく実施されなかったかをマークする。
赤い部分で最も言及の多い3つについて話し合う。
必要に応じて「完了の定義」を調整する。

結論 - 完了?

最後に一言：アジャイル環境では、最終的に「完了」というものは存在しない。完了」とは、何かが暫定的に完了したことを意味するだけであり、さらなる調整や改善はいつでも可能であり、またそうすべきである。これは、アジャイル作業の多くの美しい側面の1つである、継続的な改善である。

特にエキサイティングなのは、顧客が名乗り出てソリューション全体に疑問を投げかけるまで、ポイントが「完了」していることがあることだ。このような状況では、チームがチケットシステムの進捗よりも顧客の利益を本当に優先しているかどうかが明らかになる。

明確な定義は、衝突を避け、パフォーマンスを向上させる。この目標を達成するためのより多くの方法に興味があるなら、我々の記事も見てほしい。アジャイル・マインドセットに隠された驚くべき真実についてを見る。あるいは、心理学における最新の科学的知見を考慮に入れることで、回顧を充実させることもできる。

まさにこの約束のために、我々はレトロツールEchometerを開発した。もしEchometerがどのように機能するのか（そして機能するのか）興味があれば、ホルガーによる我々のツールの体験レポートを読んでほしい：

チームを新たなパフォーマンス・レベルに引き上げたい？私たちのレトロ・ツールがその手助けをする。ホルガーの経験を紹介しよう：

ホルガーのリモート・レトロ・ツール体験レポート

Definition of Doneに関するよくある質問

Definition of Doneには何を含めるべきですか？

Definition of Doneには、インクリメントが利用可能であるために満たすべきすべての品質基準が含まれます。典型的な例としては、受け入れ基準の達成、コードレビュー、テスト、セキュリティチェック、ドキュメント、そしてリリース可能であるための技術的条件があります。どの項目を含めるかは、チームが自分たちの製品コンテキストに応じて決めます。

Scrumでは誰がDefinition of Doneを作成しますか？

Scrumチームが協力してDefinition of Doneを作成し、維持します。単一の役割がチェックリストとして一方的に定めるべきではありません。組織は最低基準を定めることができますが、チームはそれを理解し、日常業務で適用できなければなりません。

Definition of DoneとDefinition of Readyの違いは何ですか？

Definition of Done とは、インクリメントがいつ完成し利用可能とみなされるかを定義するものです。一方、Definition of Ready は作業項目の準備条件を含むことがありますが、公式な Scrum のアーティファクトではなく、責任やフィードバックループを先送りするために使ってはなりません。

実務からの例: Echometer における私たちの社内 Definition of Done

Definition of Done は、コードとテストで終わる必要はありません。Echometer では社内で、機能性に加えて UX、保守性、可観測性、リリース準備も考慮した、より包括的な基準を用いています。以下の例は、チームが独自の品質基準を具体的かつ検証可能なものにする方法を示しています:

範囲	例示的な基準
機能性	指定された機能が動作し、典型的なエッジケースが確認され、既知の不具合はなく、未完成の機能は Feature Flag で保護され、関連する利用データが収集されている。
UX	空状態、ローディング状態、権限、エラー処理、ローカライズ、レスポンシブ表示が考慮されている。
保守性	Coding Guidelines と関連する規約が守られ、不要なコードや意図的に残した技術的負債は避けられ、モニタリングとデバッグに必要な重要情報が用意されている。
デプロイ	変更は本番にリリース済みであるか、Feature Flag により意図的に準備されており、Release Notes は追記され、必要に応じて影響を受けるステークホルダーに通知される。

この例はもちろん、普遍的に通用するテンプレートではありません。ただし、これを土台として使い、独自の定義を加え、定期的に見直し、成長するドキュメントとして継続的に উন্নえていくことはできます。

情報源

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x