会社カレンダーを別ファイルで持つだけで勤怠ロジックの見通しが良くなった話

会社独自休日と終わらない勤怠システム修正

総務部門の壁の向こうから、ある会話が聞こえてくることがあります。それは「今年の飛び石連休は、間の平日を休みにしましょう」という内容です。それを耳にした瞬間、胃がキュッと締め付けられる経験はないでしょうか。「あ、またあの作業をしなければならない」と、直感的に身構えてしまうからです。勤怠集計のプログラムを、わざわざ開かなければなりません。そして、対象の日付を例外処理として、直接コードに書き足す必要があるのです。

日本の祝日を判定するだけであれば、話は非常に簡単です。外部ライブラリを活用することで、確実かつ迅速に解決ができます。Pythonの「jpholiday」は、祝日判定に使える便利なパッケージです。これをプログラムに組み込むだけで、国民の祝日は自動で判定されます。非常に効率的な仕組みを、すぐに構築できるのが利点です。しかし、会社特有のルールとなると、そうはいきません。創立記念日や、夏季の特別休暇などが存在するからです。さらに、拠点ごとに異なる工場の稼働停止日などもあります。これらは標準のライブラリでは、一切カバーできない領域です。そのため、個別の対応が必要になってしまいます。

終わらない日付のハードコード修正

毎年、春先になると総務から連絡が届きます。「今年は拠点Aだけ、5月2日を休日にする」といった指示です。そのたびに、私は冷や汗をかきながら作業をしていました。Pythonコードのif文を探し、直接日付を追記していたからです。わずか1行の修正であっても、決して油断はできません。全拠点のテストを、最初からやり直す必要があるからです。ゴールデンウィーク直前の深夜に、一人で作業をしたこともありました。オフィスでキーボードを叩きながら、泣きたい気持ちになった経験です。同じような境遇の方は、意外と多いのではないでしょうか。

結局、手っ取り早く解決しようとして、失敗してしまいます。プログラムの中に、特定の日付を直接書き込んでしまうのです。これは「ハードコード」と呼ばれる、初心者がやりがちなミスです。条件分岐のif文が、継ぎ足しの秘伝のタレのように増えていきます。最初は「今回だけ、とりあえず対応しよう」と自分に言い訳をしていました。しかし、年を追うごとにコードはどんどん巨大化します。ついには、自分でも中身がよくわからない状態になりました。いわゆる「スパゲティ状態」に陥ってしまうことがよくあります。

ハードコードが増えた後の不安

誰にも読み解けない、複雑な条件式が完成してしまいました。プログラムを起動するたびに、大きな不安に苛まれます。「今年は何かの休日を、拾い損ねていないか」と心配になるのです。毎年、同じ時期に、同じような修正作業に追われます。そのたびに、エラーの恐怖と戦わなくてはなりません。この「終わらない修正」のループから、早く抜け出す必要があります。そうしなければ、本当の意味で業務が楽になったとは言えません。運用の仕組みそのものを見直す時期が来ているのです。

コード内休日判定の悪夢、外部化で保守性向上

では、なぜコード内に休日判定を書くことが苦痛なのでしょうか。その理由は、とても単純なところにあります。カレンダーが変わるたびに、コードそのものを直していました。その後に必ずテストが必要になり、それがミスの原因になります。修正とテストの繰り返しが、バグを招く元凶となってしまうのです。

プログラムのコード内に、特定の値を直接記述してはいけません。ルールの変更を、エンジニアしか行えなくなるからです。あるいは、コードを書いた本人に作業が集中してしまいます。担当者が有給休暇を取っている最中に、変更があるかもしれません。急なルール変更があれば、業務は完全に停止してしまいます。非エンジニアである総務担当者に、コードを触らせるのも危険です。たった一つのカンマのミスが、システムには致命傷になります。インデントのズレ一つで動かなくなるPythonでは、避けるべきです。

かつて私も、コードを修正した際にミスをしました。インデントを一つ間違えてしまったのです。その結果、本番の勤怠集計が全拠点でエラーとなりました。翌朝、出社するなり部長から内線で呼び出されました。「手作業の頃より遅れているぞ」と詰め寄られたのです。胃の奥が鉛のように重くなった経験は、今でも忘れられません。このような悲劇を繰り返さないための工夫が必要です。

疎結合：設定外部化による効率化

ここで必要になるのが、保守性の高い設計の考え方です。システム開発で重視される「疎結合」という概念を活用します。不変のロジックである「計算手順」は、まず固定する形です。そして、可変のパラメータである「休日データ」を切り離します。これらを完全に分離して管理することが重要です。プログラムは、自分の内部で休日を判断するのをやめます。代わりに、外部に置かれた設定ファイルを確認しに行きます。そこに書かれた結果を、ただ受け取るだけの構造に変えるのです。

コード修正なら、最低でも30分はかかる作業があります。テストと反映作業を含めると、それなりの負担です。しかし、外部ファイルの書き換えなら、わずか2分で完結します。この差が、一ヶ月や一年と積み重なればどうでしょうか。どれほどの自由な時間を生み出すか、想像してみてください。

この構造に移行すれば、プログラム自体は変更不要です。プログラムを触らないため、安全性も高くなります。新しいバグが入り込む余地が、完全になくなるからです。日々の運用のストレスも、大幅に軽減されることでしょう。

担当者が設定を直せる安心感

設定を外部ファイル化することには、大きなメリットがあります。非エンジニアの担当者でも、業務ルールを変更できる点です。コードを一文字も触らずに、設定を更新することが可能です。自分が休みの日に、総務が休日を追加しても問題ありません。システムは文句も言わずに、正常に稼働し続けます。属人化を排除し、システムの寿命を延ばすことができます。これが、持続可能な設計の第一歩になりました。

Excelマスタを使った休日管理

外部ファイル化を検討する際、大切なのは形式です。JSONやYAMLといった形式は、システム開発では一般的です。しかし、プログラミング未経験の担当者には向きません。JSONの括弧の構造を理解させるのは、少し酷な話です。カンマの抜けがないように編集させるのも、現実的ではありません。入力ミスが起きれば、結局は読み込みエラーが発生します。これでは、元の木阿弥になってしまうでしょう。

そこで最も有効なのが、Excelをマスタにすることです。誰もが使い慣れているツールを採用するのが一番です。これなら直感的に操作でき、入力もスムーズに進みます。入力規則を設定しておけば、表記の揺れも防ぐことが可能です。総務担当者にとって、Excelの更新は日常業務の一部になります。心理的なハードルも、ぐっと低くなるはずです。

設計図は、極めてシンプルにするのが成功のコツです。縦軸には、1年分の日付をずらりと並べます。そして横軸には、拠点名をそれぞれ配置していきます。「本社」や「大阪支店」といった具合です。それぞれの交点に、フラグを立てていくだけの表にします。具体的には「休日は1、出勤日は0」と入力します。

拠点別休日をExcelで簡単管理

このマスタさえ作れば、独自の休日をすべて吸収できます。振替出勤日も、創立記念日も、この表で管理可能です。飛び石連休の中休みも、セルを「1」に変えるだけです。総務部門は、毎年年末にこの表を更新すればよいのです。翌年の会社カレンダーを見ながら、ルーティンで行います。これで、拠点ごとに異なる複雑な課題が解決されます。視覚的に管理しやすい、シンプルな一覧表に変わるのです。

システムは、起動したときにExcelを読みに行きます。指定されたフォルダにあるファイルを、確認するだけです。人間のための見やすい表と、機械のためのデータを両立させます。これこそが、実務で保守しやすい設計の最大のコツです。無理のない運用こそが、自動化を成功させる鍵となります。

pandasでExcel連携、日付型統一の肝

マスタが完成したら、いよいよ実装のフェーズです。Pythonを使えば、Excelの読み込みは非常に簡単です。強力なライブラリである「pandas」を活用しましょう。これまで数十行もあった条件分岐が不要になります。嘘のように短い記述に、置き換えることができるからです。コードの可読性も、劇的に向上させることが可能です。

かつて50行を超えていた、複雑なif文がありました。まるでジャングルのようだったコードが、整理されます。pandasによる読み込みと辞書化を、ぜひ試してください。わずか3行ほどの、スマートなコードに集約されます。

実装の流れは、とても明快でわかりやすいものです。まず「read_excel」関数を使ってマスタを読み込みます。読み込んだデータを、Pythonの辞書型に変換します。あとは、判定したい日付と拠点名をキーにするだけです。辞書を検索し、フラグが「1」なら休日と判定します。このステップだけで、すべての処理が進んでいきます。

日付処理の落とし穴と安定稼働の秘訣

ここで、大きな落とし穴についても触れておきます。それは、日付の「データ型」が一致しない問題です。Excelから読み込んだ日付は、特殊な型として認識されます。一方、プログラム側の「今日の日付」は文字列かもしれません。見た目が同じ日付でも、システムは「別物」と判断します。これが原因で、プログラムが停止することがよくあります。キーが見つからないというエラーには、注意が必要です。

これを防ぐためには、型を統一する処理を挟みます。比較を行う前に、必ずフォーマットを揃えましょう。Excelから読み込んだ列を、文字列に明示的に変換します。その上で辞書のキーとして扱うように設定します。このひと手間を加えるだけで、確実性が増します。システムが安定して動くための、大切なポイントです。

pandasで効率化と安定稼働

初めてこの方法を試したとき、私は感動しました。日付と拠点名を指定するだけで、情報が取得できたからです。これまで書いてきた冗長なif文が、無意味に感じられました。思わず天を仰いでしまうほどの衝撃を受けたのです。画面の中で、システムがカレンダーを理解して動いています。その様子を見て、本当に嬉しくなったことを覚えています。

また、辞書から値を取り出す際のエラー対策も重要です。マスタにない未来の日付が、指定されるかもしれません。その際も、エラーを出さずに動くように工夫しましょう。デフォルト値として「出勤日」を返すように設計します。エラーで処理を止めないことが、運用の要です。想定外の事態でも、安全に動き続ける仕組みを作ります。

運用設計の要 休日判定の外部ファイル化

休日判定を外部化するのは、単なる整理術ではありません。業務とシステムの「責任の境界」を引く作業です。プログラムにルールを書くと、修正に知識が必要になります。それでは、特定の人しか触れないツールになってしまいます。自動化で楽をするはずが、逆に首を絞めることになります。そのようなパラドックスに陥らないよう、注意が必要です。

一度作った計算ロジックは、大切な資産として守りましょう。安易に変更を加えないことが、安定運用のコツです。一方で、日々変化する休日の情報は現場に任せます。担当者が、運用の中で柔軟に書き換えていく形にします。この明確な線引きこそが、長く自動化を続ける秘訣です。お互いにとって、最もストレスの少ない形を目指しましょう。

外部化で開発者の心の平穏

会社カレンダーを別ファイルにするという、小さな工夫。それだけで、コードの見通しは驚くほど良くなります。何より、あなた自身の心の平穏が保たれるはずです。毎年のように休日の対応に怯える日々を、終わらせましょう。今すぐハードコードされたif文を、消し去ってください。そして、Excelファイルの作成から始めてみてください。きっと、明日からの開発がもっと楽しくなるはずです。

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

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