kintoneの勤怠管理、打刻漏れの当日検知をn8nで自動化する方法を紹介

打刻漏れの当日検知は大がかりな開発だと思い込んでいないか

kintoneで勤怠管理をしていても、月末の勤怠締めになると、打刻漏れがまとめて表に出てきます。出勤しているのに退勤の打刻がない人、そもそも出勤の打刻が抜けている人が、一覧にずらりと並ぶ状態です。

労務担当は、これを一件ずつ本人へ確認し、あとから修正を入れていきます。この後追い作業に毎月追われている職場もあるのではないでしょうか。

打刻を促すリマインダーは、すでに入れているかもしれません。それでも押し忘れそのものは起こり続け、結局は締めのときに気づくことになります。「打刻漏れをその日のうちに見つけたい」というよくある願いが、なぜかいつも締めまで持ち越されてしまうのです。

こうした話をすると、「打刻漏れを当日に検知する仕組みなんて、専門業者に発注する大がかりな開発案件でしょう」という反応が返ってくることもあります。kintoneで勤怠を運用しているのに、そこから一歩進めるにはSIerの見積もりが要る、と身構えてしまうわけです。

ですが、つまずく場所は見た目ほど多くありません。実際に手を動かしてみると、越えなければならない壁は限られた一点に集約されていくのが分かるはずです。その一点が何かを、次の章で先にお見せしましょう。

未打刻はその日のうちに検知でき、本人がTeamsから当日中に直せる

先に到達点をお伝えします。打刻漏れは締めを待たずにその日のうちに検知でき、対象になった本人へTeamsで通知して、当日中に本人が自分で修正するところまで導けます。

労務担当が締めのあとに一件ずつ追いかける作業を、当日の本人対応に置き換えられるということです。ただし、現場の担当者が作業中に常にスマホを見られるとは限らないため、通知のタイミングには工夫が要ります。この点は記事の後半であらためて触れます。

仕組みそのものは、大がかりではありません。kintoneと、n8nのような月数千円程度から使える自動化ツールを組み合わせれば、つまずく場所さえ押さえておけば数時間から半日程度で組める規模感です。所要時間は実装経験の有無によって変わるため、あくまで目安として捉えてください。

では、越えるべき壁はどこにあるのでしょうか。それは一点だけです。kintoneの標準通知は、「打刻レコードが無いこと（＝未打刻）」を検知できません。

この“レコードが存在しないこと”という異常だけは、標準の通知条件では捕まえられないのです。逆に言えば、ここさえ埋めれば残りの部分は特別な開発を必要としません。ただし、実装そのものが可能かという話と、社内でその作業時間を確保できるかという話は別なので、そこは章の最後で切り分けます。

締めの後追い修正が労務担当に集中し、現場も直しにくい構造

なぜ、打刻漏れの修正が毎月ふくらみ、しかも労務担当に集中してしまうのでしょうか。原因は、未打刻の検知が締めのタイミングまで遅れることにあります。締めで初めて欠けが分かるため、確認と修正の負担が、まとめて労務担当の数名に集中するのです。

現場の担当者は、日中ずっとパソコンの前にいるわけではありません。締めのタイミングで「先月◯日の退勤打刻がありませんが」と急に聞かれても、当人はすぐには状況を思い出しにくいものです。検知が遅れるほど、確認のやり取り自体が重くなっていきます。

私たちは、この後追いを人力で回し続けるのではなく、異常に早く気づいて現場の担当者自身の手で直せる状態をつくるべきだと考えます。打刻漏れの防止と対策は、その都度の声かけではなく、仕組みとして回すほうが長続きするものです。

仕組みを誰が作るのかにも触れておきます。日常的にkintoneのアプリ作成や設定を触っている担当者であれば、手を動かせる範囲に収まります。n8nという自動化ツールを初めて使う場合は、n8nとは何かを解説した入門記事から入ると全体像がつかみやすいはずです。

ただし、社内にその作業時間を確保できるかどうかは別問題です。手が足りない場合の相談先は、記事の最後にご案内します。

つまずきの核心は、標準通知が“無い打刻”に反応できないこと

kintone勤怠管理の標準通知が登録済みレコードには反応するが未打刻には反応できない対比図

ここからが本題です。大がかりに見えるこの仕組みで実際につまずく核心は、標準通知が“無い打刻”に反応できないという一点にあります。ここからは、その一点を3つに分けて順に見ていく流れです。

はじめに用語を1つ定めます。この記事で言う“無い打刻”とは、打刻レコードそのものが作られていない状態（＝未打刻）のことです。「打刻はしたが値が間違っている」状態ではなく、レコードが1件も無い状態を指します。

標準の条件通知・リマインダーは、打刻した人には届いても“無い打刻”は素通りする

最初のつまずきは、kintone標準の通知の仕組みそのものにあります。条件通知やリマインダー通知は、アプリに登録済みのレコードのフィールド値や日付を条件に送られるものです。

kintone公式ヘルプでも、リマインダー通知は指定した条件を満たしたレコードに対して送信されると説明されています（kintoneヘルプ：リマインダーの条件通知）。

つまり、レコードが存在することが前提の仕組みであり、レコード自体が無い状態は条件判定の対象にならないと考えられるのです。

打刻したレコードには通知を出せても、そもそも打刻レコードが作られていない“無い打刻”には反応できません。押し忘れは「レコードが作られない」という形で起きるため、通知条件に一度も引っかからないまま締めまで残ってしまいます。

リマインダーで打刻を促していても押し忘れが減らないのは、この構造が理由です。

「誰が今日出勤予定か」が分からないと、“無い打刻”をそもそも定義できない

2つ目のつまずきは、“無い打刻”を定義するための基準がkintone単体では足りない点です。未打刻とは「出勤予定なのに打刻が無い」状態を指しますが、この判定には「今日は誰が出勤予定か」という比較対象が要ります。

打刻レコードだけを眺めても、そこに現れるのは打刻した人だけです。打刻していない人はデータとして存在しないため、打刻レコードをいくら見比べても「本来いるはずなのに欠けている人」は浮かび上がってきません。当日の出勤予定という比較対象を別に用意して、初めて未打刻を定義できるようになります。

有給・代休・シフト休みまで“打刻漏れ”と誤検知してしまう

3つ目のつまずきは、誤検知です。単純に「打刻が無い人」をすべて拾ってしまうと、元から出勤しない人まで“打刻漏れ”として通知してしまいます。該当するのは、たとえば次のようなケースです。

  • 有給
  • 代休
  • シフト上の休み

複数シフトの現場では、この誤検知が起きると通知そのものが信用されなくなります。外回りで直行直帰する人がいる職場なら、その分の考慮も欠かせません。「出勤予定なのに打刻が無い」を正しく判定するには、そもそも打刻が発生しない事情をあらかじめ除いておく必要があるわけです。

従業員マスタとの突合で、“無い打刻”を当日に見つける組み方

kintone勤怠管理で従業員マスタと打刻を突合し未打刻をTeams通知するn8n処理フロー図

3つのつまずきが分かれば、対策は素直に決まります。ここからは、つまずきに1つずつ対応する形で、実行する順に設計を並べていきます。中心になる考え方は、「今日出勤するはずの人の一覧」と「今日の打刻レコード」を突き合わせ、前者にいて後者にいない人を拾うことです。

ここからは、実際にn8nで組んだワークフローの画面とあわせて、「組む順」に見ていきます。まずは全体像です。締め時刻の定時実行をきっかけに、kintoneの3つのアプリ（従業員マスタ・勤怠区分マスタ・勤怠打刻）を取得して突き合わせ、未打刻の人だけを本人へ通知するところまでが、一続きにつながっています。

従業員マスタに「当日の出勤予定」を持たせ、突合の母集団を確定する

まず、kintoneの従業員マスタに「当日の出勤予定」を持たせます。これが突合で照らし合わせる相手、つまり「今日出勤するはずの人の一覧」です。

下の画面が、その母集団になる従業員マスタです。在籍している人と、それぞれの所定勤務曜日を持たせてあり、n8nはここから「今日出勤するはずの人」を割り出します。

そのうえで、n8nから当日の出勤予定と当日の打刻レコードの両方を取得して突き合わせると、出勤予定にいるのに打刻レコードが無い人が、そのまま未打刻の候補として抽出されます。これが2つ目のつまずき（比較対象がないと未打刻を定義できない）への直接の答えです。

突き合わせる相手は、当日の打刻レコードです。実際の運用では、打刻アプリに並ぶのは実際に打刻した人だけで、出勤予定者より数が少なくなります。この「予定にはいるのに打刻に現れない人」が、未打刻の候補です。

勤怠区分マスタで除外条件を先に設計し、誤検知を防ぐ

次に、突合をかける前に除外条件を設計します。有給・代休・シフト休み、必要なら直行直帰といった「打刻が発生しない事情」を勤怠区分マスタとして持たせ、突合の対象から先に外しておきます。

下の画面が、その勤怠区分マスタです。当日に有給や直行直帰などで打刻が発生しない人をここに登録しておき、突合の手前で母集団から外します。

除外を突合の手前に置くのがポイントです。抽出したあとに例外を除くのではなく、対象を絞る段階で休みの人を外しておけば、通知は「本当に打刻が要るのに抜けている人」だけに絞られます。これが3つ目のつまずき（誤検知）への対策です。

実際に突合を動かすと、出勤予定から休み・直行直帰を除いたうえで、打刻が無い人だけが残ります。下の画面がその抽出結果です。有給や所定休の人は通知に出ておらず、「本当に打刻が要るのに抜けている人」だけが、出勤打刻なし・退勤打刻なしといった種別つきで拾われていることが分かります。

締め時刻にn8nを定時実行し、対象者本人だけに個別にTeams通知する

抽出のロジックが固まったら、n8nを当日の所定時刻に定時実行します。標準通知が反応できない“無い打刻”を、締めを待たずにこちらから能動的に洗い出す仕組みです。これが1つ目のつまずき（標準通知は“無い打刻”に反応できない）への答えになります。

下の画面が、その実行タイミングの設定です。平日の締め時刻に1回だけ動くようにしてあり、この定時実行が「こちらから未打刻を取りに行く」きっかけになります。通知を出す時刻は、休憩の前後など本人が確認しやすい時間に合わせて調整します。

通知は、対象になった本人だけに個別に送ります。全員一律のリマインダーではなく、また他の人の目に触れる形でもなく、当人にだけ「今日の打刻が確認できていません」と届ける形です。誰が押し忘れたかを人目にさらさないための配慮でもあるのです。

通知にセルフ修正の導線を載せ、当日中に直しやすくする

最後に、通知の中に修正への導線を載せます。該当するレコードや打刻修正の申請フォームへのリンクを通知に含め、本人がその通知からたどって、当日中に自分で直せるようにするのです。

Teams通知は対象者本人だけに個別に届き、「打刻を修正する」ボタンから、その通知をたどって当日中に自分で直せるようになります。

ただし、現場の担当者は作業中に常時スマホを見られるとは限りません。通知を出す時刻は、休憩の前後など本人が確認しやすいタイミングに寄せるなど、現場の動き方に応じて調整してください。

労務担当が締めのあとに一件ずつ追いかけていた後追いを、本人が気づいたときに自分で直せる入口へ置き換える、という位置づけです。

締めの後追いが消え、打刻漏れは当日のうちに片づく

打刻漏れが締めでまとめて発覚する状態から当日に本人が直す状態への変化を示すBefore/After図

ここまでの設計を通すと、勤怠の運用はどう変わるのでしょうか。締めのときにまとめて表に出ていた打刻漏れが、当日のうちに、しかも本人の手で片づく運用に変わります。

労務担当が月末に抱えていた確認と修正のかたまりが、日々の小さな本人対応へとほどけていきます。毎月の締めでまとめて追いかけていた作業を、その日その日の短いやり取りに置き換えられるわけです。

大がかりに見えていた当日検知も、越えるべき壁は結局「“無い打刻”をどう捕まえるか」という一点でした。標準通知が反応できないその一点を、従業員マスタとの突合で埋めるだけです。そこさえ押さえれば、いま使っているkintoneと手頃なツールで、自社の手でも組める範囲に収まります。

ただし、現場の受け止め方まで単純に考えないほうがよいでしょう。作業中の担当者が常にスマホを操作できるとは限らず、締め切り間際の通知では当日中の修正時間が短くなることもあります。

通知のタイミングや文面は、自社のシフトや現場の動き方にあわせて調整する前提で設計してください。技術的に組めるかどうかと、社内でその作業時間を確保できるかどうかも、分けて考える必要があります。

なお、打刻そのものをkintoneで手軽に行う仕組みが必要な場合は、勤怠登録プラグインのような打刻の入口を整える手段もあわせて検討するとよいでしょう。

まとめ

打刻漏れの当日検知でつまずく核心は、kintoneの標準通知が「打刻レコードが無いこと（＝未打刻）」に反応できない一点にあります。この壁を、次の流れで埋めれば、締めの後追いをなくせます。

  • 従業員マスタに「当日の出勤予定」を持たせ、突合で照らし合わせる相手を確定する
  • 勤怠区分マスタで休みや直行直帰を先に除外し、誤検知を防ぐ
  • 締め時刻にn8nを定時実行し、標準通知に頼らず“無い打刻”を洗い出して本人だけに個別通知する
  • 通知に修正の導線を載せ、本人が当日中に直しやすくする

大切なのは、打刻漏れの防止と対策を、その都度の督促ではなく仕組みとして回すことです。その入口になるのが、この“無い打刻”の突合です。

最後に

未打刻をどこで区切るか、どの勤怠区分を除外するか、通知を何時に出すかは、自社のシフトや現場の働き方によって変わります。

自社の運用にどう当てはめればよいか判断がつかない場合や、作る時間を社内で確保しづらい場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。自社の環境に合わせた組み方を一緒に検討します。

関連記事