月末、総務の田中は勤怠システムの集計画面を前に手を止めた。製造二課の従業員一人の時間外労働が、今月だけで98時間に達している。特別条項付きの36協定で定めた単月100時間未満まで、残り2時間しかない。慌てて過去五か月分をさかのぼると、同じ従業員は年間の特別条項上限である720時間に対しても、すでに680時間を超えていた。協定を結んだのは半年前の人事担当者で、今は異動している。上限の内訳を記した紙は引き出しの奥にあり、Excelの集計表は部署ごとにフォーマットがばらばらで、誰がいつ何時間働いたかを正確に足し合わせるだけで午前中が終わった。現場の課長に連絡すると「繁忙期だから仕方ない」と返ってくる。だが「仕方ない」で済ませられる話ではないことは、田中が一番よく分かっていた。気づいたときには、もう崖の淵に立っていたのだ。
こうした場面は、決して特殊な会社の話ではない。むしろ多くの中小企業で、形を変えて繰り返されている。
なぜ36協定の管理はExcel・手作業だと崩壊しやすいのか
一つ目の理由は、部署・従業員ごとに異なる上限管理の複雑さにある。36協定の特別条項は、事業所ごと、職種ごとに異なる上限が設定されていることが多く、さらに年間の上限、単月の上限、複数月平均の上限という三種類の基準を同時に満たす必要がある。これを手作業で従業員一人ひとり、月ごとに突き合わせるのは、想像以上に骨が折れる作業だ。担当者が変わるたびにルールの理解が薄れ、属人化した知識が引き継がれずに抜け落ちていく。
二つ目の理由は、月次集計が事後確認になりがちで、リアルタイムに把握できないことだ。多くの現場では、月末や翌月初めにまとめて集計する運用になっている。しかしそれでは、上限に近づいている従業員がいても、気づいた時点ですでに超過している、あるいは超過が確定的な状況になっていることが少なくない。本来必要なのは「超えそうだから今のうちに手を打つ」という予防的な発想だが、事後集計の仕組みではその発想自体が成立しにくい。
三つ目の理由は、複数の労働時間管理システムや勤怠システムと連携していないため、データが分断されていることだ。打刻データは勤怠システムに、休日出勤の申請は別の申請システムに、みなし残業や裁量労働の扱いはExcelの別シートに、といった具合にデータが散らばっていると、それらを毎回手動で突き合わせて初めて実態が見える。突き合わせの手間がかかるほど、確認の頻度は下がり、結果としてリアルタイム性はさらに失われていく。
放置するとどうなるか
36協定の上限超過を放置した結果は、決して軽いものではない。まず、労働基準監督署による是正勧告の対象となる。是正勧告に従わず改善が見られない場合、書類送検に至るケースもあり、悪質と判断されれば企業名が公表されるリスクもある。一度でも企業名が公表されれば、採用活動や取引先との信頼関係に長期的な影響が及ぶことは避けられない。
さらに深刻なのは、従業員本人への健康被害だ。長時間労働の蓄積は、脳・心臓疾患や精神疾患の発症リスクを高める。万が一、過労による健康被害や労災が発生した場合、企業には安全配慮義務違反を問われる可能性があり、民事訴訟に発展すれば損害賠償責任を負うことにもなりかねない。制度の見落としが、一人の人生に取り返しのつかない影響を与えてしまうかもしれないという重みを、管理する側は忘れてはならない。
仕組み化する方法
勤怠データとの自動連携によるリアルタイム上限アラート
打刻データや勤怠システムのAPIと連携し、時間外労働の積み上げを日次・週次で自動集計する仕組みを構築すれば、月末を待たずに現在地を把握できる。特別条項の年間上限、単月上限、複数月平均といった複数の基準を同時に監視し、一定の閾値に達した時点で自動的にアラートを発する仕組みがあれば、「気づいたときには手遅れ」という事態を根本から防げる。
部署・個人単位での残業時間ダッシュボード化
集計結果を部署ごと、個人ごとにダッシュボードとして可視化することで、経営層や人事は一目で全社の状況を俯瞰できる。どの部署に負荷が偏っているか、誰が上限に近づいているかが見えれば、業務の再配分や応援体制の検討といった対策を、感覚ではなくデータに基づいて判断できるようになる。
上限接近時のエスカレーションフローの自動化
上限の一定割合に到達した時点で、本人・上長・人事へ自動通知が飛ぶ仕組みを整えておけば、対応が個人の記憶や善意に依存しなくなる。誰が、いつ、どの段階で、どう動くべきかをあらかじめフローとして定義しておくことで、繁忙期であっても対応が後手に回るリスクを大きく減らせる。
導入時の注意点
仕組みを構築する前に、まず自社の36協定の内容を正確に把握しておく必要がある。特別条項の有無、事業所ごとの上限時間、適用される回数の上限など、協定書に記載された条件を一つひとつ棚卸しし、担当者の異動があっても引き継げる形で明文化しておくことが出発点になる。また、既存の勤怠システムとの連携可否も事前に確認すべき点だ。APIが公開されているか、データ形式は何か、リアルタイム連携が可能かによって、実現できる仕組みの範囲が変わってくる。あわせて、アラートを受け取った後の運用ルールも整備しておきたい。誰が一次対応し、どの段階で誰に判断を仰ぐのか。仕組みだけを作っても、動かす人と手順が定まっていなければ機能しない。
現実的な進め方
すべてを一度に自動化しようとする必要はない。まずは自社の協定内容を棚卸しし、部署・個人単位の上限をリスト化するところから始める。次に、既存の勤怠データを月次ではなく週次で確認する運用に切り替え、事後確認から予防的な確認へと発想を転換する。そのうえで、負荷の高い部署や上限に近づきやすい従業員から優先的にアラートの仕組みを導入し、効果を確かめながら対象を広げていく。小さく始めて、確実に運用に定着させながら育てていくことが、結果として最も早く全社の仕組み化にたどり着く道になる。
壁を越えて働く人たちへ
締め切りに追われながらも、最後まで踏ん張る人がいる。人手が足りない現場で、それでも仲間のために一歩多く働こうとする人がいる。その頑張りは尊い。だからこそ、その頑張りを守る仕組みが要る。上限に気づかず走り続けさせてしまうことは、頑張りに報いることにはならない。壁を越えようとする人たちの隣に立ち、その一歩先を見ておくこと。それが、支える側の役割だ。オルアナは、壁を越えて働く人たちが、無理をして倒れることなく、次の壁にも挑み続けられるように、その足元を照らす仕組みをともに作っていきたいと考えている。