打刻漏れの督促を自動通知にする。標準機能で足りる範囲とSlack督促botの作り方

打刻漏れの督促が、労務の締め作業を長くしている

打刻漏れ自体は毎日起きます。直行直帰、退勤時の打ち忘れ、端末の不調。問題は、それが締め日までたまることです。締め日にまとめて洗い出すと、本人はもう何日の話か覚えておらず、確認と修正に往復が発生します。

督促する側の負担も軽くありません。同じ人に何度も声をかける気まずさ、送ったメールが読まれない徒労感。そして打刻が揃わないかぎり集計が確定せず、給与計算の開始が遅れます。督促は、締めを止めている作業の最上流にあります。

従業員80名の会社で毎月起きること

数字は仮に置いた値です。従業員80名で、打刻漏れが1日平均4件。月20営業日なら 4件 × 20日 = 月80件です。締め日にまとめて洗い出す運用だと、1件につき日付の特定・本人への声かけ・修正申請の確認で5分として 80件 × 5分 = 400分。締めの数日に6時間半あまりが督促に消えます。本人と上長の側にも、何日の話か思い出す時間と承認の往復が別に発生します。

翌日に本人へ自動通知が届く設計に変えると、前日のことなので本人がその場で修正申請を出し、1往復で終わります。通知を放置する人が1割いるとして月8件。数日直らなければ上長へ、締めの2営業日前には労務へ残りの一覧が届く段階を作れば、労務が見るのは一覧の8件だけです。1件5分でも 8件 × 5分 = 40分で済みます。

時間より大きいのは仕事の変わり方です。「全員に声をかける」が「一覧の数人だけ見る」になり、締めを止めていた最上流の詰まりが消えます。御社の数字で置き直すのは、1日あたりの漏れ件数と、督促1件にかかっている時間の2つです。

勤怠SaaSの標準機能で足りる範囲

まず確認したいのは、いま使っている勤怠SaaSの通知機能です。主要な勤怠SaaSの多くには、翌日に出退勤の登録がない従業員へ自動でメールやアプリの通知を送る設定があります。機能の有無や細かさは製品と契約プランで異なるため、管理画面の通知設定を確かめるところから始めてください。

この種の通知機能のポイントは、締め日にまとめてやっていた督促を「翌日に本人へ」に前倒しできることです。前日のことなら本人が覚えているので、修正が1往復で終わります。承認する上長にとっても、記憶が新しいうちの申請は確認が速く、承認の滞留が減ります。

設定だけで済むなら費用はかかりません。標準機能を全部使うのが、常に先です。それでも督促が残る会社には共通のパターンがあります。通知がメールで、日常の連絡がSlackやLINE WORKSに移っている現場では開かれない。通知を放置されたときの次の一手がない。締め直前に労務が欲しい「誰に何件残っているか」の一覧が出ない。ここから先が、標準機能の外側です。

作る側の視点。Slack督促botの作り方

Slack botでの業務自動化と勤怠・給与計算SaaSの設計は、どちらも当方が普段やっている仕事です。この督促botはその組み合わせでできる典型的な小型案件で、仕組みは次の流れになります。

毎朝、勤怠SaaSから前日の打刻データを取得します。取得の経路は勤怠SaaSのAPIか、APIがなければ管理者がエクスポートするCSVです。どのシステムでどの粒度のデータが取れるかは契約プランでも変わるため、ここが最初の調査点になります。

取得したデータを出勤予定と突き合わせ、打刻が欠けている人を検知します。休日・休暇・直行直帰の申請がある日を除外しないと誤検知になるので、除外条件の設計が品質を決めます。

検知した本人へ、SlackのDMで通知します。文面には日付と、修正申請ページへのリンクを入れます。「打刻漏れがあります」だけの通知は、確認の手間が残るぶん無視されやすくなります。数日直らなければ上長のいるチャンネルへ、締めの2営業日前には労務担当へ残りの一覧を送ります。この段階設計が、先のシナリオの「一覧の数人だけ見る」を作ります。

作りの規模としては、Googleスプレッドシートに付属する自動化機能（GAS）や小さなスクリプトで足りる範囲で、サーバーを立てるほどのものではありません。毎朝1回動く検知の処理と、Slackへ投稿する処理だけです。

つまずきやすいのは、通知の出しすぎです。毎日全員に飛ぶ通知は数週間で風景になります。本当に漏れている人だけに、1日1回まで、と絞るほうが効きます。シフト勤務や夜勤明けの誤検知も定番で、「前日に退勤打刻がない」の判定は日をまたぐ勤務では成り立ちません。勤務パターンを持っている会社は、判定条件を勤務予定ベースにする必要があります。

まず通知設定を使い切る。作るのはそのあと

順序は2段です。第一に、いまの勤怠SaaSの通知設定を全部使う。これは費用ゼロで、今日できます。第二に、それでも残った督促（Slackで届けたい、エスカレーションしたい、一覧が欲しい）だけをbotとして作る。作り始める前に、いまの契約で打刻データが機械的に取り出せるかの確認も忘れずに。APIが契約プランで閉じていて、データ取得から作り直しになる場合があります。

費用の目安です。この規模は当方の区分で「ひとつの作業を自動化する」帯（10万円〜50万円）に収まります。勤怠データの取得経路が素直（APIあり）なら帯の下のほう、CSV経由や勤務パターンの除外条件が複雑なら上のほうと考えてください。

効果は督促の時間だけで測らないでください。打刻が日々揃うようになると、締めの開始が早まり、給与計算の日程全体が前倒しになります。毎月の気まずい声かけが消えることも、担当者にとっては金額にしにくい大きな効果です。

なお、一度データの取得経路を作れば、同じ経路で機能を足せます。月末の申請リマインド、残業時間が基準に近い人への通知。督促botは、勤怠まわりの小さな自動化の入り口になります。

作る前に確認するのは3つです。通知設定をどこまで使い切っているか。現場が毎日見ている連絡手段はどこか。いまの契約で打刻データを機械的に取り出せるか。この3つで、作る必要があるかどうかまで含めて決まります。