【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倍に膨れ上がっていた。

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

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

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

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

パネル/whiteboard-requirements-leak.webp

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

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

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

「システムが完成した」と思うのは、作り手の傲慢でしかない。現実の業務は常に変化し。作り手が想像もしなかった「例外ケース」を容赦なくぶつけてくる。パネル/access-running-in-empty-office.webpシステムは。現実の前では常に未完成なのだ。半休申請という例外ケースは、確かに私の全ロジックを破壊した。しかし、それを乗り越えて組み直したことで。システムは以前よりも確実に強靭になった。非エンジニアの運用とは、美しいコードを書くことではない。現場から飛んでくる「想定外」に泥臭く向き合い。ツギハギになってもシステムを動かし続けること。例外ケースこそがシステムを鍛え、そして運用者を成長させる。泥沼のデバッグの先に見えたのは、不格好だが確実に現場を支えるシステムの姿だった。

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

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

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

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