部署名の表記が違うだけで、集計が真っ二つに割れた。同じ部署なのに別物扱いされた月末の話

月末の集計レポートに、見慣れない行が現れた

オフィスの窓から見える空が暗くなり始めた、月末の17時。

全社からかき集めた売上データをまとめ上げ、ようやく完成した月次の集計レポートを関係者宛のメーリングリストに送信した。重い肩を回し、すっかり冷めきったコーヒーに手を伸ばす。定時上がりの準備を始めようとした直後だった。机の上の内線電話が、けたたましく鳴り響いた。

発信元は、つい先ほどレポートを送ったばかりの上司。
「この部署別集計、なんか行数多くないか？ 見慣れない行が混ざってるぞ」

急いで手元のExcelファイルを開き直す。背中に嫌な汗が伝う感覚があった。

上司に指摘されてファイルを開くと、本来4行で収まるはずの部署別集計表が、なぜか8行に分裂していた。「営業一課」の下に「営業1課」が並び、「総務部」の下に「総務 部」が鎮座している。全く同じ部署なのに、売上が真っ二つに割れていた。穴があったら入りたかったし、帰宅に向けてカバンを整理していた手が完全に止まり、絶望感で胃が重くなった。

なぜこんなことになったのか。元データのリストを上から下までスクロールして眺めても、パッと見は何もおかしくない。人間の目にはどれも同じ「営業一課」に見える。

しかし、集計結果は残酷なほどハッキリと異常を示していた。同じ部署の売上が分散して表示されているため、一見すると業績が悪化しているようにすら見えてしまう。役員会議に提出される直前のデータ。このままでは大問題になる。

「営業一課」と「営業1課」は、Excelにとって別の部署だった

データを目視で追っていくと、ある違和感に気づいた。漢字の「一」と数字の「1」が混在している。

原因を見つけるまでに約1時間を溶かした。Microsof

t Excelの仕様として、ピボットテーブルやCOUNTIF、SUMIFなどの集計機能は「完全一致」が前提となっている。人間の脳は前後の文脈で補完して「どちらも営業一課だな」と柔軟に判断する。

だが、システムは冷徹です。文字コードが1ビットでも違えば、それは全くの別物として扱われる。

「営業一課」（漢数字）
「営業1課」（算用数字）
「営業 一課」（スペースあり）

これらは全て、Excelにとっては見知らぬ赤の他人同士になる。

さらにタチが悪いのは、全角と半角の混在です。全角スペースが一つ入っているだけで、集計行は無慈悲に分裂する。見た目がほぼ同じだからこそ、人間の目による事前のチェック作業をいとも簡単にすり抜けてしまう。

これが表記揺れの恐ろしさです。エラーメッセージが出るわけでもなく、システムが停止するわけでもない。ただ静かに、しかし確実に集計データを壊していく。気づかずに経営層へ提出してしまった場合、誤ったデータに基づく経営判断を下させてしまう危険性すらある。

どこで混ざったのか。入力経路を一つずつ辿った

そもそも、なぜこんなにも表記がバラバラになったのか。社内の基幹システムから吐き出されたCSVデータなら、表記はマスターデータに沿って統一されているはずです。

各部署の担当者に電話でヒアリングをしたところ、経費精算システムからの出力CSV、社内申請フォームからの自動入力、挙句の果てには前任者が作った謎のExcel台帳からの手動コピペが入り乱れていた。「うちの部署は昔からこの書き方なんで」と謎のローカルルールをドヤ顔で語られた時、怒りを通り越してひどい頭痛がした。

データが集まってくる「入口」を一つずつ確認していく。原因は明白だった。入力経路が複数存在し、統制が全く取れていなかったのです。

Webフォームには入力制限がかかっておらず、自由記述のテキストボックスになっている。別システムのCSVは古い仕様のまま放置され、各担当者は自分の好きなようにExcelの共有フォルダへ手入力している。入力する人間の数だけ、独自の表記ルールが生まれてしまう構造になっていた。

誰か特定の人間が悪いのではない。入口を一つに絞らず、入力制限も設けていなかった運用そのものに根本的な問題があった。人間は面倒なことを嫌う。コピペで済むならコピペするし、手癖で「1」と打つ人はずっと「1」と打ち続ける。その尻拭いを、月末の集計担当者が背負わされている構図だった。

その日はSUBSTITUTE関数でなんとかしのいだ

原因と構造的な問題は分かった。しかし、今は月末の18時過ぎ。とにかく今日中に正しい集計レポートを提出しなければならない。システム部門に掛け合って入力フォームを改修している暇など、1秒たりともない。

応急処置として、Excelの標準関数であるSUBSTITUTE関数を使うことにした。

約30分の突貫工事の始まりです。元データの隣に作業用の列を追加し、ひたすら文字を置き換えていく。

=SUBSTITUTE(A1,”一”,”1″)

これだけでは終わらない。悪しき全角スペースも消さなければならない。全角の数字を半角にする作業も必要です。最終的に、SUBSTITUTE関数を何重にもネストした、後任が見たら悲鳴を上げるようなおぞましい数式が完成した。

長い数式を書き終え、エンターキーをッターンと力強く叩いて正しい集計結果が出た瞬間は、謎の達成感と全能感があった。だが、冷めたコーヒーをすすって冷静になると「来月もこの儀式をやるのか？」と絶望した。根本的には何も解決していない。ただ目の前の火を必死に消しただけだった。

力技で正しい4行の集計表を作り上げ、上司に再提出した。一息ついたものの、胃の重さは完全に消えない。「直った」のではなく、「今回だけしのいです」に過ぎないという事実が、重くのしかかっていた。

再発を防ぐために、取込時に一行だけ処理を入れた

翌月、同じ悲劇を繰り返すわけにはいかない。Excelの長大な数式で毎回処理するのはミスの元であり、属人化の極みです。元データそのものに手作業で加工を加えるのではなく、データを取り込んで集計するプロセスを自動化する決断をした。

Pythonとpandasライブラリの出番です。

データの入口をシステム全体で統一することは、予算と時間の都合で物理的に難しかった。そこで、集計システム側にデータを取り込む瞬間に「強制的に表記を揃える」関所を作ることにした。

記述したコードは、実質たったの1行です。

df[“部署名”] = df[“部署名”].str.replace(“一”, “1”).str.strip()

漢数字の「一」を算用数字の「1」に変換し、str.strip()で前後の不要な空白を容赦なく削ぎ落とす。さらに正規表現を用いて、全角・半角の統一処理も組み込んです。

これだけで、どんなに各部署からバラバラな表記でデータが飛んできても、集計プログラムが回る前には必ず綺麗な「営業1課」に統一されるようになった。人間の目による不安定なチェックも、SUBSTITUTE関数のネスト地獄も、月末の冷や汗も不要になった。

結果として、翌月からの集計分裂エラーは再発ゼロになった。

集計の信頼性は、手元のExcelテクニックや目視確認の努力だけで担保できるものではない。データの入口を整え、揺らぎを許容しない冷徹な仕組みを作って初めて、本当に「楽」ができる。月末の夕方に、冷めたコーヒーではなく温かいお茶をゆっくり飲める日常は、この一行のコードから始まった。

表記揺れは、見えないバグです。エラーを吐かない。システムを止めない。ただ静かに、集計の正確さを蝕んでいく。気づいた時には月末の冷や汗が待っている。そして気づかないまま経営層に出してしまった時には、もっと厄介な事態が待っている。
データの話は、結局のところ入口の設計の話です。どれだけ集計のロジックを磨いても、入ってくるデータが汚ければ意味をなさない。「うちの部署は昔からこの書き方」を許容し続けた先に、月末17時の内線電話がある。
Pythonのstr.replace一行で解決できた問題は、本来なら入力設計の段階で潰せていたはずだった。それでも、既存のシステムを変えられない現場では、「受け取る側で吸収する」という現実解が一番速く効く。完璧を求めるより、今動く仕組みを一つ作る方がずっと価値がある。同じ月末の夕方を、もう一度あの絶望で終わらせたくないなら、まず一行書いてみることです。難しいことは何もない。pandasが入っていれば、今日から動かせる。それだけの話だった。

この一件で学んだことがある。集計エラーの根本は、大抵の場合「上流の入力設計の甘さ」にある。プルダウンで選択肢を絞れば表記は揺れない。マスタテーブルから参照させれば手打ちのバラつきは生まれない。ただ、既存のシステムを変えるには予算と承認と時間がかかる。現場の担当者に与えられた武器は限られている。そうであれば、受け取る側で正規化するしかない。エレガントではないかもしれないが、月末に冷や汗をかかなくなるなら十分です。完璧な設計を待つより、動く仕組みを今日作る方が現実的だった。あの月末の内線電話が、そう教えてくれた。静かに蝕む表記揺れを防ぐのは、コードによる仕組みだけです。人間の目視に頼る時代は、もう終わらせていい。そう決めた月末からは、定時を少し過ぎた程度で帰れるようになった。あの絶望的な内線電話からすれば、隔世の感がある。

t Excelの仕様として、ピボットテーブルやCOUNTIF、SUMIFなどの集計機能は「完全一致」が前提となっている。人間の脳は前後の文脈で補完して「どちらも営業一課だな」と柔軟に判断する。

だが、システムは冷徹です。文字コードが1ビットでも違えば、それは全くの別物として扱われる。

「営業一課」（漢数字）
「営業1課」（算用数字）
「営業 一課」（スペースあり）

これらは全て、Excelにとっては見知らぬ赤の他人同士になる。

さらにタチが悪いのは、全角と半角の混在です。全角スペースが一つ入っているだけで、集計行は無慈悲に分裂する。見た目がほぼ同じだからこそ、人間の目による事前のチェック作業をいとも簡単にすり抜けてしまう。

これが表記揺れの恐ろしさです。エラーメッセージが出るわけでもなく、システムが停止するわけでもない。ただ静かに、しかし確実に集計データを壊していく。気づかずに経営層へ提出してしまった場合、誤ったデータに基づく経営判断を下させてしまう危険性すらある。

どこで混ざったのか。入力経路を一つずつ辿った

そもそも、なぜこんなにも表記がバラバラになったのか。社内の基幹システムから吐き出されたCSVデータなら、表記はマスターデータに沿って統一されているはずです。

各部署の担当者に電話でヒアリングをしたところ、経費精算システムからの出力CSV、社内申請フォームからの自動入力、挙句の果てには前任者が作った謎のExcel台帳からの手動コピペが入り乱れていた。「うちの部署は昔からこの書き方なんで」と謎のローカルルールをドヤ顔で語られた時、怒りを通り越してひどい頭痛がした。

データが集まってくる「入口」を一つずつ確認していく。原因は明白だった。入力経路が複数存在し、統制が全く取れていなかったのです。

Webフォームには入力制限がかかっておらず、自由記述のテキストボックスになっている。別システムのCSVは古い仕様のまま放置され、各担当者は自分の好きなようにExcelの共有フォルダへ手入力している。入力する人間の数だけ、独自の表記ルールが生まれてしまう構造になっていた。

誰か特定の人間が悪いのではない。入口を一つに絞らず、入力制限も設けていなかった運用そのものに根本的な問題があった。人間は面倒なことを嫌う。コピペで済むならコピペするし、手癖で「1」と打つ人はずっと「1」と打ち続ける。その尻拭いを、月末の集計担当者が背負わされている構図だった。

その日はSUBSTITUTE関数でなんとかしのいだ

原因と構造的な問題は分かった。しかし、今は月末の18時過ぎ。とにかく今日中に正しい集計レポートを提出しなければならない。システム部門に掛け合って入力フォームを改修している暇など、1秒たりともない。

応急処置として、Excelの標準関数であるSUBSTITUTE関数を使うことにした。

約30分の突貫工事の始まりです。元データの隣に作業用の列を追加し、ひたすら文字を置き換えていく。

=SUBSTITUTE(A1,”一”,”1″)

これだけでは終わらない。悪しき全角スペースも消さなければならない。全角の数字を半角にする作業も必要です。最終的に、SUBSTITUTE関数を何重にもネストした、後任が見たら悲鳴を上げるようなおぞましい数式が完成した。

長い数式を書き終え、エンターキーをッターンと力強く叩いて正しい集計結果が出た瞬間は、謎の達成感と全能感があった。だが、冷めたコーヒーをすすって冷静になると「来月もこの儀式をやるのか？」と絶望した。根本的には何も解決していない。ただ目の前の火を必死に消しただけだった。

力技で正しい4行の集計表を作り上げ、上司に再提出した。一息ついたものの、胃の重さは完全に消えない。「直った」のではなく、「今回だけしのいです」に過ぎないという事実が、重くのしかかっていた。

再発を防ぐために、取込時に一行だけ処理を入れた

翌月、同じ悲劇を繰り返すわけにはいかない。Excelの長大な数式で毎回処理するのはミスの元であり、属人化の極みです。元データそのものに手作業で加工を加えるのではなく、データを取り込んで集計するプロセスを自動化する決断をした。

Pythonとpandasライブラリの出番です。

データの入口をシステム全体で統一することは、予算と時間の都合で物理的に難しかった。そこで、集計システム側にデータを取り込む瞬間に「強制的に表記を揃える」関所を作ることにした。

記述したコードは、実質たったの1行です。

df[“部署名”] = df[“部署名”].str.replace(“一”, “1”).str.strip()

漢数字の「一」を算用数字の「1」に変換し、str.strip()で前後の不要な空白を容赦なく削ぎ落とす。さらに正規表現を用いて、全角・半角の統一処理も組み込んです。

これだけで、どんなに各部署からバラバラな表記でデータが飛んできても、集計プログラムが回る前には必ず綺麗な「営業1課」に統一されるようになった。人間の目による不安定なチェックも、SUBSTITUTE関数のネスト地獄も、月末の冷や汗も不要になった。

結果として、翌月からの集計分裂エラーは再発ゼロになった。

集計の信頼性は、手元のExcelテクニックや目視確認の努力だけで担保できるものではない。データの入口を整え、揺らぎを許容しない冷徹な仕組みを作って初めて、本当に「楽」ができる。月末の夕方に、冷めたコーヒーではなく温かいお茶をゆっくり飲める日常は、この一行のコードから始まった。

表記揺れは、見えないバグです。エラーを吐かない。システムを止めない。ただ静かに、集計の正確さを蝕んでいく。気づいた時には月末の冷や汗が待っている。そして気づかないまま経営層に出してしまった時には、もっと厄介な事態が待っている。
データの話は、結局のところ入口の設計の話です。どれだけ集計のロジックを磨いても、入ってくるデータが汚ければ意味をなさない。「うちの部署は昔からこの書き方」を許容し続けた先に、月末17時の内線電話がある。
Pythonのstr.replace一行で解決できた問題は、本来なら入力設計の段階で潰せていたはずだった。それでも、既存のシステムを変えられない現場では、「受け取る側で吸収する」という現実解が一番速く効く。完璧を求めるより、今動く仕組みを一つ作る方がずっと価値がある。同じ月末の夕方を、もう一度あの絶望で終わらせたくないなら、まず一行書いてみることです。難しいことは何もない。pandasが入っていれば、今日から動かせる。それだけの話だった。

この一件で学んだことがある。集計エラーの根本は、大抵の場合「上流の入力設計の甘さ」にある。プルダウンで選択肢を絞れば表記は揺れない。マスタテーブルから参照させれば手打ちのバラつきは生まれない。ただ、既存のシステムを変えるには予算と承認と時間がかかる。現場の担当者に与えられた武器は限られている。そうであれば、受け取る側で正規化するしかない。エレガントではないかもしれないが、月末に冷や汗をかかなくなるなら十分です。完璧な設計を待つより、動く仕組みを今日作る方が現実的だった。あの月末の内線電話が、そう教えてくれた。静かに蝕む表記揺れを防ぐのは、コードによる仕組みだけです。人間の目視に頼る時代は、もう終わらせていい。そう決めた月末からは、定時を少し過ぎた程度で帰れるようになった。あの絶望的な内線電話からすれば、隔世の感がある。