人事台帳の更新日を誰も残しておらず、『どれが正しいデータか』わからなくなった話

錯綜する人事データ

月末が近づくと、胃の奥が鉛のように重くなる。給与計算や入退社処理の締め切りが迫るなか。最も信頼すべきデータが信用できないからです。

人事台帳を開くたびに、どのファイルが本物かを探す作業から始まる。複数の人間が同時に業務を抱え、各自のタイミングでデータを編集する。その結果、共有フォルダには微妙にファイル名が違う台帳が増殖していく。誰かが意図的に壊しているわけではない。全員が自分の仕事を終わらせようと必死に更新した結果。最新版がどれか誰も分からなくなるのです。

まず、給与計算の直前に「人事台帳_最新.xlsx」を開いたところ。昨日入力したはずの新入社員のデータが跡形もなく消えていた。慌てて別のファイルを開くとそちらにはデータがあるが。今度は別の社員の住所変更が反映されていない。冷や汗をかきながら3つのファイルを並べ、目視で一つずつセルを比較した。どれが正しいのか判断できず、結局担当者全員にチャットで確認して回る羽目になり。本来なら一瞬で終わるはずの最終確認に20〜30分も奪われた。

分断データ確認の負担とExcel限界

同一社員データが3ファイルに分岐した際の最終確認にかかっていた実測時間（分単位）。

ただでさえ残業が確定している月末に、この無駄な確認作業が毎回発生する。手が止まるだけでなく、精神的な疲労が蓄積していく。システム部門に頼めば済む話かもしれないが。総務や経理の人間にはシステム部門との折衝という別のハードルがある。結局、自分たちの手元にあるExcelでなんとかするしかない。しかし、運用ルールが曖昧なまま複数人でファイルを触り続けると。業務の土台そのものが崩壊していく。

更新履歴なきデータ分岐

次に、なぜデータが分岐し、正誤判定ができなくなるのか。原因は極めてシンプルだった。台帳に「いつ」「誰が」更新したかの記録を残していなかったからです。

多くの社内システムやクラウドツールであれば。バックグラウンドで自動的に更新ログが残る。しかし、現場で使い回されているExcelファイルにはそんな高度な機能はない。セルの中身を書き換えて保存ボタンを押せば。過去のデータは上書きされて完全に消滅する。

記録がない状態でデータが食い違うと。差分を比較しても「どちらが新しいのか」をシステム的に判定できない。最新のデータを古いデータで上書きしてしまった場合、それに気づく手段がないのだ。誰かが台帳を開き、ロックがかかっているのを見て別名で保存する。その瞬間、世界の分岐が始まる。ファイルが分かれた後で統合しようにも、タイムスタンプや更新者が不明なデータは。ただの「誰かのメモ」でしかありません。

一方で、この手の競合トラブルは。共有運用ルールと入力規則を先に固めるだけでもかなり減らせる。

履歴なきデータ管理の危険性

非エンジニアの現場では「名前と部署と給与情報だけあれば仕事は回る」と錯覚しがちだ。システムを作った当初は、一人で管理していたのかもしれない。担当者が増え、分業が始まった瞬間にこの前提は崩壊する。会社を動かす公式な台帳として運用する以上、変更の履歴を追跡できない状態は。目隠しをして高速道路を走るようなものだ。データの上書きリスクは跳ね上がり。ミスが起きたときのリカバリーは絶望的に難しくなる。

記録なき台帳の恐怖と給与誤振込、現場の疲弊

記録がない台帳の恐怖は、ファイルが分岐するだけにとどまらない。実際の業務で起きたトラブルは、もっと現場の心臓を縮み上がらせるものだった。

そのため、特に誤判定が起きやすかったのが、同姓同名、部署異動、そして給与振込口座の変更だ。情報が少しでも交錯すると、大惨事に直結する。

ある日、同姓同名の社員の一人が部署異動になった。総務の担当者が台帳を更新したが。更新する行を間違えてもう一人のデータを書き換えてしまった。悪いことに、経理の担当者が同じタイミングで別ファイルの口座情報を更新していた。月末にデータを統合しようとしたとき。誰がどの情報を正しい意図で書き換えたのか全くトレースできず。現場はパニックになった。間違った口座に給与を振り込めば大問題になる。心臓がバクバクと鳴り。手に変な汗をかきながら本人たちに直接電話して確認するしかなかった。

ここで一度立ち止まって考えてみてください

Pythonや自動化スキルを体系的に習得して、ITエンジニアとしてのキャリアを切り開きたい方には「Enjoy Tech!（エンジョイテック）」が選択肢のひとつです。

プログラミングスクール Enjoy Tech!（エンジョイテック） →

仕組み不在が招く現場の疲弊と業務麻痺

この手のトラブルは、表面上は「入力ミス」として片付けられがちだ。根本的な問題は、ミスが起きたときにそれを検知し。切り分けるためのトラッキング情報がないことにある。誰が触ったかわからない以上、すべての変更を疑うしかなくなる。

しかし、手作業のまま限界を感じるなら。まずは現場で回る小さな自動化から試すのが現実的だった。

ミスを恐れるあまり、確認作業は二重三重になる。担当者の疲弊はピークに達し。本来やるべき付加価値の高い業務に取り組む時間は完全に失われていく。誰も悪くないのに。仕組みが欠落しているだけで現場の業務は確実に麻痺していくのです。

誰がいつ何を？台帳3列の威力

この地獄のような状況を打破するために。高度なマクロやRPAを導入したわけではない。現場のITスキルを考えれば、複雑なシステムは確実に形骸化する。

さらに、やったことは非常に原始的だ。台帳の右端に「更新日」「更新者」「変更理由」という3つの列を追加し。データを編集する際は必ずこの3点をセットで入力するようルール化しただけです。

なぜこの3つなのか。それは「誰がいつ何を変えたか」という。データベースにおける最小限のトランザクション記録だからだ。日付だけでは誰に聞けばいいかわからない。名前だけでも最新の変更かどうかわからない。理由がなければ、それが正しい意図での更新か、単なる誤操作かが判別できありません。

ログ列で安堵、データ統合

最初は現場から「入力項目が増えて面倒だ」と不満の声が上がった。数日後、またファイル名の違う台帳が2つ見つかった。以前なら絶望していた状況だったが、ログ列を見た瞬間。片方が「昨日の夕方に私が入力した住所変更」で、もう片方が「今朝。別の担当者が入力した家族構成の変更」だと一目でわかった。その場でデータを安全に統合できたとき、肩からすっと力が抜け。胸のつかえが取れたような強烈な安堵感を覚えた。

まず、面倒な作業を少しだけ増やすことで。結果的に何時間もの無駄な確認作業を消し飛ばすことができる。非エンジニアにとっては、新しいツールを覚えることよりも。こうした「シンプルなルールの追加」のほうが即効性がある。

運用改善で劇的効果と意識変革

運用を始めてから、現場の空気は明らかに変わった。誰もが「このデータは正しい」という確証を持って作業できるようになった。

効果は数値として顕著に表れた。更新日列を追加した初月だけで、データの食い違いによる差し戻しは劇的に減った。最新のデータがどれか、更新日を見れば一目瞭然だからです。

次に、更新日列追加前後の差し戻し件数の変化（月6件から月2件への減少記録）。

更新者のイニシャルを必須入力にした効果も大きかった。以前は「この変更、誰がやったの？」と関係者全員にチャットを投げ、返事を待ち。状況を説明するという無駄な往復が発生していた。入力した本人が特定できているため、直接ピンポイントで確認できるようになった。

データ不明時の問い合わせ往復回数の変化（平均3往復から1往復への減少回数）。

一方で、最も劇的だったのが「変更理由」の記載だ。ただ「更新した」と書くのではなく、30文字以上で詳細に残すルールにした。その結果、懸念されていた口座情報の誤上書きが2か月連続で0件になった。変更理由を言語化するプロセスが。無意識の入力ミスを防ぐ強力なストッパーとして機能したのである。ログを残すという行為自体が、作業者の意識を切り替えるスイッチになっていた。

3つの列で台帳の信頼性回復

たった3つの列を追加するだけで、台帳の信頼性は劇的に回復する。運用を続けるためには、ルールを形骸化させない工夫が不可欠です。

非エンジニアが陥りやすい罠は「人間はルールを守ってくれるはずだ」という性善説に頼ることだ。忙しい月末になれば、「あとでまとめて書こう」と入力をサボる人間が必ず現れる。

そのため、ルールを破れない仕組みをファイル自体に組み込む。更新日にはショートカットキー（Ctrl + ;）を使うよう徹底し。手入力の手間を省く。更新者の欄はドロップダウンリストから選ばせる。変更理由が空欄のまま保存しようとしたら。条件付き書式で行全体を真っ赤に塗りつぶす。これくらい強制力を持たせて初めて、運用は定着する。

この手の競合トラブルは。共有運用ルールと入力規則を先に固めるだけでもかなり減らせる。

データ可視化で現場の安定

最初から完璧な自動化やシステム移行を目指す必要はない。身の回りにあるデータの「いつ」「誰が」「なぜ」を可視化するだけで。日々の業務は安定する。手元のファイルに少しの工夫を凝らすことが、現場の平穏を守る最大の防壁になる。