小さな改修の変更前チェックリスト｜本番事故を防ぐ確認の型
「こんな1行の直し、わざわざ手順を踏むほどでもないよな」。 そう思って本番にサッと当てたあと、まったく別の画面が真っ白になった——。保守運用をしていると、この「軽い気持ちで触ったのに」が、いちばん背筋が冷える瞬間ですよね。
不思議なもので、身構える大改修より、「小さいから大丈夫」と思った変更のほうが事故になりやすいものです。大きい改修は自然と慎重になるのに、小さい改修は確認をまるっと飛ばして、そのまま本番に触ってしまう。悪いのはあなたの技術力ではなく、「小さいから」で手順を省いてしまう、その一瞬の油断のほうです。
この記事では、改修に手をつける前にサッと通せる変更前チェックリストを一緒に用意します。毎回ぶ厚い手順を踏む話ではありません。「これだけは、小さい改修でも飛ばさない」という、軽い確認の型です。
結論：変更前は、①何をどう変えるかを1行で言えるか → ②戻せる用意（コードとデータ両方）があるか → ③どこに影響するかをざっと見たか → ④どこで・いつ作業するか（本番か検証か、時間帯）を決めたか → ⑤変えたことを記録したかの5つだけ、着手前に確認します。とくに外せないのは①②③の最初の3つ。小さい改修なら、ここだけでも事故の多くは防げます。
具体的なコマンドや戻し方は、言語・構成・DBの種類で変わります。順番と観点を出発点に、自分の現場の道具に置き換えて使ってください。
何が起きているか：小さい改修ほど確認を飛ばす理由
「小さいから大丈夫」で事故るのは、意志が弱いからではありません。次のような構造があるからです。自分を責める前に、仕組みだと知っておくと落ち着けます。
- 心理的に「変更」と認識されない：1行、設定値ひとつ、文言ひとつ。手数が少ないと、頭の中で「作業」ではなく「ついで」に分類されてしまい、確認のスイッチが入りません。
- 急ぎで頼まれがち：小さい改修は「今すぐ直して」で来ることが多く、段取りを踏む時間が最初から削られています。
- 影響が見えないまま触れてしまう：小さいがゆえに、影響範囲を調べる前に「どうせここだけ」と手が動く。実際には、その1行が離れた処理から呼ばれていることがあります。
- 一人だと止める人がいない：レビューや相談の相手がいない一人運用では、「ちょっと待った」をかけてくれる存在が自分しかいません。だからこそ、外に置いたチェックリストが相棒になります。
大改修に事故防止の手順があるなら、小さい改修にも「軽い版」が要る——それだけの話です。
変更前に通す5つの確認（着手前に）
手を動かす前に、上流から順番に通していきます。難しく考えず、頭の中で1問ずつ答えるだけでも十分です。
① 何を・どう変えるかを1行で言えるか
まず、これから触るものを自分の言葉で1行にします。
- 「どのファイル・関数・カラム・設定値を」「今どうなっていて」「どう変えるのか」を1行で書く。
- 1行で言えないときは、まだ変更内容が固まっていないサインです。無理に手をつけず、もう少し要件を確かめます。
- 「文言をひとつ直すだけ」でも、その文言が判定条件やメール本文に使われていないか、一度立ち止まります。
たった1行ですが、これが後の「戻すとき」「影響を見るとき」「記録するとき」すべての土台になります。あいまいなまま進むと、後ろの確認が全部ゆるくなります。
② 戻せる用意があるか（コードとデータの両方）
小さい改修でいちばん飛ばされやすいのが、この「戻す準備」です。当てる前に、戻し方を先に用意します。
- コードなら、変更前のファイルや値を控えておく（バージョン管理下なら、元に戻せる状態を確認）。
- 設定値なら、変更前の値をメモしてから書き換える。「元がいくつだったか」を思い出せないのが、いちばん困ります。
- データやDBを触るなら、戻し方はコードとは別問題です。カラム追加・型変更などは単純なバックアップだけでは戻しきれない場面があります。
「戻せる」の中身は、コードとデータで別物です。詳しい取り方は本番反映前チェックリスト｜作業前バックアップの取り方と、すぐ戻せるリリース設計｜ロールバック手順の用意に分けてまとめています。ここでは「戻し方を決めてから着手する」とだけ、忘れずに。
③ どこに影響するかをざっと見たか
小さくても、その1行がどこから呼ばれているかだけは、着手前に一度見ます。
- 触る関数名・カラム名・設定キーで、プロジェクト全体をざっと検索する（
grep -rn "対象の名前" .、Git管理下ならgit grep -n "対象の名前"）。 - ヒットが1か所なら影響は小さめ。複数か所、とくにバッチや外部連携から呼ばれていたら、それは「小さい改修」ではありません。
- 「検索して0件だから安全」とは限りません。変数経由の動的な呼び出しなどは検索に引っかからないことがあります。
ここは深掘りするとキリがないので、変更前は「呼び出し元の数をざっと数える」だけで十分です。多かったら立ち止まる、という判断の材料にします。しっかり洗い出す順番は既存システムの改修｜影響範囲を見落とさない調査の順番にまとめました。
④ どこで・いつ作業するかを決めたか
同じ変更でも、やる場所と時間で事故の重さが変わります。
- できるなら、まず検証環境で一度当ててから本番へ。小さい改修ほど「本番で直接」に流れがちなので、ここで一拍おきます。
- 本番で作業するなら、利用の少ない時間帯を選ぶ。真っ昼間のアクセス集中時に、ついでで触らない。
- 影響が出たとき、自分がすぐ気づける・対応できる状況か。作業直後にその場を離れないで見ていられるか。
「今すぐ直して」と言われても、いつ・どこで当てるかは自分で選べる部分です。5分ずらすだけで、事故ったときの被害が変わることは珍しくありません。
⑤ 変えたことを記録したか
最後に、「いつ・誰が・何を・なぜ変えたか」を一行残します。小さい改修ほど記録が残らず、あとで「これ、いつ変わったんだっけ」と自分を苦しめます。
- 変更前の値、変更後の値、理由を1行で。日付と担当（＝自分）も添える。
- 立派な台帳でなくてよく、メモやコミットメッセージでも構いません。「記録が残っている」ことが大事です。
- 何かあったとき、この1行が「直近で何を触ったか」を教えてくれて、切り分けの出発点になります。
記録の付け方をきちんと運用にしたいときは、変更管理台帳の付け方｜いつ・誰が・何を変えたか残すが役に立ちます。
具体例：「表示文言をひとつ直すだけ」を通してみる
たとえば「エラー画面の文言をひとつ、やさしい表現に直したい」という、いかにも小さな改修。5つに当てるとこう見えてきます。
- ①内容：
error_messageの定義を1か所、別の文章に差し替える。 - ②戻せる：変更前の文言をメモしてから書き換え（1行なので戻すのは簡単。ここは軽くてよい）。
- ③影響：
error_messageでgrep → 画面表示のほかに、この文言をそのままメール本文と管理画面のログにも流用していたことが判明。文言を変えると、メールの見た目とログの検索条件にも波及する。 - ④場所と時間：メールに影響するなら、まず検証で1通送って確認。本番反映は送信の少ない時間帯に。
- ⑤記録：「文言変更。画面／メール／ログの3か所に影響。〇月〇日、自分」と1行残す。
「文言をひとつ」のはずが、③でメールとログへの波及が見つかりました。ここに気づけたのは、着手前にgrepを1回かけたからです。手をつけたあとに気づいていたら、送信済みメールは戻せません。
影響：変更前の一拍が、何を変えるか
変更前チェックリストを1枚持っておくと、改修そのものより先に、気持ちの余白が生まれます。
- 「たぶん平気」ではなく「①〜⑤を通した」と、根拠を持って着手できる。
- 「小さいから」で飛ばしていた確認が型になり、その日の忙しさや体調に品質が左右されにくくなる。
- 事故が起きても、②の戻す用意と⑤の記録があるので、慌てず戻して原因にたどり着ける。
- 「ここまで確認して当てます」と、依頼者にも落ち着いて状況を伝えられる。
逆に、小さい改修だけノーチェックで当て続けると、たまたま無事だった日と、たまたまメールが飛んでしまった日の差が、あとから大きく効いてきます。
明日やること：次の「小さい改修」で5問だけ自問する
いきなり立派な手順書は要りません。明日できる、いちばん小さな一歩はこれです。
- 次に来る小さい改修を1つ選ぶ。
- ①：これから何をどう変えるかを、声に出して1行で言ってみる。
- ②：変更前の値・ファイルを控える。戻し方を1つ決める。
- ③：触る名前で
grep（またはgit grep）を1回だけかけ、ヒット数を見る。 - ④⑤：本番か検証か・いつ当てるかを決め、終わったら1行記録する。
5問に答えるだけで、頭の中だけで進めるより、ずっと安全になります。慣れれば1〜2分で通せます。
「変更前」チェックリスト
着手前に、これだけ確認できているかを見る項目です。コピーして自分のメモに当ててみてください。全部を毎回構える必要はありません。
まず外せない最低ラインはこの3つ。小さい改修なら、ここだけでもぐっと安全になります。
- 【最低ライン】何を・どう変えるかを1行で言えるか
- 【最低ライン】戻せる用意があるか（コードは控え、設定は変更前の値をメモ／データは戻し方を別途）
- 【最低ライン】触る名前でざっと検索し、呼び出し元の数を確かめたか
次は、メール・帳票・外部連携・データに触れるときだけ追加で確認します。当てはまらなければ飛ばして大丈夫です。
- バッチ・非同期・外部連携から同じ処理を呼んでいないか見たか
- メール・帳票・通知など「後で人が見る出口」に波及しないか見たか
- まず検証環境で一度当てられるか、当てられないなら本番のどの時間帯にやるか決めたか
- 作業直後、影響を自分で見ていられる状況か
- 変えたこと（前後の値・理由・日付・担当）を1行記録したか
全部に○が付かなくても大丈夫です。最低ラインの3つだけでも、何も確認せずに当てるより、ずっと落ち着いて手をつけられます。
よければ、こちらも
変更前チェックは、安全な改修の入口です。着手前の「影響範囲」「戻し方」「本番反映の段取り」とセットで1枚にしておくと、当日とても楽になります。
- 既存システムの改修｜影響範囲を見落とさない調査の順番：③の影響確認を、抜けにくい順番でしっかり洗い出したいときに。
- 本番反映前チェックリスト｜作業前バックアップの取り方：②の「戻せる用意」を、ファイル・DB・設定の種類別に深掘りしています。
- すぐ戻せるリリース設計｜ロールバック手順の用意：当てたあとに戻すことになっても、慌てないための段取りです。
小さい改修がこわいのは、小さいから軽く見て、確認を飛ばしてしまうからです。でも、着手前に5問だけ自問する型があれば、その油断はちゃんと止められます。 今日は次の小さい改修で、「何をどう変えるか」を1行にして、grepを1回かけてみるだけで十分です。その一拍が、あなたを「まさか、あの1行で」から守ってくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。