【この記事には画像・図解を追記する予定です。ひとまずは第一版で文書だけで公開します。】
みなさん、アジャイルしてますか？今回はチーム開発で気付いたちょっとした個人的な備忘録を書き留めておこうと思います。
日本語の解説書などでは、常々受入基準は「スクラム用語」であると解説されがちですが、スクラムガイド原典には受入条件という単語はありません。では、スクラム開発において「受入条件」はどう扱うべきでしょうか。
注：この記事は個人的なアジャイル開発宣言及びスクラムガイドの解釈であり、全てのチームにおける汎用的なアジャイル開発及びスクラム開発の解となる訳ではないと思っています。プロジェクトチームの性質（受託開発・自社開発・OSSチームなど）によっても柔軟に解釈を変える必要があると思います。
そもそもスクラムとは
そもそもスクラム開発とは、アジャイル開発における1フレームワークの位置づけだと思っています。ではアジャイル開発はなにか、となれば、開発モデルの1つであり、別種のものにはウォーターフォール開発が存在します。
ということは、スクラム開発はアジャイル開発の1分野であるということになります。
完成の定義(DoD)と受入条件(Acceptance Criteria, A/C)
では、スクラム開発チームが完成の定義（DoD）及び受入条件（A/C）という単語に直面したとき、どう扱うべきでしょうか。
完成の定義（DoD）
まず、着目するべきは完成の定義（DoD）です。完成の定義は受入条件（A/C）とことなり、スクラム開発の教典たるスクラムガイドに記述があるからです。スクラムガイド（2020）によれば、完成の定義は以下の様に記述されています。
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
(中略)
インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある。
スクラムガイド（2020）日本語版
つまり、完成の定義はそれぞれのタスクがどのような状態になれば完成といえるのか、ある種品質担保の為のルールということになります。具体的には、以下の様なものが挙げられると思います。
- チーム査読
- テストカバレッジ
- ユーザ受入テスト（UAT）のパス
- セキュリティ担当者による査読
- 内部及び外部ドキュメントの整備
この例を見てみると、完成の定義はPBIを問わず、全てのPBIにおいて共通に定められるべきだと言うことが分かります。
受入条件（A/C）
一方で受入条件（A/C）とは何でしょうか。スクラム開発では受入基準、受入要件など様々な呼ばれ方をしますが、要するに開発における「要件」がこれにあたります。ウォーターフォール開発でも受入条件や、ユーザ受入項目、必須要件などと呼ばれているものがこれにあたります。
通常、要件は最上流工程あるいは上流工程によって行われ、多くはPMやSEによって担当されます。受託開発であれば、ベンダやメーカに「見積もりお願いします～」と伝えるときにどういったシステムにしたいか伝えたり、自社開発であれば企画チームから開発チームへ「こんなシステム欲しいんだけど～」と依頼が来た際に上層組織の意思決定によって定められます。
スクラム開発においては、チームメンバにSE（システムエンジニア）、PG（プログラマ・コーダ）、DB（デバッガ）といった種別をもうけないか、全員がPG、DBの兼任であることが一般です。その為、ウォーターフォールにおいては上流工程で決まりがちな（そして逆流することがない）工程が一つのスプリント（あるいは一定のスクラム開発フロー）の中で外で決まったり内側で決まったりします。
チームメンバがPO（プロダクトオーナ）、SM（スクラムマスタ）のぞいてPG,DBの兼任であるチームの場合においては、受入条件はすでにスクラムチーム外で決まるので受入基準（A/C）はある種絶対的な機能要件となります。
一方で、チームメンバがウォーターフォールにおける上流工程から下流工程までをこなすような全能的メンバの場合、スクラムチーム内で受入基準をPOやステークホルダと交渉したり、POとステークホルダの交渉においてオブザーバとして参加することがあります。つまりスクラム開発の一連の動きの中に受入条件の設定が含まれることとなります。
いずれの場合にも、受入条件（A/C）はPBIそれぞれに対してユニークな物であることがわかります。
完成の定義（DoD）と受入条件（A/C）の関わり合い
これは完全な私見ですが、日本語のスクラム解説書においては、完成の定義（DoD）と受入条件（A/C）は完全に別種のもので混ざり合うことはない、という解説が主になっているように思います。
しかしながらここは必ずしも別種と捉えなくてもよいのではないでしょうか。完成の定義（DoD）には、プロダクトの品質担保としてユーザ受入テスト（UAT）を加えることが一般的かと思います。では、ユーザ受入テスト（UAT）は単体で構成が可能なものでしょうか。いいえ、それは受入条件（A/C）あってのものだと思います。
PG,DB主体のチームにおいて
そこで、前述のチーム体制によっては柔軟に完成の定義（DoD）を捉えるべきです。例えば、チームメンバ全員がPG,DBの動きをするチームにあっては、完成の定義（DoD）を定める為に必要な受入条件（A/C）はPBI（プロダクトバックログアイテム）が追加されたときにすでに完全に決まっていることと思います。そのため、スクラムのフローから外して捉えることが出来、完成の定義（DoD）は受入条件（A/C）と別種と捉えても大きな支障が起こることはないでしょう。（もちろん同種のものと捉えても違和感はないはずです）
よりアジャイル的なチームにおいて
一方で、全員が上流工程から下流工程まで一貫して行うメンバの場合はどうでしょうか。スクラムチームにPBIを追加しようとするとき、要件は定まりきっておらず要求や単なるユーザストーリの状態を逸しないものも多いと思います。その場合は完成の定義（DoD）がいかに不変なものであったとしてもPBIが完成されているとは言えないのではないでしょうか。ユーザ受入テスト（UAT）の実施項目たる受入条件（A/C）が定まっていないからです。つまり、スクラムをうまく回すために、スプリントプランニングなどにおけるリファインメント活動において完全なPBI*の必須要件である完成の定義（DoD）の一部分として受入条件（A/C）を捉えるべきです。その方がスプリントレビュやインクリメントのデリバの段階でのステークホルダやPOとの認識齟齬に起因する出戻りを防ぎやすいはずです。受入条件（A/C）はPBIの抽象度を下げる大事な要素の一部であるからこそ、完成の定義（DoD）に含め、ユーザ受入テスト（UAT）や検証のための要素とするべきです。
*完全なPBI: スプリントゴールにする事が出来るほど抽象度が下がっているリファインメント済みのバックログアイテム（つまり要件定義、メンバアサイン、見積もりが済んでいるということ）
外部記事の紹介
これら完成の定義（DoD）と受入条件（A/C）の関わり合いが上手に解説されている外部記事も併せて紹介しておきます。
アジャイル開発での品質保証 ～成功の鍵～ , 株式会社NTTデータ, DATA INSIGHT, 町田 欣史, 2020, https://www.nttdata.com/jp/ja/data-insight/2020/102201/
この記事では、ウォーターフォールモデルとの対比としてのアジャイル開発が解説されており、品質管理としての手法の完成の定義（DoD）と受入条件（A/C）が示されています。
DONE Understanding Of The Definition Of “Done”, Agilemania, Scrum.org, Sumeet Madan, 2019, https://www.scrum.org/resources/blog/done-understanding-definition-done
この記事では、完成の定義（DoD）に受入条件（A/C）を含めた完成の定義（DoD）の解説を行ってあります。ユーザストーリと受入条件（A/C）の関連の理解に役に立つと思います。
ユーザストーリがより抽象度が高く、受入条件（A/C）がより抽象度が低いことがわかります。また、DoDには All A/C met を含めるべきとの記述もあります。
いろいろ書いたけれど結論は。
筆者は常々スクラムチーム内で吹聴しているのですが、スクラム開発はスクラムガイドに則り、アジャイル開発宣言を尊重する限りにおいては自由にやって良いのです。
あまり言葉の定義や「こうあるべき」といったセオリーの追求にこだわりすぎず、チーム内で快適にスクラムを回す事に注力するべきです。もちろん、言葉の定義が障害でスクラムがうまく回らないなら議論する有用性は十二分にあるともおもいます。