「このタスクは完了したか?」

一見単純なこの質問に答えるには、項目や製品のインクリメントが完了しているか、進行中であるかを確認する必要があります。しかし、チームとその関係者が、「完了」を明示的に定義していなければ、それは機能しません。

カンバンやスクラムのようなアジャイル・プロジェクト管理方式では、「完了」とは完了した項目を示す視覚的ボード上の右端の列を指します。DoD（完了の定義）を明確に定めることで、DevOps チームやスクラム・チームを含むアジャイル・チームが、より効率的に項目を完了できます。

このガイドでは、アジャイル手法での DoD の意味と、より効果的で価値のあるプロジェクトにするための DoD を作成する方法についてご説明します。

DoD は、製品のインクリメントが完了して顧客に提供できるとチームが判断するために、満たす必要のある一連の基準です。DoD とは、製品のインクリメントをリリースできる時期についての、チーム・メンバー間での共通認識です。インクリメントが大きく、多くの項目で構成されている場合も同様です。プロジェクトに対して「完了」の意味を明確に定義することで、アジャイル・チームはすべてのスプリントで価値を提供し、再作業を最小限に抑えることに集中できます。

「完了」の定義は、一人が作成するものではないことにご注意ください。そうではなく、開発者、テスター、製品所有者、その他の関係者を含むプロジェクト・チーム全体がその定義に合意します。これにより、全員が項目に完了のマークを付ける前のチェックリストとともに、DoD をガイドとして利用するため、スプリント時にプロセスを円滑に進められます。

「他のチームへの引き継ぎを扱う場合は、完了の定義に、もう一方のチームの成功に必要なことをすべて含めるようにしてください」と、アトラシアンの Modern Work Coach を務める Mark Cruth は語ります。「バリュー ストリームにおけるもう一方のチームと連携し、サポートするために DoD に何を含める必要があるかを確認します」

プロジェクトの DoD は、プロジェクトの種類と関与するチームによって異なります。次の DoD の例では、これらの定義がプロジェクトの種類によってどのように異なるかを示しています。

モバイル・アプリ開発プロジェクトでは、DoD には次のような例があります。

• すべての画像を圧縮した。

• すべてのコードを縮小・gzip 圧縮した。

ソフトウェア開発プロジェクトでは、DoD の基準には次のような例があります。

• すべてのコードを、単体、統合、エンドツーエンドの各テストによって徹底的にテストした。

• チームが製品のインクリメントをステージング環境にデプロイし、テストした。

一般的なプロジェクトでは、DoD の一部として次のような例があります。

• すべてのエラーが解決した。

• すべてのリリース・ドキュメントを作成・編集した。

DoD は、製品のインクリメントが完了する時期を定義する、高レベルの一連の基準です。これにより、成果物の品質と一貫性を確保します。チームは通常、スプリント終了時、製品のインクリメントの品質をチェックする際に DoD を利用します。

対照的に、DoR（準備完了の定義）は、低レベルの具体的な一連の基準であり、製品バックログ項目にのみ適用されます。DoR では、チームが次のスプリントで取り組むバックログ項目の準備が整う時期を定義します。チームは、スプリント開始時のバックログ・リファインメントのプロセスで DoR を利用します。

高品質の製品を提供するには、顧客が希望する DoD を設定することが不可欠です。項目に完了のマークを付け、製品のインクリメントに含める準備が整う時期を、DoD によって明確にするためです。適切に作成された DoD には次のようなメリットがあります。

品質の向上：すべての製品のインクリメントを DoD の基準と照らし合わせてチェックすることで、アジャイル・チームは製品開発全体を通して品質目標を考慮するようになります。これにより、チームがリリースに必要な品質基準を一貫して満たしていることを保証します。

リスクを最小限に抑える：DoD に従うことで、チームは項目を完了とマークする前に、従うべき基準を正確に把握しているため、再作業やそれに伴う遅延のリスクを最小限に抑えることができます。これにより、プロジェクトのあらゆる段階で品質が保証されます。

チームの連携を改善する：DoD は、プロジェクトの状況での「完了」という意味の共通認識であるため、チームはより容易に顧客の要件に集中し、すべてのスプリントで価値を提供できます。

進捗の測定：DoD を明確にすることで、チームは「完了」の基準を満たす製品のインクリメントの数を追跡できます。たとえば、スクラム指標にはベロシティが含まれます。ベロシティは、設定された期間内に 1 人が提供できる完成品の数を示します。

完了の定義を作成する正確な手順は、チームやプロジェクトによって異なりますが、プロセスは同様のパターンに従います。DoD を作成する手順は、次のとおりです。

1. 適切なチームと作業を行う

DoD の作成時は、適切なチーム・メンバーと協力することが重要です。決定した基準により、参加者全員の共通認識が形成されるためです。つまり、製品所有者、スクラム・マスター、スクラム・チームのメンバー、テスター、プロダクト・マネージャー、スポンサー、他の関連する関係者など、プロジェクトの「完了」を定義する方法について意見を述べる権利のある全員を含めます。

各チーム・メンバーはそれぞれの分野での知識をプロジェクトに持ち込み、その専門分野での合理的な基準について提案できます。不適切なチーム・メンバーがいる、または主要なチーム・メンバーを含めていない場合、DoD の基準が包括的でないために、標準以下の製品になる可能性があります。

2. 基準を確立する

「完了」を定義する上での最大のタスクは、チームがプロジェクトに利用する基準を確立することです。DoD の基準が完了した作業の品質に影響を与えるため、これを設定することは非常に重要です。

プロジェクトの各要素が完了したかどうかを、どのように把握するのでしょうか。この製品のインクリメントが完了したことを示す条件は何でしょうか。基準は、具体的、測定可能、達成可能で、関連性があり、期限が明確である必要があります。適切な基準を選択するには、チームは主に次の 2 つの質問に答えを出す必要があります。

1. 基準は十分に具体的であるか？曖昧（すべてのコードがテスト済み）にせず、具体的（すべてのコードが、単体、統合、エンドツーエンドの各テストで徹底的にテスト済み）にします。

2. 基準は顧客重視であるか？良い例としては、「すべてのドキュメントを作成・更新済み」です。これにより、エンド・ユーザーが製品を利用する際のガイダンスを見つけやすくなります。

「完了の定義は承認基準と同じではないことを覚えておいてください」と Cruth は説明しています。「DoD は、どのような一連のアクティビティが完了したらユーザー ストーリーを「完了」とみなすかについてのチームの考え (これには承認基準が含まれる場合もあります) を表しますが、ユーザー ストーリーが正しく実装されたと述べることとは異なります」

3. 完了チェックリストを作成する

DoD の基準は、大規模なプロジェクトに取り組むチームに適していると思われるかもしれませんが、より小さなタスク、課題、またはエラーに取り組むチームも、同じコンセプトを適用して、それほど広範囲ではない完了チェックリストを構築できます。すべてのタスクや課題に完了チェックリストがあれば、チームは一貫して質の高い作業を提供できます。

4. ユーザー・ストーリーに承認基準を割り当てる

AC（承認基準）とは、ユーザー・ストーリーが顧客に受け入れられるために満たす必要のある条件です。AC は製品のインクリメントではなく、ユーザー・ストーリーや機能に対応するため、DoD の基準とは異なります。

しかし、DoD と同様に、AC も合意を得た基準であり、ユーザー・ストーリーまたは個々のタスクが完了したかどうかを判断するためのものです。たとえば、「ユーザーが検索フィールドを利用して、探している製品を見つけられるようにする」というユーザー・ストーリーであれば、承認基準は次のようになります。

• 検索フィールドは上部のナビゲーション・バーにある。

• 「検索」ボタンをタップすると検索が始まる。

• 検索フィールドには、「何をお探しですか？」という、灰色のプレースホルダー・テキストがある。

5. DoD を修正・更新する

DoD は静的なドキュメントではありません。スプリント中に見つかったバグやエラーはどれも品質の問題であり、「完了」の定義が不明確なために生じた可能性があります。その場合、バグが再発しないように、DoD を更新することが重要です。

「完了の定義は生きたドキュメントであるべきです。つまり、作業について新しいことを学んだら、チームは DoD をアップデートする必要があります」と Cruth は付け加えます。「四半期ごとに DoD をレビューして、必要と思われる項目がすべて含まれているか確認することを検討してください」

スプリント・レビュー時に DoD を修正・更新して、プロジェクトとの関連性を保ちます。プロジェクトが発展し、チームが顧客の要件を詳しく学ぶにつれて、DoD を達成可能になるように修正する必要がある場合もあります。スプリント・レビューやバックログ・リファインメントのミーティング時に、チーム・メンバーが DoD への変更を提案できる機会を持つようにします。

Jira を使用すると、ソフトウェア・チームは「完了」の定義を簡単に作成できます。カスタム・フィールドを作成するか、拡張機能をダウンロードして、Jira 課題ごとにチェックリストを作成します。Jira 課題タイプをカスタマイズして、作業のタイプごとに異なる DoD を作成します。

Jira は、アジャイル計画からスプリント スタンドアップに至るまでのあらゆるプログラムとプロジェクト管理のニーズに対応するうえで、パフォーマンスの高い何百万ものアジャイル チームから信頼されています。ぜひ、無料でお試しください。

「完了」の定義を作成する責任者は誰ですか？

通常、スクラム・マスターが率いる開発チームが DoD を作成します。ただし、製品所有者、テスター、その他の関係者からの意見を求める必要があります。

完了の定義と承認基準の違いは何ですか？

DoD は、製品のインクリメントが完了したかどうかを判断するための高レベルの一連の基準です。DoD はすべての製品に適用され、製品の全体的な品質を定義します。

対照的に、承認基準は特定のユーザー・ストーリーや機能にのみ適用される低レベルの条件です。AC では、ユーザー・ストーリーが顧客に受け入れられるかどうかを定義します。DoD の例としては、「すべてのドキュメントを作成・更新済み」となります。AC の例としては、「ユーザー・ドキュメントへのリンクはナビゲーション・メニューからアクセス可能」となります。

「完了」の定義を作成するためのベスト・プラクティスはどのようなものがありますか？

チームと一緒に基準を定義する：DoD を定義するには、開発者、テスター、製品所有者、関連する関係者を含むチーム全体が関与して連携する必要があります。DoD を作成すると、製品のインクリメントの完了という意味について共通認識を持てるようになります。

常に見える状態にする：スプリント計画時や、製品バックログの項目の見積もりに関する話し合いの際に、DoD を利用可能で見える状態にしておきます。チームが DoD を定期的に参照できる必要があります。印刷して壁に貼るか、Wiki やプロジェクト計画に含めます。

実用的かつ現実的である：DoD とは、利用可能なリソースを使って時間枠内に達成できるものである必要があります。さらに重要なのは、顧客が実際に必要としているものに関連しているということです。