「午後半休の翌日が振替休日」、たった1つの例外が勤怠システム全体を壊した話

有給マイナス計上、自作ロジックの絶望

月曜日の午後に半休を取得します。そして火曜日を振替休日とします。これは、ごく一般的な働き方のひとつかと思います。就業規則に違反しているわけではありません。申請した社員の方に非はまったくないのです。それなのに、私の管理するシステムが問題を起こしました。月曜日を勝手に「全休」として計上してしまったのです。その結果、その社員の有給残日数がマイナスになりました。事態が発覚したのは、月末の給与計算の直前です。本人からの指摘を受け、ようやく気づくことになりました。

給与締め日の前日のことです。営業部のエースからチャットが届きました。「有給がマイナスですが、欠勤で給料が引かれますか？」という内容です。血の気が引き、慌ててマスターデータを開きました。確かにそこには、マイナスの表記があります。自分の組んだ数式が原因だと気づきました。その瞬間、冷や汗が吹き出しました。手元のマウス操作もおぼつかなくなるほどの衝撃でした。

まず、原因を詳しく調べました。それはシステムのバグとしか言いようがない現象でした。ですが、ロジックを組んだのは私自身です。Excel関数で組み立てたのは私だったのです。バグの根本は、自分の浅はかな思い込みにありました。それを悟った瞬間の絶望感は鮮明です。今でも思い出すと、胸が重くなるのを感じます。単なる計算ミスなら、すぐに直せます。しかし今回のエラーは違いました。ロジックの根底が崩れ去っていることを意味していたのです。

半休と振替休日、仕様の隙間が生んだ勤怠データ汚染

最初の設計仕様書を見返してみました。「半休は0.5日消化とする」という一文があるだけです。振替休日との組み合わせについては、考慮されていませんでした。これこそが、非エンジニアが陥りやすい罠です。最大の落とし穴なのかもしれません。プログラミング言語でも、Excelの数式でも同じです。システムは「書かれた通りにしか動かない」のです。その冷酷な事実を、強く突きつけられました。

振替休日は、出勤日を休日に変える処理です。一方で、半休は出勤を前提とした処理です。0.5日分の休暇を差し引くようになっています。この2つが連続、あるいは重複して申請されました。そのとき、どの日がベースの出勤日なのか判定できません。そのようなロジックは存在していなかったのです。エラー画面が表示されないのは、最も恐ろしい事態です。計算エラーの通知すら出ませんでした。内部の数値だけが、静かに狂い続けていたのです。過去の類似パターンをさかのぼって照合しました。すると、なんと3ヶ月分のデータが汚染されていました。

複雑な休暇システムの落とし穴と根本解決

次に、他の組み合わせも危険だと気づきました。半休と振替休日だけではありません。時間休と深夜勤務が重なったらどうなるでしょうか。半休の翌日が祝日で、連休が続く場合はどうでしょう。正しく計算されるか、不安になりました。特別休暇と出張が重なった場合はどうなるのか。疑問が次々と湧き上がってきました。今のシステムが、まるで地雷原のように思えてきました。

頭の中だけで考えていても、キリがありません。私は会議室にこもることにしました。ホワイトボードに「申請タイプ」を書き出しました。さらに「日付条件」もひたすら並べました。2時間かけて、全パターンのマトリクスを作りました。Excelにすべてを打ち込み終えたときのことです。赤いエラー候補のセルが15個も見つかりました。自分の作ったシステムの脆さに愕然としました。

ここで必要なのは、デバッグ的なアプローチでした。テストケースの発想でシステムを見直すのです。縦軸に申請のタイプを並べました。横軸には日付の条件を並べていきます。すべての交点を一つずつ確認しました。どのような結果を返すのが正解かを埋めていきました。この総当たり戦のような作業を続けるしかありません。地道な作業ですが、避けては通れませんでした。表面的な修正だけで済ませようとすれば、どうなるか。来月、また別の不具合を起こすでしょう。根本解決には、例外をすべて出すしかありませんでした。

複雑な勤怠集計のGAS再実装

一方で、Excel関数での対応は限界でした。複雑に絡み合った条件をさばききれません。IF関数をマトリョーシカのように入れ子にします。そうすると、暗号のような数式になります。半年後の自分でも、絶対に理解できない状態です。そこで、GASを使って再実装することに決めました。勤怠集計のロジックを、根本から作り直したのです。

ベースとしたのは、switch-caseによる設計です。半休フラグと、翌日の休日種別を組み合わせます。スプレッドシートから全員のデータを読み込みます。配列として読み込み、日付ごとに条件を判定します。最後に集計結果を書き戻すという骨格にしました。非エンジニアにとって、配列処理は難しく見えます。最初はハードルが高く感じられるかもしれません。ですが、一度変数にデータを格納してしまえば安心です。人間が考える順序のままに、条件分岐を記述できます。

「もし今日が半休で、翌日が振替休日ならこの処理」。この流れを、そのままコードに落とし込みました。Excel関数のネスト地獄から抜け出すことができました。可読性の高い状態を、しっかりと維持できています。

本番エラーとバックアップ、ヒヤリハット体験

テスト用のシートでは、完璧に動いていました。すべての例外パターンが、正しく処理されています。しかし、本番環境への適用は話が別です。3ヶ月分の汚染データを修正するのは緊張しました。現場のリアルなデータは、予測不能なものです。テストケースで想定できない入力が必ず潜んでいます。

そのため、深夜のオフィスで実行ボタンを押しました。祈るような気持ちでクリックしたのを覚えています。数秒の沈黙がありました。その後、画面のログにエラーが出力されました。想定外のエラーが1件だけ出たのです。それを見た瞬間、心臓が凍りつく思いでした。

ログの赤い文字を見て、背筋が凍る感覚でした。すべてが終わった、と絶望しかけました。しかし、直前の作業を思い出しました。手動でスプレッドシート全体をコピーしていたのです。バックアップを取っていたことに救われました。震える手で、すぐにデータを元に戻しました。なんとか事なきを得ることができました。あの寿命が縮むような恐怖は、二度と味わいたくありません。

バックアップがあれば、即座に復旧できます。当たり前すぎる基本の作法です。しかし、この基本に救われた夜でした。どんなにテストを重ねても、油断はできません。ロールバックできない修正は、絶対に行わない。そのことを、強く実感した体験となりました。

エラーゼロと設計進化

冷や汗をかきながら、修正を終えました。本番データへの適用から、8ヶ月が経過しました。その間、勤怠のエラーによるクレームはありません。一度も発生することなく、安定して動いています。

修正前と後を比較すれば、効果は一目瞭然でした。どれほどの無駄な労力を削減できたかわかりません。さらに、嬉しい副産物もありました。あの地獄の棚卸しで作ったマトリクスです。これが、次のシステム改修の設計書になりました。人事部から新しい制度の要望が来たときのことです。マトリクスの空きセルを埋めるだけで済みました。影響範囲を、すぐに特定できるようになったのです。目の前のバグを直す「モグラ叩き」は終わりました。再発を防ぐ「設計」に変えることができたのです。本質的な意識転換ができた瞬間でした。

kintoneによる勤怠申請フローの可視化

ロジックが堅牢になっても、課題は残りました。Excelベースの管理には、根本的な限界があります。申請フローがブラックボックスになっていました。「送信したら終わり」で、中身が見えません。誰がどの申請を出し、どこで止まっているのか。それらが、まったく可視化されていなかったのです。

この課題を解決するために、仕組みを変えました。申請のフロントエンドをkintoneへ移行したのです。申請者がフォームに入力した時点で判定します。裏側でGASが、条件チェックを走らせます。もし不適切な組み合わせがあれば、すぐわかります。ステータスが自動的にエラーとして赤くなります。その場で本人に差し戻される仕組みです。フローが可視化され、問い合わせは激減しました。UIの使いやすさを、kintoneで補完した形です。GAS単体では難しかった部分を、うまく解決できました。

業務自動化の肝、例外処理の基礎固め

有給がマイナスになるという大惨事がありました。その最大の原因を、改めて振り返ります。それは、仕様書に「やること」しか書いていなかった点です。それで満足していたことが、失敗の元でした。「やらないこと」や「例外」の視点がありませんでした。テストケースを仕様に含める思想が、欠けていたのです。

コードを書くときも、同じことが言えます。GAS内に、例外処理の理由をコメントで残しました。執拗なまでに、細かく記録する習慣をつけました。未来の自分が読んだときのことを考えたからです。なぜ面倒な分岐があるのか、理解できなければいけません。さもなければ、また同じ過ちを繰り返すでしょう。こうした例外処理の考え方は、非常に重要です。非エンジニアがシステムを作るなら、体系的に学ぶべきです。それが一番の近道になるはずです。専門書を読んだり、プロから基礎を教わったりしてください。基礎を固めるだけで、乗り越え方が劇的に変わります。

例外を想定内に変える設計3原則

1件のクレームから始まった、システムの崩壊劇でした。泥沼の修正作業を経て、仕組みは生まれ変わりました。ここで得た教訓を、3つの原則として書き残します。

一つ目は、申請の掛け合わせパターンを書き出すことです。マトリクスを作り、仕様を網羅してください。二つ目は、GASで条件分岐を明示的に書くことです。Excelのブラックボックスを解体し、例外を吸収します。三つ目は、kintoneで申請フローを可視化することです。運用フェーズでの、ヒューマンエラーを防ぎます。この3つの原則を守れば、もう怖くありません。予期せぬエラーが起きても、改善の機会に変えられます。なお、多拠点の勤怠集計に悩む方もいるでしょう。拠点別の祝日をPythonで自動化した記事もあります。こちらも参考になるため、ぜひ目を通してください。

業務自動化の道は、決して楽なものではありません。しかし、例外を飼い慣らすことは可能です。その先にこそ、本当の効率化が待っていると信じています。

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

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