「検収完了しました、ご請求お願いします」
新人の頃、私はこの一言をクライアントからもらうためだけに、検収を「最後の動作チェック」だと思い込んでいました。表示崩れがないか、リンクが正しいか、フォームが動くか。それさえ確認すればOKだと。
ところが、いざ検収を終えて安心していたら、数日後に「やっぱりここも直してほしい」という連絡が来たことがあります。契約上は検収済みのはずなのに、です。このとき初めて、検収は「品質チェック」ではなく「契約上の区切り」なのだと痛感しました。
この記事では、Webディレクターとして検収をどう進めればいいのか、具体的な手順とトラブルを避けるための考え方を、現場での経験を踏まえて解説します。
結論から言うと、検収を無事に終わらせるコツは次の3つです。
- 検収の基準を「検収の場」ではなく、もっと前の工程で握っておくこと
- 検収後に出てきた指摘を「スコープ内か外か」で冷静に仕分けること
- 検収後のトラブルは、現場の努力ではなく契約書の内容で防ぐこと
一つずつ見ていきましょう。
Webディレクターにおける「検収」とは？デバッグ・チェックとの違い
検収は「品質チェック」ではなく「契約上の受け入れ行為」
検収とは、納品されたものが契約通りの内容になっているかを、発注者(クライアント)が確認し、正式に受け入れることを指します。
社内で行う「デバッグ」や「QAチェック」は、あくまで制作側が自主的に行う品質確認です。それに対して検収は、クライアントが「これで合意した内容を満たしている」と認める、契約上の手続きという点が大きく違います。
社内デバッグ・QAチェックとの違い
| 社内デバッグ・QAチェック | クライアントの検収 | |
|---|---|---|
| 誰が行うか | 制作側(ディレクター・エンジニア) | クライアント(発注者) |
| 目的 | 不具合を出してから提出するため | 契約内容を満たしているか確認するため |
| 完了後の意味 | 次工程(検収)に進める | 請求・支払いの起点になる |
制作側のチェックがどれだけ丁寧でも、それは検収そのものではありません。検収は、あくまでクライアント側の「合意」があって初めて成立します。
検収完了が意味すること(請求・支払いとの関係)
多くの制作契約では、検収完了をもって納品完了とみなし、そこから請求書を発行する流れになっています。つまり検収は、単なる作業の区切りではなく、お金の流れにも直結する重要なポイントです。
だからこそ、検収を「なんとなく終わらせる」のではなく、手順を踏んで進める必要があります。
検収でよくある失敗・トラブル
検収基準が曖昧なまま進めてしまう
「見てもらえればわかるはず」と考え、何を基準に検収してもらうかをすり合わせないまま提出してしまうケースです。クライアントによって「完成」のイメージが違うため、想定外の指摘が出やすくなります。
検収後に「やっぱりここも直して」と言われる
検収が終わったはずなのに、後日追加の修正依頼が来ることがあります。これが起きる原因の多くは、検収時点で「何を確認すれば検収完了とするか」がクライアントと共有できていなかったことにあります。
クライアントの検収待ちでスケジュールが止まる
検収は制作側だけでは完結しません。クライアント側の確認が遅れると、それだけで公開日がずれ込むこともあります。検収期間をあらかじめ契約や進行表に明記しておくことが、地味ですが効果的な対策です。
Webディレクターが検収を進める基本の流れ
- STEP1 検収前の社内チェック(自社QA)
クライアントに提出する前に、動作・表示・リンク・テキストなどを制作側で確認します。ここで見つかった不具合は、検収に出す前に必ず解消しておきます。 - STEP2 検収基準・検収書の準備
契約書や要件定義で合意した内容をもとに、「何を満たせば検収完了とするか」を整理します。あわせて検収書(または検収チェックシート)を用意します。 - STEP3 クライアントへの提出・説明
成果物と一緒に、確認してほしいポイントや検収期限を伝えます。「どこを・いつまでに・どう確認してほしいか」を明確にすることが重要です。 - STEP4 指摘対応・再検収
クライアントから指摘が出た場合は、契約範囲内かどうかを確認したうえで対応します。対応後は再度確認してもらい、検収完了に向けて進めます。 - STEP5 検収完了・検収書の受領
クライアントから正式な検収完了の連絡(検収書へのサイン・返送など)をもらいます。ここまで来て初めて、検収は完了したと言えます。
検収をスムーズに進めるための3つの判断軸
①基準は「検収の場」ではなく前工程で握っておく
検収の場で初めて基準をすり合わせようとすると、たいてい時間が足りません。要件定義やワイヤーフレームの段階で、「完成の定義」をある程度言語化しておくことが、検収を楽にする一番の近道です。
要件定義の詰め方については、以下の記事でも詳しく解説しています。
②指摘は「スコープ内か外か」で仕分ける
検収時の指摘がすべて無償対応すべきものとは限りません。契約や要件定義で合意した範囲内の不備なのか、それとも新たな要望(スコープ外)なのかを、まず落ち着いて仕分けます。ここを感覚だけで判断すると、後々「言った・言わない」のトラブルに発展しやすくなります。
③検収後のトラブルは契約書の内容で防ぐ
検収完了後に不具合が見つかった場合にどう対応するかは、現場の頑張りではなく、契約書に書かれた内容によって左右されます。検収期間や、検収後の不具合対応(契約不適合責任など)について、契約段階で確認しておくと安心です。
検収書のフォーマットと書き方(簡易テンプレ)
検収書は、難しい書類である必要はありません。最低限、次の項目があれば十分機能します。
| 項目 | 記載内容の例 |
|---|---|
| 案件名 | 〇〇様コーポレートサイト制作 |
| 検収対象 | トップページ〜下層ページ一式 |
| 検収基準 | 要件定義書・デザインカンプ通りであること |
| 検収期限 | 20XX年〇月〇日まで |
| 確認結果 | 問題なし／指摘事項あり(別紙参照) |
| 検収完了日・サイン | クライアント記入欄 |
指摘事項が多い場合は、スプレッドシートなどにまとめて別紙として添付すると、後から見返しやすくなります。
検収後に不具合が見つかったときの対応
検収完了後に不具合が見つかった場合、まず確認すべきは契約書に定められた「検収後の対応期間」です。多くの契約では、一定期間内の不具合であれば無償対応とする、といった取り決めがされています。
期間外の指摘や、仕様変更に近い要望については、追加対応として扱うかどうかをクライアントと改めてすり合わせる必要があります。ここで感情的にならず、契約内容に沿って淡々と説明できるかどうかが、Webディレクターとしての力量が問われる場面です。
まとめ:検収はプロジェクトの「締めくくり」であり「次への始まり」
検収は、単なる最終チェックではなく、契約とお金の流れに直結する重要な工程です。基準を早めに握り、指摘を冷静に仕分け、トラブルは契約書で防ぐ。この3つを意識するだけで、検収まわりのヒヤリとする場面はかなり減らせます。
一つひとつの検収を丁寧に積み重ねることが、クライアントからの信頼にもつながっていきます。
ディレ和尚のひとこと
検収は終わりにあらず、次の仕事への始まりなり。
