消防の勤怠は市町村の勤怠に載らない — 広域消防組合向けFGWを提案できるところまで作った

広域消防組合向けに、勤怠管理を提案した。NGWの上に載る消防専用の勤怠で、呼び名は FGW（Fire GroupWare）。中身はNGWそのもので、名前が変わるだけだ。

先に結論を書く。市町村の勤怠にそのまま載せようとして、何度も作り直した。 載らない理由を調べて、設計に書き戻したら、提案できる形になった。

消防の勤務は何が違うのか

市町村の勤怠は「平日の日中に出勤する」が前提だ。消防の署員は違う。調べて分かったことを並べる。

隔日勤務。 1当務は15.5時間。休憩は12時〜13時と17:15〜17:45、22時〜5時は仮眠。4週で10当務、155時間に収める。
2部制。 当務と非番を交互に回すと、4週で14当務になってしまう。10当務に収めるには、職員ごとに少しずつずらして、4当務を週休日へ振り替える。これがシフト生成の中核になった。
非番でも週休日でも、緊急出動がある。 出退勤を打てるのは当務と日勤だけ、という市町村向けの前提が崩れる。
年休の数え方が違う。 隔日勤務者は、1勤務日が2日分。7時間45分で1日と数える規程を、いくつかの消防の例規で確かめた。
休暇と勤務の割振りは、どちらが優先か。 人事院の運用に合わせて、休暇を優先にした。結婚・忌引・産前産後・罹災は、勤務日ではなく暦日で数える。

休暇マスターは、組合の例規が「近隣市の条例の例による」と書いていたので、その条例と規則から30件を転記した。規則の2ページ目以降は、例規集サイトの画面遷移の裏にあって、ブラウザの通信を見ないと取れなかった。

設計の判断

既存の人事・勤怠(JINJ)は触らない。 消防用の表は fgwt_* として新設した。NGW側の表に列は足していない。

DB名に意味を持たせない。 消防用のDBに fgwdb という名前を付けたが、機能の有無はDB名では分岐させない。すべて定数（消防勤怠設定）で決める。DB名で分岐すると、「名前を変えたら動かない」が必ず起きる。

署と部は、既存のマスタに寄せた。 署・分署（建物）は庁舎マスタ、署内の第1部・第2部は組織マスタに置く。専用のマスタは作らない。桁の意味にも依存しない。部門コードは「不透明なキー」と割り切り、署所の判定は庁舎コードで行う。

データ移行で必ず当たるようにした。 消防用の表のDDLは、冪等なSQLにして、DB入替の更新SQLのループに置いた。入替のたびに全団体へ、空の表が作られる。

決裁経路は一本化した。 承認は、課長・係長のオンライン決裁に寄せた。

作ったもの

当番表。 一括作成、休暇の重ね表示、最少人員を割ると赤枠。
勤怠日報。 カレンダーだけの画面で、日を押すとモーダルが開く。引継事項もここに書く。
勤務の変更。 申請・承認・履歴。勤務交代は、「代わってもらう日」と「返す日」を組にして1件で扱う。
休暇簿・休暇申請、時間外申請、勤怠承認、月締め。
帳票。 出勤簿、業務日報、時間外命令簿・月集計、休暇処理簿・代休処理簿・介護休暇簿。

緊急車両は、予約でなく運行記録にした

一般の公用車は、前もって予約して使う。消防の車両は緊急車両で、予約を取って出るものではない。主役は、出動のあとに残す運行の記録だ。

そこで、予約カレンダーを予約の画面にするのをやめて、日誌の入口にした。

境目の日以前の枠や予約をダブルクリックすると、予約フォームではなく、運行日誌が開く。
予約の無い日誌を保存すると、予約が自動で作られて日誌に紐づく。日誌の日時を直せば予約も追従し、日誌を消せば予約も一緒に消える。
境目の日は定数で決める。車両は「当日以前」から日誌。今日の運行は、もう動いているからだ。 会議室や備品は「前日以前」から。今日の予定は、まだ先のこともある。
値を0にすれば、常に予約フォームが開く。交代制勤務のない部署の会議室のように、日誌運用が馴染まない設備では、この仕組みを切って従来の予約に戻せる。

「記録し忘れを責める仕組み」ではなく、過去になった予約の画面そのものを、記録の画面に差し替える。記録しかできない画面にしておけば、記録は習慣になる。

日誌の既定値も自動で入れる。点検・確認者は、当番表で勤務中の上司（同じ部・係、次に同じ課の順）。アルコールチェックは、運転前を8:30とし、運転後は欄を押した時刻にする。

この仕組みは、車両で終わらなかった。会議室・備品の使用簿を新設して、同じ入口から開くようにした。メニュー名は「予約/運行」から「予約/日誌」になった。

使われていなかったドローン飛行記録が、消防で出番を得た

NGWには、前からドローンの飛行日誌と飛行記録PDFがあった。ほとんど使われていなかった。

消防は、災害時の状況把握や捜索にドローンを使う。出動のあとに記録を残す点で、運行日誌と同じ性質の業務だ。ドローンを備品として、予約カレンダーから飛行日誌を直接登録できるようにした。

ただし、消防で飛行記録が実際に必要かどうかは、まだ私の推測だ。 現場への確認事項に入れてある。

使われていなかった機能は、使い始めた途端に、埋もれていた不具合が全部出た。

飛行日誌の初期値の設備カテゴリが、車両になっていた。
予約の無い直接登録で、設備カテゴリが0で保存されていた。提出一覧は設備カテゴリで絞るので、記録が集計から漏れる。
飛行記録PDFは、列がA4横幅なのに縦の用紙で作っていて、右が切れていた。
飛行時間が12時間制で出ていて、1時間未満の飛行が「12時間」と表示された。

入力画面、予約との連携、PDF。この三つがそろって初めて、「使える」と言える。

失敗と作り直し

帯の長さで時刻を表現するのは、月表示では無理だと判断して、いったん捨てた。 その後、1レーンの月タイムラインに実時刻の開始・終了を渡すと、月表示のまま帯の幅が時刻に比例すると分かった。当番表を見る人の要望どおりになった。
勤怠確定の画面は、何度も作り直した。 最初は市町村の勤怠管理に寄せた。次に、カレンダーだけの勤怠日報にして、入力をモーダルに移した。入力項目の自由度が上がるからだ。
出退勤を打てる区分を広げた。 最初は市町村の勤怠から引いて、当務と日勤だけにしていた。緊急出動が非番でも起きると分かって、全区分に広げた。
既存の勤怠の不具合を、消防側で踏んだ。 取下げや却下で休暇簿が戻らない、権限を画面から送られた値で判定している、など。消防側で直し、元のNGW側には別途メモを渡した。
画面のフォームの onsubmit="return false" が、メニュー遷移を止めていた。 当番表と勤怠確定の両方で、遷移が効かなかった。

提案できる状態にした方法

仕様書は60ページ超になった。画面は、見本のダミーデータから撮った。A4では画面全体が読めないので、必要な部分を切り出して載せた。

もう一冊、現場確認用の別冊を12ページで作った。現場に確認したい10問を、7章にまとめた。 2部制の理解、部をまたぐ交代の承認者、応援と研修の扱い、確定後の修正、ドローンの飛行記録の要否。ここは、現場で聞くまで分からない。

AIとの協働作業での学び

例規の読み解きは、AIが速い。ただし、読ませる範囲を切るのは人間の仕事だった。 条例と規則を読ませて休暇を転記させたが、「どの条例の例によるか」の一段上は、こちらが指定した。

AIは「他の人もそうしている」を持ち込む。 市町村の勤怠をなぞった案が、何度も出てきた。消防の勤務の前提——非番でも出動がある——を言葉にして渡すたびに、設計が変わった。

使われていない機能をどうするかは、AIに聞いても出ない。 ドローン飛行記録を消防に使うという発想は、私の側から出た。AIは、そこから不具合を洗い出すのが得意だった。