【自治体職員向け】「ログを残す」働き方のススメ ～記録は自分を守る最大の武器だった件～

１．はじめに

　以前、こんな場面を目撃しました。

　システム障害が発生し、原因を調べようとベンダーに問い合わせたところ、返ってきた言葉がこれです。

「ログが残っていないので、原因の特定ができません」

　…ログが、ない。

　つまり、何かが壊れたのに、何が起きたのかが、まったくわからない。犯人のいない現場に集まった刑事たちが、証拠もなく首をかしげているような状態です。

　そして、もうひとつ。自治体の現場で長年働いている方なら、こんな光景も心当たりがあるかもしれません。

「あの件、誰が決めたんだっけ？」

「その指示、記録に残ってますか？」

「引き継ぎ書に書いてないんですけど…」

　記録がないと、仕事は属人化し、ミスが検証できず、責任が宙に浮きます。「ざんねんなデジタル化」が叫ばれる中、最大の問題は、ツールよりも前に、記録を残すという意識の欠如にあるのかもしれません。

　今回は、「ログを残す」という観点から、地方自治体での働き方を考えてみたいと思います。

２．「ログ」って、サーバの中だけの話じゃない

　「ログ」と聞くと、ITエンジニアがコンソール画面をにらんでいるイメージを持つ方が多いかと思います。

　確かに、サーバの動作記録、アクセス履歴、エラーの記録…これらはすべて「ログ」です。

　でも、考えてみてください。

　私たちの日々の業務だって、本質的には同じじゃないでしょうか。

• 誰と打ち合わせをして、何が決まったか

• なぜその仕様にしたのか、どんな検討経緯があったか

• ベンダーにどんな指示を出して、どう対応されたか

　これらを記録に残すことは、ITのログと本質的には変わりません。つまり、「ログを残す働き方」とは、業務のあらゆる出来事を追跡可能な状態にしておくことです。

　言い換えれば、「再現性のある仕事の仕方」とも言えます。

３．記録がなかったとき、何が起きたか（実例）

　実際に、私が見聞きした「記録がなかったせいで困った」ケースをいくつか紹介します。（フェイクを交えています）

ケース①：サーバのNTP設定漏れ

　システムの障害調査をしようとしたところ、ログファイルの時刻がバラバラで、事実関係をまったく整理できない事態が発生しました。原因をさかのぼると、導入時に時刻同期（NTP）の設定が漏れていたのです。

※時刻同期をしておかないと、障害発生時やウイルス感染時の記録が正しく読めませんね。

　「仕様書に書いていないので、やる必要がないと判断しました」

　これは、記録がないことで発注側も受注側も思考停止に陥る、典型的な例です。設定根拠の記録がなければ、何が正しかったのかすら議論できません。

ケース②：担当者交代と引き継ぎの破綻

　異動で担当者が交代した途端、前任者しか知らない「口頭での取り決め」が次々と発掘されました。なぜそのフローになっているのか、誰もわからない。でも、変えると何かが壊れそうで、誰も触れない。

　これがいわゆる「前例踏襲」の正体です。記録がないから、根拠がわからず、変えられない。

ケース③：前任者のマスタ変更、理由不明問題

　ある業務システムのマスタデータが、ある時期から変更されていることに気づきました。どの値が、いつ、誰によって、なぜ変更されたのか、一切記録がない。作業記録も、引き継ぎ書も、メールの履歴も残っていない。

　「前任の担当者に聞いてみましょう」と言ったところ、その方はすでに別の部署に異動されており、「そのときのことは、もう…」という返答が返ってきました。（誰も悪意はないのが、またつらい）

　結局、システム導入時の仕様書を掘り起こして類推するしかなく、確認作業に数日を要しました。正しいかどうかもわからないまま、「たぶんこれで合っているだろう」という推測で運用を継続せざるを得なかったのです。

※状況証拠を追い続け、より100％に近いものを推測して多分これだと進めました。

ケース④：電子申請フォームの入力規則、止まったまま

　市民向けの電子申請フォームに、年を入力する項目がありました。しかし、ある年から窓口にクレームが届き始めます。「フォームに今年の年が選べない」というものでした。

　調べてみると、入力規則のプルダウンの選択肢が前任者が担当していた年で止まっていました。その後、誰も触っていなかったのです。

　修正自体は大した手間ではありません。でも、問題はそこではなくて、「誰がいつメンテナンスするか」が引き継がれていなかったことです。市民からのクレームで初めて気づく、という状況は、組織として恥ずかしいという以上に、住民サービスの根幹を揺るがす話です。 動作確認の記録と、定期メンテナンスのスケジュールがあれば、防げたトラブルでした。

４．では、何を、どう残せばいいのか

　難しく考える必要はありません。大切なのは、以下の3つの「なぜ」を書き残すことだけです。

① なぜ、そうしたのか（決定の根拠）

　会議やメールの中で方針が決まったら、その理由を一言でいいので記録に追記してください。「係長判断のため」ではなく、「○○のリスクを考慮して、A案を採用」という粒度が理想です。

② なぜ、そうなっていないのか（意図的な非実施）

　これが一番見落とされがちです。「やらなかった」ことにも根拠があるはずです。セキュリティパッチを当てなかった理由、システム改修を見送った理由。これを記録していないと、後から「なぜやっていなかったのか」と責任を問われたときに無防備になります。

③ 誰が、何を確認したか（検収・確認の事実）

　「業者任せ」「確認した気になっていた」という状況を防ぐために、何を確認し、誰が承認したかを後から追える状態にしておくことが必要です。設定パラメータシートやチェックリストの提出を義務づけることも、記録を残す働き方の一環です。

　ツールは何でもかまいません。メール、Excelの台帳、TeamsやチャットのログでもOKです。大事なのは、仕組みとして「残る」状態にすること。個人の記憶や裁量に委ねないことです。

④ 「完璧な記録」を目指さない（これが一番大事かもしれない）

　ここまで書いておいて矛盾するようですが、「記録を綺麗に残すために残業が増えた」となっては本末転倒です。（手段が目的化する、というやつです）

　完璧な議事録を毎回作る必要はありません。チャットのスクショ1枚、決定事項の箇条書き1スレッド、それで十分です。また、後任者が共有フォルダの探しそうなところに作業履歴を残すのも一手です。

　生成AIに打ち合わせメモを投げて3行にまとめてもらう、という使い方も、今や現実的な選択肢です。

　記録は「残ること」が目的であって、「美しく整形されること」は目的ではありません。省力化・自動化できるところは積極的に手を抜いてください。

５．まとめ

　「ログを残す働き方」は、個人の誠実さや几帳面さの話ではありません。

　組織として説明責任を果たすための最低限のインフラであり、サイバー攻撃や障害が起きたときの原因究明を可能にする、守りの仕組みです。記録は、ミスを指摘するためにあるのではなく、事実関係を整理し、組織を正しく動かすための地図だと思っています。

　「ログがないから原因がわかりません」という言葉を、二度と聞きたくはない。

　そのためにできることは、今日から始められます。打ち合わせのあとに、決定事項と理由を3行書く。メールで指示を出した記録を残す。共有フォルダに資料を残す。それだけでも、1年後の自分や後任の担当者が、どれほど助かるかを想像してみてください。

　今回書いた内容は単に個人の仕事術ではなく、公務員としての『説明責任（アカウンタビリティ）』を果たすための基盤だと考えています。

　組織で「賢く、楽に、シンプルに」仕事をするためには、記録を残すことが一番の近道だと、私は信じています。