【Arc3後日談】半休申請の「例外」が全ロジックを壊した日——仕様漏れという名の罪

半休が突きつけた自作DBの仕様漏れ

自作したマクロやツールが、誰にも気づかれないまま現場のインフラになっていくことがあります。非エンジニアとして業務改善に取り組む人間にとって、これほど誇らしい瞬間はありません。前回の地獄のようなADO接続デバッグから2年。AccessとExcelを連携させて作り上げた野良DBは、信じられないほど静かに、そして安定して現場で稼働し続けていました。

誰も頼んでいないのに独学で構築したシステムでしたが、気付けば勤怠と有休管理の集計に不可欠な存在になっていたのです。有休、欠勤、遅刻、早退の4パターンを完璧に処理し、毎月の面倒な集計作業を一瞬で終わらせます。総務の担当者がボタン一つで月次レポートを出力し、定時ちょうどに鼻歌交じりで帰宅していく姿を見るたびに、密かな達成感を味わっていました。

半休という盲点

まず、システムが完全に業務に溶け込み、「もうこれ以上手を加える必要はない」と確信していました。しかし、システムというものは、運用者が安心しきった瞬間に牙を剥くことがあります。ある月の締め日が迫った午後のことでした。主要ユーザーの一人から、短いチャットメッセージが飛んできました。「半休って申請できますか？」

その数文字を見た瞬間、心臓が嫌な音を立てました。マウスを握る手にじわっと冷や汗が滲みます。有休・欠勤・遅刻・早退の4パターンしか想定していないシステムに「半休」という概念など存在しません。頭の中でデータベースのテーブル構造を急いで思い浮かべましたが、どう考えても半休を入れる隙間がありませんでした。胃の奥が鉛のように重くなり、「完璧に完成した」というあの自信が音を立てて崩れていくのを感じました。盤石だと思っていたロジックには、巨大な穴が空いていたのです。要件の洗い出しが不十分だったという、典型的な「仕様漏れ」の現実がそこにありました。

半休0.5、整数システム崩壊

非エンジニアが独学で作るシステムは、往々にして「自分が想像できる範囲の世界」だけで構築されるものです。私の野良DBも例外ではありませんでした。出勤すれば1、休めば0。有休を取得した場合も1日としてカウントする、すべてが整数で処理される「1日単位」の美しい世界だったのです。変数の型も、当然のように整数型（Integer）で定義していました。そこに「半休」という概念が持ち込まれました。半休は1日ではなく「0.5日」なのです。

次に、整数しか受け付けない設計のシステムに、小数を放り込むと何が起きるか。計算の土台が根本から崩壊します。半休を無理やり「0.5」として1件登録してみたところ、データベース側で型エラーになり保存すらできません。仕方なくデータベースのフィールドを単精度浮動小数点型（Single）に変更し、数値を流し込みました。すると今度は、月次の有休取得日数が0.5日分ずれてしまったのです。

小数点が狂わせたシステム

それだけなら個別の修正でごまかせるかもしれませんが、システムは連鎖的に狂い始めました。複数件の半休データが蓄積されると、その月の全員分の集計数字が意味不明な小数点の羅列になってしまったのです。小数点以下の端数処理、つまり切り上げや切り捨てのルールすらシステムには組み込まれていませんでした。「1か0か」の絶対的なルールで動いていた歯車に、0.5という異物が挟まったことで、システム全体が悲鳴を上げて停止してしまったのです。

半休フラグ導入、シンプルが招いた複雑化

解決策はシンプルに思えました。データベースのテーブルに「半休フラグ（True/False）」というYes/No型のフィールドを1本追加する。フラグがTrueなら0.5日として扱う。それだけで終わるはずでした。

しかし、現実は甘くありませんでした。フラグを追加した瞬間、あらゆる場所からエラーが噴き出したのです。修正が必要な箇所は1か所ではありませんでした。集計SQL、入力フォームのバリデーション、帳票出力用のVBA、そして前月比較ロジック。合計4か所すべてに「もし半休フラグがTrueだったら」というIF文を仕込まなければならないことが判明したのです。

深夜のもぐら叩きとコードの泥沼化

集計SQLを直してフォームを開くと、今度はバリデーションがエラーを吐きます。バリデーションの条件分岐を修正して帳票を出力しようとすると、レイアウトが崩壊して「0.5」という数字がセルからはみ出していました。1か所直せば別の場所が壊れるという、完全な「もぐら叩き」状態でした。深夜のオフィスで「なぜ最初から半休を想定しなかったのか」と自分を反省しながら、延々とF8キーでステップ実行を繰り返しました。画面を見つめすぎて目が霞み、頭痛が止まりませんでした。

SQLのSUM関数は単純に使えなくなり、複雑なCASE文を組み込む必要が出ました。VBAのループ処理の中でフラグの判定を追加したことで、処理速度も目に見えて落ちてしまいました。直しても直しても新しいバグが生まれます。コードはどんどんツギハギだらけになり、美しかった「0か1か」の世界は、複雑怪奇なIF文の迷宮へと姿を変えていきました。

システム全面刷新、スパゲッティコードの代償

結局、その場しのぎの修正では対応しきれないと判断しました。3日間、他の業務をすべて後回しにしてシステムの全面書き直しに没頭することにしたのです。上司には「ちょっとシステムのメンテナンスで時間がかかります」と曖昧な言い訳をしてしのぎました。既存のロジックを一度解体し、0.5日単位での集計を前提とした構造に作り直します。言葉にすれば簡単ですが、実際の作業はひたすら泥臭いものでした。

3日間の作業のほとんどは、コードを書くことではなく動作確認とテストデータの入力でした。半休と有休を組み合わせたパターン、月またぎの半休、さらには遅刻と半休の同時発生など。考え得る限りの例外ケースをひたすらExcelのシートに入力しては結果を確認する。ダミー社員の名前を無心で打ち込む時間は、まさに虚無でした。修正が完了したとき、コードの行数は元の約1.5倍に膨れ上がっていました。

スパゲッティコードと技術的負債

すべてのテストケースをクリアした瞬間、達成感よりも圧倒的な疲労と後悔が勝りました。行数が増えたことでコードの可読性は著しく下がり、まるでスパゲッティのように絡み合ってしまったのです。今後また新しい申請パターンが増えたら、この複雑なコードを解読しなければなりません。その事実が重くのしかかり、キーボードから手を離して深いため息をつきました。システムは再び動くようになりましたが、そこには「スパゲッティコード」という新たな技術的負債が残されたのです。

要件定義の欠如が招く悲劇

なぜこんな悲劇が起きたのか。原因はただ一つ、「要件定義」が抜け落ちていたからに他なりません。非エンジニアが独学で作るシステムには、体系的な要件定義など存在しないことが多いものです。目の前の不便を解消するために、いきなりコードを書き始め、いきなりテーブルを設計してしまいます。仕様書などという立派なものは一枚もありませんでした。

誰かが一番最初に「有休や欠勤以外に、半休はどうしますか？」と一言聞いていれば、設計段階のわずか30分で解決した話でした。しかし、当時の私にはその発想がありませんでした。現場からの「それ、どうなってますか？」というチャットが飛んできて初めて、要件が定義されたのです。

しかし、完成したものを後からひっくり返されるコストは、最初から要件に組み込むコストの何十倍にも跳ね上がります。「すぐ直せますよ」と安請け合いした過去の自分の浅はかさを、何度悔やんだことか。この「仕様漏れ」という罪の代償を、私は3日間の残業とスパゲッティコードという形で支払うことになりました。要件定義をサボれば、それは必ず後になってシステムを壊しにくるのです。

例外が鍛えるシステムと運用者

「システムが完成した」と思うのは、作り手の傲慢でしかないのかもしれません。現実の業務は常に変化し、作り手が想像もしなかった「例外ケース」を容赦なくぶつけてくるからです。

システムは、現実の前では常に未完成なのだと痛感しました。半休申請という例外ケースは、確かに私の全ロジックを破壊しました。しかし、それを乗り越えて組み直したことで、システムは以前よりも確実に強靭になりました。非エンジニアの運用とは、美しいコードを書くことではないようです。現場から飛んでくる「想定外」に泥臭く向き合い、ツギハギになってもシステムを動かし続けること。例外ケースこそがシステムを鍛え、そして運用者を成長させるのだと学びました。泥沼のデバッグの先に見えたのは、不格好ですが確実に現場を支えるシステムの姿でした。

例外が鍛えるシステムと運用者（続き）

📘 このスキルを活かしてさらに前へ進むなら、VBAやExcelマクロをもっと体系的に学びたい方には、実務向けの技術書で基礎を固めるのも有効な手段です。Amazonでは「Excel VBA 自動化」に関する評価の高い書籍が豊富に揃っています。VBA・Excelマクロの技術書（Amazon） → 📘 このスキルを活かしてさらに前へ進むなら、AIを使ったプログラミングをゼロから体系的に学びたい方には、生成AIプログラミングの教科書『大蔵～TAIZO～』がおすすめです。ChatGPTやClaude等の生成AIと組み合わせた実践的なコーディング手法を習得できます。生成AIプログラミングの教科書『大蔵～TAIZO～』 →

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

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