完成の定義

完成の定義とは？

完成の定義（Definition of Done、DoD）は、ユーザーストーリーやタスクが「完了した」と見なすために満たすべき基準をまとめたチェックリストです。 品質基準、テスト要件、ドキュメント、セキュリティレビューなど、複数の項目を組み合わせています。チーム全体が「完成」の意味を同じように理解できるようにする仕組みです。

ひとことで言うと： 宿題が「終わった」ことを証明するために「提出書類も確認した」「見直しもした」「先生に確認もらった」というチェックリストを用意するのと同じように、開発でも「何をもって完成とするか」を事前に決めておく仕組みです。

ポイントまとめ：

• 何をするものか： チーム全体で「完成」の基準を統一するドキュメント
• なぜ必要か： 品質のばらつきを防ぎ、出荷可能な成果物を確保するため
• 誰が使うか： 開発チーム、スクラムマスター、プロダクトオーナー

なぜ重要か

完成の定義がなければ、開発者ごと、プロジェクトごとに「完成」の解釈が異なります。ある開発者は「コードが書き終わった」で完成と考え、別の開発者は「テストも済ませた」まで含めて考えるでしょう。この曖昧さにより、品質にばらつきが生まれ、本番環境でバグが発見されるリスクが高まります。

完成の定義を明確にすることで、全員が同じゴールに向かって仕事ができます。また、見積もりの精度が上がり、スプリント中に「本当に終わったのか」という議論を減らすことができます。さらに、新しいチームメンバーがオンボーディングする際の学習資料にもなります。

仕組みをわかりやすく解説

完成の定義は一般的に、技術的な側面とビジネス的な側面の両方を含みます。技術的な側面には、コードレビュー、ユニットテスト、統合テスト、ドキュメント作成などが含まれます。ビジネス的な側面には、受け入れ基準の確認、ステークホルダーの承認、パフォーマンス確認などが含まれます。

典型的な完成の定義には以下の要素が含まれます。コード品質：コードレビューを完了し、コーディング規約に従っていることを確認すること。テスト：ユニットテスト、統合テストが実行され、一定のカバレッジを達成していること。ドキュメント：技術ドキュメントやAPIドキュメントが更新されていること。統合確認：既存のシステムと正常に統合できることを確認すること。これら全てを確認してから、初めてタスクを「完成」と見なします。

チームが初めて完成の定義を作る場合は、シンプルなもので始めることが重要です。「コードレビュー完了」「テスト完了」といった3～5個の項目から始めて、チームが成熟するにつれて、パフォーマンステストやセキュリティレビューなど、より詳しい項目を追加していくアプローチが有効です。

実際の活用シーン

新機能の開発

例えば、「ユーザー登録機能を追加する」というストーリーを進める場合、完成の定義に従って進めます。開発者はコードを書いた後、コードレビューを受けます。その後、手動テストと自動テストを実行し、ログイン画面のUIドキュメントを更新します。セキュリティチームがパスワード保存の安全性を確認し、データベース管理者がマイグレーションを確認したら、初めて「完成」と見なします。

バグ修正

バグ修正でも同じプロセスを踏みます。問題を再現し、根本原因を特定して修正したら、その修正がバグを解決することを確認するテストを書きます。既存のテストに影響がないか確認し、コードレビューを受けて、本番環境にデプロイします。

ドキュメント更新

APIの仕様が変わった場合、コード変更だけでなく、ドキュメントの更新も完成の定義に含まれます。これにより、後から新しいメンバーがコードを読むときに、最新の情報に基づいて理解できるようになります。

メリットと注意点

完成の定義の最大のメリットは、品質の一貫性です。すべてのタスクが同じ基準で検査されるため、低品質なコードが本番環境に混ざる可能性を大幅に減らせます。また、見積もりがより正確になります。完成に何が必要かが明確なため、開発者は現実的な時間を見積もれるようになります。

一方、完成の定義が厳しすぎると、チームの生産性が落ちる可能性があります。最初から完璧な自動テストやセキュリティレビューを要求すると、シンプルなバグ修正でも時間がかかりすぎます。そのため、完成の定義は定期的に見直し、チームの成熟度に合わせて調整することが大切です。

関連用語

• スクラム — 完成の定義はスクラムの重要な要素であり、スプリント中の透明性を確保するために使用されます
• ユーザーストーリー — 完成の定義は、ユーザーストーリーが本当に完了したかどうかを判断するための基準です
• スプリント — 各スプリント終了時に、完成の定義に照らして作業が本当に完了しているか確認します
• 受け入れ基準 — 個別タスクの要件ですが、完成の定義はすべてのタスクに共通の要件です
• コードレビュー — 完成の定義に含まれる重要なプロセスで、品質を確保します
• テスト駆動開発 — 完成の定義にテスト要件を含めることで、テスト駆動開発を促進します

よくある質問

Q: 完成の定義にセキュリティレビューを含めるべきですか？

A: 扱うデータの機密性によります。個人情報や決済情報を扱うシステムなら、セキュリティレビューを含めるべきです。社内ツールで機密データを扱わない場合は、簡略版を用意しても構いません。重要なのは、チーム全体で「どの機能はレビューが必要か」を事前に決めておくことです。

Q: 完成の定義を厳しくしすぎています。どうすればいいですか？

A: 段階的に見直すことをお勧めします。実装3ヶ月後、「実際にどの基準が役立っているか」をチームで振り返ります。使われていない基準は削除し、本当に必要な基準だけを残します。その上で、チームの生産性と品質のバランスを定期的に確認します。

Q: 新しいチームメンバーが完成の定義に従わない場合は？

A: 完成の定義は、チーム全体の合意に基づいたものです。新しいメンバーをオンボーディングする際には、「なぜこの基準が必要なのか」という背景を説明することが大切です。単に「ルール」として押しつけるのではなく、理由を理解してもらうことで、自発的に従うようになります。