「この動きはおかしくないですか」「この機能は想定と違います」——こういった指摘が検収直前に来る案件には、共通点があります。納品条件が曖昧なまま開発が進んでいたという点です。
何をもって「完成」とするかを顧客と合意できていなければ、どれだけ丁寧に作っても「私が期待していたのはこれじゃない」という事態が起きます。
この記事では、受託開発PMが納品前に確認すべき5点と、顧客との合意の進め方を解説します。契約や法律的な判断は含まず、実務運用としての内容です。
納品条件が曖昧だと検収で揉める
検収前トラブルの多くは、次のどれかのパターンです。
成果物の認識ズレ — 「設計書込みだと思っていた」「ソースコードだけでいいと思っていた」という認識の違いが、検収で表面化します。
受入条件が決まっていない — 「正常に動くこと」という条件は、顧客側の「正常」とPM側の「正常」が違います。何をもって正常とするかが決まっていないと、評価基準が人によって変わります。
追加対応の要求 — 検収のタイミングで「これも対応してほしい」という追加が来るケースです。最初から「今回の範囲外」を明示していれば防げたはずのものが多いです。
確認1：成果物一覧
「今回の案件で最終的に納品するものは何か」を一覧で確認します。
成果物として含まれる可能性があるものの例：
- 動作するシステム（本番環境 or ステージング環境）
- ソースコード（Gitリポジトリ or 圧縮ファイル）
- 設計書・仕様書（バージョン・フォーマット）
- テスト結果（テスト仕様書・結果一覧）
- 操作マニュアル（管理者向け・エンドユーザー向け）
契約書やSoWに記載がある場合はそれが基準になりますが、記載がない場合や曖昧な場合は、早い段階で顧客と確認しておきます。
確認2：受入条件
「顧客が検収OKを出す条件は何か」を確認します。
「動いていること」では不十分です。具体的に「どの機能が、どの操作で、どういう結果を返すこと」という条件を明確にします。
テストシナリオを受入条件の形で作れると、顧客にも「これを確認してOKなら検収OK」という共通認識が持てます。また、PMとしても「これがクリアできれば納品できる」という基準になります。
確認3：確認方法
「受入条件をどうやって確認するか」を決めます。
顧客が自分で操作して確認するのか、PMがデモを行うのか、テスト結果を提出するのかによって、準備するものが変わります。
特に顧客が自分で確認する場合は、確認に使う環境（本番 or ステージング）と確認期間を事前に決めておきます。「確認してください」と渡したまま音沙汰がない、という状況を避けるために「〇週間の確認期間を設けます」という形にします。
確認4：対象外
今回の納品に含まれないものを明示します。
「対象外」を明確にすることで、検収時の追加対応を防ぎやすくなります。「このページはデザイン未適用ですが今回の対象外です」「スマホ表示は今回含みません」という形で記録に残します。
対象外事項は追加発注の起点にもなります。「今回の範囲外の機能については、別途ご相談ください」という形でつなげられます。
確認5：検収期限
「顧客が検収を完了する期限」を確認します。
検収期限が設定されていないと、「まだ確認中です」という状態が続き、プロジェクトの終了タイミングが曖昧になります。次の案件の見通しも立てにくくなります。
「検収確認の期間は〇週間でお願いできますか。〇月〇日を検収完了の目安として設定させてください」という形で合意します。検収完了後の次ステップ（保守移行 or 追加開発）についても、この段階で確認しておくと次の計画に入りやすくなります。
顧客と合意する流れ
5点の確認は、設計フェーズの終盤か開発開始前に行うのが理想です。この段階で合意しておくと、開発後半や検収直前に「聞いておけばよかった」という状況を防げます。
確認した内容はメールまたは議事録に残し、顧客に「この内容で認識合っていますか？」と確認します。口頭確認だけで終わらせず、文字に残すことがポイントです。
まとめ
納品条件の合意は、開発を始める前に整えておくことで、検収でのトラブルを大幅に減らせます。
成果物一覧・受入条件・確認方法・対象外・検収期限の5点を確認し、顧客との共通認識を作ること。これが受託開発PMの納品管理の基本です。
納品管理・検収対応を含む受託開発PM実務を学びたい方は、受託開発PM向けの課題別パックをご覧ください。