アジャイルコーチとして、あるいはスクラムマスタとして、スクラムチームの改善に取り組まなければならないとき、私がいつも最初に確認するのは「完成の定義（完了の定義、DoD、Definition Of Done）」です。
「スクラムがうまくいっていない」と表現されるとき、多くの場合、期待されるより開発のスピードが遅いということや、品質に問題があるということが起きています。そしてそれは、完成の定義が適切に記載されていない、あるいはそもそも完成の定義がない、ということが原因だったりします。
スクラムガイドでは「完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述で ある。」と定義されています。
Scrum.org スクラムガイド（日本語ダウンロードできます）
インクリメント（スクラムチームがスプリントで完成させるもの）が、どのような条件を満たすべきか？例えば、ソースコードの静的解析は実施されているか？自動ビルド・自動テストは実施されているか？検証環境やステージング環境に配置されているか？プロダクトオーナーがスプリントレビューよりも前に完成したアプリを実際に動かして確認することができるか？など・・・従来のウォーターフォールでは「受け入れ条件」に記載されるような細かいことが記載されるのが完成の定義です。
もちろん、書式や記載方法などに凝ったドキュメントである必要はなく、また、プロダクトオーナーを含めたスクラムチームメンバー全員が同じ認識を持つことができるならばシンプルな記述でよく、むしろ箇条書きで簡潔に書くのがポイントだと思います。ただ、たとえシンプルにでもこれが全く記載されていないと、チームメンバーそれぞれがイメージするインクリメントの完成した状態に、微妙な認識の差が生じることになります。
完成の定義がないままスプリントが進むと、必ず品質に問題が生じます。例えば、テストを全く実施しなくても、プログラムコードを書くという「タスク」を実施しただけでインクリメントは完成したと思うメンバーがいるかもしれません。そしてそれはただ作業が終わっただけで、完成している保証が全くありません。そして多くの場合ほとんどまともに動きません。
そこまでひどい状況でないとしても、完成の定義がなければ、余裕があるスプリントでは十分にテストされているが、余裕がないスプリントでは、帳尻をあわせるように品質を犠牲にして、テストが十分でなくても（あるいはバグがあることがわかっていても）アプリが十分完成しているように見せかけることができます。これは余裕をなくしているのが原因かもしれないので、開発者だけを責めることはできないかもしれませんが、どちらにしてもそういう状態ならないために、微妙な認識の食い違いを、そのままにしておくことはできません。
また、完成の定義は見積もりにも大きく影響します。スプリントバックログを実現するためにインクリメントをつくるので、スプリントバックログに記載された内容と、完成の定義に記載された内容の両方を満たすのに必要なタスクをこなしていくのが、スプリントの開発者の役割になります。完成の定義がなかったり、曖昧で認識の食い違いがあると、必要なタスクにもずれが生じてしまいます。タスクが正しく洗い出せなければ見積もりも正しくできません。スプリントゴールを決めるがうまくいかないのも、進捗が思ったように進まないのも、すべてこの完成の定義が曖昧だから、かもしれません。
完成の定義がない場合、例えば「Azure DevOps の Test Plans にテストを定義して、それをすべて実施し、成功にする」と1行書くだけでも大きく品質が改善されます。開発者はテストケースを記載して手動テストを実施しなければならないことがわかりますし、テストケースと結果をプロダクトオーナーも確認することができます。細かい部分がわからなくても、少なくともテストしたかどうかはわかります。そういった作業が必要ならば、どこまでタスクが必要か？１スプリントではどこまでできるか？がより具体的にイメージできるようになって、進捗がずるずると遅れているようにみえるということからは少し改善されるかもしれません。そして、テストケースのレビューと改善を続けていけば、やがてチームの開発の品質は少しずつ改善されていきます。
非常に重要なことは、完成の定義を守るということが開発者に求められているということが、この１行だけで十分に伝えられるということ。（もちろん、毎回、スプリント計画の時に、完成の定義はこれですとプロダクトオーナーと開発者が確認をします）そして、プロダクトオーナーは開発者にどうしても死守してもらいたいことがあるなら完成の定義（あるいは個別の内容としてプロダクトバックログの詳細）にしっかりと記載しなければならないことが認識できます。これは、「アジャイルだから適当にやっているんだろう」というのが大きな誤解であり、ではどうすればちゃんとやれるのか？というのをイメージすることになりますし、スクラムのレトロスペクティブで改善（「検査」と「適用」）を行う場合にも、完成の定義を更新すればよいのだという具体的なイメージが持てます。お互いに信頼して、改善できるというイメージが持てれば、次は、プロダクトバックログの記載方法だったり、スプリントレビューの内容だったりと、スクラム全体の改善にだんだんと取り組むことができるようになります。
Azure DevOps では完成の定義を、バックログのカンバンボードに表示することができます。
かんばんボードでの完了の定義 – Azure Boards | Microsoft Docs
ただこれはちょっとわかりづらくて（iアイコンを押さないと表示されない）、変更の管理もできないため、Wiki や Markdown README としてAzure DevOpsの最初に表示されるページに記載してもよいと思います。
完成の定義はチーム全体で１つのリストを持っていて、スプリントごとに、レトロスペクティブで更新（改善）し、スプリントプランニングでプロダクトオーナーと開発者が合意して、スプリントを開始します。
もし、プロダクトバックログに固有の受け入れ条件がある場合には、プロダクトバックログのアイテム内に記載します。
（2021年11月20日 誤字脱字修正）
コメント
