ホームページの完成連絡を受けたら、最初に全ページを眺めるのではなく、何を基準に、いつまでに、どの環境で確認するかをそろえます。検収で見るべきなのは、合意した仕様や原稿との一致、利用者が通る経路の表示と動作、公開に必要なSEO・計測設定、そして公開後に管理できるデータとアカウントです。
検収は、完成した画面を見て好みの修正を無制限に追加する工程ではありません。一方で、「制作会社が確認済みだから」と内容を見ずに承認する工程でもありません。契約書、見積書、要件、承認済みの原稿・デザイン、変更履歴を基準に成果物を照合し、結果を「承認」「修正依頼」「保留」に分けて期限内に返す作業です。公開の前後どちらに検収期間を置くか、修正や支払いにどう影響するかは契約によって異なるため、まず個別の取り決めを確認してください。
最初に検収の基準と期限を一枚へそろえる
検収で意見が割れやすい原因は、確認する人ごとに基準が違うことです。担当者は最終デザインを見ていても、決裁者は初期提案の資料を見ているかもしれません。メールで承認した変更が見積書へ反映されていない、途中で差し替えた原稿が複数のファイルに残っている、といった状態では、同じ画面を見ても判断が一致しません。
確認を始める前に、次の資料を一か所へ集め、「今回の検収で正本とする版」を決めます。資料が複数ある場合は、日付だけで決めず、最終承認した人と変更内容まで確認します。
| 基準にする資料 | 検収で決められること | 曖昧な場合の扱い |
|---|---|---|
| 契約書・発注書・見積書 | 納品範囲、検収期限、修正条件、支払いとの関係 | 解釈を決めつけず、制作会社へ確認して保留にする |
| 要件定義・仕様書・ページ一覧 | ページ、機能、対応端末、外部連携の対象 | 追加要望と当初仕様を分ける |
| 承認済みワイヤー・デザイン・原稿 | レイアウト、文章、画像、導線の基準 | ファイル名ではなく承認日時と承認者を記録する |
| 変更履歴・議事録・メール | 制作途中で合意した追加、削除、延期 | 口頭変更は内容と合意者を文章で再確認する |
| 納品物一覧・未対応事項一覧 | 受領するファイル、アカウント、マニュアル、後日対応 | 「含まれると思っていた」で承認しない |
同時に、検収期間、回答窓口、社内確認者、対象URL、対象ブラウザ・端末を決めます。確認者が複数いる場合でも、制作会社への返答は一つにまとめます。営業担当は表現、現場担当は業務フロー、管理担当はアカウントを見るなど、担当を分けるのは有効ですが、別々のメールやチャットから修正が飛ぶと、重複や矛盾が起きやすくなります。
検収対象と、公開後に検討する改善案も分けてください。たとえば、仕様にあった問い合わせフォームが送信できないなら検収時の修正対象です。完成画面を見て新たに予約機能を追加したくなった場合は、当初の範囲に含まれていなければ追加相談です。どちらも必要な話ですが、同じ一覧へ混ぜると、承認できない理由が分からなくなります。
検収は、仕様・原稿、表示・動作、SEO・計測、データ・権限の四領域に分けると漏れを減らせます。前の領域で前提がずれていると後のテスト結果も変わるため、基準の照合から順番に進めます。
仕様・原稿・ページ構成は承認済みの版と照らす
最初に見るのは、ページ数や機能が「あるか」だけではなく、合意した範囲が正しい場所へ反映されているかです。ページ一覧と実際のURLを並べ、トップページ、サービス、会社情報、採用、よくある質問、問い合わせなど、対象になったページがそろっているかを確認します。ヘッダーやフッター、スマートフォン用メニューから同じページへたどれるか、旧URLからの移行やリダイレクトが仕様に含まれる場合は、その対応も対象です。
原稿は誤字だけでなく、情報の正しさと掲載場所を見ます。社名、住所、電話番号、営業時間、担当窓口、サービス名、料金、注記、採用条件など、間違えた時の影響が大きい情報から確認すると効率的です。制作途中の仮テキスト、ダミー画像、コメント、非公開の社内メモが残っていないかも確認します。文章が最新でも、古いPDF、バナー、画像内文字、構造化された一覧だけが更新前のままということもあります。
画像やダウンロード資料については、指定した素材が使われているか、切り抜きで重要部分が欠けていないか、代替テキストやキャプションが必要な箇所にあるかを見ます。写真、イラスト、フォント、動画、PDFなどの利用条件や納品範囲は契約ごとに異なります。掲載できていることと、元データを自由に再利用できることは同じではありません。購入素材やライセンス品がある場合は、利用できる媒体、期間、編集可否、契約終了後の扱いを確認します。
リンクは、文字やボタンの見た目だけでなく、遷移先のURLまで確認します。電話、メール、地図、SNS、予約、外部サービス、PDF、プライバシーポリシーなどは、似たURLへ誤って接続されても画面上では気付きにくい箇所です。別タブで開くか同じ画面で開くかまで仕様で決めている場合は、その動作も照合します。
デザインの確認では、「最終承認したデザインとの差」と「完成後に生まれた好み」を分けます。承認済みデザインと異なる色、配置、余白、画像、文言は、差分として具体的に指摘できます。一方、承認済みの状態がそのまま実装されているのに、「やはり雰囲気を変えたい」と感じた場合は、新しい要望として相談するのが整理しやすい進め方です。好みを我慢する必要はありませんが、契約内の修正なのか、追加作業なのかを分けることで、費用と日程を判断できます。
表示と動作は重要な利用経路から実機で通す
全ページを同じ深さで確認するより、利用者が目的を達成する経路からテストします。たとえば「トップページからサービス内容を読み、問い合わせフォームを送る」「求人一覧から募集要項を開き、応募する」「商品ページから外部予約へ移動する」といった主要経路です。ここが止まる不具合は公開判断への影響が大きいため、装飾の微調整より先に確認します。
対象環境は、契約や仕様に書かれた端末・ブラウザを基準にします。「すべての機種で同じ見え方」を目標にすると終わりがありません。少なくとも、仕様で指定されたパソコン環境とスマートフォン実機で、次の点を見ます。
- 文字や画像が画面からはみ出さず、重なっていないか
- メニュー、固定ボタン、モーダル、スライダーが開閉できるか
- ボタンやリンクを指で押し分けられ、押した結果が分かるか
- 画面幅を変えても、途中の幅だけレイアウトが崩れないか
- 拡大表示でも文章を読め、操作対象が隠れないか
- キーボード操作でリンクや入力欄へ移動でき、現在位置が見えるか
- マウスを重ねた時だけ出る情報が、タッチ端末でも利用できるか
見た目の差が出た時は、端末名だけでなくブラウザ、画面幅、ログイン状態、発生したURLを記録します。キャッシュが残っていると修正前の画面が表示されることがあるため、再読み込みや別ブラウザでも確認します。ただし、確認のたびに環境を変えると再現条件が分からなくなるので、最初の条件を残したうえで切り分けます。
問い合わせフォームは、画面が開くだけでは検収できません。入力前から受信まで、一連の流れを通します。
- 必須項目を空欄にした時、何を直せばよいか分かるエラーが出るか
- メールアドレスや文字数など、仕様で決めた入力条件が働くか
- 入力内容が確認画面または送信前の画面へ正しく引き継がれるか
- 送信後に完了が分かり、二重送信しにくい状態になっているか
- 利用者向け自動返信と管理者向け通知が、指定した宛先へ届くか
- メールの件名、差出人、返信先、本文、文字化け、リンクが正しいか
- 添付、予約、外部連携、データ保存が範囲に含まれる場合、その先まで動くか
テストには個人情報を含まない識別しやすいデータを使い、件名や氏名欄に検収テストだと分かる文字を入れます。送信後は、管理画面や外部サービスへ不要なテストデータが残っていないかも確認します。実際の顧客情報や社員の私用アドレスを使う必要はありません。
電話番号、メールリンク、地図、SNS、PDF、動画、外部予約なども、クリック後の結果まで見ます。存在しないURLへアクセスした時に、利用者が戻れる案内が出るかも確認対象です。テストサイトでは動いていても、本番ドメイン、SSL、メール送信元、外部サービスの許可設定が変わると結果が変わることがあるため、公開後の本番確認が契約に含まれるかも明確にします。
SEO・計測・公開設定は「入っている」ではなく結果まで見る
SEO設定は、専門用語の欄が埋まっているかではなく、対象ページで意図した値が出ているかを確認します。契約範囲に含まれる項目を、代表ページだけでなく、トップ、主要サービス、記事、問い合わせ完了など役割の違うページで見ます。
主な確認対象は、ページタイトル、検索結果向けの説明文、見出し構造、画像の代替テキスト、正規URL、インデックス制御、XMLサイトマップ、旧URLからの転送、OGP、ファビコンです。すべての案件で同じ項目が必要とは限りません。仕様に含まれていない高度なSEO対応を、検収段階で当然の納品物として追加しないことも大切です。
特に注意したいのが、テスト環境で使った公開制限の残りです。本番公開するページに noindex が残っていると検索結果へ出ない原因になります。一方、robots.txtは主にクローラーのアクセスを調整するもので、ページを検索結果から確実に隠すための設定とは役割が違います。公開するURL、公開しないURL、クロールを抑えるURLを分けて確認し、XMLサイトマップには公開対象の正規URLが載っているかを見ます。リニューアルなら、重要な旧URLが意図した新URLへ移動することも確認します。
アクセス解析も、タグらしいコードが入っているだけでは不十分です。対象のGA4プロパティとウェブデータストリームが合っているかを確認し、検収用のアクセスやフォーム送信を行って、リアルタイム表示やデバッグ用の画面でイベントを受信できるかを見ます。通常の集計レポートへ反映されるまで時間がかかる場合があるため、納品当日の確認を集計表だけに頼らないようにします。問い合わせや予約をキーイベントとして扱う仕様なら、発生条件、イベント名、重複計測の有無まで確認します。
計測へ送るURLやイベント情報に、氏名、メールアドレス、電話番号、問い合わせ本文などの個人情報が混ざらないことも確認します。フォーム送信後のURLへ入力内容を付ける設計や、入力値をそのままイベントへ渡す設計は避け、必要な判定だけを送る形にします。
表示速度は、測定ツールの点数一回分だけで合否を決めません。契約に数値基準がある場合は、その測定条件に合わせます。数値基準がない場合は、主要ページをスマートフォン相当の条件で開き、最初の表示が極端に遅くないか、大きな画像や動画で操作が止まらないか、読み込み途中に大きくレイアウトが動かないかを確認します。測定日時、端末、通信条件、対象URLを残しておくと、再確認時に比較できます。
アクセシビリティも、対応範囲を確認したうえで基本項目を見ます。見出しの順序、画像の代替テキスト、文字と背景の見分けやすさ、拡大時の読みやすさ、キーボードのフォーカス、フォームのラベルとエラー表示は、専門ツールがなくても確認できる入口です。ただし、この簡易確認だけで規格への適合を保証できるわけではありません。適合レベルや試験方法が契約にある場合は、その基準と報告書で判断します。
データ・アカウントはログインと復旧まで確かめる
サイトが表示されていても、データと管理権限が整理されていなければ、更新や障害対応のたびに制作会社へ確認することになります。まず、契約上の納品物を一覧で確認します。HTMLやテーマ、プログラム、デザインデータ、写真の元データ、原稿、データベース、設定ファイルなど、何が渡されるかは制作方法と契約によって異なります。「ホームページ一式」という言葉だけで、編集可能な元データや有料素材の権利まで含まれるとは判断できません。
WordPressの「エクスポート」で取得できるファイルは、記事や固定ページなどの移行には役立ちますが、それだけでテーマ、プラグイン、画像ファイル、設定、データベースを含む完全な復旧データになるわけではありません。バックアップ納品が範囲にある場合は、何を含むデータか、取得日時、保管場所、復元方法、誰が復元するかを確認します。自動バックアップがある場合も、「設定されている」だけでなく、保存期間、保存先、復元権限を把握します。
アカウントは、次のようにサービス単位で棚卸しします。該当しないものは除き、外部予約や決済などがある場合は追加します。
- ドメイン登録・DNS・CDN
- レンタルサーバー、クラウド、バックアップ
- WordPressなどのCMS
- 業務用メールとフォーム送信サービス
- GA4、Search Console、タグ管理
- 地図、reCAPTCHA、動画、SNS、予約、決済などの外部サービス
各サービスについて、契約名義、管理者、請求先、更新日、復旧用メール、二段階認証、制作会社の権限、緊急時の連絡先を記録します。IDやパスワードを平文の共有表へ並べるのではなく、組織で管理できるパスワード管理方法や安全な受け渡し手段を使います。納品されたIDは、実際にログインできるか、必要な設定を閲覧できるか、復旧先が退職者や制作会社だけになっていないかまで確認します。
CMSでは、全員へ同じ管理者IDを配らず、担当業務に必要な権限を個人ごとに付ける方が履歴を追いやすくなります。検収用や制作作業用の一時アカウントは、引き継ぎと再確認が終わってから削除または権限を下げます。公開後の更新担当、権限、保守範囲を先に整理したい場合は、WordPressでホームページを依頼する前に決めること｜更新・権限・保守の整理表も判断材料になります。
マニュアルは、ファイルを受け取るだけでなく、担当者が一度操作して使えるかを試します。最低限、文章と画像の更新、公開前プレビュー、ユーザー追加、バックアップ、問い合わせ確認、誤操作時の連絡方法を対象にします。保守契約がある場合は、WordPress本体やプラグインの更新、バックアップ、障害調査、軽微修正、営業時間外対応など、どこからが別料金・別依頼になるかを確認します。
未対応事項や既知の制約も納品物の一部として記録します。「特定環境で表示差がある」「外部サービスの審査待ち」「原稿確定後に差し替える」「公開後に計測を再確認する」といった項目を、担当者と次の確認日が分かる状態にします。口頭で「あとで直す」と聞いただけでは、検収完了後に優先順位が分からなくなります。
修正依頼は再現条件と合意基準で書く
修正一覧の目的は、不満を強く伝えることではなく、同じ現象を制作側が再現し、修正後に発注側が同じ条件で確認できるようにすることです。「スマホで崩れている」「思っていたのと違う」だけでは、対象箇所や期待する結果が分かりません。
一つの指摘には、次の情報をそろえます。
| 記録項目 | 書く内容 |
|---|---|
| ID・場所 | 通し番号、ページ名、URL、画面内の位置 |
| 確認環境 | 端末、ブラウザ、画面幅、ログイン状態 |
| 再現手順 | どのページから何を押し、何を入力したか |
| 期待する結果 | 承認済み仕様・原稿・デザインではどうなるはずか |
| 実際の結果 | 何が表示され、どこで止まったか |
| 証拠 | 全体位置が分かる画面と、必要に応じた拡大画像・動画 |
| 区分・影響 | 仕様差、不具合、質問、追加要望。公開を止めるか |
| 状態 | 未確認、対応中、再確認、解決、次期対応など |
たとえば「お問い合わせページが崩れています」ではなく、「問い合わせページをスマートフォンのブラウザで開き、確認画面へ進むと、送信ボタンが画面右側へはみ出して押せない。承認済みデザインでは画面内に収まる。対象URLと画面全体の画像を添付」のように書きます。色や余白の差なら、承認済みデザインの該当箇所も示します。
指摘の影響度は、件数ではなく利用者と業務への影響で決めます。主要ページが開かない、問い合わせを送れない、通知が届かない、公開情報が誤っている、本番ページにnoindexが残るといった問題は、公開や承認を止める理由になり得ます。わずかな余白差や特定条件だけの装飾差は、仕様との関係を確認したうえで、公開後対応にできる場合があります。何を重大とするかはサイトの目的と合意内容で変わるため、感覚だけで優先度を付けません。
社内から集めた指摘は、重複を削除し、矛盾を解消してから一つの一覧で渡します。ファイル名や版番号を付け、追加・変更した箇所が分かるようにします。修正後は、制作会社から「対応済み」と連絡を受けるだけで閉じず、元の再現条件で再テストします。別の箇所へ影響しやすいメニュー、フォーム、共通部品、リダイレクト、計測タグは、周辺の経路も短く確認します。
全体の返答は「承認」「修正後に再確認」「情報不足のため保留」のどれかが分かるようにします。保留は返答を止める意味ではなく、何が分かれば判断できるか、誰が確認するか、次の回答日を記録する状態です。契約上の検収期限がある場合は、期限前に未確認項目を含めて状況を共有します。
検収完了は未修正ゼロではなく、すべての扱いが決まった状態
検収を終えられるのは、細かな要望が一件も残っていない時だけではありません。合意した納品範囲を確認でき、公開や主要業務を止める問題が解決し、残る項目について担当者、対応方法、期限、費用区分が決まっている状態なら、条件付きの承認や次期対応へ整理できる場合があります。反対に、画面がきれいでも、管理アカウント、データ、未対応事項が不明なままなら、引き継ぎは完了していません。
最終回答の前に、次を確認します。
- 検収の正本、対象URL、対象環境、期限が明確になっている
- 契約・見積・仕様にあるページと機能を照合した
- 原稿、画像、リンク、会社情報、ダミー要素を確認した
- 主要な利用経路をパソコンとスマートフォンで通した
- フォームを入力エラーから受信までテストした
- 公開対象のnoindex、robots.txt、サイトマップ、転送を確認した
- GA4などの計測を実際のアクセスやイベントで確認した
- 納品データ、利用条件、バックアップと復元方法を確認した
- ドメイン、サーバー、CMS、計測などへログインできた
- マニュアル、保守範囲、未対応事項、緊急時の連絡先を確認した
- 修正一覧に再現条件、期待結果、証拠、状態、期限がある
- 承認・修正・保留の結論を、契約上の期限内に記録して返す
検収で大切なのは、見る項目を増やすことより、合意した基準と確認結果を結び付けることです。仕様、利用経路、公開設定、引き継ぎを順に確認し、未対応を曖昧に残さなければ、承認後の「聞いていなかった」「使えなかった」を減らせます。
