「完了の定義」はチームの実力を表わすバロメーターである

プロダクトマネジメントにおいて、初めて「完了の定義」を導入する際のポイントは３つある。

①　完了条件が明確であること。
②　開発者全員が知っていること。
③　途中で変更しないこと。

順番に説明していこう。

①　完了条件が明確であること
「完了した」か、「完了していない」か、そのどちらかしかない。

イエスか、ノーか
○か×か
合格か不合格か

「90％完了」は完了していないことと同じだ。
完了に向けての進捗率は関係ない。完了条件を100%満たしていなければ、すべて未完成である。

「完了の定義」は曖昧であってはならない。「ほぼ完了」とか「たぶん完了」ではダメだ。
完了基準のひとつひとつに、明快なチェックリストが作れるかどうかが一つの目安だ。
チーム全員にとって、客観的に判断できる基準であること。

②　開発者全員が知っていること
完了条件は、開発者全員が知っていなくてはならない。
開発者は、全員で協業してプロダクトインクリメントを作る。
同じプロダクトなんだから、メンバー全員が同じ認識で作り込んでいかないと、仕上がりにムラが出る。

「完了の定義」はチームのルールだ。開発メンバー全員が、どこまでできたらコードベースにチェックインできるかわかっていて、徹底できないと、一貫性のあるプロダクトにならない。

「完了の定義」はプロダクト単位で共通だ。
複数チームで開発しているなら「完了の定義」は全チームで共有する。

③　途中で変更しないこと
「完了の定義」は、開発メンバーが目指す「共通ゴール」である。
何をどこまで作れば「完了」するかわかるから、作業規模を見積もれる。
完了条件が固定だから、スプリント計画会議で、これから実装するバックログのタスクが洗い出せるのである。

更に「完了の定義」があることで安心して作業に専念できる。
何をどこまで作れば「完了」かわかるから、顧客に出すまで不安なこともない。どこまで作り込めば満点取れるかわかるから安心である。

完了条件（完了の定義）が途中で変更されると、やり直さないといけないし、作業規模も見直さなくてはならないから、ややこしくなる。

また、スプリント終盤で完了条件を下げるチームをたまに見かけるが、これは絶対にしてはいけない。
ハードルを低くすることで「完了」に持って行くと、プロダクトオーナーとあらかじめ合意した品質基準（受入基準）が満たせなくなる。
ごまかしの完成品は、当然受け入れられない。

そもそも「完了の定義」は開発チームが自ら決めたコミットメントだ。
プロフェッショナルとして、品質を作り込もう。チームで決めた「完了の定義」を全うしよう。

繰り返しになるが、プロダクトマネジメントで、初めて「完了の定義」を設ける際、以下の3つのポイントを守ろう。

誰の目にも明らかである
全員が理解していて守れる
スプリント途中で変えない

「完了の定義」は、チームの成熟度によって拡張していく。
日々の作業を通して、チームのコミュニケーションとコラボレーションは浸透していく。
スプリント毎にふりかえりを実施し、継続的に改善していくことで、チームのベロシティー（総合力）もあがっていく。
TDDやBDDの開発プラクティスを推進し、冗長なテストを自動化することで、開発チームの実装能力がモリモリついてくる。

チームの成熟度に伴い、更に高い「完了の定義」を目指そう。

同じ完成条件であれば、スピーディーに実装できるようになる。
顧客・市場リリースまでにかかる期間を短縮できれば、スプリント毎にリリースできるようになる。最終的に、スプリント中に頻繁にリリースできるようになる。

「完了の定義」はチームの実力を示すバロメーターである。

完了の定義がカンタンにわかる３つのポイント