完了の定義について問い合わせが多いので書いておこう。
英語では、”Definition of Done” とか、”Done Done” と言われる。日英ミックスで「Doneの定義」と言われることもある。
外国人と仕事していると”Everything’s done!”等、頻繁に耳にする言葉だが、一般的にはステーキを注文する際、お肉の焼き加減を伝えるときに”Well-done”と伝える位だろうか。
プロダクトマネジメント、とりわけスクラムでは、「完了の定義」はマストである。そして完了の定義は開発者のものである。
字面の通り、何をどこまでやったら「完了」なのか明確化しておくために定義する。
プロダクトインクリメントは開発メンバーが共同して作り上げる。
チームとして仕上げる条件を決めておかないと仕事のできばえにバラツキがでる。同一プロダクトなのに部分部分でムラがでるとやっかいだ。だから、開発チーム全員で何をどこまでしたら「完了」とするのか定めて、徹底する。
完了の定義を理解するポイントは3つある。
① 「完了の定義」と「受入基準」の違いを正しく理解する
② 「受入基準」を満たさないと「完了」できないことを理解する
③ 「完了の定義」を３つのレベルの「完了」に分解する
順番に見ていこう。
① 「完了の定義」と「受入基準」の違いを正しく理解する
「完了の定義」は、開発者の視点で作業が完了したことを意味する。作り手の視点で、ここまでやりますと決めて、そのレベルまで仕上げるコミットメントだ。
これは開発チーム全員で共有する。最終的に一つのプロダクトに統合するわけだから、仕上げレベルにムラがあるとやり直しが発生してしまう。
一方、「受入基準」はプロダクトオーナーが定義する。
何をどこまで作ったらお客様に届けられるとか、現場で使ってもらえるという目指す水準だ。
受入基準は、要求毎に異なる。
例えば、社内スタッフ向け画面であれば、わかりさえすればいい。だが、社外向けのユーザーインターフェースなら、カラフルで洗練されたデザインで会社ロゴも表示される等、求められる水準（受入基準）が厳しくなる。
「完了の定義」は開発チームで共有し、開発者自ら定義する。そして、同一プロダクトなら、ユーザーストーリーに関わらず一律同じである。
「受入基準」は利用者代表としてPOが定義する。こちらはユーザーストーリー毎に異なる。
続いて二つめ。
② 「受入基準」を満たさないと「完了」できないことを理解する
「完了の定義」と「受入基準」が異なることはわかった。でも、開発者とプロダクトオーナーがそれぞれ好き勝手に、定義や基準を決めて進めてよい訳ではない。
当たり前だが、POが求める水準でプロダクトを作らないと完了とは見なされない。受入基準を満たさない限り、永遠に仕掛品なのである。「受入基準」と「完了の定義」両方を満たさなくてはならない。
２つの関係は3パターンあるが、1番効率のいいのはイコールの関係だ。
- パターン１
受入基準 > 完了の定義 ：求められる水準を満たしていない為、リリースできない。 - パターン２
受入基準 = 完了の定義 ：ニーズにマッチしているので、リリースできる。 - パターン３
受入基準 < 完了の定義 ：求められる水準以上なので、当然リリースできる。
※プレミアム感を求める顧客に対する訴求効果があり、競合するプロダクトとの差別化に繋がるならメリットがある。単なる金メッキだと時間とお金のムダ。
最後に３つめ。
③ 「完了の定義」を３つのレベルの「完了」に分解する
「完了の定義」と「受入基準」が違うことはわかった。そして、これら両方とも満たさないといけないことも理解した。では、いよいよ完了に向けての実装の話になるが、これがなかなかムズカシイ。
スプリントは通常2週間だ。営業日にして10日。顧客の求める機能要件だけでなく、品質要件も含めて実装するのだからそうたやすいことではない。特に、新しいチームにはハードルが高いだろう。
もちろん要求をコンパクトにスライスして、細分化することで高品質なインクリメントの実装を目指すわけだが、新しいチームだと、要求の的確なサイジングのコツ自体掴んでいないこともある。そうなると、10日後に外部のお客様に自信満々でインクリメントを展開するのは非現実的だ。
そこで、ファイナルの完了の定義の前に、2つの内部の完成の定義を設けて、徐々に完成度を高めていく方法をとる。
完了の定義を基本的なものから順に：
1．「ユーザーストーリー」レベルの完了の定義
2．「スプリント」レベルの完了の定義
3．「リリース」レベルの完了の定義
に分ける。そして順にクリアしていく。
例えばこうだ。
ユーザーストーリーの完了：
・コーディングとリファクタリング完了
・単体テスト完了
・ピアレビュー
・QAレビュー
・簡素な文書化
・POによる受入テストに合格（受入基準を満たす）
※ 非公式なデモを通して一次フィードバックを獲得する。
スプリントの完了：
・パフォーマンステスト完了
・主要な不具合の100％解消（軽微なバグは残っていてもよい）
・ユニットテストのコードカバレッジ80％以上
・文書化70％完了
※ 公式なデモを通して、PO以外の利害関係者からもフィードバックを募る。
リリースの完了：
・利害関係者による公式受入テストに合格（受入基準を満たす）
・パフォーマンステスト完了
・不具合100％解消
・文書化100％完了
・障害発生時のリカバリーフロー完成
・組織で定義されたリリースゲートチェックに合格
※ 顧客に自信を持って届けられる高品質な完成品であること。
何度も言うが、理想は一つのスプリントで全て完結してリリースできることである。
だが、チームの実装能力、組織のガバナンス、顧客の期待値等考慮すると、一度のスプリントでそれら全てを満たすプロダクトインクリメントを展開していくことが困難な事もあるだろう。そんな時は、完成の定義を3分割して、それぞれの完成条件を満たしながら、段階的にレベルアップしていく。
ポイントは3分割しながらも、各レベルで一通り作り込んでいくことだ。各レベルで作ってテストして文書も書くのである。そしてこのサイクルを繰り返すことでもりもり改善していくのである。
ストーリーが完了したら、POに使ってもらいフィードバックを募る。次に、社内のパワーユーザーや主要顧客に近い担当者に厳しい目でチェックしてもらい、改善する。
最終完了レベルのリリース時点では、プロダクトを自信満々でお客様に届けることができる。
プロダクトマネジメントの要諦 The Rules of the Game of Product Management 