古いまま放置しない｜運用ドキュメントを腐らせない更新ルール
「この手順、書いてあるとおりにやったのに動かない」 障害の夜、頼りにした運用ドキュメントの中身が実態とズレていて、かえって時間を溶かしてしまった——そんな経験、ありませんか。
作ったときは正しかったはずのドキュメントも、サーバーを移したり、担当者が変わったり、手順をひとつ変えたりするたびに、少しずつ現実とズレていきます。気づいたときには「書いてあることを信じていいのか分からない資料」になっている。これは、あなたのマメさが足りないからではありません。「作る」より「保つ」ほうがずっと難しいのが運用ドキュメントです。今日は、分厚い見直し作業に頼らず、ドキュメントを古いまま腐らせないための「更新の仕組み」を、一緒に軽く決めていきましょう。
結論：ドキュメントは「定期的にまとめて見直す」より、「変えたら、その場で直す」を作業の一部に組み込むほうが続きます。具体的には、①各ドキュメントに「最終更新日・記入者」を必ず載せる ②本番を変える手順の最後に「ドキュメント更新」を1行入れる ③直せないときは「ここは古いかも」と印だけ残す。この3つで、完璧な鮮度は求めず「信じていい度」を保ちます。
環境や体制（システム数、チームか一人か、wikiかテキストか）で最適な形は変わります。本文は一例として、自分の現場が続けられる軽さに読み替えてください。
何が起きているか：ドキュメントは黙って古くなる
運用ドキュメントがズレていく原因は、サボりではなく「更新のきっかけがない」ことです。
- サーバーやミドルウェアを入れ替えたのに、構成の記述は前のまま
- 手順を1つ改善したのに、手順書は古いやり方のまま
- 連絡先や契約先が変わったのに、引き継ぎ資料は前任者時代のまま
- 「あとでまとめて直そう」と思ったまま、次の障害が来て流れる
作業とドキュメント更新が別々のタイミングになっていると、更新はいつも後回しになります。そして厄介なのは、古いドキュメントは「古い」という顔をしていないことです。パッと見は整っているのに中身だけ古い。だから障害の夜に信じて読んで、ハマる。
つまり問題は「更新を忘れる」ことより、更新する瞬間が決まっていないことにあります。ここを仕組みで埋めれば、記憶力や意志の強さに頼らなくてよくなります。
具体例：古いドキュメントは「無い」より危ないことがある
同じ「深夜にサイトが落ちた」でも、ドキュメントの鮮度で景色が変わります。
古いドキュメントを信じたとき：手順書どおりにサービスを再起動しようとしたら、コマンドもパスも前の構成のまま。動かず、原因が手順なのか障害なのか切り分けられず、二重に消耗する。「書いてある＝正しい」と思い込む分、何もないときより判断が遅れることすらあります。
鮮度が保たれているとき：先頭に「最終更新: 先月／記入者: 自分」と書かれている。最近の変更履歴も数行ある。だから安心して読め、そのまま初動に入れる。
差を生んだのは情報量ではなく、「この資料をいま信じていいか」が分かるかどうかです。だから目指すのは「常に完璧」ではなく、「古いところは古いと分かる」状態です。
腐らせない3つの更新ルール
大がかりな棚卸しは、時間が取れずに結局続きません。だから「小さく・その場で」を仕組みにします。
- 各ドキュメントの先頭に「最終更新日・記入者」を必ず置く。これだけで、読む人が鮮度を判断できます。更新したら日付を直す——それを更新の合図にします。日付が数か月前のまま、が「見直しどき」のサインになります。
- 「本番を変える手順」の最後の1行に、ドキュメント更新を入れる。リリース手順書や変更作業のチェックリストの末尾に「関連ドキュメントを更新した」を1項目足すだけ。作業とセットにすれば、更新のタイミングを覚えておく必要がなくなります。属人化を防ぐ変更管理台帳と相性がよいところです。
- 直せないときは「印」だけ残す。急いでいて本文を直す余裕がないなら、その場所に「※2026-07-06時点で古いかも。要確認」と1行残す。中途半端でも、読む人が地雷を踏まなくなります。「正しく直す」より「危ないと分かる」を優先します。
補助として、月初などに「更新日が古い順」でドキュメントをざっと眺める習慣があると、印を付けた箇所や放置箇所に気づけます。ただし主役は①〜③の「その場で」です。定期見直しは、あくまで取りこぼしの保険と考えてください。
そのまま使えるひな型
各ドキュメントの先頭に、この数行を置くだけで始められます。
─────────────────────────────
最終更新: 2026-07-06 / 記入者: 自分
このドキュメントの担当: 〇〇
※内容を変えたら、この日付を必ず直す
※直せないときは本文に「※古いかも・要確認」と印を残す
─────────────────────────────そして、リリース・変更作業のチェックリストの末尾に、この1行を足します。
- [ ] 今回の変更に関わる運用ドキュメントを更新した（or「古いかも」の印を付けた）たったこれだけで、「作業したら直す」が回り始めます。仕組みにしてしまえば、意志の力はいりません。
影響：鮮度が保たれると、障害も引き継ぎも軽くなる
ドキュメントを腐らせないだけで、いざというときの負担が変わります。
- 障害対応で迷わない：信じて読めるので、手順どおり動けて初動が速い。
- 引き継ぎで揉めない：受け取る側が「これは最新か」を日付で判断できる。前任者への確認回数が減る。
- 自分が消耗しない：「これ合ってたっけ」と毎回不安になったり、記憶で補ったりする負担が減る。
- 少しずつ良くなる：完璧を目指さなくても、触るたびに直るので自然に鮮度が上がっていく。
ドキュメントは、評価や体裁のために保つのではありません。いちばん助かるのは、次にそれを開く誰か——たいていは、未来のあなた自身です。
続けるコツ：完璧な最新化を目指さない
更新ルールが続かない一番の理由は、「常に完璧に最新であるべき」と気負って、直せないと自己嫌悪になり、やがて見なくなることです。だから、力を抜きます。
- 「正しく直す」より「古いと分かる」を優先：印を残すだけでも十分価値がある。
- まとめて直そうとしない：変えた場所だけ、その場で1行。全体の整合性は後回しでいい。
- 更新日を直すのは義務にする：中身より、まず日付。鮮度の表示が信頼の土台になる。
- 重要なドキュメントから始める：全部は無理。障害の夜に開くもの（アクセス情報・連絡先・障害初動）から鮮度を守る。
「いつも完璧に最新」ではなく「信じていいか判断できる」。それだけで、ドキュメントは十分に役立ちます。
明日やること
- いちばんよく使う運用ドキュメントの先頭に「最終更新日・記入者」を入れる
- リリース・変更作業のチェックリスト末尾に「関連ドキュメントを更新した」を1項目足す
- 今ズレに気づいている箇所に「※古いかも・要確認」の印を1つ残す
- 更新日が古い順に、手持ちのドキュメントをざっと眺めてみる
今日のチェックリスト
- 主要ドキュメントの先頭に「最終更新日・記入者」を書いた
- 「内容を変えたら日付を直す」を決めた
- 変更・リリース作業の最後に「ドキュメント更新」を1行入れた
- 直せない箇所に「古いかも・要確認」の印を残す運用にした
- まず守るドキュメント（アクセス情報・連絡先・障害初動）を決めた
- 更新日が古い順に見直す軽い習慣を持った（保険として）
ドキュメントは、一度作って終わりではなく、少しずつ育てて保つものです。完璧に最新でなくて大丈夫。「変えたら直す」を一度だけ仕組みにしておけば、あとは触るたびに勝手に鮮度が上がっていきます。まずは今日、いちばん大事な1枚に「最終更新日」を書き足すところから始めてみましょう。
よければ、こちらも
保守運用の実務ヒントを、メールでお届けしています。よかったら受け取ってください。