スクラムにおける完了の定義(Doneの定義)とは?

完了の定義 / Definition of Done (DoD)」は、スクラムにおいて必須のアイテムの1つです。スクラム開発において何を持って完了とするかを明確化した定義になります。

チームの結束でプロダクトインクリメントを開発する中で、完了の定義で「何をもって完了とするかの定義」をチームメンバーで共通認識できていないと、仕事の出来栄えにバラツキが出来てしまいます。

また、「完了の定義(Doneの定義)」に入れるもの、Undone(完了していないアイテム)にするものの判断も最終的なインクリメントの質に直結するため、完了の定義(Doneの定義)を考えるのはスクラムマスターの腕の見せどころでもあります。

今回は、スクラムにおいてもマストアイテムである完了の定義(Doneの定義)について定義の確認や、メリット、注意点など深堀りしてみたいと思います。
因みに完了の定義は、「Doneの定義」と言われたり「完了の定義」「完成の定義」「DoD」とさまざまに呼ばれますが、同義になります。

スクラムにおける完了の定義(Doneの定義)とは

スクラムにおける完了の定義(Doneの定義)

完了の定義(Doneの定義)とは

完了の定義とは、かんたんに言えば「完了チェックリスト」です。何をどこまでやれば「完了」かを定義したリストです。
品質を満たすために必要な確認と考えるとよいでしょう。ただし、これらは変化する可能性があるため、継続的に見直し改善する必要があります。

完了の定義の解釈は誤解を生みやすいですが、完了の条件としては「完了した(合格)」「完了していない(不合格)」のどちらかしかありません。スクラムチームメンバーが共通理解できるためにも、完了の条件が明確でわかりやすい事が重要です。

Undoneワークとは

スプリント期間中に、完了の定義を満たさなかったアイテムです。つまり完了していない(不合格)」のアイテムをUndoneワークと言います。

スクラムにおける完了の定義(Doneの定義)を理解するポイント

スクラムにおける完了の定義(Doneの定義)

完了の定義は、扱うプロダクトやサービス、またはチームによって大きく異なりますが、難しいものではありません。

「完了の定義」と「受入基準」の違いを理解する

スクラム開発プロセスで「完了の定義」と「受け入れ基準」の両方が存在することがあります。完了の定義はすべての作業に共通ですが、受け入れ基準は一つのPBI(ユーザーストーリ)に対して固有のものです。
完了の定義は、機能要件や、非機能要件、品質を満たすことです。一方、受け入れ基準は、機能要件としてユーザーストーリで定義した機能が提供する条件を定めています。

Joe Justice

例えば受け入れ基準の例としては
下記のようなものが考えられます。

  • すべての必須項目に入力しないとフォームを送信できない
  • 支払いはクレジットカードと請求書の選択が可能
  • フォームからの情報は登録データベースに保存される
  • フォームを送信した後、ユーザーと管理者へ確認メールが送信される

完了の定義(Doneの定義)を作成する

Joe Justice

まず完了の定義を作成する前に
以下の質問について考えてみましょう。

  • プロダクトが使用できるとはどういう状態か?
  • どのような環境でうまく機能しなければならないか?
  • どんなテストに合格しなければならないか?

これらをチームで共通理解するために、明確な条件を作成します。

完了の定義の例

Joe Justice

ソフトウェア開発であれば
下記のようなものが考えられます。

  • コードレビュー
  • 機能テストに合格
  • 単体テスト合格
  • 統合テストに合格
  • リグレッションテストが作成され合格している
  • テスト環境にデプロイされている
  • POはユーザーストーリーの完了を確認している

スクラムにおいて完了の定義(Doneの定義)を明確にするメリットについて考えてみましょう。

完了の定義(Doneの定義)をつくる事で、品質が担保されます。よくアジャイルでは品質が担保されないという声を聞きますが、この完成の定義を満たさなければリリースすることはできません。

PBIのタスクに対し必要なチェックリストが特定されているため、Undoneワークがないかをきちんと考える事ができるので、結果としてUndoneのリスクを減らす事に繋がります。

また、完了の定義(Doneの定義)を明確に定める事で、各スプリント内でDone、Undoneを明確に測定できるため、透明性が向上し最終的にクオリティーの高いインクリメントを作る事にも繋がります。スクラムメンバーも完了の定義(Doneの定義)を理解しながら進捗の把握ができる点もプロダクトの向上に繋がる要素になるでしょう。

スクラムにおける完了の定義(Doneの定義)の注意点が弱いと遅延のリスクがある

スクラムにおいて完了の定義(Doneの定義)の質が、リリースされるインクリメントのクオリティーに大きな影響を与えます。完了の定義(Doneの定義)の注意点についてもまとめておきます。

完了の定義(Doneの定義)が弱いと遅延のリスクがある

リリース可能なインクリメント=完了の定義(Doneの定義)+Undone

これを言い換えると

リリース可能なインクリメント-Undone=完了の定義(Doneの定義)

とシンプルに考えた場合、Undoneの数が多くなると完了の定義(Doneの定義)が薄く貧弱になってしまいます。

しかし、完了の定義(Doneの定義)が弱く質が低いと、潜在的に出荷可能との差分となるUndoneが多く発生してしまい、リリースの遅延に繋がったり、柔軟性の欠如にも繋がってしまいます。こうしたUndoneが各スプリントで発生してしまうと、スプリントの失敗にも繋がってしまいます。

顧客にクオリティーの高いプロダクトを届ける為にも、質の高い完了の定義(Doneの定義)を定める必要があります。一般的に完了の定義(Doneの定義)は、スクラムチームの熟成度によって決まる事が多いです。

また、Undoneをスプリント内に取り込み、強い完了の定義(Doneの定義)を作れるかは、スクラムマスターの腕の見せどころでもあります。

Undoneの回収は計画的に行いスプリントの失敗を避ける

Undoneは負債と考える事ができるわけですが、リリースの直前でUndoneの回収を行う状況になってしまうと、スプリントの失敗にも繋がってしまいます。

プロダクトのリリースに影響を与えそうなリスクの大きなUndoneの回収は定期的に行う必要があると言えます。

見落とされがちですが、意外と重要!準備完了の定義

準備完了の定義 / Definition of Ready (DoR)」とは文字通り、準備完了を確認するためのチェックリストです。
チームが作業に取り組み始める前に、確認すべきものです。
例えば、ユーザー ストーリーがスプリントに取り込まれ作業に入る前、またはチームがスプリントを開始する前です。

準備完了の定義の例

Joe Justice

どのようなことが揃えば準備完了と言えるでしょうか?

例えば下記のようなものが考えられます。

  • ユーザーストーリーが明確になっている
  • 受け入れ基準が確認されている
  • スプリントで完了できるサイズになっている
  • 開発に必要な情報が揃っている
  • ユーザーストーリーはテスト可能である

なぜ準備完了の定義が必要なのか?

スプリントプランニングが長引く、またはうまく行かないという声をよく聞きます。それは準備完了の定義が無いことが一つの原因では無いでしょうか?
スプリントプランニング前に、各ユーザー ストーリーが準備完了の定義を満たしていれば、会議は無駄なくスムーズに進めることができます。

完了の定義と準備完了の定義に関するFAQ|教えてジョー

準備完了の定義は、見積もりが完了していないといけないの?

チームはまず、完成の定義や受け入れ基準を知らなければ、作業サイズを見積もることはできません。POは要件を明確にし、完成の定義をチームと定める必要があります。
しかし、チームによっては見積もりを必要としないこともあるので、必ずしも見積もりの完了は必須ではありません。チームの状況に合わせて必要か不要かは決めてください。

準備完了と完了の定義(完成の定義)を作成するのはいつ?

リファインメントで実施します。リファインメントの完了は、PBI(ユーザーストーリ)が準備完了の定義を満たしていることです。

準備完了と完了の定義(完成の定義)の項目はどのくらい作成すればいいの?

ビギナーチームの場合、詳細なチェックリストが必要かもしれません。しかしこれらのチェックリストは、シンプルであればシンプルである方がいいです。

完成の定義の理想は、全て自動化されていることです。

完了の定義と準備完了の定義のまとめ

準備完了の定義と完了の定義は、開始前と開始後のスプリントの重要なポイントです
これらはチームとして合意し作成する必要があります。また一度作って終わりではなく、必要に応じて適宜見直し、改善を行うことも大切です。