勤怠管理システムの自作-チケット

概要

当システムでは、年次有給休暇の権利や消費量、遅刻・早退などの実績を「チケット」という単位で管理します。
有給休暇の残数を鉄道の回数券のように管理したら楽かもしれない と思いついたのが始まりです。

私が所属する会社では「届出書」という物で有給取得数や遅刻早退の実績を管理していましたが、勤怠管理システムとしては「届出」の有無よりも権利の消費管理の方が重要だと考えました。「届出書」という名前にしておくと無用な指摘を受ける可能性があり、「チケット」という名前でごまかすようにしました。

仕組み

有給休暇のチケット1枚が有給休暇1日分に相当します。
有給取得のチケット1枚には480pt(分単位の所定労働時間)のポイントが付与されており
丸一日休暇を取得した場合、ポイントを全て消費します。
半休を取得した場合、ポイントが半減します。
時間休を取得した場合、約60pt消費します。

私用外出(中抜け)した場合は私用外出のチケットを作ります。
10分外出した場合は10ポイントに相当します。
月報作成時に私用外出チケットのデータを読み込み、労働時間から差し引きます。

遅刻した場合は遅刻のチケットを作ります。
人間の管理職に対して遅刻の理由を説明するための物です。
勤怠管理システムとしては打刻時刻を見れば遅刻したことが分かるため、無視しています。

データ構造

チケットデータは親子構造を持ちます。
「休日出勤した → 代休の権利が発生した → 代休の権利を消費した」
という感じで赤黒伝票のような管理をします。

チケットの親子関係を管理するために「閉包テーブル」という仕組みを使うことにしました。

具体例

実際にはチケットデータとチケットの親子関係データは別々のテーブルで管理しています
特に重要な項目だけ抜き出して記載しています。

権利フラグがtrueのデータを「権利チケット」と呼んでいます。
有給休暇の権利チケットは、有給休暇付与処理(バッチ)で作成しています。
権利チケットを起点として子孫全てのポイントを合計すると、権利チケットの残りポイントが取得できます。

有給休暇を利用するとき、親となる権利チケットを紐付ける処理を「引き当て処理」と呼んでいます。
引き当てるチケットは以下のようにして取得します。

Where
  チケットタイプが一致する
  && 残りポイントが足りている
  && 有効期限内である
OrderBy
  有効期限Toの昇順
  残りポイントの昇順

有給休暇

終日休暇にするパターン

半休・時間休を取るパターン

ID	親	タイプ	ポイント	権利フラグ	取消フラグ	説明
20	null	有休	480	true	false	有給休暇の権利チケット。
21	20	半休	240	false	false	半休1回目。 半休を使った場合、実際に休んだ時間とは関係なくチケットポイントが半減する。
22	20	時間休	60	false	false	時間単位の有給休暇を取得したことを示すデータ。

時短勤務の社員が有給休暇を利用するパターン

ID	親	タイプ	ポイント	権利フラグ	取消フラグ	説明
30	null	有休	480	true	false	有給休暇の権利チケット。
31	30	有休	-420	false	false	この社員の所定労働時間は420分(7時間)。計算処理がしやすいように、所定労働時間と同じポイントを消費する。
32	31	調整	-60	false	false	有休の権利としては480ptあり、有休として利用したのは420pt。残りポイントが0になるように調整チケットを作成する。このチケットはユーザーからは見えない。親チケットと連動して削除されるため、調整データだけが残る心配はない。

有給休暇のチケット1枚は常に1日分の休暇になります。
時短勤務中に付与した1日分の有給休暇は、通常勤務に戻った後も1日分として使える必要があります。

代休

代休が発生した場合、休暇として使用するか・労働時間として計上するか選べる場合があります。
チケットデータに親子関係を持たせているため、割と単純な方法で対応できます。

休日出勤と代休の発生、代休の利用

ID	親	タイプ	ポイント	権利フラグ	取消フラグ	説明
100	null	休日出勤	-480	false	false	休日出勤の届出書に相当する。
101	100	代休振替	480	false	false	休日出勤の労働時間を代休に振り替えたことを示すチケット。
102	101	代休	480	true	false	代休の権利があることを示すチケット。
103	102	代休	-480	false	false	代休の権利を使って休暇を取ったことを示すチケット。

休日出勤を取り消す場合の処理

例：休日に誤ってスマホ打刻をしてしまい、休日出勤扱いされた。
月報を修正して出勤・退勤しなかった事にします。
休日出勤の事実が無くなるため、休日出勤チケットが消滅します。
同時に休日出勤チケットの全ての子孫が消滅します。代休の権利も消滅します。

代休への振り替えを拒否する場合の処理

ユーザー自身が代休振替チケットを取り消します。
(代休への振り替えを行わず、給与として支払って欲しいという意思表示になります。)
代休振替が拒否されたという実績を残すために、代休振替チケットは取消フラグがtrueの状態で残り続けます。
代休振替チケットが取り消されたことで、子孫である代休の権利も自動的に取り消しになります。

承認機能について

チケットの承認機能は存在しません。
「面倒だった」というのが最大の理由です。
実際の運用では、事前に「根回し」が行われるはずです。チケットの承認機能が存在しないことは大きな問題ではないと考えて優先度を下げました。

なお、月報の締め処理を行うと月報に紐付くチケットも締め処理済みとなるため、データの整合性は保たれます。

時季変更権との兼ね合い

上長による承認機能を設ける場合、この問題に遭遇するはずです。
有給休暇の時季変更権については、労働基準法 第39条 ⑤ に書かれています。

利用日を変えさせるという意味での却下は可能ですが、取り下げさせるという意味での却下は不可能です。
「事業の正常な運営を妨げる」かどうかをシステム側で判断するのは現実的ではありません。
厄介な問題に巻き込まれないように、注意して仕様を決める必要があります。

労働基準法で定められた基準より多くの有給休暇を付与した場合、基準を超えた部分には時季変更権などの制限が適用されなくなるはずです。
当システムでは労働基準法に書かれた日数以上の有給休暇は付与できないようにしました。基準を超える休暇は「季節休暇」として明確に分離することで面倒事を回避しています。

反省点

既存の業務に対して「チケット」という新しい名前を付けたのは、正しい判断だったのか微妙なところです。

渋々勤怠情報の入力に協力しているユーザーから見ると、新たに「チケット」という概念について理解する必要が出てきたと感じるかもしれません。
ユーザーが出来るだけ既存の知識を流用できるように、「届出書」という名前を残しておくべきだったかもしれません。