概要
労働基準法 第107条にある「労働者名簿」と、勤怠管理システムにログインするためのユーザー情報をまとめて作成する機能です。
この画面に入力するデータは個人情報にあたるため、労働者本人の同意を得てから収集する必要があります。
勤怠管理システムとしては同意を得る過程をサポートするような機能はありません。
データを保存するサーバーが国外にある場合、労働者に通知すべき事項が増えるかもしれません。
個人情報保護法は3年ごとに見直しが行われるため、最新の情報を確認するようにしてください。
法律関係の仕様
データ構造
労働基準法 第107条で「各事業場ごとに」と書かれていますが、データ構造の都合により、ユーザーデータはシステム内で一意になるように保持しています。
勤怠管理システムは事業場ごとに導入するのではなく、会社全体で導入して、会社のプロパティとして事業場を持つイメージです。
public class 会社
{
public List<事業場> 事業場リスト { get; set; }
}入力項目
入力すべき項目は法律で決まっています。
労働基準法 第107条
労働基準法施行規則 第53条
データの型・桁について指定した仕様は見つかりませんでした。
仮に制限があるとすれば、e-Gov電子申請あたりかと思いますが、労働者名簿はXMLやJSONといった形式ではなく、画像・PDF・Excel等での添付になるようです。
https://jsite.mhlw.go.jp/kagoshima-roudoukyoku/content/contents/2018-0516-5_4.pdf
労働者名簿の様式は「様式第十九号(第五十三条関係)」として存在しているので、そこから文字数を推測できます。当システムの場合は、氏名などは基本的にnvarchar(100)、枠が大きいものはnvarchar(1000)として定義しました。
データの保存期間
プログラマー的には
「(データの最終更新日時、または、退職日どちらか大きい方の値) + 5年 >= 現在日時」がtrueの間は保存が必要という程度に考えておくと安全です。
退職日から月報の締日までのタイムラグを考えた場合、上記の日付+1か月の間保存しておけば、さらに安全だと思います。
労働者名簿の保存期間
・労働基準法 第109条 労働者名簿は5年間保存
・労働基準法 第143条 109条で「5年」ってなってるけど、当分の間、3年間で良い
労働者名簿としての保存期間以外にも注意が必要です。
例えば月報で労働者名を表示する際に、労働者マスタとJOINするような設計になっている場合、労働者データも月報と同じ期間だけ保存が必要です。
月報データや打刻データと関連しそうな法律として・・
・労働基準法 第115条 賃金の請求権は5年間、災害補償その他の請求権は2年間
・労働基準法 第143条 ③ 115条に「5年間」って書いてある部分について、当分の間、退職手当の請求権は5年間、賃金の請求権は3年間
退職手当の算出基準が勤続年数である場合、入社日と退職日のデータが必要になります。
DB設計次第では、実質的に労働者名簿を5年間保存するのと同じことになりそうです。
上記の法律にある「X年間」の起算日については、労働基準法施行規則 第56条 に記載されています。
「退職日」は会社に所属している最後の日です。退職日当日に出勤して仕事をすることは可能ですし、有給休暇で休むことも可能です。
退職日の翌日の0:00から契約が切れた状態になります。
民法 第141条 ←期間の満了についての仕様が書かれています。
当システムでは退職日に時刻要素を持っていないため、退職日の翌日の0:00になった瞬間に契約が切れます。
退職日当日に徹夜して、翌日の始業時刻まで働くという可能性は有り得ないものとして無視しています。
もしも、所定労働時間が23:00～翌日8:00という勤務形態がある場合、退職日に時刻要素まで持たせなければうまく機能しないかもしれません。
保存とは逆のパターン
労働者名簿の内容は個人情報にあたるため、不要になった時点で削除する必要があるはずです。
・個人情報の保護に関する法律 第19条 “遅滞なく消去”
極端な解釈をした場合、保存期間が過ぎたデータは日次バッチで自動削除するという事になります。
当システムでは自動削除機能はありません。そもそも、ユーザーデータの削除について十分に考えておらず、実質永久に削除できない状態になってしまいました。
自動削除機能を搭載せずに運用する場合、年間カレンダーの作成など、年次業務の一部として退職者データを手動で削除するというルールを定めれば良いと思います。
データの出力機能
当システムでは労働者名簿の出力機能を搭載していません。
出力機能の重要性を知らなかったのが原因です。
平成17年3月31日 基発第0331014号
https://www.jaish.gr.jp/anzen/hor/hombun/hor1-46/hor1-46-48-1-0.htm
電磁的な記録として保存してもOK的な事が書かれていますが、下記の制限があります。
※AND条件です。
・”直ちに必要事項が明らかにされ”
・”写しを提出し得るシステムとなっていること”
出力する際の基本的なレイアウトは「様式第十九号(第五十三条関係)」です。
e-GovのサイトからPDFをダウンロードできます。
https://elaws.e-gov.go.jp/document?lawid=322M40000100023
縦書きの実装が面倒だとか、住所の表示可能桁数が明らかに不足している等の問題で苦労するはずなので、最初から独自レイアウトにするのもアリかもしれません。
労働基準法施行規則 第59条の2 でレイアウトを変えても良い旨が記載されています。
管理監督者フラグ
協定届帳票を作る過程で苦し紛れに追加した項目です。
用語の使い方が間違っているかもしれません。
当システム内では「社長」や「役員」を示すために使います。
このフラグをONにすると、協定届の「常時使用する労働者数」にカウントされなくなります。
労働基準法 第41条 にある「残業代が払われない人」は、このフラグとは関係ありません。
残業代が払われる/払われないの区別は、ユーザーに紐付ける契約データによって制御する想定です。
仕様
ユーザーデータの登録
ユーザーの新規追加を行うと、そのユーザーに紐付く有休付与実績データも同時に登録します。
日次バッチで有休付与実績データをチェックしており、入社日から6か月経過した時点で自動的に有給休暇を付与します。
既存データの入社日の値を変更した場合、有給休暇が実際に付与される前であれば、付与タイミングも入社日に連動して変化します。既に有給休暇が付与されている場合は、付与タイミングは変化しません。
入社日を下手に操作した結果、有給休暇の付与が行われなくなる現象を避けるための仕様です。
システムの運用開始時に既存の社員のデータを入力した場合、入社日は過去の日付になります。
その日の日次バッチで有休付与対象として扱われるため、変更猶予は「当日中」となります。
既存の社員が前年から繰り越した有休の権利を持っている場合、日次バッチでの付与とは別に有休の権利データを手動で投入することができます。
運用開始時点で既に消費している有休を差し引いて付与するという機能はありません。(忘れていました。)
勤怠管理システムを導入する際は、初期データ投入の方法や準備期間、実運用開始タイミングについても考えておくと良いです。
メジャーな勤怠管理システムであれば、初期データ投入を代行してくれる人が見つかるかもしれません。
ログイン情報の通知
新たに追加したユーザーに対して、どうやってパスワードを通知するかという問題がありました。
当システムの場合は、システム管理者が「パスワードのリセット」ボタンをクリックする方式にしました。
ランダムに生成した文字列を初期パスワードとして設定して、ユーザー本人のメールアドレス宛に送る仕組みになっています。
ユーザーがパスワードを忘れた場合、全く同じ手順でパスワードの再発行を行います。
後から気が付きましたが、この仕様には致命的な欠点があります。
唯一のシステム管理者本人がパスワードを忘れてしまった場合、何もできなくなります。
ログイン画面に「パスワードを忘れた場合」というリンクを設けて、そこからパスワードをリセットする仕組みにするべきでした。
退職処理
内部的には退職日に値を書き込むだけです。
労働基準法施行規則 第53条 にある通り、退職事由を書き込む欄も存在します。
システム内のあらゆるSQLで、退職日をもとにユーザーデータを取得するか否か制御しています。
退職後はユーザーデータが抽出されなくなり、打刻やログインができなくなります。
唯一の管理者ユーザーを対象に退職処理を行おうとした場合は入力エラーになります。他のユーザーに管理者権限を付けてから退職処理を行う必要があります。
退職日には過去日の入力も可能ですが、退職日よりも未来の日付の月報が存在する場合は入力エラーになります。
削除機能
登録直後、月報データを作る前のユーザーデータであれば削除できます。
退職日に値が入っている場合、前述の保存期間が切れる前のデータは削除できません。
退職処理と同じで、唯一の管理者ユーザーは削除できません。
法的な保存期間を過ぎた後のデータの削除処理については考えていませんでした。
削除処理の際、ユーザーデータだけを削除すると月報や打刻データとの紐付けが切れて、データが破損してしまいます。
本格的な削除処理を搭載する場合は、ユーザーデータに紐付く全てのデータを対象に法的な保存期間をチェックして、一括削除する仕組みになると思います。
反省点
「社員番号」は何となく不要な気がして項目を作りませんでした。
実際に使ってみた感想として、ユーザーを検索するとき、同姓同名のユーザーがいると詰みます。
社員番号は持たせた方が良いと感じました。
退職事由(特に死亡事由)は裁判で扱うレベルの情報になるため、自由に変更できるのはまずいかもしれません。新規追加や変更の度に履歴データを残すような設計にした方が良かったと考えています。
ユーザーの認証には「ASP.NET Identity」を使っていますが、労働者名簿とシステムのユーザーを単一のテーブルに持たせる設計にした影響で、大部分を独自実装することになりました。
労働者名簿とシステムで使うユーザーは分離できるような設計にした方が良かったです。