休日・祝日マスタの設計
このページは、企業や団体の休日・祝日マスタの設計 (DB、UI) について考えるページです。
目次
注意
- このページを作ったひとが現在進行形で考えていることのため随時内容が変わることがあります。
- 日本の国民の祝日にもとづく休日と、企業・団体の休日を対象にしています。従業員固有の休み (有給休暇やシフト上の休み) はここでは除いています。
設計時に検討すること
どの休日・祝日をどのように管理するのか
参考: 休日・祝日の種類
国民の祝日にもとづく休日の種類
種類 | 説明 |
---|---|
月・日固定の休み | ・例: 元日 = 1月1日、文化の日 = 11月3日 |
年・月・日固定の休み | ・例: 令和天皇の即位 = 2019年5月1日、海の日 = 2020年に限り7月23日 |
月・週・曜日固定の休み | ・例: 成人の日 = 1月の第2月曜日 |
固有ルールの休み | ・春分の日 (春分日。計算はできるが官報の暦要項の掲載をもって確定になる) ・秋分の日 (秋分日。同上) ・振替休日 (国民の祝日が日曜日にあたるとき、その日後においてその日に最も近い国民の祝日でない日) ※月曜日確定ではない ・国民の休日 (前日・翌日が国民の祝日である、国民の祝日以外の日) |
- 補足
- 上記は2020年時点での情報 (法律の施行期間を考慮する必要がある)
企業・団体の休日の種類
種類 | 説明 |
---|---|
曜日固定の休み | 土日など (法定休日と法定外休日) |
法定休日 | 労働基準法第35条 をもとに就業規則で定められた休み |
法定外休日 | 就業規則で定められた、法定休日以外の休み |
期間の休み | 夏季休暇、年末年始休暇など、特別休暇のうち決まった期間の休み |
その他 | 対象企業・団体の休暇のルールによっては国民の祝日にもとづく休日の種類と同じように月日固定、年月日固定、年週曜日固定、固有ルールの休みがあり得る (設立記念日を休みにするなど) |
- 補足
- 対象企業などの曜日の休みが変わる可能性がほぼ無ければ曜日の休みは DB 上に情報を持っていなくてもいい
国民の祝日にもとづく休日と企業・団体の休日でテーブルを分けるか
- 意味的に異なるので分けたほうがわかりやすい場合がある
- 日付で管理する方式 (後述) の場合、分けないほうが実装しやすい
- 休日判定するときに1テーブル見る程度で済む
- ルールで管理する方式 (後述) の場合、分けたほうが実装しやすい
- 国民の祝日と企業・団体の休日はルールの変更頻度に差がある
- 国民の祝日には休暇期間 (数日にわたる休み) の概念が必要な休日が今のところないが、企業・団体の休日には休暇期間の概念が必要な休暇がある (前述の夏季休暇、年末年始休暇。また、年末年始休暇は年をまたぐ)
よくある方式
日付で管理する方式
その年に決まった休日・祝日を年月日で持つ方式です。基本的にはこちらの方式のほうがルールで管理する方式 (後述) より圧倒的に楽です。
データの例
内部ID | 日付 | 休日名 |
---|---|---|
1 | 2020-01-01 | 元日 |
2 | 2020-01-02 | 年始休暇 |
3 | 2020-01-03 | 年始休暇 |
4 | 2020-01-13 | 成人の日 |
5 | : | : |
- 補足
- 休日名は要件的に必要なければ持たなくて可
- 国民の祝日にもとづく休日と企業・団体の休日を見分けるための列を追加しても可
- 上記の形だと期間の休日でもデータが1日ずつに分かれるので、1期間1レコードにしたい場合は「日付」列を「開始日」「終了日」の2列にする (1日の休みは開始日と終了日を同じ日にする)
UI の例
- 指定年の12か月分の月カレンダーが表示され、日ごとに表示されたチェックボックスにチェックを入れて登録ボタンを押下することで1年分の休日が一括登録できる方式
- 休日自体の登録はしやすい。休日名を登録させたい場合この方式だと難しくなる
- 指定年の登録済の休日データ行 + 新規行 + 行の追加削除移動ができるボタンを持つグリッド部品が表示され、必要な情報を入力して登録ボタンを押下することで1年分の休日が一括登録できる方式
- 休日名を登録させやすい
利点・欠点
項目 | 説明 |
---|---|
利点 | ・日付の計算処理 (休日判定処理) が不要のため工数が抑えられて楽 ・データの追加がしやすい (毎年のカレンダーを見ればいい。また、国民の祝日について - 内閣府 に CSV がある) ・月カレンダー方式の UI だと休日登録操作が楽 (市販のカレンダーや会社で作った休日表の Excel などを見てチェックボックスをポチポチすればいい) |
欠点 | ・メンテナンスが毎年必要 |
ルールで管理する方式
法律などをもとにしたルール (定義) をデータとして持つ方式です。
データの例
内部ID | 施行開始年 | 施行終了年 | 月 | 日 | 週 | 曜日 | 固有 | 休日名 |
---|---|---|---|---|---|---|---|---|
1 | 1949 | 9999 | 1 | 1 | NULL | NULL | NULL | 元日 |
2 | 1949 | 1999 | 1 | 15 | NULL | NULL | NULL | 成人の日 |
3 | 2000 | 9999 | 1 | NULL | 2 | 1 (月曜日) | NULL | 成人の日 (改正) |
4 | 1967 | 9999 | 2 | 11 | NULL | NULL | NULL | 建国記念の日 |
5 | 1949 | 9999 | 3 | NULL | NULL | NULL | shunbun | 春分の日 |
: | : | : | : | : | : | : | : | : |
- 補足
- 成人の日は1949~1999年までは1月15日、2000年からは1月の第2月曜
- 春分の日は固有列の名称をもとにプログラム上で春分日を計算する
(もし仮に官報の暦要項で確定した日と計算上の春分日が違う事態になった場合はその年の春分の日だけ年月日固定の休みとしてデータ追加するなどの対応が必要)
UI の例
- 指定年の登録済の休日データ行 + 新規行 + 行の追加削除移動ができるボタンを持つグリッド部品が表示され、必要な情報を入力して登録ボタンを押下することで1年分の休日が一括登録できる方式
- 一括方式でなくてもいい (変更頻度が多くないので一覧・登録・編集・削除画面でもストレスは少ない)
利点・欠点
項目 | 説明 |
---|---|
利点 | ・うまく設計・実装できれば毎年はメンテナンスしなくていい (法改正時などのみで OK) |
欠点 | ・休日判定処理の実装工数がかかる (法知識が必要) ・法改正時のデータ追加が若干面倒 (顧客が休日データをメンテナンスする場合特に) |
- その他
- どの言語でも祝日判定を行う外部ライブラリが公開されていることが多いが、長期稼働が必要なシステムの場合下記の理由で基本的に使うことは避けたほうがいい
- メンテナンスが続く保証がない
- 決められた形式のファイルでしか定義データを管理できない、DB 管理の取り決めが作りたいシステムと合わないなどがよくある
- 問題が起こった時の情報が少ないことが多い (ソースを読むなどの必要が出てくる)
- どの言語でも祝日判定を行う外部ライブラリが公開されていることが多いが、長期稼働が必要なシステムの場合下記の理由で基本的に使うことは避けたほうがいい
参考
- 国民の祝日について - 内閣府
- knooto 内のページ