我々は完成の定義によって何をしたいのか整理する
ありさん完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述で
ある。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。
完成の定義により、作業が完了してインクリメントの⼀部となったことが全員の共通認識とな
り、透明性が⽣み出される。プロダクトバックログアイテムが完成の定義を満たしていない場
合、リリースすることはできない。ましてやスプリントレビューで提⽰することもできない。
そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
インクリメントの完成の定義が組織の標準の⼀部となっている場合、すべてのスクラムチーム
は最低限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロ
ダクトに適した完成の定義を作成する必要がある。
開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場
合、共通の完成の定義を作成して、それに準拠する必要がある。
ありさん完成の定義は「品質」にかかわるドキュメントである。
品質は、荒ぶる四天王（※アジャイルサムライより）の一角であり、アジャイル開発あるいはスクラムというフレームワークにおいては QCD を固定して S(スコープ) を調整するのが一般的なイメージ。アジャイル開発の外部委託において準委任契約が前提とされていることもそうした理由からだと考える。
ありさんt_wada さんが公開されている下記の登壇資料も参考になります。
これらの資料では特に内部品質である保守性を中心に言及されている。
保守性を担保することでスピードは上がる。リードタイムが短くなりデプロイ頻度が上がる。
保守性、移植性（優れた設計と変更容易性）によりあらゆるレベルでの調整が可能になる。 ⇒ アジリティ
ありさんスクラムガイドに戻ると、完成の定義とはインクリメントに対する品質基準を定めたものでありリリース可否の決定に影響を与えるものである。より正確に言うとインクリメントが常にリリース可能な状態で保たれていることを保証するというもの。
- 品質を固定する ⇒ 完成の定義を満たすための作業を削ることはできない。見積りに含める。
- スコープを調整する ⇒ バックログアイテムを削る。バックログアイテムそれぞれのスコープを調整する。
あらゆるレベル（リリースサイクル、スプリント）で上記が当てはまる。
インクリメントが常に潜在的にリリース可能な品質状態を保っていることによって、リリース計画やさらにトップレベルの経営判断等に柔軟性を持たせることができる。完成の定義が完全であればリリースまでのリードタイムを限りなく圧縮できる。
完成の定義にはあらゆる品質特性の項目が含まれると考えている。
ありさん現実的にはキャパシティやチームの成熟度によって必要な品質基準を満たすための作業をスプリントに含められずリリーススプリント等を設けて対応することはある。
⇒ スプリントに含めない項目を Undone ワークとしその多寡によって完成の定義の強弱を表現したりする。
⇒リリース、スプリント、PBI のそれぞれの粒度でそれぞれ完成の定義を作ることもある。
Undone あるいはリリースの完成の定義としてスプリント内で完了させられない項目の存在はつまりインクリメントを実際にリリースするまでに必要なリードタイムとなりプロダクトのアジリティを測る指標になると言えると思います。
⇒ チームの成長により完全な完成の定義になればあらゆるレベル、タイミングでのリリースが可能
👇は納得感がありました。
スクラムの「完成の定義」はたったひとつ。「完成の定義」を全員で合意しよう
ありさん「スコープを優先し品質に不安の残るプロダクト」よりも、「スコープをある程度犠牲にするが品質の担保されたプロダクト」のほうがあらゆるレベルで調整、リスク管理がしやすい
⇒ 前者は技術的負債も蓄積しやすい。Undone の有無を除いてもリードタイムが大きくなりやすくリリース可能なアウトカムを生むことが難しい（最悪の場合、リリース可能なものが何もない期間が長期間続きビッグバンリリースと変わりなくなる）。
結果的には中長期的（リリースサイクルやビジネス的なサイクル）にみると品質を担保しながら進めるほうがスピードが上がる。
ありさんまとめ
「我々は完成の定義によって何をしたいのか」に対して、品質を担保したいということは前提として太字で書いたような内容に対してチーム内のマインドを作り上げるということがしたかったことではないかというまとめ
- 完成の定義とはプロダクトの品質基準を定めたもの
- 品質は調整不可なパラメータ、スコープで調整する
- 納期、コストを固定しスコープで調整する ⇒ 請負型の開発の場合には準委任契約が適当
- 完全な完成の定義に近づくほどリリースのリードタイムが小さくなる
- Undone の項目を列挙する（リリースの完成の定義のようにレベル分けした完成の定義を作成することを含む）ことでリリースまでの残作業、リードタイムが可視化される ⇒ これらを考慮した計画立て、調整が可能になる
- 品質を担保することが中長期的に見てスピードを上げる、スコープを広げることにつながることをチーム内の共通認識とすることが重要
- スプリントの作業見積りの段階で完成の定義を満たすための作業もはっきりと含めることが重要 ⇒ これが不明瞭であれば開発作業で時間が引き延ばされることが想定される
- 完成の定義を満たしていない PBI は Done にしない ⇒ 目先のベロシティを上げることは短期的なスピードアップに過ぎないということを共通認識とする