完了の定義

完了の定義とは、作業が完了したとみなされる前に満たされなければならない条件を、共有された明確な記述のことです。個々の項目に固有の受け入れ基準とは異なり、完了の定義はチームが作成するすべての成果物に一律に適用され、チームが自らに課す品質基準を明示します。

その目的は、完全性を客観的かつ一貫性のあるものにすることです。完全性の定義がなければ、完了とは個々の開発者が理解した意味合いに左右され、時間的制約や誰に依頼するかによっても異なります。ある人にとっての完了とは、テスト、ドキュメント作成、アクセシビリティチェック、デプロイを含みますが、別の人にとっては、自分のマシンでコードがコンパイルされることを意味します。こうした差異は、結果が表面化するまで目に見えません。通常は、遅れて発見された欠陥や、出荷前に再検討が必要な作業として現れます。

一般的な定義では、コードレビューの完了、合意された基準での自動テストの網羅、すべてのテストの合格、アクセシビリティ要件の充足、ドキュメントの更新、セキュリティに関する考慮事項への対応、定義されたしきい値内でのパフォーマンス、そして少なくともステージング環境へのデプロイが含まれます。具体的な内容よりも、それらが合意され、文書化され、理想論ではなく実際に適用されることの方が重要です。

最も重要な機能は、隠れた作業が静かに蓄積されるのを防ぐことです。テスト、ドキュメント作成、アクセシビリティ対策が行われていない状態で完了とマークされた項目は、一見進捗しているように見えますが、実際には後日、通常はより悪い状況下で履行しなければならない義務を生み出します。このようなバックログを蓄積しながらも着実に成果を上げていると報告しているチームは、幻想を報告しているに過ぎず、数か月後に説明のつかない作業の遅延という形でそのツケが回ってきます。

また、品質が最も重要であり、同時に最も放棄されやすいプレッシャーのかかる状況下でも品質を守ることができます。締め切りが近づくと、基準を緩和しようとするプレッシャーは強まり、緩和が明確に示されることは稀です。単に一部を省略した状態で完了とマークされるだけです。定義を譲れないものとして扱い、スケジュールが脅かされたときに範囲を縮小するという規律こそが、真のスピードで作業を進めるチームと、将来の進捗状況を借りて報告しているチームを区別するものです。

定義は一度設定するのではなく、能力の向上に合わせて進化させるべきです。自動展開機能を持たないチームは、最初は定義を含めることはできませんが、機能が実装されたら追加すべきです。定義を定期的に（通常は振り返りの場で）見直し、プラクティスが成熟するにつれて基準を引き上げることで、静的なチェックリストではなく、意図的な改善のための仕組みへと変化させることができます。

また、その定義は達成可能なものでなければならない。なぜなら、チームが通常の状況下で満たせない基準は、公然と再交渉されるのではなく、ひっそりと無視されることになるからだ。そして、無視された定義は、控えめな定義よりも悪い。なぜなら、共通の基準が完全に失われてしまうからである。チームが真に維持できるレベルに設定し、能力の向上に合わせて意図的に引き上げていくことで、実際に行動を律する基準が生まれる。

作業がどうしても基準を満たせない場合、完了の定義を変更するのではなく、例外事項を明確に記録することが誠実な対応です。特定のチェックを行わずに出荷し、その理由を明示し、是正措置を追跡することは、適切な判断と言えます。一方、同じ項目を完了済みとマークしながら、その見落としを記録しないのは、誰も同意しておらず、誰も覚えていない技術的負債となります。

定義によって品質が実際に何を意味するかが決まるから、納品チームだけでなく、結果に責任を負う人々の同意も必要となる。実際には、それは以下のように確立される。 製品開発 アクセシビリティとエクスペリエンスの基準は UX監査 基準とパフォーマンス閾値 Webパフォーマンス 予算を組み込むことで、基準が機能的な義務だけでなく、義務全体を反映するようにする。