リモートワークや業務委託の活用が進むにつれ、多くの企業やチームで「出社や勤務時間で縛る管理」を見直す動きが広がっています。前作の記事 では、オフィスへの出社強制という「人間管理」から、アウトプットを客観的に評価する 「仕事管理」 へのパラダイムシフトの重要性を論じました。

仕事管理（成果評価）とは、従業員や外部パートナーの勤務時間や場所を拘束して行動を監視するのではなく、事前に合意された「明確な成果物」とその受入基準・検収結果に基づいて業務遂行を評価・管理するマネジメント手法です。

しかし、現場で「時間や場所を自由にして、成果で評価しよう」と方針を決めた途端、多くのプロジェクトが別の壁に直面します。納品・検収フェーズを迎えたときに、「どこまで作れば完了なのか」「終わったのか終わっていないのか」 を巡って、発注者と受注者の間で深刻な摩擦が発生するのです。

「成果で管理する」と宣言しながら、肝心の「成果とは何か」を定義しないまま作業を任せるのは、自律の尊重ではなく マネジメントの放棄 に過ぎません。本記事では、受発注現場でなぜ完了判定のすれ違いが起きるのかを解き明かし、揉めないための「完了の定義（Definition of Done）」の設計方法と実務ルールを解説します。

1. なぜ「完了の判定」で揉めるのか ── 受発注双方のギャップ

成果の定義や検収条件が曖昧なままプロジェクトが進むと、納品時に発注者（クライアント）と受注者（エンジニア・受託会社）の間で以下のような致命的な認識のズレが生じます。

観点発注者（クライアント）の主張・不安受注者（エンジニア・受託会社）の主張・疲弊
完成の認識「納品されたが、実際の業務環境で動かしたらエラーが出て使えない」「仕様通りに実装して納品した。予定されていた工程はすべて完了している」
手直しの範囲「業務で使えないのだから、使えるようになるまで無償で直してほしい」「検収段階になって新たな要望や変更を際限なく求められて請求できない」
検収の対応「忙しくて確認する時間がない。じっくり確認してから検収したい」「納品後何週間も検収が放置され、入金サイクルが狂って死活問題になる」

このように、客観的な合否基準がないまま主観的な「できた／できていない」で争うと、発注側は「中途半端なものを押し付けられた」、受注側は「理不尽な無償労働を強いられた」と、双方が被害者意識を抱える泥沼のトラブルに発展します。

法律や公的ガイドラインが求める「検査の明示」

こうした受発注間の摩擦は個別の感情論にとどまらず、法制度や取引標準の観点からも厳しく問題視されています。

2024年11月1日に施行された フリーランス・事業者間取引適正化等法（フリーランス新法） では、発注事業者がフリーランスに業務委託を行う際、直ちに明示すべき取引条件の一つとして「給付の内容について検査をする場合は、その検査を完了する期日（検査完了期日）」の明示が義務付けられました1。さらに、正当な理由のない「受領拒否」や、受領後に無償で追加作業を行わせる「不当なやり直し」も明確に禁止されています1。

また、IPA（独立行政法人情報処理推進機構）が公開している 「情報システム・モデル取引・契約書（第二版）」 においても、納品後の受入検査は事前に合意された検査仕様書に基づいて行うこと、不合格とする場合は具体的な理由を記載した書面を提出すること、そして検査期間内に正当な異議申し立てがなければ合格とみなす「みなし合格条項（みなし検収）」の導入が強く推奨されています2。

裁判例においても、請負契約における「仕事の完成」は予定された全工程が終了しているか否かで客観的に判断され、軽微なバグが存在していても直ちに「未完成（代金不払い）」とはならず、主要機能が動作していれば完成と認められた上で契約不適合責任（修補請求等）として処理されるのが実務上の一般的な整理です3。

契約実務とエンジニアリング実務の双方において、「何をもって終わりと呼ぶか」を着手前に定義しておくこと は、もはやトラブル防止の必須要件となっています。

2. 「完了の定義（Definition of Done）」を分解する3つの要素

では、具体的に「成果」や「完了」をどのように定義すればよいのでしょうか。

アジャイルやスクラム開発では、チーム全体が共有する品質基準として 「完了の定義（Definition of Done: DoD）」 という概念が用いられます。スクラムガイド（2020年版）では、完了の定義を次のように述べています（同ガイド日本語版の訳語は「完成の定義」）4。

「完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を表す正式な記述である。」

スクラムにおける完了の定義（DoD）がプロダクト全体に適用される共通の品質基準（テスト通過、コードレビュー済み等）であるのに対し、各チケット固有の機能要件は「受入基準（Acceptance Criteria: AC）」と呼ばれます5。

この考え方を受発注や外部委託の商取引に応用する場合、完了の定義は次の 3つの要素 に分解して設計します。

完了の定義（DoD）を構成する3要素（納品対象物・受入判定条件・完了の証跡）の概念図

① 納品対象物（Deliverables）

「成果物」という言葉を抽象的に使わず、委託が終わった後に自社や別の会社が引き継げる一式 として、納品対象となる実体を確定リストで列挙します。

  • プログラム本体と、その保管場所・版の指定（Gitリポジトリの指定ブランチ、リリースタグ）
  • 動かすために必要な設定一式（環境設定ファイル、インフラ構築スクリプト）
  • データベースの構築手順と初期データ
  • 外部システムと接続するための仕様書（API仕様書、OpenAPI / Swagger 等）
  • 運用担当者が読む操作手順書・公開手順書

デザインやライティングの委託なら、編集可能な元データ（レイヤーを保持した制作ファイル、原稿ファイル）と、使用フォント・素材の利用許諾範囲がここに当たります。

② 受入判定条件（Acceptance Criteria）

どのような状態になれば「検収合格」とするかを、発注者自身が ○ × を付けられる文 で定めます。

  • どこで動けば合格か: 対象OS、ブラウザ（Chrome最新版等）、動作に必要なソフトウェアの指定バージョン
  • どの業務が通れば合格か: 「ユーザー登録 → 決済 → 完了メール送信」の一連の流れがエラーなく完了すること
  • 速度や同時利用人数の前提（非機能要件）: 主要画面が表示されるまでの時間（例: 2秒以内）、同時に使う人数の想定
  • 不具合の線引き: 業務が回らない・データが壊れる不具合はゼロ件。見た目や軽微な操作性の問題は合格後の修正対応とする

③ 完了の証跡（Evidence）

「受入判定条件を満たしていること」を、発注者が自分で動かして確かめる前に確認できる記録 として添えます。

  • 自動テストの実行ログ（全項目が合格した記録）
  • 発注者が実際に触って確かめられる検証用環境のURLと、確認用のテストアカウント
  • 主要な操作画面のスクリーンショットまたは操作録画
  • 外部システムとのやり取りの通信ログ

納品時に「作りました、確認してください」とだけ伝えるのではなく、判定条件とそれを裏付ける証跡をセットで提示する ことで、発注者側の確認コストを劇的に下げ、感情的なすれ違いを根絶できます。

3. 揉めない案件にするための3つの実務ルール

完了の定義を絵に描いた餅にせず、日々の受発注業務で機能させるための3つの実務ルールを紹介します。

ルール1: 着手前に「検収チェックリスト」を受託側から提示・合意する

発注者の多くは、開発技術や詳細なテスト手法の専門家ではありません。「検収条件を事前に決めてください」と丸投げしても、発注者側で的確な受入基準を言語化するのは困難です。

そこで、受託側・エンジニア側から要件定義や見積もりの段階で「今回の検収項目チェックリスト」をドラフトとして提示 します。「どの環境で、どのような手順を実施し、何が表示されれば合格とするか」をテーブル形式で事前に共有し、着手前に発注者の合意を取り付けておきます。

ルール2: 検収期間と「みなし検収」を明確にする

納品後に発注者が多忙を理由に何週間も検収を放置すると、受託側は請求書を発行できず、キャッシュフローが圧迫されます。

契約書や個別発注書には、必ず 検収期間（標準的には納品後7〜10営業日、中規模案件で14営業日程度） と みなし検収条項 を明記します6。

みなし検収条項の文面例
「発注者は、成果物の納品を受けた日から10営業日以内に受入検査を行い、合否を受託者に通知するものとする。上記期間内に正当な理由を付した書面または電磁的方法による異議申し立てがない場合、当該期間の満了をもって検収合格とみなす。」

フリーランス新法でも受領日から60日以内の報酬支払いが義務付けられているため、検収期間を短く区切って運用することは双方の法令遵守にも寄与します1。

ルール3: 「仕様変更」と「不具合修正」の境界線を事前に引く

検収期間中に最も揉めやすいのが、「どこまでが無償の手直しで、どこからが有償の追加開発か」という線引きです。

  • 不具合（バグ）: 合意済みの仕様書や検収チェックリストに記載された動作を実現していないもの ＝ 無償修正の対象（契約不適合）
  • 仕様変更 / 追加要望: 当初のスコープに含まれていない機能追加、デザイン・文言の大幅な変更、業務フローの変更 ＝ 別途見積もり・次期フェーズでの対応

「後から思いついた要望」が発生した場合は、その場で安易に引き受けず、「それは仕様変更にあたるため、追加工数とスケジュールへの影響を算出して次期見積もりをご提示します」と伝えて切り分けるプロセスを事前に共有しておきます。

4. FAQ：完了の定義と検収実務に関するよくある疑問

Q. 準委任契約（SESや時間精算）でも「完了の定義」や検収条件は必要ですか？

A. はい、必要です。
準委任契約は「仕事の完成」ではなく「善管注意義務に基づく役務の提供」に対価が支払われる契約形態ですが、月次の作業報告やマイルストーンにおいて「今月は何をもって予定タスクを遂行したとみなすか」の共通認識がないと、発注者との期待値のズレが生じ、契約途中終了やトラブルの原因になります。準委任であっても、スプリントや月ごとの「完了の定義」を定めておくことが健全な関係維持に不可欠です。

Q. 納品後に発注者から検収の返信が来ない場合、どう対応すべきですか？

A. みなし検収期間の満了を待つとともに、期限前にリマインドと動作証跡を送付します。
契約上はみなし検収条項により自動合格となりますが、事後の紛争を避けるため、検収期日の2〜3営業日前に「〇月〇日をもって検収完了扱いとなります」というリマインドを行い、あわせて自動テストログや動作録画などの証跡を再送して合意を取り付ける運用が実務上最も安全です。

5. まとめ：「完了の定義」を書くことが、働く自由の最大の防御壁になる

時間や場所に縛られない自律的な働き方（フルリモートワークやワーケーション）は、放任やサボりの免罪符ではありません。

着手前に「何を終わりと呼ぶか」を明確に言語化し、客観的な証跡によって完了を証明できるからこそ、発注者との強固な信頼関係が築かれ、世界中どこにいても自律して仕事を進めることができます。

完了の定義を事前に書くことは、発注者にとっては 「期待通りの品質が担保される安心」 であり、受注者にとっては 「不当な手戻りや放置から身を守る最大の盾」 です。

いま進行中のプロジェクトや新規の受発注において、「完了の定義」と「証跡」が事前に文書化されているか、ぜひ一度点検してみてください。

Meetsource では、システム開発・AI導入における要件定義や完了の定義の策定、受発注プロセスの設計支援を行っています。完了の定義から一緒に設計できる開発パートナーをお探しの際は、お気軽に コンタクトフォーム よりお問い合わせください。

Footnotes

  1. デジタル庁 (e-Gov法令検索) - 特定受託事業者に係る取引の適正化等に関する法律（令和5年法律第25号、2024年11月1日施行。第3条: 取引条件明示義務・検査完了期日、第4条: 受領後60日以内支払、第5条: 受領拒否・不当やり直しの禁止） ↩ ↩2 ↩3

  2. 独立行政法人情報処理推進機構 (IPA) - 情報システム・モデル取引・契約書（第二版）（2020年12月22日公表。請負型モデル契約第27条: 受入検査仕様書に基づく検査、不合格時の書面通知義務、みなし合格条項） ↩

  3. モノリス法律事務所 - システム開発の検収とみなし検収条項の適用場面とは（2021年公開。請負契約における仕事の完成基準、東京地裁平成24年2月29日判決等における軽微なバグと契約不適合責任の切り分け、みなし検収条項の有効性） ↩

  4. Ken Schwaber & Jeff Sutherland - The Scrum Guide（2020年11月版。Definition of Done の公式定義、インクリメントへのコミットメント、透明性の担保） ↩

  5. kakashi_h5 - スクラムにおける完了の定義（DoD）と受入基準（AC）（Qiita、2022年公開。DoDとACの概念的差異と実務上の使い分け） ↩

  6. 井口 涼（弁護士） - 受託開発でクライアントと揉めないための契約書のポイント（note、2023年公開。受託開発における検収期間7〜10営業日の設定実務、みなし検収条項の設計と仕様変更管理） ↩