受け入れ基準と完成の定義、活用のポイントは？ ─ ”とはいえ”シリーズ #12「インクリメント編」（後編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第12回のテーマは「インクリメント」です。後編では、「完成の定義」のつくり方や「受け入れ基準」との違い、活用のポイントについてお話します。

前編はこちら

インクリメントってどんなもの？　できない時はどうすればいい？ ─ ”とはいえ”シリーズ #12「インクリメント編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにア…

redjourney.jp

完成の定義って、いつ つくるの？

新井：
最初のスプリントが始まる前には、ある程度のものをみんなで考えておけるといいですね。

ただ、最初から完璧なものをつくるのは難しいこともあると思います。
後から修正してもまったく問題はないので、そういう前提のもとでまずはつくってみて、ちょっとずつ足りなかったものを付け足すというやり方でいいんじゃないでしょうか。

中村：
私も同じ意見です。完成の定義がない状態でスプリントに取り組んでいくと、何回か繰り返すうちに、内部的な品質にバラつきが出てきます。

それが分かってから完成の定義をつくってもいいのですが、結構時間を無駄にしてしまうかなと思います。

新井：
一人一人「当たり前」は違うので、完成の定義がないと大体ズレてしまうんじゃないかな。
みんなの解釈が合っていることの方が稀じゃないでしょうか。

中村：
完成の定義って、言ってみれば言葉の持つ意味の認識合わせなので、何をつくるかとか、どうつくるかといった認識合わせと比較したら、相対的には簡単なはずなんですよ。

でも、完成の定義をつくろうとすると、大抵スムーズにはいかないんですよね。

簡単なはずの完成の定義ですら、みんなの認識を合わせるのは難しい。
だから、ソフトウェアづくりでもズレるのは当たり前なんです。

ズレるのが悪いわけではなく、みんなそれぞれに「思い込み」があることを前提に、どう思っているかを共有したり、意見交換をしたりしていくといいですね。

新井：
違和感を感じたら、「どういう解釈をしたの？」と、責めるわけじゃなく率直に会話をしていけるといいですよね。他のメンバーから異なる言葉で翻訳をされて腹落ちすることもあります。

妥協していいところと悪いところとか、お互いに思っていることがあるでしょうから、自分たちのプロダクトゴールを満たすためにはどうすればいいか、チームですり合わせることでいいものが出来上がるし品質も保たれると思います。

中村：
スクラムガイドには、「インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必要がある」と書いてあります。

組織の規模にもよりますけど、大体は組織としてこういうことを満たそうということが明示されていたり、暗黙の了解として存在したりします。
そういうのを活用してもいいと思うんですよね。

あるいは、今までどんな風に完成の定義を使っていたか、チームのメンバー同士で話してみるのもいいと思います。

「受け入れ基準」と「完成の定義」は使い分けた方がいい？

新井：
受け入れ基準の話は、スクラムガイドには特に出てこないですよね。

現場によって違うとは思いますが、多くの場合、個々のプロダクトバックログについて検査するには、完成の定義だけではカバーしきれないのではないでしょうか。

プロダクトオーナーが何を求めているのか、という辺りは、プロダクトバックログアイテムによって少しずつ違ってきますから、受け入れ基準やクライテリアのようなものを別途用意して品質を担保する方がいいですね。

とはいえ、すべてのプロダクトバックログアイテムに受け入れ基準が必要かというと、そういうわけでもなくて、個人的には、プロダクトや製品の品質、要望がきちんと形になればそれでいいんじゃないかなと思います。

中村：
完成の定義は、基本的にすべてのプロダクトバックログアイテムに共通するもので、それらが満たすべき内部的な品質について言及するものです。

例えば、コードレビューで二人が確認済みであるとか、静的エラーがないとか、ステージング環境にデプロイされているとか、マニュアルが最新化されているとか。

一方、受け入れ基準は、新井さんの言うように、個々のプロダクトバックログアイテムについての内容です。
ユーザー目線で見て、何ができる必要があるか、どうなっているのが良いか、といったことですね。

新井：
分かりやすい！

中村：
自分たちが自信を持って使ってもらえる品質の基準が完成の定義で、それをユーザーが「これができているとうれしいな」と思うかどうか、ユーザー目線での切り口が受け入れ基準とも言えます。

例えば、「テストコードのカバレッジが90％」ということなら、受け入れ基準というよりは完成の定義じゃないかなと思います。

混乱しがちなところではありますね。

参加者コメント：
完成の定義は共通で、受け入れ基準はアイテムごとに違うので、それぞれをフォーマットとして用意しているのですが、イメージとしては完成の定義の中に受け入れ基準があると捉えていました。

新井：
非エンジニアの人たちには、受け入れ基準という概念を説明するのがなかなか難しいですよね。
そういう概念のもとで仕事をしてこなかった方も多いと思うので…。

中村：
あまり馴染みがないチームでは、「受け入れ基準」「完成の定義」という言葉はあえて使わずに、「何ができたらユーザーは喜ぶか」「自分たちがこれでOKと言えるのは何か」という2つの項目をつくって考えていましたね。

参加者コメント：
ユーザーストーリーで書いていると、受け入れ基準が含まれている場合が多い気がします。

中村：
ユーザーストーリーはカードにすることが多いと思うのですが、カードの表面に「ユーザーがどうなったら喜ぶか」のストーリーを書いて、裏面には詳細な機能などの受け入れ基準を書くという方法を文献で見たことがあります。

受け入れ基準はユーザーストーリーの裏側というか、表裏になっているような気がします。