朝いちばんのデスクで、頭の中の順番を思い出しながら監視画面とバックアップの結果を一つずつ確認している一人運用の保守担当者
ドキュメント・引き継ぎ約17分

定期作業を手順化する｜日次・週次・月次を1枚のチェックリストに

朝いちばん、席についてブラウザを開く。監視画面を見て、バックアップの結果メールを見て、昨夜のバッチのログを見る。順番も、どこを見るかも、体が覚えています。

でも、それを誰かに説明しようとすると、意外と言葉が出てこない。「毎朝これとこれを見てます」と口では言えても、紙に書いたものはどこにもない。休んだ日に代わってもらうのは、ちょっと難しい。

これは、書かなかった人が悪いわけではありません。毎日できてしまっているものは、書き出す理由がないまま何年も過ぎるのです。困っていないから手が止まる。ごく自然なことです。

結論：定期作業の手順化は、①1週間、実際にやったことをそのままメモする → ②日次・週次・月次に振り分ける → ③1項目を「見る場所・正常な状態・違ったときの動き」の3行に落とす → ④1枚にまとめて、やった記録を残すの順で進めます。順番に意味があります。先に理想の運用表を作ろうとすると、たいてい続かないからです。まず、いま実際にやっていることを写し取るところから始めます。

いきなり完成形を目指さなくて大丈夫です。①だけでも、頭の中の荷物はかなり軽くなります。所要は、①に1週間（1日あたり数分）、②〜④で合計2時間ほどです。

何が起きているか：定期作業が手順にならない4つの理由

「そのうち書こう」と思いながら何年も書かれないのには、ちゃんと理由があります。自分の意志の弱さではないので、まずそこを分けておきます。

そして、もうひとつ実務的な話があります。経済産業省の「システム管理基準」でも、運用は手順を定めて実施し、その記録を残して点検するという考え方が土台に置かれています。社内の監査や、取引先からのセキュリティ確認で「日々の運用点検はどうしていますか」と聞かれる場面は、ある日突然やってきます。頭の中にある運用は、そのとき示すものがありません。

逆に言えば、この4つはどれも書き出すだけで半分は解ける問題です。次から順番に見ていきます。

定期作業を手順化する4ステップ

定期作業を日次・週次・月次の3つの頻度に振り分けて並べた図
頻度は「気づくのが1日遅れて困るか、1週間遅れて困るか」で決めると迷わない

一度に全部やろうとしなくて大丈夫です。上から順に、できたところまでで構いません。

① 1週間、実際にやったことをそのままメモする

最初にやるのは、設計ではなく記録です。あるべき運用表を考え始めると手が止まります。そうではなく、今週の自分を観察するだけにします。

書き方は雑で構いません。日付と、やったことを一行ずつ。「監視画面を見た」「バックアップのメールを確認」「ディスク見た」——この粒度で十分です。

記憶で書こうとすると、必ず抜けます。実物から拾うと早いです。

シェルの履歴からよく打つコマンドを拾うなら、こんな形で見られます。

history | awk '{$1=""; print substr($0,2)}' | sort | uniq -c | sort -rn | head -30

ここで大事なのは、「これは書くほどのことじゃない」を除外しないことです。30秒で終わる確認ほど、頭の中に埋もれています。そして休んだ日に代わりの人が困るのは、たいていその30秒のほうです。

1週間続けると、たいてい10〜20項目になります。思っていたより多い、と感じる人がほとんどです。それは、あなたが日々こなしてきた量がそれだけあったということです。

② 日次・週次・月次に振り分ける

出そろったら、頻度で分けます。ここでの判断軸はひとつだけにします。

その項目に異常があったとき、気づくのが「1日遅れて困る」なら日次。「1週間遅れて困る」なら週次。「1ヶ月遅れて困る」なら月次。

「毎日見たほうが安心だから日次」で決めると、日次の項目が増えすぎて続きません。日次は5分以内に収まる量が上限、と先に決めてしまうのがコツです。入りきらないものは週次に落とす。それで困るなら、その項目は本来監視で自動的に鳴らすべきものです。

振り分けの目安は、だいたいこのあたりに落ち着きます。

頻度よく入るものねらい
日次（5分以内）監視の未対応アラート、夜間バッチの成否、バックアップの成否、サービスの死活昨日から今朝までに壊れていないかを見る
週次（15〜30分）ディスク・メモリの使用量の推移、エラーログの傾向、遅いページ・遅いクエリ、不審なログイン試行単発では気づけない「じわじわ増えているもの」を見る
月次（1〜2時間）証明書・ドメイン・契約の期限、アカウントと権限の棚卸し、パッチ適用状況、EOLの確認、バックアップからの復元テスト期限があるもの、放っておくと静かに切れるものを見る

日次と週次の違いは、点で見るか、線で見るかです。ディスク使用量は、今日82%という数字だけ見ても判断できません。先週が78%だったと分かって初めて「このペースだと2ヶ月後に埋まる」と読めます。この「線で見る」感覚はディスク使用量とログの肥大化を監視するで扱っています。

月次に入る「期限もの」は、一覧にしておくと毎月同じ表を眺めるだけで済むようになります。証明書はSSL/TLS証明書の期限切れを防ぐ更新と監視、サポート終了はEOL（サポート終了）の棚卸し手順が対応します。

③ 1項目を「見る場所・正常な状態・違ったときの動き」の3行にする

ここが、この記事でいちばん効く部分です。振り分けただけの一覧は、実はまだ渡せません。「ディスクを見る」と書いてあっても、どこを見て、何なら正常で、違ったら何をするのかが書かれていないからです。

そこで、1項目を3行に決め打ちします。

たとえば、こう書きます。

【日次-3】ディスク使用量
  見る場所 : web01 に ssh して `df -h`（/ と /var を見る）
  正常な状態: どちらも使用率 80% 未満
  違ったら : 85%未満なら記録だけして週次で追う。
             85%以上なら当日中に /var/log を確認（→ ログ肥大の記事の手順へ）。
             95%以上は書き込み障害が近いので、その場で対応する。

3行にすると、いくつかのことが同時に起きます。まず、自分が何を基準に判断していたのかが自分でも分かる。次に、他の人が同じ判断をできるようになる。そして、「違ったときの動き」が書けない項目が出てきます。それは、見てはいるけれど、異常だったときにどうするか決めていなかった項目です。手順化して初めて見つかる穴で、見つかったこと自体が収穫です。

正常な状態を書くときは、いまの実測値を控えておくのがおすすめです。「だいたい20〜30件/日」のような普段の幅が書いてあると、数ヶ月後の自分が「これは多いのか」で迷わずに済みます。閾値の決め方そのものは監視アラートの閾値の決め方が参考になります。

なお、3行の書き方は障害対応の手順書と同じ考え方です。すでに障害対応 runbook テンプレートを作っているなら、その並びに合わせておくと、いざというとき同じ読み方で使えます。

④ 1枚にまとめて、やった記録を残す

最後に、置き場所と記録です。ここを決めないと、作った翌月には行方不明になります。

置き場所は、朝いちばんに開く場所にします。社内Wikiの奥深くではなく、ブラウザのブックマークバー、あるいはチャットのピン留め。開くのに3クリックかかる手順書は、忙しい朝に開かれません。あわせて、運用ドキュメントに最低限書くべき項目テンプレートで作った1枚があるなら、そこからリンクを張っておくと迷子になりません。

記録は、実行のたびに1行だけ残します。

2026-07-30 日次 山田 異常なし
2026-07-31 日次 山田 web01 のディスク 82%（先週78%）→ 週次で追う
2026-08-01 日次 （未実施：終日障害対応）

「異常なし」の行にも意味があります。これが積み重なると、平常時がどうだったかの記録になり、何かあったときに「いつから変わったか」を遡れます。そして未実施の行も、隠さず残すほうが役に立ちます。飛ばした日が続いていることに、後から気づけるからです。

そして、全部できない日を最初から許しておきます。日次の中でも「これだけは外せない」最低ラインを2〜3個決めて印を付けておく。忙しい日はそこだけ。これがないと、1日サボった時点で表ごと使われなくなります。

おまけ：手順書ができたら、そのまま自動化の設計書になる

3行に落とした項目は、そのまま自動化の仕様になっています。「見る場所＝取得するコマンド」「正常な状態＝判定条件」「違ったときの動き＝通知先」だからです。

ただ、いきなり全部を自動化しなくて大丈夫です。効き目の順に並べると、こうなります。

  1. 見に行くのをやめて、届くようにする。毎朝バラバラの画面を開いているものを、1通のメールやチャット通知にまとめる。これだけで日次が数分縮みます。
  2. 異常なときだけ鳴らす。正常時の通知が毎日届くと、そのうち読まなくなります。ただし「何も来ない＝正常」は、通知の仕組み自体が壊れたときに見分けがつきません。ここは監視自体が止まっていないか｜「アラートが来ない」を検知するとセットで考えます。
  3. 判定まで自動にする。閾値超えを検知して鳴らすところまで寄せる。

そして、人が目で見る作業をゼロにはしないでおきます。数字の異常は機械が得意ですが、「なんとなくいつもと違う」は人が先に気づきます。週次で5分だけグラフを眺める時間は、残しておく価値があります。

具体例：社内システムと公開サイトを一人で見ている場合

社内の業務システムと会社の公開サイトを一人で保守している、という状況で考えてみます。担当して3年目、手順書はありません。

①1週間のメモを取ってみたところ、14項目が出てきました。自分では「毎朝5分くらい」と思っていたのに、書き出すと監視画面・バックアップメール・バッチのログ・受注連携の件数と、朝だけで4つ。加えて、水曜にディスクを見る、月初に証明書を確認する、といった不定期のものが混ざっていました。「思っていたより多い」というのが最初の発見でした。

②振り分けでは、日次を4項目に絞りました。監視の未対応アラート、夜間バッチの成否、バックアップの成否、受注連携の件数。この4つで所要4分です。ディスクとエラーログの傾向は週次へ、証明書・アカウント棚卸し・パッチ適用は月次へ回しました。「毎日見たい気持ち」はありましたが、日次5分の枠を守るほうを優先しています。

③3行化をしていて、穴が2つ見つかりました。受注連携の件数は毎朝見ていたのに、何件なら正常なのかを決めていなかったこと。そしてバックアップが失敗していたとき、復元できるかを確かめたことがなかったこと。前者は過去1ヶ月の実測から「平日80〜150件、土日20〜60件」と書き、後者は月次に復元テストを1項目足しました（バックアップからの復元テスト手順）。手順を書く作業が、そのまま点検になった形です。

④1枚化では、チャットの自分専用チャンネルにピン留めし、実行記録もそこに1行ずつ投げることにしました。作成にかかった時間は、①の1週間を別にして2時間ほどです。

3ヶ月後。夏休みで4日空けるとき、この1枚を同僚に渡して日次の4項目だけ頼めました。以前は「まあ、4日くらいなら」と誰にも頼まずに休んでいた場面です。戻ってきたら、実行記録に4日分の「異常なし」が並んでいました。その4行を見たときの安心感は、手順書を書いた理由そのものでした。

影響：1枚あると何が変わるか

そして、いちばん大きいのは属人化がひとつ減ることかもしれません。頭の中にしかない運用は、本人にとっても重荷です。書いて渡せる形にすることは、責任を手放すことではなく、抱えているものを置ける場所を作ることです。この考え方は属人化を防ぐナレッジ共有のはじめ方にもまとめています。

明日やること：メモ帳を1枚開くところから

いきなり全部は要りません。明日できる、いちばん小さな一歩はこれです。

  1. メモ帳（紙でもテキストファイルでも）を1枚開いて、日付を書く。
  2. 明日の朝やった確認作業を、その場で1行ずつ書く。「監視画面を見た」で十分です。
  3. これを1週間続ける。1日あたり1〜2分です。
  4. 1週間たったら、出てきた項目を日次・週次・月次に振り分ける。
  5. 日次の項目だけ、「見る場所・正常な状態・違ったときの動き」の3行に落とす。

1〜3までなら、明日の朝2分で始められます。設計は来週の自分に任せて、明日は書き写すだけにしてください。頭の中にあるものを外に出す作業は、それ自体がいちばん時間のかかる部分で、そしてやってしまえば二度とゼロには戻りません。

「定期作業の手順化」チェックリスト

コピーして、自分のメモに当ててみてください。全部そろえる必要はありません。

まず外せない最低ラインはこの3つです。時間がなくても、ここだけは押さえます。

次の項目は、余裕があるとき・より確実にしたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「1週間分を書き出した」さえ言えれば、頭の中にしかなかった運用は、もう外に出ています。

よければ、こちらも

定期作業の1枚は、ほかの運用ドキュメントとつながると効きが増します。

手元のチェックリストを1項目ずつ確かめ終えて、静かな達成感とともに顔を上げている保守運用の担当者

定期作業を手順化するのは、几帳面な人のための作業ではありません。毎日ちゃんとやってきた人が、その中身をやっと外に出せる作業です。書けるということは、それだけのことを続けてきたということでもあります。

今日は、明日の朝に開くメモ帳を1枚用意するところまでで十分です。書き出すのは明日の自分に任せてしまいましょう。動いて当たり前のシステムが今日も動いていたのは、記録に残っていないあなたの数分があったからです。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語