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

Webサイト運用カレンダーは、「毎月サイトを確認する」と書くだけでは動きません。期限までに準備が必要な作業と、状態を定期的に確かめる作業では予定の作り方が違います。担当者の退職やキャンペーン公開など、日付が決まってから発生する作業もあります。

まず固定期限・定期確認・出来事を契機とする作業へ分けます。各予定には主担当・代替担当・準備開始日・完了とする証拠を持たせます。未完了時の連絡先まで決めると、予定表が実際の運用を動かす道具になります。

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

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

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

期限日の予定だけでなく、確認・承認・支払いの開始日を置きます。休日や経理の締め日も考えます。完了証跡には更新後の新しい期限や決済結果を残し、ボタンを押した記録だけで終わらせません。

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

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

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

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

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

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

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

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

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

予定名には対象と行動が分かる言葉を使います。「サーバー確認」ではなく、「本番バックアップの成功時刻を確認」のように書きます。主担当が休みの場合に備え、代替担当と参照手順も設定します。

完了条件は画面、通知、作業記録などで示します。問題がなかった場合も確認日と確認者を残します。問題があった場合は、修正作業の所有者・期限・再確認日を新しい予定にします。

繰り返し予定を無期限に複製すると、形だけの作業になります。数回ごとに頻度と項目を見直します。異常が続く項目は頻度を上げ、役割を終えた項目は削除します。

個人の予定表だけで管理すると、退職時に予定も消えます。会社が管理できる共有カレンダーを使い、閲覧者と編集者を分けます。通知先は一人に限定せず、業務上必要な担当へ届くようにします。

月末には未完了と翌月の期限を確認します。年末には翌年の契約日と事業予定を反映します。日付を移しただけで完了扱いにせず、遅延理由と新しい承認を残します。

運用カレンダーの目的は、作業数を増やすことではありません。期限前に判断を始め、異常を次の行動へつなぐことです。担当・期限・証跡がそろった予定だけを残せば、兼任担当者でも優先順位を説明できます。