拠点ごとに休日ルールが違うと、勤怠計算が毎月崩れた話

月末勤怠を壊すExcelの構造欠陥

月末の金曜日、午後4時。経理部から内線が鳴る。「〇〇拠点の勤怠データ、合計勤務時間が合わないみたいで…」。胃がずしりと重くなる感覚。またか。時計の針が午後5時を指す頃には。各拠点の人事担当からの問い合わせがチャットに溜まり。画面右下に通知がポップアップし続ける。目の焦点が合わなくなり、蛍光灯の光がやけに目に染みる。

拠点ごとに異なる休日カレンダーを。一枚の巨大なExcelシートで管理しようとした者の末路である。本社は土日祝休み。A工場は土曜も稼働する週がある。B営業所は地域のお祭りの日を特別休日に指定している。これらの複雑な条件を。天才的な誰かが作ったVLOOKUPとIF関数がネストした長大な数式で捌いていた。だが、その製作者はもういない。ブラックボックス化したExcelは、誰にも触れない聖域と化していた。

単一ロジックの無理、集計作業の構造的破綻

まず、なぜ、こんな単純なはずの集計作業が毎月のように破綻するのか。原因は入力ミスや担当者の不注意ではない。もっと根深い、構造的な欠陥がそこにあったのだ。全ての拠点の休日ルールを、一本の数式。一枚のシートという「単一のロジック」で無理やり処理しようとしたこと。それが全ての元凶だった。例外に次ぐ例外を重ねた結果、もはや誰も全体を把握できなくなり。小さな修正が予期せぬ場所でエラーを引き起こす。月末の混乱は、起こるべくして起きていたのです。

休日の3層定義で勤怠管理を再建

自分たちが陥っていた罠は。「休日」という言葉で全ての休みを一緒くたに扱っていたことにある。しかし、その性質は全く異なる。この違いを無視した設計が、あらゆる計算を狂わせていた。解決の糸口は。休日をその性質に応じて3つのレイヤーに分解して定義し直すことにあった。

第一のレイヤーは「祝日」。これは国民の祝日に関する法律で定められた、全国共通の休日だ。個別の企業の都合では変わらない、最も基本的なカレンダーの構成要素です。

次に、第二のレイヤーが「会社休日」。創立記念日や夏季・冬季の特別休暇など、会社全体で一律に定められた休日のことだ。これは全社員に適用されるルールであり、祝日とは別に管理する必要がある。

そして最も厄介なのが、第三のレイヤー、「拠点独自休日」だ。工場のシフト制に伴う特定の休み、営業所がある地域だけの休日。あるいは特定の職種だけに適用される休暇。この変動要素こそが、勤怠計算を複雑化させる主犯格だった。

休日定義の混乱、基本無視と分類

以前のExcelでは、これら3つが祝日リストのシートに無秩序に混在していた。ある拠点の特別休日を祝日リストに追加した結果。その日付が他の全拠点で休日扱いになってしまい。総労働時間が想定より大幅に少なく計算される大惨事を引き起こしたこともある。勤怠管理の実務では、祝日設定、所属や拠点単位の休日設定。そしてそれらの自動更新設定を分離して扱う設計が一般的だ。自分たちはその基本を完全に無視していた。

一方で、先にツールを導入したり、自動化スクリプトを書いたりする前に。まずこの「休日の定義」を整理し、関係者全員で合意する必要があったのだ。どんなに高機能なシステムを導入しても、土台となるデータの構造が歪んでいては。まともな結果は得られない。泥臭いが、この分類こそが再建の第一歩だった。

Excel堅牢化、カレンダーマスタ

Pythonを導入するまでもない、あるいは予算が下りない。そんな状況でも、Excel運用のまま堅牢性を高める方法はある。それは「カレンダーマスタ」という考え方を導入することだ。全てのロジックを関数に詰め込むのではなく、変動する要素をデータとして切り出す。

具体的には、新しいシートを1枚作り、「カレンダーマスタ」と名付ける。A列に1年分の日付を並べ、B列に曜日を入れる。ここまでは誰でもやるだろう。重要なのはここからだ。C列に「祝日フラグ」、D列に「会社休日フラグ」を立てる列を用意する。祝日なら1、そうでなければ0、といった具合です。

拠点別休日マスタで運用と保守をシンプル化

そのため、そして。E列以降に「本社休日フラグ」「A工場休日フラグ」「B営業所休日フラグ」といったように。拠点ごとの休日フラグ列を追加していく。こうすることで、「この日にこの拠点は休みか？」という判定が、複雑なIF文ではなく。マスタシートの特定のセルを見るだけで完結するようになる。非エンジニアが運用を続けるなら、コードを直接修正するより。このマスタファイル（ExcelやCSV）をメンテナンスする方が遥かに安全で。保守性も高い。

勤怠データを集計するシート側では、`SUMIFS`や`COUNTIFS`、あるいは`XLOOKUP`といった関数を使って、このマスタを参照する。例えば、A工場の特定の月の勤務日数を計算したい場合、「カレンダーマスタのA工場休日フラグが0である」という条件を追加するだけで済む。数式がシンプルになり、可読性も劇的に向上する。

悪循環を断つカレンダーマスタ化

もちろん、毎年のマスタ更新は手作業になる。だが、年に一度、全拠点のカレンダー情報を集約してこのマスタを作る手間は。毎月発生する原因不明のエラー調査と修正作業に比べれば。比較にならないほど小さなコストだ。拠点別の休日差分を同一ロジックで処理しようとすることが。締め日前の膨大な差分修正と再計算を生んでいたのだから。このマスタ化は、その悪循環を断ち切るための、現実的で効果的な一歩となる。

自動化の肝は「検証ロジック

しかし、Excelでのマスタ運用が軌道に乗れば。次はいよいよPythonによる自動化が視野に入る。Excelで確立した「休日定義の分離」という設計思想は。Pythonスクリプトを書く際にもそのまま活きる。むしろ、その恩恵を最大限に引き出せる。

日本の祝日判定には、`jpholiday`という非常に便利なライブラリが存在する。PyPIで継続的に更新されており、数行のコードで特定の日付が祝日かどうかを判定できる。これで、まず「祝日レイヤー」の判定は自動化が完了する。

しかし、これだけでは不十分だ。祝日以外の「会社休日」と「拠点独自休日」は、別途ExcelやCSVファイルで作成したカレンダーマスタを`pandas`で読み込み、祝日情報とマージして最終的な勤務日カレンダーを生成する必要がある。

品質保証を自動化する検証ロジック

さらに、ここで絶対に忘れてはならないのが。「検証ロジック」を最初からスクリプトに組み込むことだ。データを取り込み、集計して、結果を出力する。それだけでは不十分。出力された結果が本当に正しいのか、機械的にチェックする工程を挟むのです。

例えば、集計が完了した後に。各拠点・各個人の月間総労働時間があるべき範囲（例えば140時間〜190時間など）に収まっているかチェックする。あるいは、休日と定義された日に出勤記録が残っていないか。逆に平日なのに勤務記録が全くない従業員がいないか。といった異常値を検出するコードを追加する。

この締め日前チェックを自動化することで、人的ミスやデータの不整合を早期に発見し。手戻りを劇的に減らすことができる。エラーが見つかれば、結果ファイルを出力せずに。どこがおかしいかを具体的に示す警告メッセージを出すようにしておく。集計処理の高速化だけでなく、この「品質保証」の工程まで自動化することこそ。真の業務改善と言えるだろう。

例外を表に出す設計とデータ管理

まず、拠点ごとに異なる休日ルールに振り回され、毎月の勤怠集計が破綻していた日々。そこから自分たちが学んだ最も重要な教訓は、ツールやテクニック以前の問題だった。それは、「例外を隠蔽せず、全て表に出す設計」を最初にやるべきだ、ということです。

複雑なIF関数やVBAマクロは、一見すると賢い解決策に見える。しかし、それは例外的なルールをブラックボックスの中に隠蔽しているに過ぎない。仕様変更や担当者の交代があれば、途端に誰も触れない技術的負債と化す。そうではなく、祝日、会社休日。拠点独自休日といったルールを「カレンダーマスタ」という誰の目にも見えるデータとして切り出す。この単純な分離が、全てを変えた。

自動化の本質：設計思想と価値

この設計思想は、ExcelでもPythonでも。あるいは高価な勤怠管理システムを導入する場合でも変わらない。変動要素をデータとして管理し、ロジックは可能な限りシンプルに保つ。例外が発生すれば、コードを書き換えるのではなく、マスタデータを修正すれば済む。この原則を守るだけで、システムの保守性は劇的に向上し、属人化を防ぐことができる。

次に、自動化のプロジェクトを評価する際。自分たちはつい「処理時間が何時間から何秒に短縮されたか」という点に目を奪われがちだ。しかし、本当に価値があるのはそこではない。差し戻しの件数や、再集計の回数がどれだけ減ったか。締め日前の問い合わせ電話がどれだけ鳴らなくなったか。そうした「手戻りコスト」の削減こそが、本質的な効果測定の指標となる。

自動化へ向けた業務の整理と設計

もしあなたが今、複雑なExcelファイルと格闘しているなら。いきなりPythonを学ぼうとする前に、一度立ち止まってほしい。その業務に潜む「例外」は何か。何度も手修正している箇所はどこか。まずはそれを紙に書き出し、分類し、管理可能なデータとして整理することから始める。自動化という華やかなゴールを目指す前に。この泥臭くも重要な設計作業に取り組むことこそが。未来の自分を助ける最短ルートなのです。

関連リンクとチェックリスト

学習サービスとアンケート