プロジェクト管理の基本概念

プロジェクト完了条件ぷろじぇくとかんりょうじょうけん

完了基準受入条件DoD（Definition of Done）検収スコープ管理品質基準

プロジェクト完了条件について教えて

簡単に言うとこんな感じ！

「このプロジェクト、いつ終わりにしていいの？」っていう問いへの答えを事前に決めておいたものだよ！「機能が動いた」「テストが全部通った」「お客さんがOKと言った」みたいな”終わりの定義”を最初に合意しておかないと、ゴールのないマラソンになっちゃうんだ。

プロジェクト完了条件とは

プロジェクト完了条件（英語では Completion Criteria や Definition of Done (DoD) とも呼ばれます）とは、「このプロジェクトが終わった」と全員が合意できる状態を、事前に具体的な言葉で定義したものです。「だいたいできた」「ほぼ完成」では発注者とベンダーの認識がズレやすいため、客観的に判断できる基準をあらかじめ決めておくことが目的です。

ビジネスの現場では、完了条件は発注側（顧客）とベンダー（開発会社）が契約時またはプロジェクト開始時に合意しておくことが基本です。この合意が曖昧だと、「まだ直してほしい箇所がある」「いや、もうスコープ外です」といった水掛け論になりがちです。特にシステム開発の検収（けんしゅう）、つまり発注者が成果物を受け取る場面では、完了条件が契約上の根拠になります。

完了条件は、プロジェクト全体に対して定めるものだけでなく、各フェーズ・各タスク・各機能単位にも設定できます。アジャイル開発の世界では、これを Definition of Done（DoD） と呼び、「このユーザーストーリーは何を満たしたら”完成”か」をチームで合意する文化が根付いています。

完了条件の構成要素と種類

完了条件は「何を・どのレベルで・誰が確認したら終わりか」という3つの軸で整理できます。

軸	具体例
何を（対象）	機能、画面、帳票、マニュアル、テスト結果
どのレベルで（基準）	バグゼロ、エラー率1%以下、表示速度3秒以内
誰が確認したら（承認）	顧客の担当者、品質保証チーム、ステアリングコミッティ

完了条件の種類

完了条件はスコープ（対象範囲）によっていくつかのレイヤーに分かれます。

レイヤー	名称	説明
タスク単位	タスク完了条件	「設計書のレビューが承認された」など個々の作業の終わり
機能・ストーリー単位	DoD（Definition of Done）	「この機能が動作し、テストを通過し、ドキュメントが揃った」
フェーズ単位	フェーズゲート基準	「要件定義フェーズの全成果物が承認された」
プロジェクト全体	最終完了条件	「検収テスト合格・本番稼働・移行完了・ドキュメント納品」

覚え方：「SMART基準」で完了条件を作る

良い完了条件は SMART であることが重要です。

Specific（具体的）：「品質が高い」ではなく「バグ件数が重大度A：0件、B：3件以下」
Measurable（測定可能）：数値や合否で判断できる
Achievable（達成可能）：現実的に到達できる水準
Relevant（関連性がある）：ビジネス目標に紐づいている
Time-bound（期限がある）：「○月○日までに確認」が明記されている

歴史と背景

1950〜1970年代：ウォーターフォール型開発が主流。契約書に記載した「仕様書との一致」が完了条件の中心。検収テストで合否を判定する形が定着
1990年代：ソフトウェア品質の重要性が増し、ISO 9001などの品質マネジメント規格に「受入基準」の明文化が求められるようになる
2001年：アジャイルマニフェストが発表。短いサイクル（スプリント）での”動くソフトウェア”の定義が必要となり、チーム内での DoD が普及し始める
2009年：Scrum Guide が Definition of Done を正式に定義。「完了していないものはリリースしない」という原則が広まる
2021年：Scrum Guide 更新版では DoD を「プロダクトの品質基準を満たす正式なコミットメント」と位置づけ、さらに重要性が強調される
現在：アジャイル・ウォーターフォール問わず、完了条件の明文化はプロジェクト管理のベストプラクティスとして認識されている

良い完了条件・悪い完了条件の比較

発注者として「この完了条件、本当に大丈夫？」とチェックできるよう、良い例と悪い例を対比します。

観点	❌ 悪い完了条件の例	✅ 良い完了条件の例
具体性	「システムが正常に動作すること」	「全テストケース（計250件）が合格し、重大バグ件数が0件であること」
測定可能性	「ユーザーが使いやすいこと」	「ユーザー受入テストで承認率80%以上を達成すること」
承認者の明記	「確認が完了すること」	「情報システム部長が検収書に署名すること」
期限	「テスト後に完了」	「2026年6月30日までに本番環境での動作確認が完了すること」
範囲	「機能が揃っていること」	「要件定義書 v2.3 に記載された全45機能が実装されていること」

以下の図は、完了条件がプロジェクトのどのフェーズで機能するかを示しています。

発注者として押さえるべき実務ポイント

プロジェクトを発注する立場から、完了条件に関して特に重要な点をまとめます。

① 完了条件は「契約書」または「プロジェクト計画書」に明記させる

口頭の合意だけでは後から「言った・言わない」になります。必ず文書に残し、双方の責任者がサインした形にしましょう。

② 「誰がOKを出すか」を必ず決める

完了条件がいくら具体的でも、承認者が不明だと判断が宙に浮きます。「情報システム部長」「業務部門責任者」など、具体的な役職・氏名を指定してください。

③ 変更が生じたら完了条件も更新する

プロジェクト途中でスコープが変わったのに完了条件が古いままでは、何を基準に終わりを判断するかわかりません。変更管理（チェンジコントロール）と完了条件の更新はセットで行いましょう。

④ 「完了条件未達のまま本番稼働」は避ける

「とりあえず動かして後で直す」は、未完了のリスクを棚上げにしているだけです。未達の場合は条件を緩和するのか、期限を延ばすのかを意思決定し、記録に残すことが重要です。