チケットタイプの一覧
当システム特有の概念である「チケット」の種類の一覧です。
| チケットタイプ | 説明 |
|---|---|
| 有給休暇 | 当システムでの有給休暇は、労働基準法 第39条 にある年次有給休暇だけを指します。 企業が独自で法律の要求を超える休暇を付与する場合、季節休暇として別物扱いします。 有休付与日数はDBに固定で保持しており、ユーザーが指定する必要はありません。 この仕様にしたことで、法律関連のチェック処理の際 if (チケットタイプ == 有給休暇) という実装で済むようになりました。 |
| 半休 | 昭24.7.7基収1428号 午前半休・午後半休と呼ばれる有給休暇の使い方です。 当システムでは午前・午後の区別なく半休と呼んでいます。 中抜けのために半休を使うことはできません(実装が面倒なので)。 企業によって「半日」の定義が異なるため、初期状態では以下の仕様としました。 ・半休を使った場合、実際に休んだ時間に関係なく有給休暇の権利ポイントを半分消費します。 ・入力チェックは緩くしています。 例えば午前半休を取得した場合、以下の条件がtrueなら正常と判定します。(C#) (チケット利用開始時刻 == 始業時刻 && チケット利用終了時刻 < 終業時刻) |
| 時間休 | 労働基準法 第39条 ④ 1時間単位で使える有給休暇です。 当システムでは、契約データ単位で時間休の利用可否と利用可能日数(1～5)を設定できます。 |
| 季節休暇 | 当システム独自の概念かもしれません。夏季休暇や年末年始休暇に相当します。 企業が独自に付与する休暇で、休める回数が決まっていて、休む日付は各自で指定できるという条件に当てはまる場合、少しくらい呼称が違っても全て季節休暇となります。 なお、年末年始休暇のように休日となる日付が決まっている場合は、カレンダーマスタメンテナンス画面で所定休日と指定することができます。 有給休暇は法的にいろいろな制限がありますが、季節休暇は企業独自の休暇なので自由に扱えます。 |
| 代休振替 | 労働時間を代休に振り替えたことを示すチケットです。 当システムの初期設定では、下記の場合に代休振替が自動発生します。 ・実動時間が所定労働時間の2倍に達した場合 ・休日出勤して実働時間が所定労働時間以上に達した場合 各ユーザーは、このチケットを取り消すことができます。 取り消した場合は代休が消滅して給与での支払いになります。 また、月報を作成した段階で強制的に労働時間(=給与)として計上されます。 標準ロジックでは、給与として計上された後は有給フラグがOFFの代休の権利が残ります |
| 代休 | 代休の権利や消費を示すチケットです。 初期状態では最小利用単位などの制限はありません。 有給休暇とは違い、常にポイント単位で残数管理します。 例えば、時短勤務で1日の所定労働時間が7時間のユーザーの場合、 有休休暇を丸1日取得すれば、常にチケット1枚(480pt)を消費しますが 代休を丸1日取得した場合は、420ptの消費になります。 |
| 代替休暇 | 労働基準法 第37条 ③ 詳しい説明が書かれたPDF https://www.mhlw.go.jp/stf/houdou/2r9852000000uefi-img/2r9852000000ugqj.pdf 代替休暇の権利や消費を示すチケットです。 最小利用単位は1日or半日ですが、足りない場合は他の休暇と連結して良いと書かれています。 ※当システムでは十分に対応できていません。 他のチケットと連結するように自動引き当てする処理は出来ましたが、連結した結果が常に最小利用単位を満たすように保護し続けるのはメチャクチャ難しいので諦めました。 |
| 休日出勤 | 休日出勤したことを示すチケットです。 代休振替の親チケットとして振る舞います。 打刻処理時にバックグラウンドで休日出勤かどうかの判定を行い、休日出勤チケットを自動生成します。 月報が修正され、休日出勤の事実が無くなった場合は、連動して休日出勤チケットの一族も消滅します。 常に月報の実働時間と一致している必要があるため、ユーザーは操作できないようにしました。 ユーザーが全く操作できないのは仕様バグです。システム上で休日出勤の事前申請が出来なくなってしまいました。 |
| 欠勤 | 実動時間が0である理由を説明するためのチケットで、人間が管理業務をするために使います。 当システム内部では使われていません。出勤率の計算時は実動時間の数値を元に判定しています。 |
| 特別休暇 | これらのチケットタイプ全てに当てはまらない休暇であることを示します。 |
| 遅刻 | 始業時刻～作業開始時刻の間に労働していない理由を説明するために使います。 人間が管理業務をするためのチケットです。 当システムとしては遅刻や早退のチケット作成は必須ではありません。 就業規則によって遅刻や早退の回数をカウントする必要がある場合は、チェック処理を搭載したカスタムロジックを新たに実装する必要があります。 フレックスタイム制の場合は、コアタイムに対して使えます。 スーパーフレックス制の場合は、このチケットタイプは使えません。 |
| 早退 | 作業終了時刻～終業時刻の間に労働していない理由を説明するために使います。 他は遅刻と同じです。 |
| 私用外出 | 開始打刻～終了打刻の間で労働していない時間帯を示すチケットです。 実際の業務では休憩と私用外出を分けている場合があるため、当システムでも休憩時間とは別々に管理できるようにしています。 実動時間の計算の際は休憩時間と同じ扱いになります。 私用外出チケットを作る代わりに休憩開始打刻・休憩終了打刻することもできます。 昼休みなど、元々の休憩に重なる形で私用外出チケットを作った場合、重複する時間帯に相当するポイントが差し引かれた状態のチケットができます。 |
| 休業 | 労働基準法 第26条 労働基準法 第76条 このチケットが使われている時間帯は、休業時間として月報に計上されます。 最終的には給与管理システムへ連携され、「平均賃金の60%以上」の手当の元ネタになるはずです。 |
| 調整 | ユーザーからは見ることができない、システムの内部制御専用チケットです。 時間休は最大で5日分使えますが、通常勤務と時短勤務では「1日」の長さが違います。 チケットポイントの消費量の違いを吸収するために、調整チケットにポイントを持たせます。 |
| 繰越調整 | 有給休暇の権利を翌年に繰り越すとき、残りポイントを回復させるチケットです。 繰り越し処理は、新しく有給休暇が付与されるタイミングで行われます。 時間休を使って少しだけ残ったポイントがあるとき、企業によっては残りポイントを全回復させる場合があります。 当システムではチケットポイントを赤黒伝票のような形式で管理しているため、ポイントを回復させるために専用のチケットを作る必要があります。回復用のチケットをユーザーに見せないように、繰越調整というチケットタイプで管理します。 |
| 特別計上 | チケットを買い上げて残りポイントを労働時間(=給与)として計上するとき、チケットのポイントを減らすためのチケットです。 使い道は3パターンあります。 ①月報を作成するとき、有給フラグがONの代休チケットは全て買い上げます。 この挙動によって残業代の未払いを防ぎます。労働基準法 第24条 ②月報を作成するとき、有効期限が切れた代替休暇チケットは全て買い上げます。 この挙動によって残業代の未払いを防ぎます。 ③有給休暇や季節休暇の有効期限が切れた後、チケットを買い上げます。 消滅したポイントを労働時間(=給与)として計上することで、 疑似的に有給休暇の買い上げを実現しています。 |
| 未払繰越 | 代替休暇振替チケットの親となるチケットです。 1か月の超過労働時間が60時間を超えた分を、未払繰越チケットポイントと相殺します。 以下のようなイメージでチケットが作られます。 60h超過分→未払繰越チケットで相殺→代替休暇へ振り替える→代替休暇の権利が発生 |
| 代替休暇振替 | 労働基準法 第37条 ③ 1か月の超過労働時間が60時間を超えた場合、自動的に代替休暇を発生させます。 ユーザーは代替休暇振替チケットを取り消しすることができます。 取り消しすると、それ以降に作られる月報で買い上げ処理の対象になり、労働時間(=給与)として計上されます。 |
実装ネタ
これらのチケットタイプはC#コード中では列挙値として扱い、DBにはint型で保持します。
私の実装技術の都合で、ストアドやビューのSQL文中にはint型の固定値が書かれていたりします。
/// <summary>
/// チケット種別
/// </summary>
public enum TicketTypes : int
{
/// <summary>
/// 有給休暇
/// </summary>
[Display(Name = "有給休暇")]
Yukyu = 1,
}残業申請について
当システムでは労力の都合で残業申請機能を搭載していません。
システムとしては残業した結果の労働時間だけが分かれば良く、残業申請の有無や残業の理由といったデータを持たなくても最低限動かせるからです。
もし残業申請機能を搭載するのであれば、承認機能も搭載する必要が出てきます。
当システムでは労力の都合上、チケットの承認機能も搭載していません。
残業申請は、残業が始まる前に承認されるのが適切ですから、申請が入力された場合に承認者にメール等で通知する機能も必要です。
残業申請の承認前に、「現状の残業時間がxx時間、上限はxx時間」といった情報が閲覧できると便利かもしれません。
ここからは個人的なエピソードです。
残業申請機能について真面目に考えるのがダルいので、最初から乗せる気はありませんでした。
明らかに無理なスケジュールが原因で残業をしているときに、「残業申請を入力するために1分余計に残業する」という運用バグを回避することができます。
産前産後休業・病気などによる休職について
長期にわたって休むことが確実な場合、ユーザーに紐付けるカレンダーを切り替える想定です。
カレンダーのすべての日付を所定休日・法定休日とすることで、労働義務が無い状態にできます。
上記以外の休業について
「1日だけ育児休業」といった場合は、特別休暇チケットを使う想定です。
厳密に運用するならチケットタイプを増やすべきですが、実装が大変そうなので見送りました。
大変そうな理由について、言い訳を並べます。
下記の項目について、企業が独自で決めても良いものと、法的に変更不可能なものがあります。
- 有給とするか無給とするか
- 出勤率計算で全労働日に含めるか
- 出勤率計算で出勤したものと見なすか
チケットタイプごとに上記の項目をカスタマイズする機能を搭載して、
法律に違反しないような入力チェックを行う必要があります。
就業規則は事業場単位で異なる場合があり、法改正や就業規則の変更により、ある日付を境にして変わる場合もあります。つまり、カスタマイズの際は事業場単位にデータを入力してもらい、DB上では別々のデータとして扱う必要があります。
カスタマイズしたデータを取得するときは日付による絞り込みが必要です。
さらに、社員マスタに男性として登録されているユーザーが生理休暇チケットを作成した場合、エラーとするか？ という微妙な問題があります。
・・・と難しい問題があったので、判断をユーザーに丸投げする方式を採りました。
本格的に運用するのであれば、上記のカスタマイズ機能は搭載する必要があると思います。
すべての上司が有給・無給などを正確に判断するのは大変負担が大きいですし、
知らないうちに違法な状態で運用してしまうリスクが残るなら、勤怠管理システムを導入する利点が無くなってしまいます。
実装していないチケットタイプ
下記の休暇が存在することを知らなかったため、システムには搭載できませんでした。
子の看護休暇(育児介護休業法 第16条の2)
介護休暇(育児介護休業法 第16条の5)
「一の年度において五労働日（二人以上の場合にあっては、十労働日）」と書かれていることから、残数管理ができると便利です。