この記事は、Nichervan Fazelさんの「The Crucial Guide to “Definition of Done” in Scrum」を翻訳したものです。翻訳はNichervanさんの許諾をいただいています。誤訳、誤字脱字がありましたら、ご指摘ください。
はじめに
複雑なプロダクト開発の世界において、スクラムはチームが柔軟かつ反復的な方法で高品質なプロダクトを提供することを可能とする協力なフレームワークとして登場した。スクラムの礎のひとつとして「完了の定義（DoD: Definetion of Done）」がある。これは、開発プロセス全体を通じて一貫した品質と透明性を確保するためのカギを握る概念だ。
この記事では、スクラムにおける「完成の定義」の重要性を掘り下げ、その構成要素を探り、実例を通して現実世界での実践について解説する。
「完成の定義」がないと起こること（曖昧さの代償）
「完成の定義」が定義されていないままチームがプロダクト開発に着手するシナリオを想像してみてほしい。このような状況では、チームメンバーは完成度合いをそれぞれが自分なりに解釈してしまうため、品質レベルにばらつきが生じる。結果として期待に応えられないものとなる。モバイルアプリの開発を例にして考えてみよう。
- 一貫性のない品質
チームメンバーの中には、コア機能を実装したら自分のタスクは完了だと考える人もいれば、重要なエッジケースやエラー処理を省く人もいるかもしれない。その結果、アプリが予期せずクラッシュし、ユーザー体験（UX）が低下してしまうかもしれない。 - 未発見のバグ
テストの基準が明確に定義されていないことによって、テスト作業によりすべての潜在的なバグが発見に至らないかもしれない。その結果、重要な問題が隙間から漏れ出し、エンドユーザーに到達することでフラストレーションを引き起こし、信頼を損なうことになりかねない。 - ミスコミュニケーションとフラストレーション
統一した完成の定義がなければ、開発者とプロダクトオーナーを含めたステークホルダーは、何をもってタスクを完了したのか、それぞれが異なる期待値を持っているかもしれない。このズレは、フラストレーション、責任のなすり付け合い、チーム内の緊張関係に繋がってしまう。 - 予測不可能な進捗具合
明確な完成の定義がなければ、進捗を正確に計測することが困難となる。この曖昧さがプロジェクトのゴール達成までにどれだけの作業が残っているかを見積もるというチームの能力を妨げることとなる。 - 予測不可能な予測
明確な完成の定義がなければ、チームは次のスプリントでどれだけの作業を選択すべきかの予測を改善することができなくなる。
原文の箇条書きは数字だが、序列に明確な意図がないため変更してある
「完成の定義」の紐解き
完成の定義は、プロダクトバックログアイテム（PBI）が完成したとみなされる前に満たさなければならない包括的な品質の基準である。完成の定義は、スクラムチームのメンバー間で共通認識として機能し、期待値を合わせ、一貫した品質レベルを確保する役目を果たす。完成の定義には、プロダクトによっていくつかの側面がある。
- コーディング標準
すべてのコードは、あらかじめ定義されたコーディング標準に準拠し、一貫性と保守性を確保していなければならない。 - テスティング
バグを発見し、機能を検証するために、ユニットテスト、統合テスト、受け入れテストを含めた包括的なテストを実施しなければならない。 - ドキュメント
将来の理解と保守を手助けするために、ユーザーガイドやAPIドキュメントなどの必要なドキュメントを準備する必要がある。 - ピアレビュー
コードの変更は、問題を特定し、設計上の判断を検証し、全体的な品質を確保するために、ピアレビューを受ける。 - パフォーマンス
ソリューションは、事前に定義したパフォーマンスの基準を満たし、円滑で応答性の高いユーザー体験を保証すべきである。 - インテグレーション
新規の機能は既存のシステムにシームレスに統合されているべきである。 - ユーザーの受け入れ
完成した作業は、プロダクトオーナーあるいは指名されたステークホルダーの期待に沿うものであることを確認するためにレビューされ、承認されるべきだ。
原文の箇条書きは数字だが、序列に明確な意図がないため変更してある
よく練られた「完成の定義」のメリット
上記のリストは、ソフトウェア開発に携わるチームのほんの一例に過ぎない。プロダクトによって完成とみなされる前に満たされなければならない基準は異なるものだ。さらに、ソフトウェアでない場合は、完成の定義に含まれる独自の基準が含まれているだろう。
しっかりとした完成の定義を確立することは、スクラムチームとプロダクトの全体の両方に多くの恩恵をもたらす。
- 一貫性
完成の定義に対する共通理解が曖昧さを排除し、チーム全体の作業品質に一貫性をもたらす。 - 透明性
ステークホルダーは開発プロセスを明確に見通すことができ、合意済みのの基準に従い作業が完了していることに信頼を寄せることができる。 - 品質保証
徹底したテストとピアレビューによって、より質の高い成果物を作り、バグのリスクを低減させ、ユーザー体験を向上させる。 - 予測可能性
明確な完成の定義があれば、チームの作業予測性が向上し、進捗状況を追跡できるようになる。 - 継続的改善
チームは、時間経過とともに完成の定義を評価し、洗練し、新たな課題や進化するベストプラクティスに完成の定義を適応させることができる。
原文の箇条書きは数字だが、序列に明確な意図がないため変更してある
まとめ
結論として、完成の定義は、高い品質のプロダクトを一貫して提供すること確実にするスクラムにとって不可欠な要素である。明確な完了するための基準を定義することで、スクラムチームは曖昧さの落とし穴を回避でき、コミュニケーションを強化し、コラボレーションと卓越性の文化を作り上げることができる。よく練られた完成の定義を取り入れることで、チームは並外れた価値を提供し、ステークホルダーとエンドユーザーの両方の期待に答えることができるのだ。
本記事の翻訳者:
長沢 智治 – アジャイルストラテジスト
サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。
『More Effective Agile』、『Adaptive Code』、『今すぐ実践！カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。
Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。
