朝のオフィスで、問い合わせのメールを開いたまま「直したはずなのに」と少し困った表情でモニターを見つめる保守運用の担当者
保守・改修約12分

直したつもりが直っていない｜改修の効果を確かめる4つの手順

「昨日の件、まだ同じエラーが出るんですけど……」

夕方に改修を本番へ出して、自分の画面で動きを見て、「直りました」と返した。ところが翌朝、依頼者から同じ症状の連絡が届く。画面を開き直すと、たしかに自分の環境では出ない。でも、依頼者の画面では出ている——。「直したよね？」と自分を疑う、あの居心地の悪い時間。保守を続けていると、一度は通る道だと思います。

これは、あなたの腕が足りなかったからではありません。多くの場合、「何を見たら直ったと言えるか」を決めないまま、手元で一度動かして確かめていたことが原因です。修正のコード自体は正しくても、本番に届いていなかったり、依頼者の条件では別の道を通っていたりすれば、症状は残ります。

この記事では、「直したつもり」を「直ったと言える」に変えるための確かめ方を、手順を小さく分けて一緒に整理していきます。

結論：改修の効果は、次の4つを順番に確かめます。①直す前に「直ったと言える条件」を1行で決める（再現手順と、症状の数字）、②修正が本番に届いているかを確かめる（コードの版・全台・キャッシュ）、③依頼者と同じ条件で再現手順をもう一度なぞる、④ログや件数の数字が、直す前より減ったかを見る。手元で一度動いたことではなく、決めておいた条件を満たしたことを「直った」の根拠にすると、手戻りはぐっと減ります。

なお、コマンドや画面は言語・サーバー構成で変わります。ここで持ち帰ってほしいのは順番と観点です。手元の環境に置き換え、検証環境で試してから使ってください。

何が起きているか：「直った」と言える条件が決まっていない

「直したのに直っていない」は、たいてい次のどこかで起きています。

共通しているのは、確かめる前に「何が起きなくなれば直ったと言えるか」が言葉になっていないことです。基準がないと、手元で動いた瞬間に安心してしまう。これは誰にでも起きる、ごく自然な流れです。

改修の効果を確かめる4つの手順

左から右へ4つの場面が並び、メモに条件を書く・サーバーに届いたか見る・同じ条件で試す・グラフの数字が下がったのを見る、という確認の順番を表した図
「決める→届いたか→同じ条件で試す→数字で見る」の順に確かめると、「直したつもり」が「直った」に変わる

① 直す前に「直ったと言える条件」を1行で決める

いちばん効くのは、直し始める前の1行です。問い合わせを受けたら、次の2つをメモに書いておきます。

[直ったと言える条件]
  再現手順：会員Aでログイン → 注文履歴 → 2025年以前の注文を開く → 500エラー
  症状の数字：エラーログの "Undefined index: tax_rate" が 1日あたり約40件
  直ったら：同じ手順でエラーが出ない ＋ 上のログが翌日0件

再現手順は、依頼者から聞いた誰が・どの画面で・何をしたら・何が起きたかをそのまま書きます。聞き取りが曖昧なときは、「動きがおかしい」の切り分け｜最初に聞く7つの質問リストが使えます。手元で再現できないときは「再現しない」バグの調べ方もあわせてどうぞ。

ポイントは、「直ったら」の行を先に書いておくことです。直したあとに基準を考えると、どうしても「手元で動いたからOK」に寄ってしまいます。

② 修正が本番に届いているかを確かめる

次に、直したコードが、実際に依頼者の使っている本番で動いているかを見ます。思い込みが入りやすいところなので、目で確かめるのがおすすめです。

# 本番サーバーで、いま置かれているコードの版を確かめる（Gitで配置している場合）
cd /var/www/app && git rev-parse --short HEAD

# Gitを使っていない場合は、直したファイルの更新日時と中身で確かめる
ls -l --time-style=long-iso /var/www/app/lib/Order.php
grep -n "tax_rate" /var/www/app/lib/Order.php

出てきた版や中身が、自分が出したつもりの修正と一致しているかを見ます。あわせて、次の3つも確かめておくと安心です。

ここで「届いていなかった」が見つかれば、修正そのものは正しかったということです。自分を責めずに、反映の手順に1行足せば済みます。

③ 依頼者と同じ条件で、再現手順をもう一度なぞる

修正が届いていることを確かめたら、①で書いた再現手順を依頼者と同じ条件でなぞります。自分の管理者アカウントで1回動かすだけだと、依頼者が通る分岐を通らないことがあるからです。

特定の人だけで起きる症状の追い方は特定のユーザーだけエラーになるときの切り分けで詳しく整理しています。

④ ログや件数の数字が、直す前より減ったかを見る

最後に、画面の印象ではなく数字で確かめます。①で書いた「症状の数字」を、直す前と後で比べます。

# 直す前の日と、直した翌日で、同じエラーの件数を比べる（ログの場所・形式は環境に合わせて）
grep -c "Undefined index: tax_rate" /var/log/app/error.log.1   # 直す前（前日分）
grep -c "Undefined index: tax_rate" /var/log/app/error.log     # 直した後（当日分）

ログのローテーションの区切りや形式は現場ごとに違うので、同じ長さの期間どうしを比べるようにします。たまにしか出ない症状なら、1日だけでなく数日〜1週間見てから「直った」と判断するほうが安心です。いつもの件数を知っておくと比べやすくなります（監視の平常値（ベースライン）を把握する）。

数字が減っていなければ、直したのは別の原因だったかもしれません。それは失敗ではなく、原因の候補が1つ減ったということです。どこを通っているかが見えないときは、改修時にログを仕込むで次の一手を打てます。

具体例：「注文履歴が開けない」を4つの手順で確かめる

ある会員サイトを一人で保守している担当者の、よくある流れです。

変わったのは、修正の腕ではありません。「直った」の基準を先に決めて、その基準で確かめたことです。依頼者に返す言葉にも、迷いがなくなりました。

影響：確かめ方を決めておくと、何が変わるか

明日やること

  1. いま対応中の改修に「直ったと言える条件」を1行書く。再現手順と、症状の数字（ログの件数など）の2つだけで十分です。
  2. 本番の版を確かめるコマンドをメモしておく。git rev-parse --short HEAD か、ファイルの更新日時と中身の確認か。自分の環境で使えるほうを手順書に残します。
  3. 依頼者と同じ条件で試せるテスト用ユーザーを1つ用意する。一般会員の権限で、管理者とは別のアカウントです。
  4. 「直りました」と返す前に、数字を1回見る習慣をつくる。

今日やるのは、1の「条件を1行書く」だけでも十分です。それだけで、次の「直りました」に少し自信が持てるようになります。

「直したつもり」を防ぐ確認チェックリスト

全部を一度にそろえなくても大丈夫です。まずは「条件を先に1行書く」と「返す前に数字を1回見る」の2つだけで、手戻りの多くは手前で拾えるようになります。

よければ、こちらも

明るい昼のオフィスで、モニターの緑のチェックマークを確かめ、ほっとした笑顔でノートに印をつけている保守運用の担当者

「直したつもり」は、怠けた結果ではありません。急いで依頼者を助けようとした、その気持ちの表れです。あとは、確かめる順番を1本持っておくだけ。そうすれば、あなたの「直りました」は、依頼者にとっても自分にとっても安心できる一言になります。

まずは次の問い合わせで、直し始める前に「直ったと言える条件」を1行だけ書いてみてください。

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

関連用語