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

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

月曜日の午後に半休を取り、火曜日を振替休日とする。ごく普通の働き方だ。どこにも就業規則の違反はないし、申請を上げた社員は何も悪くない。それなのに。私が管理している勤怠システムは月曜日を「全休」として勝手に計上してしまった。結果としてその社員の有給残日数がマイナスに突入し。月末の給与計算直前になって本人からの強烈なクレームで発覚した。

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

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

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

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

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

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

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

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

ここで必要なのはテストケースの発想でシステムを見直すというデバッグ的なアプローチである。縦軸に申請のタイプを並べ、横軸に日付の条件を並べる。すべての交点を一つずつ確認し。それぞれがどのような計算結果を返すのが正解かを埋めていく。この総当たり戦のような作業を地道にやるしかないのだ。表面的な数式の修正だけで済ませようとすれば。来月また別の組み合わせでシステムが爆発する。根本的な解決には、すべての例外パターンをテーブルの上に引っ張り出すしかなかった。

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

一方で、複雑に絡み合った条件をExcel関数だけでさばくのは限界に達していた。IF関数をマトリョーシカのように入れ子にしていくと。半年後の自分が読んでも絶対に理解できない暗号が完成する。そこでGoogle Apps Scriptを使って勤怠集計のロジックを根本から再実装することに決めた。

ベースとなるのは。半休フラグと翌日の休日種別を組み合わせるswitch-caseの設計だ。スプレッドシートから全員の勤怠データを配列として読み込み、日付ごとに条件を判定し。最後に集計結果を書き戻すという3ステップの骨格を作る。非エンジニアにとって、GASの配列処理は最初こそハードルが高く感じる。だが、一度変数にデータを格納してしまえば。あとは人間が考える順序のままに条件分岐を記述できる。もし今日が半休でかつ翌日が振替休日ならこの処理ルートを通す。という流れをコードの形に落とし込む。Excel関数のネスト地獄から抜け出し。可読性の高い状態を維持することが最大の目的だった。

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

テスト用のスプレッドシートでは。すべての例外パターンの条件分岐が完璧に動いていた。しかし、本番環境の3ヶ月分の汚染データへ適用するとなると話はまったく別である。現場のリアルなデータには。テストケースですら想定できなかったイレギュラーな入力が必ず潜んでいるからです。

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

ログの赤い文字を見た瞬間、全身の毛穴が開く感覚があった。終わったと思ったが。直前に手動でスプレッドシート全体をコピーしてバックアップを取っていたことを思い出した。震える手ですぐにデータを元に戻し、事なきを得たが。あの10秒間の寿命が縮むような恐怖は二度と味わいたくありません。

バックアップを取っておけば即座にリストアできる。当たり前すぎる基本作法だが、この本番前のバックアップに救われた夜だった。どんなにテストを重ねても。ロールバックできない一発勝負の修正プログラムを走らせてはいけありません。

エラーゼロと設計進化

しかし、冷や汗をかきながら修正プログラムを本番データに適用し終えてから。現在に至るまで8ヶ月が経過した。その間、勤怠システムに関するエラーのクレームはただの1件も発生していありません。

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

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

計算ロジックが堅牢になっても。Excelベースの勤怠管理には根本的な限界が残されていた。それは、申請フローが送信したら終わりのブラックボックスになっていることだ。誰がどの申請を出し、どこで承認が止まっているのかがまったく可視化されありません。

さらに、これを解決するために。勤怠申請のフロントエンドをkintoneのワークフローへ移行することにした。申請者がフォームに入力した時点で、裏側でGASが条件チェックを走らせる。もし例外パターンの組み合わせに抵触していれば。kintone上のステータスが自動的に条件エラーとして赤く表示され。本人に差し戻される仕組みだ。システム上でフローが可視化されたことで、総務への問い合わせは激減した。GAS単体では実現できないUIの使いやすさを。kintoneとの連携によって補完したのです。

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

あの日。有給がマイナスになるという大惨事を引き起こした最大の原因を改めて振り返る。それは仕様書にやることだけを書いて満足していたからだ。やらないこと、想定外の組み合わせ。テストケースを仕様書に含める設計思想が抜け落ちていたのです。

コードを書くときも同じだ。GASのスクリプト内に。なぜその例外処理を入れたのかをコメントで執拗に残す習慣をつけた。未来の自分が読んだときに、なぜこんな面倒な条件分岐があるのかを理解できなければ。また同じ過ちを繰り返すからだ。こうした業務自動化における例外処理の考え方や。非エンジニアが自力でシステムを設計するためのノウハウは。体系的に学ぶのが一番早い。AmazonでGASの実務書を一冊手に取るのも良いし。侍エンジニアのようなスクールでプロからエラーハンドリングの基礎を叩き込まれるのも確実な方法だ。基礎を固めるだけでも、次に同じ壁にぶつかったときの乗り越え方が劇的に変わる。

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

まず、たった1件のクレームから始まった勤怠システムの崩壊は、泥沼の修正作業を経て。ようやく堅牢な自動化の仕組みへと生まれ変わった。ここで得た教訓を、例外を想定内に変える3つの設計原則として書き残す。

申請の掛け合わせパターンを全列挙したマトリクスを作り、仕様を網羅する。GASで条件分岐を明示的に書き。Excel関数のブラックボックスを解体して例外を吸収する。kintoneで申請フローを可視化し、運用フェーズでヒューマンエラーを防ぐ。この3つの原則さえ守っていれば、次に予期せぬエラーが起きたとしても。それをシステムの崩壊ではなく設計の改善機会に変えられるはずだ。なお、多拠点での複雑な勤怠集計に悩んでいる場合は。拠点別祝日カレンダーをPythonで自動化した記事も参考になるためぜひ目を通してほしい。業務自動化の道は険しいが、例外を飼い慣らした先にこそ本当の効率化が待っている。

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

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