仕事を進めていると、「終わったつもりだったのに、後から修正が出た」「担当者は完了と言っているが、確認者から見るとまだ不十分」「納品した後に、必要な確認が抜けていた」といった問題が起こることがあります。
このような問題の原因の一つは、「完了」の基準が人によって違うことです。
たとえば、資料作成であれば、担当者は「本文を書き終えたら完了」と考えているかもしれません。しかし、上司は「誤字確認、関係部署レビュー、体裁調整まで終わって完了」と考えているかもしれません。
システム開発でも、開発者は「コードを書き終えたら完了」と思っていても、チームとしては「テストが通り、レビューが終わり、ドキュメントも更新されて初めて完了」と考える必要があります。
そこで役立つのが、Definition of Doneです。
Definition of Doneは、日本語では「完了の定義」や「完了条件」と訳されます。作業や成果物について、「何を満たせば完了と言えるのか」を事前に明確にするためのフレームワークです。
特にScrumやアジャイル開発でよく使われますが、考え方自体は、資料作成、研修教材作成、業務改善、Web制作、営業資料、社内プロジェクトなど、さまざまな仕事に応用できます。
この記事でわかること
・Definition of Doneとは何か
・Definition of Doneは何に使うのか
・Definition of Doneの基本的な考え方
・Definition of Doneの使い方
・Definition of Doneの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「Definition of Doneは、何を満たせば完了と言えるかを明確にするための型だ」とつかめれば十分です。
Definition of Doneとは？
Definition of Doneとは、作業や成果物が「完了した」と言える条件を明確にしたものです。
英語のDefinition of Doneは、直訳すると「完了の定義」です。略してDoDと呼ばれることもあります。
仕事では、「終わった」という言葉がよく使われます。しかし、何をもって終わったとするかは、人によって違います。
たとえば、ブログ記事作成で考えてみます。
ある人は、本文を書き終えた時点で完了と考えるかもしれません。別の人は、タイトル、メタディスクリプション、タグ、画像、誤字確認、SEO確認、WordPress入稿まで終わって完了と考えるかもしれません。
この認識がずれていると、後から「まだ終わっていない」「確認が足りない」「公開できる状態ではない」といった問題が起こります。
Definition of Doneでは、こうしたズレを防ぐために、完了条件を事前に決めます。
たとえば、記事作成のDefinition of Doneは、次のようになります。
・タイトルが設定されている
・本文が完成している
・見出し構造が整っている
・誤字脱字を確認済み
・メタディスクリプションが設定されている
・タグが設定されている
・WordPressに貼り付けできる形式になっている
・最終確認者のレビューが完了している
初心者向けに言い換えるなら、Definition of Doneは「これを全部満たしたら完了と言える、というチェックリスト」です。
一言でいうと、Definition of Doneは作業や成果物の完了条件を明確にするためのフレームワークです。
Definition of Doneは何に使うのか
Definition of Doneは、作業の完了基準をそろえるために使います。
プロジェクトでは、担当者、確認者、承認者、利用者など、さまざまな人が関わります。それぞれが違う完了イメージを持っていると、手戻りや品質問題が発生しやすくなります。
Definition of Doneは次のような目的で使われます。
・完了の基準を明確にする
・担当者と確認者の認識ズレを防ぐ
・品質のばらつきを減らす
・手戻りを減らす
・レビューや承認をスムーズにする
・成果物の品質を安定させる
・チーム内の共通ルールを作る
・Scrumやアジャイルで成果物の完成基準をそろえる
たとえば、社内研修教材を作る場合、「スライドができたら完了」では不十分かもしれません。実際には、説明の分かりやすさ、誤字確認、法務確認、確認テスト、受講者向け案内、LMS掲載形式なども必要になることがあります。
Definition of Doneを決めておけば、「教材として公開できる状態とは何か」が明確になります。
また、作業中の判断も楽になります。担当者は、完了条件を見ながら作業すればよいため、何をどこまでやればよいか迷いにくくなります。
どんな人に向いているか
Definition of Doneは、成果物の品質や完了基準を明確にしたい人に向いています。
特に、次のような人におすすめです。
・チームで仕事を進めている人
・作業完了後の手戻りが多い人
・確認者と担当者の認識ズレに悩んでいる人
・成果物の品質を安定させたい人
・Scrumやアジャイルを実践している人
・レビューや承認の基準を明確にしたい人
・資料作成、教材作成、Web制作などを管理している人
・新人や外部委託先に作業を依頼する人
Definition of Doneは、IT開発だけのものではありません。
たとえば、営業資料作成、研修教材作成、ブログ記事作成、動画制作、契約書レビュー、業務マニュアル作成、Webページ公開、問い合わせ対応などにも使えます。
特に、「終わったはずなのに、毎回何かが抜けている」「担当者によって品質がばらつく」「完了報告を受けても、本当に終わっているか分からない」という場合に役立ちます。
Definition of Doneの基本的な考え方
Definition of Doneの基本は、「完了」を曖昧な言葉のままにしないことです。
仕事では、「完了しました」「できました」「終わりました」という言葉がよく使われます。しかし、その中身が明確でなければ、確認者は安心できません。
Definition of Doneでは、完了を判断するための条件を具体的にします。
条件は、できるだけ確認可能な形にします。
たとえば、次のような表現は曖昧です。
・きれいに仕上げる
・分かりやすくする
・問題ない状態にする
・ちゃんと確認する
これでは、人によって判断が変わります。
一方、次のように書くと確認しやすくなります。
・誤字脱字チェックを実施済み
・上司レビューが完了している
・確認テストが10問作成されている
・WordPressのH2、H3見出し構造が整っている
・リンク切れがないことを確認済み
・関係部署から承認を得ている
Definition of Doneで大切なのは、完了条件を「誰が見ても確認できる形」にすることです。
また、Definition of Doneは、作業ごとに細かく作る場合もあれば、チーム共通のルールとして作る場合もあります。
たとえば、開発チームでは「すべての機能に共通する完了条件」を設定することがあります。資料作成チームでは「社外提出資料の完了条件」を定めることもできます。
完了条件を決めることで、品質基準が明確になり、作業の抜け漏れを減らせます。
Definition of Doneの使い方
手順1 対象となる作業や成果物を決める
最初に、Definition of Doneを適用する対象を決めます。
すべての仕事に細かい完了条件を作る必要はありません。まずは、手戻りが多い作業、品質ばらつきが大きい成果物、関係者の確認が必要な仕事から始めると効果的です。
対象の例は次の通りです。
・Webページ公開
・ブログ記事作成
・社内研修教材作成
・営業資料作成
・システム機能開発
・問い合わせ対応
・業務マニュアル作成
・社内説明会の準備
・契約書レビュー
・動画教材制作
たとえば、社内研修教材を対象にするなら、「教材が完成した」と言える条件を決めます。
システム開発なら、「機能が完成した」と言える条件を決めます。
営業資料なら、「顧客に提出できる状態」と言える条件を決めます。
まずは、完了の認識ズレが起こりやすい作業から取り組むのがおすすめです。
手順2 現在の完了基準を洗い出す
次に、現在どのように「完了」を判断しているかを洗い出します。
多くの場合、完了基準は明文化されていません。担当者の経験や上司の感覚、過去の慣習に頼っていることがあります。
そこで、まずは関係者に確認します。
・今は何をもって完了としているか
・完了後にどんな手戻りが起きているか
・よく抜ける確認項目は何か
・確認者は何を見ているか
・利用者や顧客から指摘される点は何か
・過去に問題になったことは何か
たとえば、研修教材であれば、過去に次のような問題があったかもしれません。
・誤字脱字が残っていた
・確認テストが作られていなかった
・スライドの説明が難しすぎた
・受講時間が長すぎた
・LMS掲載形式に合っていなかった
・関係部署の確認が漏れていた
このような問題を洗い出すことで、Definition of Doneに入れるべき条件が見えてきます。
手順3 完了条件を具体的に書き出す
次に、完了条件を具体的に書き出します。
ここでは、できるだけ確認可能な条件にすることが重要です。
たとえば、社内研修教材のDefinition of Doneなら、次のように書けます。
・研修目的が明記されている
・対象者が明確になっている
・各章に学習目標がある
・スライド本文が完成している
・確認テストが作成されている
・誤字脱字チェックが完了している
・関係部署レビューが完了している
・受講時間が想定範囲内に収まっている
・LMSに掲載できる形式になっている
・受講後アンケートが用意されている
営業資料なら、次のようにできます。
・顧客課題が明確に書かれている
・提案内容が1ページ目で分かる
・価格や条件に誤りがない
・法務確認が必要な表現を確認済み
・商品名や商標表記が正しい
・社内承認が完了している
・PDF化して表示崩れがない
・提出先に合わせた宛名や日付になっている
このように、完了条件は「確認できる行動」や「満たすべき状態」として書くことが大切です。
手順4 関係者と合意する
完了条件を書き出したら、関係者と合意します。
Definition of Doneは、担当者だけで決めても十分ではありません。確認者、承認者、利用者、関係部署など、成果物に関わる人と認識を合わせる必要があります。
たとえば、担当者が「誤字チェックまでで完了」と考えていても、承認者が「法務確認まで終わって完了」と考えているなら、ズレが残ります。
合意するときに確認したいことは次の通りです。
・この条件を満たせば本当に完了と言えるか
・抜けている確認項目はないか
・条件が多すぎて現実的でないものはないか
・誰がどの条件を確認するか
・完了条件を満たせない場合はどう扱うか
・例外対応は必要か
Definition of Doneは、品質を高めるためのものですが、条件を増やしすぎると現場負担が大きくなります。
そのため、「必ず必要な条件」と「できれば望ましい条件」を分けることも有効です。
手順5 実際の作業で使い、見直す
最後に、Definition of Doneを実際の作業で使います。
完了報告をするときは、単に「終わりました」と言うのではなく、Definition of Doneを満たしているか確認します。
たとえば、次のように使います。
・完了条件をチェックリストとして確認する
・レビュー前に担当者が自己確認する
・承認者が確認するときの基準にする
・完了条件を満たしていないものは未完了として扱う
・手戻りがあった場合は条件を見直す
実際に使ってみると、条件が不足していたり、逆に細かすぎたりすることがあります。
たとえば、毎回同じ修正が発生するなら、その項目をDefinition of Doneに追加します。ほとんど使われない条件や負担が大きすぎる条件があれば、見直します。
Definition of Doneは、一度作って終わりではありません。チームの仕事や成果物の性質に合わせて改善していくことが大切です。
Definition of Doneの具体例
例 社内研修教材を作る場合
社内研修教材を作る場合のDefinition of Doneを考えてみます。
研修教材では、単にスライドを作るだけでは不十分です。受講者が理解できること、実務に使えること、確認テストがあること、公開できる形式になっていることなどが重要です。
たとえば、完了条件は次のようになります。
・研修の目的が明確に書かれている
・対象者が明確になっている
・各章の学習目標が設定されている
・スライド本文が完成している
・初心者にも分かる表現になっている
・実務で使える具体例が入っている
・確認テストが作成されている
・誤字脱字チェックが完了している
・専門部署の内容確認が完了している
・受講時間が想定範囲内に収まっている
・LMSに掲載できる形式になっている
・受講後アンケートが用意されている
このようなDefinition of Doneがあると、教材作成者は何を満たせば完成なのかが分かります。
また、確認者も同じ基準でレビューできます。
もしDefinition of Doneがなければ、担当者は「スライドができたので完了」と考えるかもしれません。しかし、実際には確認テストがなかったり、受講時間が長すぎたり、LMS形式に合っていなかったりする可能性があります。
Definition of Doneを決めておくことで、公開直前の手戻りを減らしやすくなります。
別の例 Webページを公開する場合
Webページ公開にもDefinition of Doneは有効です。
Webページの場合、本文を書いただけでは完了とは言えません。見出し、リンク、画像、SEO設定、表示確認、公開後確認など、さまざまな条件があります。
たとえば、完了条件は次のようになります。
・タイトルが設定されている
・タイトルタグが設定されている
・メタディスクリプションが設定されている
・H2、H3の見出し構造が整っている
・本文の誤字脱字チェックが完了している
・リンク切れがない
・画像の表示確認が完了している
・スマートフォン表示で崩れがない
・CTAが設置されている
・カテゴリとタグが設定されている
・プレビュー確認が完了している
・公開後に実ページを確認している
このような完了条件を決めておくと、「記事を書いたけれどSEO設定が抜けていた」「公開したらスマートフォンで崩れていた」「リンクが切れていた」といった問題を減らせます。
Webページは、作成者、編集者、確認者、公開担当者が分かれることもあります。Definition of Doneがあると、担当者間の引き継ぎもスムーズになります。
具体例でわかるポイント
Definition of Doneの具体例からわかるポイントは、次の通りです。
・完了の意味は人によって違う
・完了条件を明確にすると認識ズレを防げる
・チェックリスト化すると抜け漏れを減らしやすい
・担当者と確認者が同じ基準で判断できる
・成果物の品質が安定しやすい
・手戻りが多い作業ほど効果が大きい
Definition of Doneは、作業者を縛るためのものではありません。誰が担当しても、必要な品質を満たした状態で完了できるようにするための実務的なルールです。
Definition of Doneを使うメリット
Definition of Doneを使う最大のメリットは、「完了」の認識ズレを減らせることです。
仕事では、担当者が完了したと思っていても、確認者や利用者から見るとまだ不十分なことがあります。そのズレが、手戻り、品質問題、納期遅れの原因になります。
Definition of Doneを使うメリットは次の通りです。
・完了条件が明確になる
・担当者と確認者の認識がそろう
・品質のばらつきを減らせる
・手戻りを減らしやすい
・レビューや承認がスムーズになる
・新人や外部委託先にも依頼しやすくなる
・作業漏れを防ぎやすい
・チームの共通品質基準を作れる
・Scrumやアジャイルで成果物の完成度を安定させられる
特に実務で大きいのは、レビューの効率化です。
完了条件が曖昧だと、レビュー担当者は毎回細かい抜け漏れを指摘しなければなりません。Definition of Doneがあれば、担当者が事前に自己確認できるため、レビューではより本質的な内容に集中できます。
また、チームの教育にも役立ちます。新人や外部委託先に対して、「この条件を満たせば完了です」と伝えられるため、作業依頼がしやすくなります。
Definition of Doneを使うときの注意点
Definition of Doneは便利ですが、使い方を間違えると、単なる細かいチェックリストになってしまいます。
重要なのは、成果物の品質や目的に直結する条件を設定することです。何でも入れすぎると、確認作業が重くなり、現場で使われなくなります。
よくある失敗例は次の通りです。
・完了条件が曖昧なままになっている
・条件が多すぎて現実的に運用できない
・誰が確認するか決まっていない
・担当者だけで決めて、確認者と合意していない
・一度作った後に見直さない
・作業ごとの違いを無視して同じ条件を使い回す
・品質ではなく形式チェックだけになる
・完了条件を満たしていないのに完了扱いする
・例外対応のルールがない
・条件を守ること自体が目的化する
特に注意したいのは、Definition of Doneを厳しくしすぎることです。
完璧な条件を求めすぎると、作業が進まなくなります。重要なのは、目的に対して必要な品質を満たすことです。すべての作業に最高レベルの完了条件を求める必要はありません。
また、Definition of Doneはチームで合意して運用するものです。上司や管理者が一方的に条件を押し付けると、現場では形だけのチェックになりがちです。
実際に使いながら、「この条件は必要か」「この条件が抜けていたから手戻りしたのではないか」と見直すことが大切です。
関連フレームワークとの違い
Definition of Doneと似た場面で使われるフレームワークはいくつかあります。それぞれの違いを理解しておくと、プロジェクト管理や品質管理で使い分けしやすくなります。
Scrumとの違い
Scrumは、Product Backlog、Sprint、Review、Retrospectiveなどを使って、短いサイクルで成果物を作るフレームワークです。
Definition of Doneは、Scrumの中で成果物が完了したと言える条件を明確にするために使われます。
Scrumが仕事の進め方全体を示すフレームワークだとすれば、Definition of Doneはその中で「完成の基準」を定めるルールです。
Scrumは反復的な進行管理、Definition of Doneは完了基準の明確化に強いフレームワークです。
Acceptance Criteriaとの違い
Acceptance Criteriaは、日本語では「受け入れ条件」と訳されます。
Definition of Doneがチーム共通の完了条件であるのに対して、Acceptance Criteriaは個別の要件や機能が受け入れられる条件を示すものです。
たとえば、Definition of Doneは「テストが完了している」「レビューが終わっている」「ドキュメントが更新されている」といった共通条件です。
一方、Acceptance Criteriaは「ユーザーが正しいIDとパスワードを入力した場合、ログインできる」「必須項目が未入力の場合、エラーメッセージを表示する」といった個別機能の条件です。
Definition of Doneは共通の完了基準、Acceptance Criteriaは個別要件の受け入れ条件と考えると分かりやすいです。
チェックリストとの違い
チェックリストは、確認項目を一覧化したものです。
Definition of Doneもチェックリストの形で運用されることが多いですが、単なる確認リストではありません。
Definition of Doneは、「完了」と判断するための共通基準です。つまり、チェックリストよりも、チームやプロジェクトにおける品質基準としての意味が強いです。
チェックリストは確認作業の道具、Definition of Doneは完了判断の基準です。
RACIとの違い
RACIは、タスクごとの役割分担を整理するフレームワークです。
RACIでは、誰が実行し、誰が責任を持ち、誰に相談し、誰に共有するかを整理します。一方、Definition of Doneは、何を満たせば完了と言えるかを整理します。
たとえば、営業資料作成で、RACIは「作成者、承認者、相談先、共有先」を明確にします。Definition of Doneは「誤字確認、法務確認、PDF化、上司承認が終わっていること」を明確にします。
RACIは役割分担、Definition of Doneは完了条件に強いフレームワークです。
Kanbanとの違い
Kanbanは、タスクの状態を見える化し、仕事の流れを管理するフレームワークです。
Kanbanでは、「未着手」「作業中」「レビュー中」「完了」のようにタスクを移動させます。このとき、どの条件を満たせば「完了」に移してよいのかを決めるのがDefinition of Doneです。
Kanbanは作業状態の見える化、Definition of Doneは完了状態の基準づくりに向いています。
Definition of Doneはどんな場面で使うと効果的か
Definition of Doneは、完了基準が曖昧になりやすい仕事で効果を発揮します。
逆に、一人で完結する単純な作業や、完了条件が明らかな定型作業では、細かく作る必要はありません。
Definition of Doneが効果的な場面は次の通りです。
・Scrumやアジャイル開発
・Webページ公開
・ブログ記事作成
・社内研修教材の作成
・営業資料や提案資料の作成
・業務マニュアル作成
・動画教材制作
・問い合わせ対応の完了基準づくり
・システム機能開発
・外部委託成果物の検収
・社内説明会やイベント準備
・品質ばらつきが起こりやすい業務
特に、「完了したはずなのに後から抜け漏れが出る」「担当者によって仕上がりが違う」「レビューで毎回同じ指摘が出る」という仕事では、Definition of Doneを作る効果が大きくなります。
また、外部委託先に仕事を依頼する場合にも有効です。成果物の完了条件を事前に示しておくことで、検収時の認識ズレを減らせます。
まとめ
Definition of Doneは、作業や成果物が「完了した」と言える条件を明確にするためのフレームワークです。
仕事では、「完了しました」という言葉がよく使われます。しかし、担当者、確認者、承認者、利用者の間で完了のイメージが違うと、手戻りや品質問題が起こります。
Definition of Doneを使えば、何を満たせば完了と言えるのかを事前に明確にできます。誤字確認、レビュー完了、テスト完了、承認取得、公開形式への変換など、必要な条件を具体的に整理することで、抜け漏れを減らしやすくなります。
ただし、完了条件を増やしすぎると運用が重くなります。目的に対して必要な品質を満たす条件に絞り、実際に使いながら見直すことが大切です。
まずは、今よく手戻りが起きている仕事を一つ選び、「これを満たしたら完了と言える」という条件を5つ書き出してみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
Scrumとは？初心者向けに意味・使い方・具体例をやさしく解説
Kanbanとは？初心者向けに意味・使い方・具体例をやさしく解説
RACIとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
プロジェクト管理で使えるフレームワークまとめ｜初心者向けに種類・使い分け・活用例を解説
