完了の定義テンプレート

Definition of Done（DoD）テンプレートとは？

Definition of Done（DoD）テンプレートは、ユーザーストーリーやタスクが「完了」と見なされる前に満たすべき技術的・機能的基準を網羅したチェックリストです。各ストーリーごとに固有の「受け入れ基準」とは異なり、DoD はすべての作業項目に適用される共通の基準です。スピードを優先してテスト、ドキュメント、コンプライアンスを省略しないようにして、「技術的負債」を防ぎます。

「品質」監査：リリース可能な基準を徹底する 3 つの方法

DoD の有効性はチームの規律に左右されます。テンプレートを確定する前に、次の 3 つの専門的な健全性チェックを行ってください：

1. 「未完了の作業」監査

監査：ストーリーを「Done」に移動して、ドキュメントや統合テストを「次のスプリント」に回していませんか？ 対処：品質の先送りを監査してください。適切な DoD には、回帰テストとドキュメントの更新が含まれている必要があります。システム全体に対して文書化され、テストされていないものは「Done」ではなく、単に「Developed」に過ぎません。テンプレートには「新たな技術的負債を発生させないこと」を要件として明記してください。

2. 「自動化による検証」テスト

監査: あなたの DoD は "human promises"（例: "I checked the code"）に基づいていませんか？ 対策:二値検証 を監査してください。可能な限り、手動チェックを自動化されたチェックに置き換えましょう。"Code is reviewed" の代わりに "Pull Request approved by 2 peers." を、"Unit tested" の代わりに "Unit test coverage > 80%." を使います。これにより主観性が排除され、"Done" の状態が測定可能で議論の余地がなくなります。

3. "Global vs. Local" の対立

監査：DoD が長すぎて、チームがスプリント目標を達成するためにその半分を無視していませんか？ 対処法：現実に即した監査を行う。まずは「最小限の実用的な DoD」から始め、チームが成熟するにつれて拡張していきましょう。チームが現実的に毎スプリントで完全なセキュリティー監査を実施できない場合、それをストーリー単位の DoD に入れないでください。代わりに「リリースの定義」に移してください。これにより、日々の DoD が達成可能で守られるものになります。

戦略的フレームワーク： 「完了」の 3 つのレベル

プロフェッショナルな組織では、完了の各段階を管理するために、3 つの異なるテンプレートを使用することがよくあります：

• レベル 1: ユーザーストーリーの DoD（スプリントレベル）

  • 重点：コードの品質、ピアレビュー、特定の受け入れ基準を満たすこと。

  • 例：単体テストが通っている、プロダクトオーナー（PO）が承認している、機能テストが通っている。

• レベル 2: スプリント/機能の DoD（インテグレーションレベル）

  • 重点：機能がアプリ全体とどのように連携するか。

  • 例：回帰バグがない、パフォーマンス指標が安定している、ステージング環境が更新されている。

• レベル 3: リリースの DoD（マーケットレベル）

  • 重点：法務、マーケティング、セキュリティーのコンプライアンス。

  • 例：セキュリティーの侵入テストに合格している、翻訳が完了している、ユーザーマニュアルが更新されている。

完了の定義（DoD）テンプレートの主な構成要素

高いパフォーマンスを発揮する DoD には、次の5つのコアカテゴリが必要です:

• 開発基準: コードにコメントが付けられ、リファクタリングされ、メインブランチにコミットされている.

• テスト & 品質: ユニットテスト、統合テスト、手動の "スモークテスト" が完了し、すべて合格している.

• 環境 & DevOps: コードがステージング環境にデプロイされ、ビルドパイプラインを通過している.

• レビュー & 承認: ピアレビューが完了し、プロダクトオーナー (PO) が機能を承認している.

• 非機能要件: 機能が速度、アクセシビリティー、セキュリティーに関する具体的なベンチマークを満たしている.