Webサイト運用カレンダーの作り方【年次・月次確認】

Webサイト運用カレンダーは、契約更新などの「期限が決まっている予定」と、フォームやバックアップなどの「定期的な確認」を分けて作ると使いやすくなります。会社で共有しているカレンダーや表計算で十分です。

毎月の確認と年1回の見直しは、次のように分けられます。頻度は小規模な会社サイトの例です。注文を受けるサイトや更新が多いサイトでは、監視やバックアップ確認をもっと短い間隔で行います。

緊急性の高い脆弱性対応や障害対応は、この定期予定を待たずに行います。

固定期限は満了日から準備を逆算する

サーバー・ドメイン・有料プラグイン・外部サービスには契約期限があります。自動更新であっても、決済日と登録カードの確認日を予定にします。解約やプラン変更の申請期限が満了日より前なら、その日を起点に逆算します。

ICANNの更新通知に関する案内では、認定レジストラから失効前のおおむね1か月前と1週間前に通知する要件が説明されています。しかし通知が旧担当者へ届けば、会社は期限に気づけません。事業者の通知と自社の予定を二重に使います。

期限日の予定だけでなく、確認・承認・支払いの開始日を置きます。休日や経理の締め日も考えます。更新後の新しい期限や決済結果が分かれば、手続きが終わったか確認できます。

月次確認は異常時の次の行動まで決める

月次作業には、サイト監視の結果・フォームの受信・バックアップの成功・更新待ちの有無などを置きます。すべてを月初に詰め込まず、業務の締めや保守会社の報告日に合わせます。重要度が高い項目は月次より短い頻度が必要です。

WordPressではSite Healthの公式解説を確認の入口にできます。更新状態・テーマ・プラグイン・サーバー・データベースなどの情報が表示されます。ただし警告を見ただけで完了とせず、対応者と期限を別の予定へつなぎます。

「フォームを確認する」なら、実際に送信して指定先で受信できたかを確認します。「バックアップ確認」なら、対象と成功時刻を見ます。異常があった場合の依頼先と優先度を予定の説明欄へ書きます。

四半期や年次には変化を見つける予定を置く

毎月変わらない項目を眺めるだけでは、契約や管理体制のずれを見落とします。四半期や半年ごとに管理者アカウント、外部委託先、通知先を見直します。頻度は固定せず、担当交代や扱う情報の重要度に合わせます。

年次には契約全体・予算・復旧体制・不要サービスを見直す予定を置きます。棚卸しは台帳を読む日ではなく、実際の管理画面や請求と照合する日です。見つけた差分の修正は、影響と承認を確認して別日に計画します。

年間の販売・採用・休業予定も重ねます。長期休暇前には連絡体制と更新作業を確認します。アクセスが増える施策の前には、負荷確認と障害時の判断者を決めます。

人やサイトの変更をきっかけに予定を追加する

担当者の退職・異動は、年次確認を待たずに処理します。権限の追加、通知先の変更、旧権限の停止を人事予定へ連動させます。制作会社との契約変更も、管理対象と緊急連絡先を見直すきっかけです。

WordPressやPHPの大きな更新、フォーム改修、ドメイン変更もイベントです。事前バックアップ、検証、公開後確認を一つのまとまりとして予定へ置きます。公開日だけを書き、準備と確認を担当者の記憶へ残しません。

新しい外部サービスを導入したら、契約期限と月次確認の要否をその場で決めます。廃止したサービスは今後の予定から外します。カレンダーと資産台帳を同時に更新すると、存在しない作業が残り続けません。

予定の説明欄は短くても使えます

たとえば「毎月第1営業日：問い合わせフォーム確認」という予定なら、説明欄に対象URL、担当者、正常時の通知先、届かなかった場合の相談先があれば作業しやすくなります。

確認結果は「9月分、送信・受信とも正常」のような短い記録で構いません。異常があった場合だけ、症状と対応状況を添えます。すべての予定に長い報告書を求めるより、必要なことが続けられる形の方が良いかと思います。

保守会社の作業と重複させない

保守会社が更新や監視を行っているなら、社内の予定は報告確認と、契約・掲載内容など自社でしか判断できない項目を中心にできます。同じ検査を社内外で繰り返す必要はありません。

個人の予定表だけに置くと担当交代で見えなくなるため、会社で引き継げる保存先にしておくと安心です。カレンダーは作業を増やすためではなく、忘れると困る予定を、無理なく続けられる形にするためのものです。