問い合わせ対応を「調査ログ」に残して資産にする方法
「これ、前にも調べた気がする……」。 問い合わせの内容を見て、そう思った瞬間に、少しだけ気持ちが重くなりますよね。半年前の自分が同じことを調べたはずなのに、どこにどう書いたか思い出せない。結局また、ログをたどって、コードを開いて、一から確かめ直す。
一人で保守運用をしていると、問い合わせ対応は「その場で解決して終わり」になりがちです。調べて、答えて、次のタスクへ。せっかくの調査が、あなたの頭の中だけに消えていきます。
この記事では、問い合わせ対応をそのつど軽く「調査ログ」として残し、少しずつ資産に変えていくやり方を一緒に整理します。立派なナレッジベースを作る話ではありません。今日の対応のついでに、数行だけ書き足す。それだけで、未来の自分がずいぶん楽になる、という現実的な一手です。
結論：問い合わせ対応は、①現象（何を聞かれたか）→ ②調べたこと（どこを見たか）→ ③原因 → ④対応 → ⑤次への一言の5項目を、対応の直後に数行で残します。きれいにまとめる必要はありません。「次に同じ問い合わせが来た自分が、これを読めば5分で思い出せるか」だけを基準にすると、書く手間と後で助かる度合いのバランスがちょうどよくなります。
残す場所や形式は、現場の道具（チケット管理、社内Wiki、テキストファイル、スプレッドシート）で変わって大丈夫です。大事なのは「凝った仕組み」より「続けられる軽さ」です。
何が起きているか：調査が消えてしまう3つの理由
同じことを何度も調べてしまうのは、あなたの記憶力の問題ではありません。たいてい、次の3つの構造が原因です。
- 記録が「対応結果」だけになっている：チケットに「対応済み」「再起動で復旧」とは残っていても、どこを見て・なぜそうなったかが抜けている。結果だけでは、次に再現しても手がかりにならない。
- 書く場所とタイミングが決まっていない：対応が終わるとすぐ次の作業へ移るので、「あとで書こう」が積み上がって消える。書く場所も毎回違うと、探すのも億劫になる。
- 自分しか見ないから省略してしまう：一人だと「自分が分かればいい」と略しすぎて、半年後の自分には通じない暗号になる。未来の自分は、他人とほぼ同じくらい記憶を失っています。
どれも「気合いが足りない」話ではなく、仕組みがないと自然にそうなる種類のものです。だから、根性で覚えるのではなく、残す型と場所を先に決めておくのが近道です。
調査ログに残す5項目（そのまま使えるテンプレ）
書くのは、次の5項目だけです。一問一答のように、上から埋めていきます。
① 現象：何を聞かれたか（相手の言葉のまま）
まず、問い合わせの内容を相手が言った言葉のまま短く書きます。専門用語に翻訳しすぎないのがコツです。
- 「管理画面にログインできない」「月末の帳票が出ない」など、検索で引っかかる言葉で書く。
- いつ・どの画面・どの操作で起きたか、分かる範囲でひとこと添える。
- 半年後の自分は、正式なエラー名ではなく「あのログインできないやつ」で思い出します。その言葉で拾えるようにしておきます。
ここが検索の入口になるので、未来の自分が使いそうな言葉を意識するだけで、後の再利用率がぐっと上がります。
② 調べたこと：どこを見たか
次に、どこを・どういう順で見たかを残します。ここが、結果だけの記録に一番足りない部分です。
- 見たログの場所（ファイル名やパス、どのサーバーか）、開いた画面、叩いたコマンド。
- 「最初はアプリのログを見て、外れていたのでDBのスロークエリを見た」といったたどった順番。
- 空振りだった調査も、消さずに残す。「ここは見たけど関係なかった」は、次の自分にとって立派な時短情報です。
正解までの道だけでなく、行き止まりの道も書いておくと、次に同じ現象が出たとき「あそこは見なくていい」と分かって早く着けます。
③ 原因：なぜ起きたか
分かった範囲で、なぜそうなったかを書きます。断定できないときは、断定しないまま残すのが誠実です。
- 「ディスクが満杯でログが書けず処理が止まっていた」など、原因を一文で。
- 確証がなければ「おそらく〜。ただし断定はできていない」と、分かっていないことも正直に書く。
- 再発したときに「あのとき疑ったが確かめきれなかった点」が分かると、次の調査が進みます。
原因が最後まで特定できなくても大丈夫です。「ここまでは分かった／ここから先は未確認」の線が引けているだけで、次の対応はずっと楽になります。
④ 対応：何をして、どう戻したか
実際にやった対応と、元に戻す必要があるものがあるかを書きます。
- 実施した作業（設定変更、再起動、データ修正、パッチ適用など）を具体的に。
- 一時しのぎなのか、恒久対応なのかを明記する。「今回は再起動で急場をしのいだが、根本解決ではない」は必ず残す。
- 本番のデータや設定を触ったなら、いつ・何を・どう変えたかを残す。これは変更管理の記録にもそのまま使えます。
「その場しのぎ」を「解決済み」と書いてしまうと、未来の自分が油断します。しのいだだけなら、しのいだと書く。それが後の自分を守ります。
⑤ 次への一言：再発したらどうするか
最後に、次に同じことが起きたときの自分へのメモを一行だけ添えます。ここが「調査ログ」を「資産」に変える、いちばん大事な一行です。
- 「再発したら、まず◯◯のログを見れば早い」
- 「根本対応として、△△の監視を入れれば予防できそう（未対応）」
- 「この問い合わせは月末に増える。前もって案内すると減るかも」
未来の自分への申し送りです。ここに一行あるだけで、同じ現象が来たときのスタートラインが、何段も前に進みます。
具体例：「帳票が出ない」問い合わせを1件残してみる
たとえば「月末の帳票が出力されない」という問い合わせを、5項目に当てはめるとこうなります。
- ①現象：経理担当から「月末バッチの請求帳票が出ない」。毎月1日の朝に気づく。
- ②調べたこと：まずアプリのエラーログ（/var/log/app/）→異常なし。次にバッチのログ→「ディスク書き込み失敗」。
df -hでログ用パーティションが100%だった。 - ③原因：古いログが溜まりディスク満杯。帳票の一時ファイルが書けずバッチが途中で停止。
- ④対応：不要な古いログを退避して空きを確保し、バッチを手動で再実行→帳票は出力できた（一時しのぎ。ログローテーションは未設定のまま）。
- ⑤次への一言：再発したらまず
df -h。根本対応はログローテーション設定（未対応）。放置すると毎月末に再発する。
たった5行ですが、次に同じ問い合わせが来たら、②③をなぞるだけで数分で原因にたどり着けます。しかも⑤に「根本対応が残っている」と書いてあるので、余裕のある日に手を打つきっかけにもなります。
影響：ログが1件ずつ資産になっていくと、何が変わるか
調査ログを続けていくと、問い合わせ対応そのものより先に、気持ちの余裕が変わってきます。
- 同じ問い合わせに「また一から」ではなく「前のログを見れば早い」と落ち着いて臨める。
- 「その場しのぎ」が記録に残るので、根本対応の宿題が見える化され、後回しにしっぱなしを防げる。
- 「この現象は月末に増える」といった傾向が見えてきて、問い合わせが来る前に手を打てるようになる。
- 引き継ぎや、誰かに助けを求めるとき、「これまでの対応履歴」としてそのまま渡せる。属人化が少しずつ減る。
逆に、対応結果だけを残していると、同じ規模の問い合わせでも、たまたま覚えていた日と忘れた日の差が大きく出ます。調査ログは、その差を埋めて、あなたの対応品質を安定させる土台になります。
明日やること：次の1件だけ、5項目で残してみる
最初から全部を仕組み化しようとしなくて大丈夫です。明日できる、いちばん小さな一歩はこれです。
- 残す場所を1つだけ決める（今あるチケット・Wiki・テキストファイル、どれでもいい。増やさず、既にある場所に寄せる）。
- 明日きた問い合わせのうち、少し調べたもの1件だけを選ぶ。
- その1件を、①現象→②調べたこと→③原因→④対応→⑤次への一言の5行で書く。
- きれいにしようとせず、箇条書きのまま残す。空欄があってもそのまま置く。
- 1週間後、同じような問い合わせが来たら、そのログを開いてみる。役に立ったら、続ける理由になります。
全部の問い合わせを残す必要はありません。「少し調べたもの」「詰まったもの」だけで十分です。1件ずつでも、半年後には立派な対応辞典になっています。
「調査ログ」チェックリスト
1件残すたびに、これだけ見ておくと後で効きます。コピーして、自分のメモに当ててみてください。5項目ありますが、全部を毎回埋めきる必要はありません。
まず外せない最低ラインはこの2つです。忙しい日はここだけでも残しておきましょう。
- 【最低ライン】現象を「未来の自分が検索しそうな言葉」で書いたか
- 【最低ライン】その場しのぎか、恒久対応かを区別して書いたか
次の項目は、少し詰まった問い合わせ・再発しそうなもののとき追加で残します。軽い質問なら飛ばして大丈夫です。
- どこを・どの順で調べたか（空振りした調査も含めて）残したか
- 原因を、断定できない部分は「未確認」と正直に書いたか
- 「次に再発したらどうするか」を一行、未来の自分に残したか
全部に○が付かなくても大丈夫です。最低ラインの2つだけでも、何も残さないより、次の自分がずっと助かります。
よければ、こちらも
調査ログは、問い合わせ対応を資産に変える入口です。残した記録は、変更管理や障害対応の型とセットにしておくと、いざというときにそのまま使えます。
- 障害対応runbookテンプレート｜初動・切り分け・連絡・記録を1枚に：問い合わせが障害に育ったとき、初動と連絡の型があれば落ち着いて動けます。
- 変更管理台帳の付け方｜いつ・誰が・何を変えたかを残す：調査ログの「④対応」で本番を触ったら、変更の記録にもそのまま残しておきましょう。
- 500エラーが出たら最初に見る5つのログ｜場所と確認の順番：「②調べたこと」で迷わないよう、まず見るログの場所を型にしておけます。
「また同じことを調べている」のがつらいのは、頑張った調査が消えてしまうからです。でも、対応のついでに5行残すだけで、その調査はあなたの資産に変わります。 今日は次の1件だけ、①〜⑤で書いてみる。それだけで十分です。その1件が、半年後のあなたを助ける、最初の1ページになります。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。