みんな土日が休みではなかった
きっかけは「休暇の申請ができない職員がいる」というひとつの報告だった。雇用契約によっては、土日に勤務し火・木が休みという職員もいる。だがNGWは「休日とは土日と祝日である」という思い込みを、休暇・時間外・出勤簿・カレンダーの至るところに埋め込んでいた。それをたったひとつの式に一般化した記録。三つの環境への横展開と、カレンダーのバージョン違いを吸収した一手まで。
きっかけは、ひとつの報告だった。「休暇の申請ができない職員がいる」。
詳しく聞くと、こうだ。会計年度任用職員には、雇用契約によって勤務する曜日が人それぞれある。たとえば火・水・金・土・日に勤務し、月と木が休みという契約。その人が、自分の勤務日である土曜日に休暇を申請しようとすると、NGW が「その日は休日です」と拒む。
NGW は、休暇の日数を数えるとき土日と祝日を自動で除いている。土曜は休み。そう決めてかかっていた。だがその人にとって土曜は立派な勤務日だ。みんなが土日休みとは限らない。 当たり前のこの事実を、システムのほうが知らなかった。
考えてみれば、見落としてよい話ではなかった。自治体が運営する施設——図書館や体育館、観光や催しの窓口——は、むしろ土日にこそ利用者が集まる。そこに詰める職員が土日に働き、平日に休むのは、はじめから必然だ。「役所は平日、土日は閉まっている」という像は、庁舎の内側だけを見た思い込みにすぎない。
これは運用で後から出てきた例外ではない。設計の段階で織り込んでおくべきことだった。 正直に言えば、最初からの見落としである。
前提が、あちこちに埋まっていた
厄介なのは、ひとつの画面では済まないことだった。「休日とは土日と祝日である」という前提は、NGW の勤怠まわりの至るところに、善意のかたちで埋め込まれていた。
- 休暇申請では、土曜だけの申請を「期間がまるごと休日」と見て弾いていた。
- 休暇の日数計算も、土日を除いて数えていた。
- 時間外勤務では、その日が平日か休日かで割増の区分が変わる。土曜に働けば無条件で休日勤務の扱いだった。
- 出勤簿では、土日の日付が赤く印字される。
- 勤怠のカレンダーは、土曜を青、日曜を桃色に塗る。
どれも「土日＝休み」を前提にした、まっとうな作り込みだ。悪いコードではない。ひとつの隠れた思い込みが、機能をまたいで散らばっていた。土曜に働く人が現れた瞬間、その全部が一斉にほころびを見せた。
たったひとつの式に一般化する
直し方は、職員ごとに分岐を足すことではない。それをやると、思い込みが散らばったまま例外だけが増える。「休日」の定義そのものを一段引き上げる。
休日 ＝ 祝日である、または、その日の曜日が、その職員の勤務曜日に入っていない
こう置くと、通常の職員は「勤務曜日＝月〜金」というひとつの特殊ケースにすぎなくなる。月〜金が勤務曜日なら、土日は勤務曜日に入っていないから休日。これまでとまったく同じ結果だ。火水金土日が勤務曜日なら、土曜は勤務日、月木が休日。同じ式が、両方を正しく捌く。
職員ごとの勤務曜日は、職員×年度で管理している休暇簿のデータに、小さなJSONでひとつ持たせた。設定がなければ月〜金とみなす。何も設定しなければ、これまで通り。 既存の全職員の挙動は一行も変わらない。後方互換を、既定値ひとつで担保した。
肝心なのは、この判定をあちこちに書かないことだ。判定はひとつのヘルパーに集約し、休暇も時間外も出勤簿もそれを呼ぶ。入口が一本なら、直すときも一箇所で済む。将来こしらえ直すときも迷わない。祝日は全職員一律で休日。これは式の第1項に置いたので、勤務曜日が何であっても揺るがない。（祝日にも働く契約がいつか出てきたら、という将来の余地は、ヘルパーの引数ひとつぶんだけ空けてある。）
三つの環境と、カレンダーのバージョン違い
NGW には、いま動いている本番版のほかに、次の版を育てている開発環境と、勤怠だけを切り出した派生版がある。同じ改修を三つに届けなければならない。
判定ロジックは素直に運べた。外部ライブラリに依存しない、ただの PHP だからだ。数える、色を決める、割増の区分を選ぶ。どれも「その日は休日か」を問う一行を差し替えるだけで済む。既定値が従来動作なので、差し込んでも既存の職員には何も起きない。
ひとつだけ、環境ごとに顔つきが違った。カレンダーで休みの曜日を色分けするところだ。ここは FullCalendar という外部ライブラリの上に載っている。そして環境によって FullCalendar のバージョンが違った。ある版は、カレンダーの各曜日セルに fc-tue（火曜）というクラスを付ける。別の版は、同じ火曜のセルに fc-day-tue という別名のクラスを付ける。片方の書き方で CSS を当てても、もう片方ではセルに一切色が付かない。
これは実際に、色の付かない環境の画面を見て初めて気づいた。手元では正しく塗れている。別の環境ではまるで効かない。CSS を疑い、優先順位を疑い、キャッシュを疑い、最後に開発ツールでセルのクラス名を覗いた。名前そのものが違った。外部ライブラリのバージョン差が牙をむく典型である。
直し方は素朴だが確実だ。両方に当てる。 休みの曜日それぞれについて、fc-tue と fc-day-tue の両方を並べた CSS を吐く。どちらのバージョンでも、どちらかが必ず当たる。バージョンを判定して分岐するのではなく、両にらみのセレクタを一度に書いておく。これで三つの環境が同じ一枚のコードで足並みをそろえた。休みの曜日の列は、日曜と同じ淡い色で静かに塗られるようになった。
AIとの協働作業での学び
この改修で AI がいちばん力を出したのは「一段上げる」提案だった。個別の職員のために分岐を足すのではなく、休日の定義そのものを勤務曜日の集合で表す。そして「通常職員は月〜金という特殊ケースにすぎない」という見立て。ここが定まると、散らばっていた前提がひとつの式にきれいに畳めた。既定値で後方互換を取るという設計の型も、AI が最初から織り込んでいた。
一方、どこに前提が埋まっているかを知っていたのは人間だった。休暇だけでなく、時間外の割増区分も、出勤簿の赤い日付も、カレンダーの色も。「土日＝休み」がどの機能に効いているかは、現場でその画面を使ってきた感覚からしか出てこない。AI は示された一箇所を直せるが、他にも同じ思い込みが潜んでいると嗅ぎ当てるのは使い手の勘だ。
カレンダーの一件は、動かしてみないと分からないことがあるという当たり前を改めて教えた。判定ロジックは机上で正しく運べても、外部ライブラリのバージョン差は、実際に色の付かない画面を見て初めて表に出る。AI が抽象を組み、人間が現実を突き合わせる。今回もその往復だった。
「みんな土日が休み」。長く疑わずにいた、たったひとつの思い込みだ。それを式ひとつぶんだけ広げてやると、NGW は土曜に働く人のことも、ようやく知ることができた。
これはたぶん未来の話でもある。AI が仕事に浸透していくほど、働き方はもっと自由になる。週に四日だけ出て、休む曜日は自分で選ぶ。そんな職場も当たり前に出てくるだろう。そのとき土台になるのは、まさに「休みは土日とは限らない」を当然として扱える仕組みだ。今回埋めたたったひとつの穴は、図らずもその入口だった。
……とはいえ、そんな立派な話にする前に、まず言っておくべきことがある。土曜に働いている職員は、いまこの瞬間も現場にいたのだ。未来を語る前に、目の前の一人である。