前の制作会社から受け取れたのは管理画面の案内だけで、どこを直せばよいか分からない。新しい会社に修正を相談しても、仕組みが分からないため見積もりが決まらない。こうしたときは、改修と一緒にすべてを頼む前に、次の判断に必要な現状調査を切り出す方法があります。
依頼の中心は、サイトを隅々まで調べることではありません。今回直したい箇所について、確認できた事実、根拠のある推定、まだ確認できない点を分け、追加で必要な権限や資料を残すことです。この記事では、自社サイトの引継ぎを進める担当者が、調査範囲と成果物を新しい制作会社に伝えるための整理方法を紹介します。
調査の入口は「次に何を決めたいか」から
資料が少ないときほど、「全体を調べてください」という依頼になりがちです。しかし、会社概要の文章を更新したいのか、問い合わせフォームを変えたいのか、サーバーを移したいのかでは、調べる対象と深さが異なります。最初に、調査後に決めたいことを一文にします。
たとえば「既存の仕組みを使って採用ページを追加できるか判断したい」なら、ページの作成方法、共通のメニュー、更新担当の権限、公開手順などが主な確認対象になります。一方、フォームの項目変更なら、入力画面だけでなく、送信処理、通知先、保存先、外部サービスとの連携まで確認が必要になる場合があります。
依頼時には、対象URLと希望する変更、今困っている症状、業務上の期限を渡します。ログイン方法や契約の整理がまだできていない場合は、その不足も明示します。調査担当が利用できる環境と、発注側が用意する情報を分けると、着手後に前提が違うことへ気づく事態を減らせます。
ここで決めるのは、改修の可否を先に約束することではありません。どの事実が確認できれば判断できるか、何が不明なら追加調査が必要かをそろえることです。調査だけを発注する場合にも、最後にどの判断材料を受け取るかまで決めておきましょう。
公開画面と管理環境では、分かる範囲が違う
公開ページからは、画面の表示、リンク先、読み込まれる画像や外部サービスなどを確認できます。ただし、見えている画面だけで、更新元のファイル、サーバー側の処理、契約者まで確定できるわけではありません。同じ見た目のページでも、作られ方が異なることがあります。
Chromeの公式資料では、開発者向けのNetworkパネルで、ページが読み込むデータやファイルの通信状況、応答の内容、要求のきっかけなどを確認できると説明しています。これは公開画面が何を読み込んでいるかを調べる手がかりです。通信の記録だけで、サーバー内の全処理や契約内容まで分かると広げないようにします。出典：Chrome for Developers
管理環境に入れる場合は、使っている機能、設定、権限など、確認できる範囲が増えます。WordPressの公式資料では、サイトヘルスの情報画面に、テーマやプラグイン、サーバー等の構成情報が表示されることを説明しています。また、この画面は情報を示すもので、設定を変更する画面ではないと区別されています。出典：WordPress.org
ただし、その情報を取り出しただけで、独自の追加処理や外部連携を含む仕様書が完成するわけではありません。管理画面で確認した内容、許可されたファイルで確認した内容、担当者から聞いた内容を分けて記録します。調査報告に根拠の場所が残れば、後から追加情報が届いた際にも判断を更新できます。
調査の前に、使える権限と行ってよい操作を決める
管理画面のアカウントがあることと、すべての設定を変更してよいことは別です。調査の対象環境、必要な閲覧範囲、設定変更の有無、テスト送信の有無を、着手前に制作会社と確認します。初回相談でパスワード一式を送るのではなく、必要な段階で共有方法を決めます。
公開中の環境を調べる場合は、閲覧だけで確認する項目と、保存や送信などの操作を伴う項目を分けます。フォームを実際に送るなら、通知を受け取る担当者、テストと分かる内容、記録の扱いまでそろえます。注文や予約など業務へ影響する操作も、単なる画面確認に含めないようにします。
資料がないからといって、その場で機能を止めたり、更新したりして原因を探すことが必ず必要とは限りません。変更を伴う検証が必要なら、別環境の準備や戻し方を含めて範囲を決めます。調査中に修正した方が早そうな箇所が見つかっても、調査結果と変更作業を区別して扱います。
権限が足りず確認できない場合は、そこで得られた事実までを報告に残します。「調査不能」の一言で終わらせず、何を見られなかったか、誰にどの権限を依頼すれば進められるかを書いてもらうと、自社側の準備を具体化できます。
確認済み・推定・未確認を分けた報告見本
調査報告は、機能の一覧だけでなく、確認状態と根拠が読み取れる形にします。下表は、会社サイトの修正を検討する架空の例です。実在サイトの診断結果ではありません。必要権限は固定の正解ではなく、その環境と調査内容に応じて確認するものです。
| 調査対象 | 確認状態 | 根拠として残すもの | まだ分からないこと | 次に必要な確認・権限 |
|---|---|---|---|---|
| 会社概要の本文 | 確認済み | 管理画面の編集欄と公開URLの対応 | 保存後の承認手順 | 更新担当への確認、試せる環境 |
| 共通メニュー | 推定 | 複数ページの同じ表示と読込元 | 全ページが同じ設定を使うか | 共通設定や対象ファイルの閲覧 |
| フォームの入力欄 | 確認済み | 確認した画面と日時 | 通知先、保存先、外部連携 | フォーム設定と受信側の確認 |
| バックアップ | 未確認 | 今回見られなかった対象を記載 | 取得範囲、時点、復元方法 | 管理担当への照会、必要な管理画面 |
| 外部サービス | 推定 | ページから読み込むサービスの情報 | 契約者と継続利用の条件 | 契約資料とサービス管理者の確認 |
「確認済み」は、その行に書いた事実を確かめたという意味に限定します。入力欄を見たことを、フォームの送信から受信まで正常に動くことへ読み替えないようにしてください。同じ対象でも、画面は確認済み、受信は未確認という状態があり得ます。
「推定」には、そう考えた根拠と、確定に必要な確認を付けます。公開ページで同じメニューが表示されていても、すべてが一つの設定から出力されるとは限りません。見た目が同じという観察と、更新元が共通という推定を分けるだけで、修正範囲を決めるときの誤解を減らせます。
「未確認」は、欠陥や不合格と同じではありません。権限がない、資料待ち、今回の対象外、再現できなかったなど、理由を添えます。未確認を空欄にすると、調べ忘れなのか、意図的に対象から外したのかが伝わらなくなるためです。
成果物は、次の担当者が確認を続けられる形にする
成果物として受け取るものは、報告書のファイル名だけで決めないようにします。対象ページ・機能の一覧、確認した範囲、構成の関係図、根拠のある調査結果、未確認事項と必要な情報、次の作業案を含めるかを確認します。調査結果から改修見積もりへ進むなら、その前提も記載してもらいます。
構成図では、ページ、更新元、外部サービス、通知先などの関係を示します。分かっていない接続を確定した線で結ばず、点線や注記で区別すると、図だけを見て判断する人にも限界が伝わります。技術名の多い図になる場合は、発注側が知りたい「どこを変えると何へ影響するか」の説明を添えてもらいます。
画面の証拠には、URL、確認日時、利用した権限や環境、確認した操作を添えます。古い検証環境の画面と現行公開画面が混ざると、確認済みの意味が変わります。画像だけを並べるのではなく、報告表の行と証拠を対応させる番号を付けると、質問する場所を特定しやすくなります。
受け取る報告書に、パスワードや利用者の個人情報をそのまま載せる必要はありません。共有してよい範囲を決め、機微な設定や記録は必要な担当者だけが扱える場所へ分けます。次の制作会社や社内担当に渡せる資料と、限定して扱う情報を区別しておくと、報告書自体も引継ぎに使いやすくなります。
調査に使った資料が後から更新された場合には、どの版を確認したかも残します。新しい資料が届いても過去の報告を無言で上書きせず、再確認した箇所と残る不明点を示します。発注側は、最新の資料があることと、最新の資料で調査済みであることを分けて受け取ります。
調査と改修の見積もりを分けて比較する
調査の見積もりでは、ページ数だけでなく、対象機能、閲覧する環境、操作を伴う検証、資料の読み込み、報告内容を確認します。同じ「現状調査」でも、公開画面だけを見るものと、権限のある管理環境まで確かめるものでは範囲が異なります。
追加調査が必要になる条件も、先に確認しておきます。必要な権限が取得できない、独自処理が見つかる、外部サービスの管理者確認が必要になるといった場合に、どこで一度報告を受け、費用や日程を見直すかを決めます。すべての不明点がなくなるまで無制限に調べる依頼にしないことが重要です。
報告後の提案は、「そのまま使える」「一部を直す」「追加確認が必要」「別の構成を検討する」など、根拠と条件が分かる選択肢で受け取ります。資料不足だけを理由に全体の作り直しを決めるのではなく、継続できる範囲と判断できない範囲を比較します。
調査が終わったことと、改修が完了したことも別です。調査結果を基に変更する場合には、作業対象と確認方法を新たに決めます。現状で動いていた機能を、変更後にも同じ条件で確認できるよう、調査時の記録を検収の出発点として使います。
調査の対象ページを代表例に絞る場合は、選んだ理由も依頼書に残します。トップページと会社概要だけを見て、予約や会員ページを含む全サイトが同じ構成だとは判断できません。共通の仕組みを確認するためのページと、独自機能があるため別に調べるページを分けておきます。
また、調査時に症状が出なかった場合の報告方法も決めます。「問題なし」ではなく、「指定した操作と環境では再現しなかった」と記録し、問い合わせがあった日時や条件との違いを残します。再現に必要な情報を追加で集めるのか、今回は保留にするのかを判断できる形にします。
報告を受け取ったら、未確認のまま残す項目を決める
発注側の確認では、最初に決めた判断へ答えが出ているかを見ます。「採用ページを追加できるか」が目的なら、追加方法、必要な権限、共通部分への影響、残る条件が示されているかを確かめます。技術情報が多くても、次に何を発注すればよいか分からない報告なら、判断との対応を説明してもらいます。
未確認事項は、すべてを直ちに解消する必要があるとは限りません。今回の改修に影響する項目、後の運用で確認する項目、現時点では対象外にする項目へ分けます。ただし、対象外とする理由と、再確認が必要になる条件を残しておきます。未確認を問題なしとして消さないことが大切です。
最後に、追加資料を探す担当、権限を用意する担当、改修案を決める人、次の確認日をそろえます。資料が足りないサイトでも、確認できた範囲と不足を分けた報告があれば、次の行動を具体化できます。現状調査は、過去の仕様書を完全に復元することだけでなく、これからの更新を判断できる資料を残すために依頼しましょう。
参考資料
公開情報を2026年9月16日に確認。調査機能の説明を参照し、報告表と図は架空の設計例として作成しています。
