Kintai

勤怠の出発点は、人と契約と配属にある

同じ時刻に出勤していても、予定されているシフトや契約、勤務先が異なれば、確認すべき内容も変わります。そのため勤怠管理では、時刻の記録より前に、誰がどの条件でどこに勤務するのかを整理する必要があります。

Kintaiは、従業員台帳、雇用契約、配属先と異動履歴、シフトを扱います。本人の操作、店舗責任者の確認、本部・人事の管理という役割を分け、従業員情報と日々の勤務記録をつなぎます。

単独の打刻画面ではなく、人の情報と働く時間を合わせて扱う勤怠・HRの基盤として設計しています。人事情報とログイン用のアカウントも、同じものとして扱うのではなく、関連づけて管理する構成です。

一日を一行にまとめると、見えなくなること

たとえば、昼と夜に分かれて勤務する日を考えます。最初の出勤から最後の退勤までを一つの区間として扱うだけでは、どの時間帯に働き、どこで休み、どのシフトに確認が必要なのかがわかりません。

Kintaiは、一日の勤怠に対してシフトごとの区間を持つ構成を採用しています。勤務実績、警告、承認状況などを区間ごとに扱いながら、日単位の集計へつなげます。日をまたぐ勤務や、予定されたシフトの外での勤務も、集計と確認の対象になります。

このように管理の単位を分けることで、日合計だけを見て判断するのではなく、どの勤務部分に対応が必要かを確認するための情報を用意できます。なお、ここで示した勤務例は設計を説明するためのもので、実際の従業員データではありません。

打刻漏れや修正を、承認のある手順にする

現場では、打刻を忘れたり、記録に訂正が必要になったりすることがあります。それを管理者が数字だけ書き換えて済ませると、本人から何が申請され、どの状態で受け付けられたのかがわかりにくくなります。

Kintaiには、従業員本人による修正申請と、その確認・承認の流れがあります。申請では対象の勤務記録と理由を扱い、本人の記録かどうかも確認します。申請しただけで勤務実績が直ちに変更されるのではなく、承認後の処理につなぐ構成です。

締め済みの期間や重複した申請には、通常の未処理データとは異なる制約があります。「入力できるか」だけでなく、「いまの状態で、その操作を認めてよいか」を扱うことが、日々の勤怠と月次業務をつなぐうえで重要になります。

店舗の確認と、本部の締めをつなぐ

月次締めは、画面から対象月を選んで集計するだけの処理ではありません。店舗で内容を確認し、本部へ提出し、必要に応じて差し戻す流れがあります。確定した後に訂正が必要になった場合には、再開の手順も必要です。

Kintaiは、店舗側での従業員別の締めから、本部への提出・承認を扱います。設定によって店舗で確定する運用もあり、すべての組織に一つの承認手順を固定する構成ではありません。確定後の再開申請と承認も、別の状態として扱います。

実装では、処理前に対象の状態を確認し、同じ記録に対する操作が重なる場面も考慮します。こうした状態の管理は、利用者から見えるボタンの数よりも地味ですが、確定した勤務データを次の業務へ渡すための土台になります。

店舗端末と、通信が不安定なときの扱い

打刻の入口には、従業員のWeb画面と店舗タブレットがあります。店舗端末は端末として登録・接続し、出退勤、休憩、外出などの記録を扱います。個人が使う画面と、複数の従業員が利用する共用端末では、運用の前提が異なります。

店舗タブレットには、通信できない間の打刻を端末側に保持し、接続回復後に同期する仕組みがあります。ただし、通信断中に記録できたことだけで、すべての時刻が無条件に確定するわけではありません。オフラインで取得された記録を区別し、時刻の検証や人による確認が必要な場合を扱います。

これは「いつでも完全に止まらない」という保証ではなく、通信状況が変わる現場で、記録とその確認をどう継続するかという設計です。利用端末や設定を含めて、導入時の運用を確認します。

給与処理に渡すデータと、製品の責任範囲

勤務時間は、所定時間、残業、深夜、休日などの区分を含めて整理されます。さらに、シフト変更、残業申請、欠勤、有給の付与・利用・残数といった周辺業務も、勤務記録の確認に関わります。

Kintaiには月次の出力や勤務データを読み取るAPIがあり、給与処理などの後続業務へデータを渡す接点を備えています。一方で、給与の算定から振込や税務申告までを、すべて同じ製品で完結すると説明しているわけではありません。

開発にあたっては、データを集めるところ、確認して確定するところ、次のシステムへ渡すところを分けて考えます。どこまでをKintaiが担い、どこからを既存の仕組みや担当者が担うのか。その境界を明確にすることも、業務システムの設計の一部です。