IT担当者がいない会社でのサーバー管理体制のつくり方

IT担当者がいない会社でも、サーバー管理を誰か一人の善意へ任せる必要はありません。技術作業を外部へ委託し、社内は契約と優先順位を管理する形なら、専任者なしでも継続できます。

最初に作るのは詳しい手順書ではなく、責任者・実務担当・外部支援先の三者が何を決めるかという分担です。分からない作業を抱えず、判断と連絡が止まらない体制を目指します。

社内に責任者と実務担当を一人ずつ置く

責任者は予算、契約、復旧の優先順位を決めます。実務担当は更新通知を受け取り、管理台帳と外部連絡を維持します。同じ人が兼ねる場合でも、休暇や退職に備えて代理者を決めます。

技術に詳しいことより、未対応を放置せず記録できることが重要です。管理画面の最高権限を全員へ渡す必要はありません。日常の確認に必要な権限を分け、契約変更は承認を通します。

責任者と実務担当は、月に一度だけ未処理課題を確認します。判断が必要な項目を実務担当が抱え込まず、費用や停止を伴う作業は責任者へ上げます。代理者も同じ記録を読める状態にします。

台帳には、契約名義・請求先・登録メール・ドメイン・DNS・Web・メール・制作会社を記録します。パスワードそのものは平文で載せず、会社の保管場所への参照を示します。更新日と問い合わせ先も残します。

最初から完璧な資産台帳を目指さず、現在使っているサイトとメールから始めます。請求書・DNS応答・管理画面を照合し、所有者が不明な項目を課題として残します。新しいサービスは台帳へ追加してから契約します。

台帳の更新責任者と保存場所を決めます。複製が複数あると古い情報を参照するため、正本は一つにします。閲覧できない人が出ないように、代理者で開けるかを確認します。

月次では、更新通知・バックアップ失敗・容量増加・管理者変更を確認します。サイトの表示とフォーム通知も利用者側から見ます。異常がなくても確認日を残し、未処理の通知が積み上がらないようにします。

年次では、契約時の想定と実績を比べます。料金・利用者数・障害・復元試験・不要アカウントを見直します。担当交代があった場合は年次を待たず、アカウント停止と連絡先変更を同日に行います。

確認項目を増やしすぎると続きません。月次は通知と異常の早期発見、年次は契約と構成の判断に絞ります。作業結果には次回日を付け、未完了だけを引き継ぎます。

制作会社や保守会社には、WordPress更新・監視・バックアップ確認など具体的な作業を依頼します。社内は、いつ止めてよいか、どの機能を優先して戻すかを判断します。委託先へ丸投げすると、契約終了時に情報が残りません。

契約には対象サイト・対応時間・報告内容・緊急連絡・アカウント返却を記載します。サーバー会社のサポート範囲も別に確認します。委託先が対応できない休日や専門領域には、代替連絡先を用意します。

月次報告は作業した項目だけでなく、失敗と保留を分けて受け取ります。社内担当者は報告を台帳へ結び付け、期限のある課題を責任者へ伝えます。委託先変更時の引き継ぎ資料にもなります。

監視は通知を送るだけでなく、受け取った人が次の行動を選べる必要があります。表示停止・フォーム失敗・証明書期限など、業務影響の大きい項目から始めます。通知先を個人メール一つへ固定しません。

通知文には、対象URL・発生時刻・確認画面・最初の連絡先を含めます。夜間に即時対応しない方針なら、翌営業日に確認する基準を決めます。不要な通知を減らし、本当に対応する警告を見逃さないようにします。

通知経路は年に一度テストします。共有メールへ届いても、担当者が振り分けルールで見落とす場合があります。受信から外部連絡までの時間を測り、対応できない通知は設定を見直します。

障害を検知したら、変更を止め、現象と時刻を記録します。サーバー会社の障害情報を見て、自社だけの問題なら制作会社へ切り分けを依頼します。社外告知を出す人と技術対応する人を分けます。

年に一度は、テスト障害を想定して台帳から連絡先へ到達できるか試します。連絡できなかった番号やログインできないアカウントを直します。専任者がいない会社の強みは、複雑な仕組みより短い連絡経路を維持できることです。

訓練後は、判断に必要だった情報だけを手順へ足します。説明を増やすより、対象・時刻・影響・連絡先の四点をすぐ出せる方が役立ちます。次の代理者が同じ流れを再現できれば体制は機能しています。