問い合わせフォームの通知が届かないため制作会社へ連絡したところ、メールの管理会社へ確認するよう案内された。メール会社からは送信元の確認を求められ、社内担当が同じ説明を繰り返している。ホームページと会社メールを別々に管理している企業では、連絡先が分かっていても、確認をどのようにつなぐかで止まることがあります。
保守を頼むときは、会社名や電話番号だけでなく、症状、管理しているサービス、契約先、確認を頼む窓口を結び付けて整理します。さらに、各社からの回答を社内の誰がまとめるかを決めます。原因が分からない段階でも、確認済みのことと、次に聞くことを引き継げる状態が目標です。
この記事では、大阪の企業がホームページ保守を検討する際にも使える、Web・DNS・メールの管理範囲の整理方法を説明します。扱う課題は地域共通です。現在の契約を続けながら連絡体制を整える内容で、サーバー移管やメール設定の操作手順は扱いません。
「サーバーの担当」を、機能ごとに分けて確かめる
まず、Webサイトの表示やフォームを管理する人と、会社メールを管理する人が同じかを確認します。同じドメイン名を使っていても、Webとメールが同じ環境で動いているとは限りません。「サーバーはA社」とだけ記録せず、何を置き、何を管理している契約かを補います。
DNSは、ドメイン名に対してWebやメールなどの接続先を案内する設定を担います。ドメインの登録・更新を扱う契約とも分けて確認します。同じ会社の管理画面にまとめられている場合でも、登録の更新手続き、DNSの設定変更、Webの保守、メール利用者の管理では、担当や権限が異なることがあります。
Microsoft 365の公式FAQでは、メールの行先に関係するMXレコードの変更と、一般公開のWebサイトを別のホスティングで用意することが説明されています。Webとメールで同じドメインを使っていても、担当するサービスを分けて把握する必要があると分かります。Microsoft 365のドメインFAQ
社内の管理表には、サービス名、契約先、操作できる担当、問い合わせ窓口を分けて記入します。請求書にある会社名と、技術的な質問を受ける窓口が一致するとは限りません。販売代理店を通じた契約なら、問い合わせは代理店経由なのか、利用企業が直接行うのかも契約先へ確かめます。
この段階で全員に管理者権限を渡す必要はありません。誰が確認でき、変更する場合は誰へ依頼するかが分かれば、連絡の入口を作れます。権限がない人へ「設定を見てください」と頼み続ける状態を避けるための整理です。
症状と確認窓口をつなぐ表を作る
次の表は、複数の会社に保守を頼む架空の企業の例です。A社はWeb保守、B社はDNS管理、C社はメールの契約窓口とします。実在する契約や障害事例ではなく、自社の連絡表を作るための設計例です。表の症状だけで原因や責任が確定するわけではありません。
| 見えている症状 | 確認するサービス | 例の契約先・窓口 | 社内担当がつなぐ情報 |
|---|---|---|---|
| ページが開かない | Webの表示・稼働状況。必要に応じDNS | A社からWeb側の確認。DNS確認はB社へ | 対象URL、日時、表示された内容、A社の確認範囲 |
| フォームの通知だけ届かない | フォームの送信処理と、通知先メールの受信 | A社とC社。それぞれの確認対象を分ける | 該当する送信の日時、通知先、送信側・受信側で確認できたこと |
| 会社メールを広く受信できない | メール利用環境・サービス状況。必要に応じDNS | C社へ状況を伝え、DNS確認はB社と連携 | 対象者の範囲、送信元の違い、エラー、直前の変更 |
最初に連絡する窓口は、実際の保守契約に合わせます。総合窓口を一社に依頼している場合は、その窓口が他社へ問い合わせるのか、社内担当へ確認先を案内するのかを決めます。総合窓口という名前だけで、他社サービスを操作できることにはなりません。
フォーム通知の例では、「ホームページが表示されているからWeb側は正常」とは判断できません。また、「送信完了の画面が出たから受信まで完了した」とも限りません。Web側でどの処理まで確認できたか、メール側に該当する記録があるかを、各担当の確認範囲に合わせて照合します。
Google Workspaceの受信トラブルの案内でも、MXレコード、アカウントやドメインの状態、メールログなど、複数の確認対象が示されています。メールが見当たらないという症状から、一つの設定だけを原因と決めないための参考になります。Google Workspaceの受信トラブルの案内
連絡表には、自社が契約するサービスの公式障害情報のページも添えます。掲載された障害の対象や時刻が自社の症状と合うかを確認する材料です。情報が出ていないことだけで、自社環境に問題がないと扱わないようにします。
図は架空の連絡体制の例です。矢印は担当間の情報共有を表し、メールの配送経路や原因の確定を示していません。
最初の連絡では、原因の推測より確認できた状況を渡す
問い合わせるときは、「サーバーがおかしい」ではなく、何が、いつから、どの範囲で起きているかを伝えます。例えば、会社メールすべてなのか、一つのアドレスだけなのか、フォーム通知だけなのかを分けます。確認していない範囲は未確認として残し、全社の障害へ広げて書かないようにします。
一件の連絡票に、発生日時、対象URLやメールアドレスの範囲、利用した環境、画面や返送メールに出た表示、直前に行った変更をまとめます。時刻は「朝から」だけでなく、確認した日時を記します。複数の担当が別の時間の現象を調べていると、回答が食い違って見えることがあります。
正常に使えている機能も添えます。Webページは閲覧できる、通常の業務メールは受信できる、特定の端末だけで発生する、といった情報です。これは原因を断定する材料ではなく、確認する範囲を担当者と共有するための情報です。
ログやメール本文を送る必要がある場合は、担当者から求められた範囲と受渡方法を確認します。連絡先一覧にパスワードを一緒に記載したり、関係のない顧客情報を全社へ転送したりする形にはしません。受付番号や確認時刻を残せば、詳細を必要な担当者だけへ共有しながら話をつなげられます。
テスト送信が必要になったときも、実施者、宛先、時刻、使用する文面をそろえます。担当者ごとに同じフォームを何度も送ると、どの通知の確認結果か追いにくくなります。試験で問い合わせや自動返信が発生する場合は、実運用への影響を確認してから、合意した方法で行います。
「契約外」の回答を、次の確認へ引き継ぐ
担当会社から契約外と案内されたときは、その言葉だけで別会社へ送り直すのではなく、何が確認済みで、どこから未確認なのかを分けます。対象サービス自体が契約外なのか、調査はできても変更作業が別料金なのかでも、次に決めることが違います。
例えばA社がフォームの設定だけ確認したなら、「Webは問題なし」と要約せず、「フォームの宛先設定を確認。送信処理の記録は未確認」と残します。C社が指定した時刻の受信記録を確認した場合も、調べたアドレスや時間帯を含めます。確認の範囲を落とすと、まだ調べていない場所が正常と扱われてしまいます。
次の窓口へ渡す内容は、症状、確認した対象、結果、残っている質問、元の問い合わせ番号を一つにまとめます。回答を集約する社内担当が、各社へ同じ案件として伝えます。担当同士で直接やり取りしてもらう場合も、その連携が依頼範囲に含まれるかを確かめておきます。
社内の集約担当は、技術的な原因を一人で判断する役ではありません。質問がどこで止まっているか、追加の調査を誰に依頼するか、作業の承認が必要かを整理する役です。主担当が不在でも追えるよう、会社で共有できる場所へ回答と次の確認先を残します。
受付と復旧の約束も区別します。連絡を受け付ける時間、調査を開始する条件、追加作業の見積り、完了後に確認する項目を別々に確認します。「保守に入っている」「緊急対応あり」という短い説明だけで、すべての障害を直ちに解消できると受け取らないことが大切です。
DNSなどを変える前に、他サービスの確認担当を決める
調査の結果、DNSやメールの設定変更が提案されたら、作業する担当だけでなく、影響を確認する担当も決めます。ホームページのための変更という説明でも、同じ管理環境にメールの設定が含まれていれば、その扱いを確かめる必要があります。
変更依頼には、対象サービス、変更する範囲、承認者、実施者、作業後の確認者を記します。Webの表示とフォームを確認する人、会社メールを確認する人を分け、どちらの結果がそろったら対応完了とするかを共有します。具体的な設定値や実行手順は、現在の構成を確認できる担当者が判断します。
同じ時間帯に別会社が別の設定を変更すると、何が症状に関係したのか追いにくくなります。作業の予定と変更した内容を集約担当へ伝え、他の変更と重なっていないかを確認します。問題が出たときに戻すかどうか、誰が判断し、誰が作業できるかも事前に決めます。
これは、社内のWeb担当者がDNSを自力で書き換えるための案内ではありません。保守会社へ依頼するときに、作業だけが先行せず、関係するサービスの担当者へ確認がつながるようにする準備です。
作業後の報告は「対応済み」だけで終えず、何を変更し、誰が何を確かめたかを残します。フォーム通知なら、合意した試験の送信時刻と、通知先で確認した結果を対応させます。通常の業務メールにも影響する変更なら、その確認結果は別に記録します。一つの画面が直ったことと、関係する機能の確認が終わったことを分けるためです。
症状が解消しても原因が特定できなかった場合は、その状態を記録します。「原因不明だが現在は再現しない」と「原因を確認して修正した」では、再発した際に渡す情報が違います。残る質問や継続して見る項目があれば、担当と次に確認する条件を決めます。原因が分からないまま、特定の会社の責任として連絡表に残さないようにします。
連絡図は、変更と担当交代のたびに更新する
連絡表ができたら、メールを使えない状況でも確認できる保管場所と、契約上利用できる代替の連絡方法を記します。障害が起きているメールアドレスだけが唯一の窓口だと、依頼を送れたか、回答が届いたかを確認しにくくなります。
営業時間外の扱いは、各社の契約に合わせます。通常の会社案内に載っている受付時間を、そのまま保守の対応時間や復旧保証として転記しません。夜間は受付のみ、翌営業日に調査などの条件があるなら、社内の連絡表でも分かるようにします。
定期確認では、電話番号が有効かだけでなく、担当サービスと依頼できる作業が変わっていないかを見ます。メールサービスの追加、フォームの変更、社内担当の異動、契約更新は見直しのきっかけになります。新しい窓口を追加した日と、確認した相手を残せば、古い情報を使い続けることに気付きやすくなります。
最初から複雑な管理図を作る必要はありません。自社で起こり得る一つの症状を選び、連絡先へ渡す情報と、回答の戻り先を線で結びます。その線の途中に「誰が確認するか不明」「別料金か未確認」があれば、保守を依頼する前に確かめる項目です。
管理範囲と連絡のつなぎ方を、保守の相談材料にする
Web・DNS・メールを別々に管理していても、症状と確認対象、各社の窓口、社内の集約担当が対応していれば、次に何を聞くかを整理できます。担当会社を一つにまとめることだけを解決策にせず、現在の契約で誰がどこまで確認するかを明確にしましょう。
みやあじよのホームページ保守・運用では、現在の管理環境や契約を確認し、作業範囲、不具合の切り分け、関係先との連携を整理します。自社の連絡表を基に依頼内容を見直したい場合は、管理環境と不具合の切り分け相談で支援内容をご確認ください。受付時間や追加作業を含む具体的な範囲は、個別の環境と契約に合わせて確認します。
