はじめに

この記事では、アジャイル開発における「Doneの定義（Definition of Done, DoD）」について記載していく。
Doneの定義をしない場合（もしくはチーム内で共有しない場合）どう言うことが起こるのか？
またプロジェクトの成功にどのような影響を与え、どのように決定すべきか例を交えながら記載していく。

まずはDoneの定義とは？

アジャイル開発における「Doneの定義（Definition of Done, DoD）」とは、成果物が「完了」と見なされるために満たすべき基準を明確化したチェックリストです。これにより、チーム内での認識を統一し、品質を担保しつつ手戻りを防ぎます

主な内容

チェックリスト例: 単体テストや結合テストの合格、コードレビュー完了、非機能要件の達成など
メリット: 品質向上、透明性確保、リスク削減
注意点: 過剰な依存や不十分な検証の可能性

DoDは継続的に見直し改善する必要があります

「Doneの定義」がチーム内で共有されない場合に発生しうる問題

以下のような問題が発生することが考えられる。

品質のばらつき: 各メンバーが異なる基準で「完了」を判断するため、成果物の品質が一貫しない
手戻りの増加: 完了基準が曖昧だと、後から修正や追加作業が必要になることが多い
コミュニケーション不足: チーム内やステークホルダー間で期待値が一致せず、誤解や摩擦が生じる
スプリント計画の混乱: タスクの進捗状況が正確に把握できず、計画が崩れる

完了に認識が人によって異なることになるため、成果物であるアウトプットが対応する担当者によって異なることになる。

「Doneの定義（Definition of Done, DoD）」をした場合

「Doneの定義（Definition of Done, DoD）」はプロジェクトの成功に以下のような重要な影響を与えます：

品質の向上: 明確な基準により、成果物の一貫性と品質が担保されます
透明性の向上: チーム全員が進捗状況を正確に把握でき、コミュニケーションが円滑になります
リスクの軽減: 未完了作業（Undone）の発生を抑え、リリース遅延や手戻りを防ぎます
効率的なプロジェクト管理: タスク完了基準が明確化され、計画と実行がスムーズになります

先ほどの項目では「Doneの定義」がチーム内で共有されない場合の問題について記載したが、
この項目では逆に逆にDoneの定義が明確であり、かつチーム内で正しく共有されていれば
誰が担当してもDoneの定義を満たしていれば成果物のアウトプットにブレは生じにくくなることになる。

特にスケジュールがタイトである場合は、Doneの定義が明確であることが非常に重要となる。
スケジュールギリギリの状態で作成されたアウトプットが、レビュアーや受け入れ担当者の意図したアウトプットと異なることを回避できる。

Doneの定義を作成する手順

Doneの定義を適切に設定することで、チームの生産性と成果物の品質を向上させることができます。
この項目では、Doneの定義を作成する手順について記載していく。

チーム全員で話し合う
- プロダクトオーナー、開発者、テスターなど、全員が参加する必要があります。
顧客に提供するために必要な作業を洗い出す
- 「プロダクトを顧客に届けるために何が必要か」を考えます。
- コーディング、テスト、ドキュメンテーションなど、あらゆる作業を含めます。
現実的に毎スプリントで実施可能な作業を選択する
- チームの能力と現状を考慮し、実現可能な項目を選びます
リストを作成し、合意を得る
- 選択した項目をリスト化し、チーム全員の合意を得ます。
定期的に見直し、改善する
- スプリントレトロスペクティブなどで定期的に見直し、必要に応じて更新します。

Doneの定義の具体例

以下は、一般的なDoneの定義の例です：

コーディング完了
- 機能が実装されている
- コードレビューが完了している
- コーディング規約に準拠している
テスト
- 単体テストが作成され、全てパスしている
- 結合テストが実施され、パスしている
- 受入テストが実施され、パスしている
ドキュメンテーション
- ユーザーマニュアルが更新されている
- API仕様書が更新されている
  ※いわゆるマスタードキュメントとなるドキュメンテーションを明確にする必要がある
品質
- パフォーマンス要件を満たしている
- セキュリティチェックが完了している
デプロイ
- 開発環境にデプロイされ、動作確認が完了している
- ステージング環境にデプロイする準備が整っている

Doneの定義を効果的に使用するためのヒント

具体的に記述する: 「テスト完了」ではなく、「全ての単体テストがパスし、結合テストが実施されている」のように具体的に記述します。
測定可能にする: 「高品質」ではなく、「コードカバレッジ80%以上」のように測定可能な基準を設定します（※定量的に記載可能な部分は可能な限り定量的に記載する）。
チーム全体で合意する: Doneの定義はチーム全体で合意し、全員が理解し遵守する必要があります。
可視化する: Doneの定義をタスクボードの近くに掲示するなど、常に参照できるようにします。
段階的に改善する: 最初から完璧なDoneの定義を作る必要はありません。徐々に改善していくことが重要です

Doneの定義を適切に設定し、活用することで、チームの生産性が向上し、高品質な成果物を継続的に提供することができます。定期的に見直し、改善することを忘れずに、チーム全体でDoneの定義を育てていきましょう。

Doneの定義を強化するためには？

以下のツールや方法が有効となる。

チェックリストの活用: 明確な基準をリスト化し、タスクごとに適用できるようにする
JiraやTrelloなどのツール: チェックリストやカスタムフィールドを活用し、各タスクに対するDoDを可視化
振り返り（レトロスペクティブ）: スプリント後にDoDを評価し、改善点を議論
ワークショップの実施: チーム全員でDoDを議論し、共通認識を形成
品質管理ツール: 自動テストやコードレビュー支援ツールで基準達成を確認

以上