暫定対応と恒久対応を分けて管理する｜「戻し忘れ」を防ぐ残し方
「とりあえずサーバーを再起動したら直った」。 「エラーになる処理を、いったんコメントアウトして止めた」。 「タイムアウトが厳しいので、設定を長めに広げて逃がした」。
障害を前にしたとき、まずは止血——つまり暫定対応で被害を止めるのは、正しい判断です。一人で保守運用をしていれば、なおさら「まず止める」が最優先になります。
こわいのは、そのあとです。 止血できて安心した瞬間に、暫定対応が「なかったこと」になり、恒久対応に戻さないまま本番に残り続ける。半年後、まったく別の障害の原因が、実はその暫定対応だった——これは、責められるべき油断ではなく、記録の仕組みがないと誰にでも起きることです。
この記事では、暫定対応（一時対処）と恒久対応を分けて管理し、戻し忘れ・直し忘れを防ぐ残し方を、一人運用でも回る軽さで一緒に整理します。
結論：暫定対応を打ったら、その場で「暫定対応リスト」に1行だけ残す。書くのは〈いつ・何を・なぜ暫定か・戻す条件・期限〉の5つだけです。そして暫定は必ず「借金」として見える場所に積む（台帳・チケット・コード内の目印）。恒久対応が終わったら、リストから消して初めて完了。この「残す→積む→消す」を回すだけで、戻し忘れの多くは防げます。
そもそも、なぜ暫定対応は消えてしまうのか
暫定対応が残り続けるのは、忘れっぽいからではありません。構造的に消えやすいからです。
- 障害が止まると、緊張が解ける。「直った」で一区切りついてしまい、そこから先が後回しになる。
- 暫定対応は、往々にして目立たない。設定を1行変えた、cronを一時的に止めた——コードの大きな変更と違って、記憶にも記録にも残りにくい。
- 一人運用だと、引き継ぎ相手がいない。誰かに「これ暫定だから戻してね」と言う機会そのものがなく、自分の頭の中だけに残る。
- 「動いているもの」は触りづらい。暫定で直った状態が続くと、恒久対応の優先度がどんどん下がる。
だから、気合や記憶に頼るのではなく、打った瞬間に手が動いて記録が残る——その仕組みを先に用意しておきます。ここが今日のいちばんの肝です。
暫定対応を打ったら、その場で1行残す
止血できたら、落ち着く前に、「暫定対応リスト」に1行だけ書きます。場所は、いつも見る台帳・チケット・作業ログの近く——普段の運用でどうしても目に入るところが一番です。書く項目は、次の5つだけにします。
- いつ：暫定対応を打った日付。
- 何を：何を、どう変えたか（例：
nginxのタイムアウトを30秒→120秒に広げた／集計cronを一時停止した）。 - なぜ暫定か：本来どうあるべきで、いまなぜ間に合わせなのか（例：重いクエリが本原因。根治するまでの逃がし）。
- 戻す条件：何が済んだら恒久対応に移せるか（例：クエリを改善したら元の30秒に戻す）。
- 期限（見直し日）：いつまでに手を付けるか。決められなければ「◯週間後に必ず見直す」でよい。
5つで十分です。長い報告書はいりません。大事なのは、「これは暫定で、まだ終わっていない」という事実が、あとから自分の目に必ず入ること。多くの戻し忘れは、この1行がないだけで起きています。
「暫定対応リスト」の1行の例
コピーして、自分の台帳に当ててみてください。
| 日付 | 何を(暫定内容) | なぜ暫定か | 戻す条件 | 見直し日 | 状態 |
|------|----------------|-----------|----------|----------|------|
| 07/11 | nginxのproxy timeoutを120秒に延長 | 重い集計クエリが本原因。根治まで逃がす | クエリ改善後に30秒へ戻す | 07/25 | 未対応 |状態は「未対応／対応中／恒久化済（=完了）」の3つだけで回ります。恒久対応が終わって初めて、この行を消せます。
暫定を「借金」として見える場所に積む
リストに書いたら、次は現物にも目印を残します。リストと現物の両方に痕跡があると、片方を見落としても、もう片方で気づけます。一人運用の保険です。
- コードを暫定で変えたなら、その場所にコメントで目印を付けます。
// TODO(暫定): クエリ改善後にこの分岐を戻す（07/25まで）のように、「暫定」という語と戻す条件・期限を一緒に書くのがコツ。あとでgrepで暫定対応を一覧できます（例：grep -rn "TODO(暫定)" .）。 - 設定を暫定で変えたなら、変更管理の記録に「暫定」と明記します。設定ファイルにコメントが書けるなら、その行のそばに理由と戻す条件を残しておくと、次に触る人（未来の自分）が迷いません。
- cronやジョブを一時停止したなら、止めた事実そのものが忘れやすいので、リストの見直し日を短めに置きます。「止めっぱなし」は静かな障害のもとです。
- チケット管理を使っているなら、暫定対応には専用のラベル（例：
暫定対応）を付け、恒久対応のチケットを必ず1枚起票しておきます。暫定を打った瞬間に、対になる「宿題」を作っておくイメージです。
ポイントは、暫定対応を技術的負債（借金）と同じ扱いにすること。借金は、見えるところに残高が積まれているから返そうと思えます。暫定対応も同じで、見える場所に積まれていれば、返す（恒久化する）きっかけが自然に生まれます。負債の見える化そのものは、技術的負債を見える化して優先順位をつける方法も参考にしてください。
恒久対応に移すときの見極めと、消し方
見直し日が来たら、暫定対応リストを開いて、1件ずつ「どうするか」を決めます。すべてをすぐ恒久化する必要はありません。判断して、その判断も残すのが大事です。
- 恒久対応に着手する：本原因を直し、暫定で広げた設定・止めた処理を元に戻す。ここで「暫定を戻す」まで含めて初めて恒久対応です。設定を広げっぱなし・分岐を残しっぱなしにしない。
- いったん見直し日を延ばす：まだ着手できないなら、それでも構いません。ただし「なぜ延ばすか」と次の見直し日をリストに追記します。判断ゼロで放置しないことが、戻し忘れとの違いです。
- 暫定を恒久仕様として正式採用する：「暫定で広げたタイムアウトが、実は妥当だった」ということもあります。その場合は、暫定ではなく正式な設定として決め直し、理由を記録して、リストからは「恒久化済」で消します。なんとなく残すのではなく、選んで残す。
恒久対応が終わったら、必ず本番反映前の確認を通します。暫定を戻す作業も立派な変更なので、うっかり別の障害を生まないよう、本番反映前のチェックリストと作業前バックアップの型に沿って進めると安心です。そして、暫定→恒久まで一連の流れは、あとで振り返れるよう障害対応の対応履歴にも1行残しておくと、同じ暫定を繰り返さずに済みます。
「暫定対応の管理」チェックリスト
暫定対応を打ったとき・見直すときに、これだけ押さえられているかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回そろえる必要はありません。
まず外せない最低ラインはこの3つです。急ぎの障害対応でも、ここだけは押さえます。
- 【最低ライン】暫定対応を打った直後に、リストへ1行（いつ・何を・なぜ暫定か）残したか
- 【最低ライン】「戻す条件」と「見直し日」を決めたか（決まらなくても仮の日付を置いたか）
- 【最低ライン】現物（コード・設定）にも「暫定」と分かる目印を残したか
次の項目は、暫定が増えてきたとき・恒久化するときに追加で確認します。当てはまらなければ飛ばして大丈夫です。
- 恒久対応のチケット（宿題）を、対になる形で起票したか
- 暫定を
grepなどで一覧できる目印の付け方に統一したか - 見直し日に、1件ずつ「恒久化／延期／正式採用」の判断をしたか
- 恒久化のとき、暫定で広げた設定・止めた処理を「元に戻す」ところまでやったか
- 暫定を戻す作業も、本番反映前チェックとバックアップを通したか
- 完了したら、リストからその行を消した（＝完了の印にした）か
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「打った直後に1行残す」さえ習慣にできれば、暫定対応が静かに居座り続ける事故は、ぐっと減らせます。
よければ、こちらも
暫定対応の管理は、障害対応と変更管理のあいだをつなぐ、地味だけど効く一手です。前後の型もセットにしておくと、いざというときの動きが軽くなります。
- 技術的負債を見える化して優先順位をつける方法：積み上がった暫定対応も含めて、返す順番をつけるための1枚です。
- 本番反映前のチェックリストと作業前バックアップの取り方：暫定を恒久に戻すときも、この型で事故を防げます。
- 障害対応を属人化させない「対応履歴」の残し方：暫定から恒久までの流れを、あとで振り返れる形で残すために。
「暫定でしのいだ」ことは、恥ずかしいことでも、あとで責められることでもありません。まず被害を止めたのは、正しい判断です。 足りないのは記憶力ではなく、打った瞬間に残る1行だけ。今日から次の暫定対応で、〈いつ・何を・なぜ暫定か〉の1行をリストに書くところから始めてみてください。その1行が、半年後の自分を、思わぬ障害から守ってくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。