勤怠管理システム開発は法令が仕様を決める【2026年版】労働時間の把握・36協定・割増・年休の設計要件

『自社の就業規則が特殊すぎて、どの勤怠管理システムも合わない気がする。作るしかないのか』——人事労務や情シスの方から、こうした相談をよく受けます。

結論から言うと、勤怠管理システムの開発は、他の業務システムと決定的に違う点がひとつあります。要件の出どころが社内の業務ルールではなく、法令にあることです。何を記録し、何をどう分けて集計し、何年残すかは、労働基準法と同施行規則、労働安全衛生規則が先に決めています。ですから発注前にまず確かめるべきは費用相場ではなく、自社の就業実態が法令要件のどこに引っかかるかです。

この先では、法令から設計要件への対応関係、労働時間の記録方法と打刻手段4種の比較、時間外・深夜・休日を分けて持つ集計の要件と36協定の上限警告、変形労働時間制やフレックスなど制度差の扱いと年5日の年休、記録の保存年数と給与計算システムへの連携、そして外部チームで作る場合の進め方までを順に整理します。数値と条文はすべて厚生労働省とe-Gov法令検索で直接確認し、確認日を添えました。なお本記事は法令の一般的な整理であり、法的助言ではありません。自社への当てはめは必ず就業規則と社会保険労務士の確認を経てください。

私は人材業界の出身で、2018年からホーチミンを拠点に、ベトナムでの開発体制づくりを約100社支援してきました。人材の仕事をしていた頃から給与計算と就業規則には触れてきましたが、勤怠のシステム化で最初に詰まるのは、いつも技術ではなく法令の解釈と、拠点ごとに違う就業規則の扱いでした。当社は日本人PM付きのラボ型で継続開発を担いますが、勤怠のように標準品が成熟した領域では「作らないほうがよい」とお伝えすることも少なくありません。

読み終えるころには、自社が「パッケージで足りる側」か「作る必要がある側」かを、根拠を添えて一文で説明できるようになっているはずです。当てはまる章だけ拾い読みしていただいても構いません。

勤怠管理システム開発が他の業務システムと違う点——仕様の出どころが社内ではなく法令にある

販売管理でも在庫管理でも、要件の出どころは社内の業務ルールです。誰がどの順に承認するか、どの帳票を出すか——最後は社内で決められます。勤怠管理システムだけは違います。何を記録し、何をどう分けて集計し、何年残すかを、法令が先に指定しているからです。この章では、その対応関係を先に固定します。

要件は「法令 → 就業規則 → システム設計」の順で下りてくる

勤怠のデータは、最後に必ず賃金の計算根拠になります。記録そのものが、労働時間と賃金を説明する証拠として機能する。ここが他の業務システムと決定的に違う点です。売上の集計ロジックを間違えれば経営判断を誤りますが、勤怠の集計ロジックを間違えると、未払い賃金という形で直接の法的責任になります。

だから要件は3段で下りてきます。まず法令が最低ラインと計算の枠を決める。次に、その枠の中で自社の就業規則が所定労働時間・休憩・休日・手当を具体的に定める。最後に、就業規則に書かれたルールをシステムが実装する。この順番を飛ばして、いきなり「どんな機能が要るか」から始めると、後から必ず戻ります。

私は人材業界の出身で、システムの外側から給与計算や就業規則に触れてきました。その経験から言うと、勤怠のシステム化が止まるのは技術的な難所ではなく、たいてい「就業規則に書いていないことを、現場が慣習で運用していた」という場所です。2018年からホーチミンで約100社の開発体制を見てきましたが、勤怠まわりの要件定義で最初に時間がかかるのも同じ箇所でした。

法令が直接指定している設計要件(対応表)

条文が設計に直結するものを並べます。いずれも2026年9月19日にe-Gov法令検索および厚生労働省の公開資料で確認しました。

出典: e-Gov法令検索(労働基準法・労働基準法施行規則・労働安全衛生法・労働安全衛生規則・平成6年政令第5号)、厚生労働省「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」。いずれも2026年9月19日確認。

この表のうち、自社の就業規則で「標準と違う」扱いをしている行がいくつあるか。それが、パッケージに載るかどうかの最初の目安になります。

なお、本記事は公開されている法令と行政資料を整理したものであり、法的助言ではありません。 自社の就業規則への当てはめ、特に変形労働時間制や裁量労働制の適否については、必ず社会保険労務士の確認を受けてください。

費用の話に入る前に、この対応表で自社の位置を確かめる

費用が気になるのは当然です。ただ、勤怠管理システムの金額は「作る範囲」で決まり、その範囲は上の表のどこで標準から外れるかで決まります。順番が逆になると、見積もりを取っても比較できません。業務システム全般の費用の構造(規模別の相場、見積書に載らない連携・移行費、5年総額の考え方)は『業務システム開発 外注 費用』の記事にまとめてありますので、金額のレンジはそちらを参照してください。本記事では金額表は作りません。

代わりにこの先で扱うのは、上の表を自社の要件に翻訳する手順です。記録(打刻)、集計と計算、制度差と休暇、保存と連携の順に下りていきます。まずは入口である「どう記録するか」からです。

労働時間をどう記録するか——客観的な打刻が原則、自己申告は例外

勤怠管理システムの入口は打刻です。ここで集めたデータがそのまま賃金の計算根拠になるため、「どう集めたか」が後から問われます。打刻手段の選定を利便性だけで決めると、記録の信頼性を自分で下げることになります。この章では、行政が示している原則と、打刻手段ごとの向き不向きを整理します。

厚生労働省のガイドラインが求める原則的な方法

厚生労働省は「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」を平成29年1月20日に策定しています。そこでは、使用者が始業・終業時刻を確認し記録する方法として、原則として次のいずれかによるとされています。

1. 使用者が、自ら現認することにより確認し、適正に記録すること
2. タイムカード、ICカード、パソコンの使用時間の記録等の客観的な記録を基礎として確認し、適正に記録すること

つまり客観的記録が原則で、自己申告は例外です。ガイドラインは、上記の方法によることなく自己申告制によりこれを行わざるを得ない場合に講ずべき措置として、労働者への十分な説明、実際に労働時間を管理する者への説明、必要に応じた実態調査と労働時間の補正、自己申告した時間を超えて事業場内にいる時間の理由確認などを挙げています。特に、入退場記録やパソコンの使用時間の記録など事業場内にいた時間が分かるデータがある場合に、自己申告との間に著しい乖離が生じているときは、実態調査と補正を求めています。

さらに同ガイドラインは、労働者が自己申告できる時間外労働の時間数に上限を設け、上限を超える申告を認めない等、適正な申告を阻害する措置を講じてはならないとしています。システムの仕様として「残業申請は月45時間まで入力可」と作り込む発想は、ここに抵触しかねません。上限は警告するもので、入力を塞ぐものではない——この線引きは設計時にはっきりさせておくべきです。

なお、労働安全衛生法66条の8の3は、面接指導を実施するため、厚生労働省令で定める方法により労働者の労働時間の状況を把握しなければならないと定めています。その方法は、労働安全衛生規則52条の7の3で「タイムカードによる記録、パーソナルコンピュータ等の電子計算機の使用時間の記録等の客観的な方法その他の適切な方法」とされ、記録は3年間保存する措置が求められています。労働基準法の労働時間管理とは別建ての義務がもう1本ある、と理解しておくと設計を誤りません。

打刻手段4種の比較——PC・スマホのGPS・ICカード・生体認証(表)

実務で選ばれる打刻手段は、おおむね次の4つです。どれが優れているかではなく、就業形態のどこに合うかで決まります。

生体認証について補足します。個人情報保護法施行令1条は、個人識別符号となる身体の特徴として、DNAの塩基配列、容貌、虹彩、声帯の振動等、歩行の態様、手のひら・手の甲・指の皮下の静脈の形状、指紋・掌紋を挙げています。これらを電子計算機の用に供するために変換した符号で、特定の個人を識別するに足りるものは個人情報として扱われます。つまり生体認証打刻を採用した時点で、扱うデータの性質が一段上がります。海外の開発拠点を使う場合は、本番データを渡さない設計が前提になります。この点は『ベトナム データ越境 個人情報』の記事で扱った考え方がそのまま当てはまります。

当社が支援した案件でも、複数拠点を持つ企業ほど打刻手段が混在していました。本社はPCログ、工場はICカード、訪問部門はスマホ——というように。混在自体は悪くありません。問題は、手段ごとに記録の粒度と欠損の出方が違うのに、集計側が一種類の前提で作られている場合です。設計では「打刻手段ごとに欠損の起き方が違う」ことを先に洗い出してください。

不正打刻と、打刻漏れの後始末をどう設計するか

不正打刻の対策としてよく挙がるのは、生体認証、GPS、IPアドレス制限といった「入口を固める」手段です。ただ、実務で件数が多いのは意図的な不正より単純な打刻漏れです。そして漏れた日をどう埋めるかの設計が、システムの信頼性を決めます。

打刻漏れの修正機能は必ず要ります。要るからこそ、次の3点を仕様に書いてください。第一に、誰が修正できるか(本人申請+上長承認か、労務担当のみか)。第二に、修正の履歴が残るか(修正前の値、修正者、修正日時、理由)。第三に、修正が集計と給与連携にどう反映されるか(締め後の修正をどう扱うか)。履歴が残らない修正機能は、記録の証拠力を自分で壊します。

私が求人プラットフォームの応募者管理システムを手がけたときも、ステータス変更の履歴と権限設計が最後まで論点でした。勤怠はそれ以上に、誰がいつ値を変えたかが問われます。修正履歴は「あれば便利な機能」ではなく、記録の一部だと考えてください。

記録の仕組みができても、それだけでは足りません。集めた時間を、法令が求める区分に分けて数えられなければ、賃金の計算にたどり着かないからです。

集計と計算の要件——時間外・深夜・休日を分けて持ち、36協定の上限を月中に知らせる

打刻データが集まったら、次は数える工程です。ここで多くのシステムが躓きます。理由は単純で、労働時間を「合計何時間」という1つの数値で持ってしまうからです。法令は最初から、種類ごとに分けて数えることを求めています。この章では、集計の要件を条文から起こします。

賃金台帳が要求する5つの区分——足し合わせて持ってはいけない

労働基準法施行規則54条は、賃金台帳に労働者ごとに記入すべき事項として、氏名、性別、賃金計算期間、労働日数、労働時間数、そして労働時間を延長し若しくは休日に労働させた場合または午後10時から午前5時までの間に労働させた場合における延長時間数・休日労働時間数・深夜労働時間数、賃金の種類ごとの額、控除額を挙げています。

ここから導かれる設計要件は明快です。少なくとも、労働日数 / 労働時間数 / 延長時間数(時間外) / 休日労働時間数 / 深夜労働時間数の5つを、別々に保持して出力できなければなりません。集計の最小単位を「日×労働者×区分」に置くのが実務的です。月次で合算だけを持つ設計にすると、後から区分を分けられず、賃金台帳の出力でつまずきます。

厚生労働省のガイドラインも、賃金台帳にこれらの事項を記入していない場合や、故意に虚偽の労働時間数を記入した場合には、労働基準法120条に基づき30万円以下の罰金に処されるとしています。帳票出力は「あとで作る機能」ではなく、データ構造を決める制約条件です。

私が決済アプリの開発に関わったとき、金額の計算ロジックで徹底したのは「途中経過を残す」ことでした。合計だけを保存すると、差異が出たときに原因を特定できません。勤怠も同じです。日ごとの区分別の内訳が残っていれば、監督署の調査でも社内の問い合わせでも、その日まで遡って説明できます。合計だけを持つ設計は失敗のもとです。

割増率は重なる——時間外・深夜・休日・月60時間超(表)

割増賃金の率は、区分ごとに別々に定められています。しかも重なります。

労働基準法37条1項は「二割五分以上五割以下の範囲内でそれぞれ政令で定める率以上の率」と規定し、その政令である平成6年政令第5号が、時間外は2割5分、休日は3割5分と定めています。深夜は同条4項に直接2割5分以上と書かれており、時間外の割増とは別建てです。したがって、深夜帯にかかった時間外労働は両方が適用されます。

月60時間超の5割については、中小企業への適用猶予措置が2023年4月1日に廃止され、企業規模にかかわらず適用されています(厚生労働省「中小企業の事業主の皆さまへ 月60時間を超える時間外労働の割増賃金率が引き上げられます」2026年9月19日確認)。なお37条3項は、労使協定を結べば引上げ分の割増賃金に代えて有給の休暇(代替休暇)を与えることができると定めており、これを採用する企業では代替休暇の残日数管理までシステムの範囲に入ります。

割増率と上限時間は、自社の就業規則でこれを上回る定めを置いている場合があります。実装する率は必ず自社の就業規則と社会保険労務士の確認を経てください。本記事に書いた率は法定の最低限です。

設計上の要点は、率をコードに直書きしないことです。法定の最低率、自社の規定率、適用開始日を持つマスタとして外に出しておく。法改正や就業規則の改定があったとき、改修規模が一桁変わります。

36協定の上限を月末に知っても遅い——警告設計に必要なデータ

時間外労働の上限は、労働基準法36条3項・4項により、原則として1か月45時間・1年360時間です(1年単位の変形労働時間制で対象期間を3か月超とする場合は1か月42時間・1年320時間)。特別条項を結んだ場合でも、同条5項・6項により次の4つを守る必要があります。

1. 1年について時間外労働が720時間以内
2. 1か月について、時間外労働と休日労働の合計が100時間未満
3. 対象期間の初日から1か月ごとに区分した各期間に、直前の1・2・3・4・5か月を加えたそれぞれの期間について、時間外労働と休日労働の合計の1か月あたり平均が80時間を超えないこと
4. 時間外労働が1か月45時間を超えることができるのは、1年について6か月以内

厚生労働省の働き方改革特設サイトも、複数月平均80時間以内と月100時間未満はいずれも休日労働を含む、と明示しています(2026年9月19日確認)。違反には罰則(6か月以下の懲役または30万円以下の罰金)が科されるおそれがあるとされています。

ここから警告機能の要件が決まります。まず、2と3は休日労働を含む数字なので、時間外と休日を合算した「もう1つの集計値」が要ります。賃金計算では分けて持ち、上限判定では足す——同じデータから2通りの集計が必要だということです。次に、3の複数月平均を出すには直前5か月分の確定値を保持していなければなりません。年度初めに導入したシステムは、最初の半年は平均を計算できない。移行時のデータ取り込みを要件に入れておいてください。

そして、警告のタイミングです。月末に集計して「45時間を超えていました」と分かっても、もう手を打てません。実務で効くのは、日次で当月の累計を更新し、閾値(例えば所定の8割)に達した時点で本人と上長に通知する設計です。残業の事前申請ワークフローと組み合わせれば、申請の段階で「この申請を承認すると上限に達する」と見せられます。

自社のいまの仕組みは、月の何日目に上限超過の兆候をつかめるでしょうか。そこが答えられないなら、警告設計が要件の最優先です。

制度差と休暇——変形労働時間制、フレックス、裁量労働、年5日の取得義務

ここまでは、通常の労働時間制を前提にした話でした。実際の企業では、工場は1年単位の変形労働時間制、本社はフレックス、一部の職種は専門業務型裁量労働制、というように制度が混在します。労働時間制度が違えば、時間外と判定する基準そのものが変わります。この章では、制度差と休暇の扱いを整理します。

労働時間制度ごとに集計ロジックが変わる(表)

制度ごとに、清算の単位と上限が異なります。2026年9月19日にe-Gov法令検索で確認した内容です。

この表を自社に当てはめると、「どの制度が、どの従業員グループに、いつから適用されているか」というマスタが必要だと分かります。しかも制度は年度単位で変わります。過去の月を再計算するには、その月に適用されていた制度を復元できなければなりません。制度の適用履歴を期間つきで持つ——これが、勤怠管理システムの設計でもっとも見落とされる点です。

裁量労働制について1点補足します。労働基準法施行規則24条の2の2第3項は、専門業務型裁量労働制の協定事項として、みなし労働とすることについて労働者本人の同意を得ること、同意しなかった者に不利益な取扱いをしないこと、同意の撤回に関する手続を定めることを挙げています。そして同意および撤回の記録を協定の有効期間中および満了後5年間(施行規則71条により当分の間3年間)保存することも求めています。つまり、裁量労働制を使うなら同意管理の画面と保存が要件に入ります。

制度の適否——自社の業務が専門業務型裁量労働制の対象業務に当たるか、1年単位の変形労働時間制の要件を満たすか——は、法的な判断です。システムの要件として確定させる前に、必ず社会保険労務士の確認を受けてください。

年次有給休暇——付与日数の自動計算と、年5日の時季指定義務

年次有給休暇は、労働基準法39条1項により、雇入れの日から6か月継続勤務し全労働日の8割以上出勤した労働者に10労働日を与えることから始まります。以降は同条2項の表に従い、6か月経過日から起算した継続勤務年数1年ごとに1日、2日、4日、6日、8日、6年以上で10日を加算します。所定労働日数が少ない労働者については同条3項により比例付与になります。

システム化で効くのは同条7項です。年10労働日以上の年次有給休暇が付与される労働者について、そのうち5日は、基準日から1年以内の期間に、労働者ごとに時季を定めて与えなければならないとされています。厚生労働省の働き方改革特設サイトは、対象を「法定の年次有給休暇付与日数が10日以上の全ての労働者(管理監督者を含む)」とし、労働者自らの請求、計画年休、使用者による時季指定のいずれかの方法で取得させる必要があると説明しています(2026年9月19日確認)。

そして労働基準法施行規則24条の7は、年次有給休暇を与えたときに、時季・日数・基準日を労働者ごとに明らかにした年次有給休暇管理簿を作成し、当該期間中および満了後5年間(施行規則71条により当分の間3年間)保存することを求めています。山口労働局の解説は、この管理簿について「必要なときにいつでも出力できる仕組みとした上で、システム上で管理することも差し支えありません」と明示しています(2026年9月19日確認)。帳票を紙で出す必要はないが、いつでも出せることが条件だ、という意味です。

設計要件に落とすと、(1)入社日と勤続年数からの付与日数の自動計算、(2)所定労働日数が変わった場合の比例付与の再計算、(3)基準日の統一(いわゆる斉一的取扱い)を採る場合の分割付与の扱い、(4)残日数と取得日数の監視、(5)年5日に届きそうにない労働者の抽出、(6)管理簿の出力、の6つになります。パート・アルバイトの比率が高い企業ほど、(2)が重くなります。

休憩の自動控除と、申請・承認ワークフローの置き方

相談でもっとも多く見かける危うい実装が、休憩の一律自動控除です。「12時から13時は必ず60分控除」と作り込んでおくと、実際には電話番で作業していた日も控除されます。労働基準法34条は労働時間が6時間を超える場合に少なくとも45分、8時間を超える場合に少なくとも1時間の休憩を労働時間の途中に与えることを求めていますが、これは「与える」義務であって、「取ったことにしてよい」という規定ではありません。

現実的な設計は、自動控除を初期値として置きつつ、実態が違った日を本人が申告し、上長が承認して控除を取り消せる経路を必ず用意することです。厚生労働省のガイドラインが自己申告制について求めている「実態調査と補正」の考え方は、休憩にもそのまま当てはまります。控除を固定値でしか持てないシステムは、後から必ず手作業の温床になります。要注意です。

申請・承認ワークフローも同じ観点で設計します。残業の事前申請、休日出勤、打刻修正、有給申請、代替休暇——それぞれに承認者と経路があり、拠点や職位によって経路が違うのが普通です。私が応募者管理システムを手がけたときも、ステータス遷移と権限の組み合わせが最後まで残る論点でした。勤怠ではさらに、承認の履歴が記録の一部になります。誰がいつ承認したかを残せない設計は、後で説明責任を果たせません。

ここまでの4章で、自社の就業実態が「標準から外れる箇所」がいくつ出てきたでしょうか。その数を数え上げる作業こそが、勤怠管理システムの要件定義です。

作った後のほうが長い——記録の保存年数、給与計算システムへの連携、法改正のたびの改修

勤怠管理システムは、リリースが終わりではありません。記録は数年残り、毎月給与計算につながり、法改正のたびに直すことになります。開発期間が半年でも、その後の運用は10年続きます。この章では、作った後に効いてくる3つの論点を扱います。

何年残すのか——条文は5年、当分の間3年という二重構造

保存年数は、条文を素直に読むと混乱します。整理すると次のとおりです。

厚生労働省のガイドラインも、労働者名簿・賃金台帳のみならず、出勤簿やタイムカード等の労働時間の記録に関する書類について、労働基準法109条に基づき3年間保存しなければならないとしています(ガイドライン策定時点の年数表記)。

設計判断としては、5年を前提にデータを保持する形にしておくことを勧めます。理由は2つあります。ひとつは、条文上の原則がすでに5年であり、「当分の間」がいつ終わるかは本記事の執筆時点(2026年9月19日)で確認できていないこと。もうひとつは、賃金請求権の消滅時効も同じ附則(143条3項)で当分の間3年とされており、原則の5年に戻れば保存年数の実務も動く可能性があるからです。いつ変わるかは確認できていません。断定はできません。 ただ、保存年数をコードに埋め込まず、設定値として外に出しておくだけで、そのときの改修は数日で済みます。

もうひとつ実務的な注意を。保存が必要なのは集計後の月次データだけではありません。打刻の生データ、修正履歴、承認履歴まで含めて「労働時間の記録に関する書類」です。ストレージ容量の見積もりは、打刻件数×従業員数×年数で概算してください。数百名規模であれば負担になる量ではありませんが、生体認証の画像データまで残す設計にすると話が変わります。

給与計算システムへの連携——どこまでを勤怠側が持つか

勤怠は単体で完結しません。必ず給与計算につながります。ここで先に決めるべきは、責任の分界点です。

どれが正解ということはありません。ただ、この分界を決めずに開発を始めると、同じ計算ロジックが勤怠側と給与側の両方に実装され、法改正のたびに2か所直すことになります。要件定義の早い段階で、連携ファイルの項目定義(CSVかAPIか、項目名、桁、締め日、再送の扱い)まで合意してください。締め後に打刻修正が入った場合の再送ルールは、必ず揉める箇所です。

連携先が既存の給与パッケージであれば、そのパッケージが受け付けられる取込フォーマットが事実上の制約になります。「連携できます」という営業の説明と、実際に自社の項目が全部載るかは別の話です。発注前に取込仕様書を1枚もらってください。

法改正のたびに改修が要る——これがSaaSの最大の強みである

ここは率直に書きます。勤怠管理システムを自社で作るということは、法改正対応を自社で背負うということです。時間外労働の上限規制(大企業2019年4月・中小企業2020年4月適用)、月60時間超の割増率50%の中小企業への適用(2023年4月)、年5日の年休取得義務(2019年4月)——直近だけでもこれだけの改正があり、いずれも施行日が期限になります。

SaaSやパッケージの最大の価値は、機能の豊富さではなく、この改正対応が月額に含まれている点です。標準的な就業形態の会社が自社開発を選ぶと、この一点だけで割高になります。作らない判断のほうが正しい場面は多い、というのが実情です。

そのうえで、作ると決めた場合の回し方です。改正対応は「年に数回、短期間にまとまった工数が要る」という波のある仕事です。当社のラボ型では、1名から体制を組め、増員に約1週間、開始まで最短2週間という可変性を持たせています。介護記録SaaSのCareViewerでは、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次に優先順位を判断しながら改修を続けています。制度改正が絡む機能は、この「週次で優先順位を決め直せる」形との相性が良いと感じています。

段取りで1点だけ注意を。ベトナム拠点を使う場合、テト(旧正月)の連休が入ります。2026年は2月14日から22日です。日本の年度末や4月1日施行の改正対応と重なりやすいので、改正の施行日が4月なら12月中に着手する——このくらいの前倒しが現実的です。継続的な改修を外部チームで回す体制の作り方は、『システム改修 開発保守 外注』の記事にまとめています。

保存は最長5年、改正対応は年に1〜2回。開発が6か月で終わっても、その後に向き合う期間はこの桁です。

外部チームで勤怠管理システムを作る場合の進め方——法令解釈は発注者と社労士が持つ

ここまで読んで、「やはり作るしかない」と感じた方もいれば、「標準品で足りそうだ」と思った方もいるはずです。この章では、まず作らない判断の条件を書き、そのうえで作ると決めた場合に外部チームをどう使うかを整理します。当社の体制にも触れますが、合わない案件はその旨を書きます。

パッケージ・SaaSで十分なケース——作らない判断のほうが多い

次の条件にすべて当てはまるなら、作らないほうが安く、速く、安全です。

• 労働時間制度が通常の労働時間制か、1か月単位の変形労働時間制、またはフレックスタイム制のいずれか1つに収まっている
• 就業規則が1本で、拠点や雇用形態による所定労働時間・休憩・休日の違いが、パラメータの範囲で表現できる
• 打刻手段が1〜2種類で、特殊な装置を必要としない
• 手当の計算が、勤務時間と固定額の組み合わせで表現できる
• 既存の給与計算システムが、標準の取込フォーマットを持っている

前章で書いたとおり、法改正対応が月額に含まれることがSaaSの最大の価値です。自社で持つべき理由がないのに自社で持つと、改正のたびに見積もりを取り、予算を取り、テストをすることになります。標準機能で足りる業務まで作り込むのは失敗のもとです。作り方の分類そのものを整理したい場合は『スクラッチ開発とは』の記事を、社内システムを企画する段階の考え方は『社内システム開発 進め方』の記事をご覧ください。小さく始めるならノーコードという選択肢もあり、『ノーコードとは』の記事で限界も含めて整理しています。

作る判断が成立するのは、標準品に載らない制度差が複数残る場合、既存の基幹システム(原価管理、生産管理、介護記録など)と勤怠を同じデータで回す必要がある場合、そして複数社の統合で就業規則が並立している場合です。この3つのいずれかに当たるなら、検討の価値があります。

作ると決めた場合の役割分担——解釈済みのルールを渡す

外部チームを使うときに、最初に決めるべきことがあります。法令の解釈は発注者側と社会保険労務士が持ち、開発側は「解釈済みのルール」を実装する。 この線引きを曖昧にしたまま進めると、誰も責任を取れない仕様ができあがります。

開発ベンダーが「労働法に詳しい」ことは歓迎すべきですが、詳しいことと責任を負えることは別です。使用者としての責任は発注者にあります。要件定義の進め方そのものは『要件定義 進め方』の記事に、可用性や保存要件のような非機能の決め方は『非機能要件とは』の記事にまとめました。

繰り返しになりますが、本記事の内容は法的助言ではありません。 実装する数値やルールは、必ず自社の就業規則と社会保険労務士の確認を経てから開発チームに渡してください。

当社の体制と、向く案件・向かない案件

当社はホーチミンを拠点に、2,000名以上のIT人財データベースから直接アサインするラボ型開発を提供しています。体制はパターンA(日本人PM/ブリッジSE+エンジニア)とパターンB(エンジニアのみ)があり、勤怠のように法令要件が絡む案件では、仕様の解釈確認が頻繁に発生するためパターンAを勧めています。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準にしています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

単価は公開しており、実務3年目安で月1,500USD(約22.5万円・1USD=150円換算目安)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で月額約80万円から。業務システム全般の費用構造は『業務システム開発 外注 費用』の記事、開発会社の比較軸は『システム開発会社 選び方』の記事を参照してください。

向く案件は、既存の基幹システムと勤怠を一体で持つ必要があり、改修が継続的に発生するケースです。介護記録SaaSのCareViewerでは、日本語対応ブリッジSE1名とフルスタック2名の体制で継続開発を担い、従来比で半分以下のコストを維持しながら、週次で優先順位を判断しています。

向かない案件もはっきり書きます。就業規則が標準的でSaaSの標準機能に載る場合、ご相談をいただいても「作らないほうがよい」とお伝えします。法令解釈まで丸ごと任せたいという依頼もお受けできません。解釈を持つのは使用者であり、そこを引き受けると発注者にとってかえって危うい形になるからです。生体情報のような個人識別符号を含む本番データを海外拠点に渡す前提の案件も、そのままの形ではお受けしていません。

【FAQ】勤怠管理システム開発でよくある質問

最後に、相談の場で繰り返し聞かれる5つの質問をまとめます。いずれも法令の一般的な整理であり、自社への当てはめは社会保険労務士の確認を前提としてお読みください。

Q1. 既存の勤怠SaaSを使いながら、足りない部分だけを作ることはできますか?

できます。むしろ現実的な解の一つです。打刻と基本集計はSaaSに任せ、自社固有の手当計算や基幹システムとの突き合わせだけを作る、という分け方がよくあります。条件は、SaaS側がデータを取り出せるAPIまたはCSV出力を持っていることです。ただし、同じ計算を両側で持たないよう責任の分界点を先に決めてください。決めないまま連携すると、法改正のたびに2か所直すことになります。

Q2. 管理職は勤怠管理の対象外にしてよいのでしょうか?

いいえ、外せません。労働基準法41条2号の管理監督者に当たる場合、労働時間・休憩・休日に関する規定は適用されませんが、深夜割増(同法37条4項)は適用されます。また、厚生労働省の働き方改革特設サイトによれば、年5日の年次有給休暇の時季指定義務の対象は「法定の年次有給休暇付与日数が10日以上の全ての労働者(管理監督者を含む)」です(2026年9月19日確認)。さらに労働安全衛生法66条の8の3による労働時間の状況の把握は、管理監督者も対象です。「管理職は打刻不要」という設計は、この3点で行き詰まります。

Q3. 開発期間はどのくらい見ておくべきですか?

要件の確定にかかる時間が支配的です。実装そのものより、就業規則の棚卸しと社会保険労務士との確認に何か月かかるかで全体が決まります。当社が関わった案件でも、開発チームの着手前に発注者側で2〜3か月を要したケースがあります。スケジュールを引くときは、給与計算の締め日を避けた並行稼働期間(旧システムと新システムを同時に回して結果を突き合わせる期間)を2〜3か月分、必ず確保してください。この期間を削った案件で、初回の給与計算が荒れる場面を見てきました。

Q4. 打刻の生データは何年残せばよいですか?

労働基準法109条は労働関係に関する重要な書類を5年間保存すると定め、同法附則143条1項により当分の間3年間とされています。出勤簿やタイムカード等の労働時間の記録もこれに含まれると、厚生労働省のガイドラインが示しています。設計上は、原則である5年を前提にデータを保持し、保存年数を設定値として外に出しておくことを勧めます。「当分の間」がいつ終わるかは、本記事の執筆時点では確認できていません。なお労働安全衛生規則52条の7の3第2項による労働時間の状況の記録は3年間です。

Q5. 御社に頼める範囲はどこまでですか?

開発チームが担うのは、確定したルールの実装、計算結果を検証できる形で残す設計、既存システムとの連携、そしてリリース後の継続改修です。法令の解釈と自社への当てはめは、発注者と社会保険労務士が持つ範囲になります。体制は日本人PM/ブリッジSE付きのパターンAを推奨し、1名から、開始まで最短2週間、増員に約1週間。就業規則が標準的で、SaaSの標準機能に載ると判断できる場合に、率直に「作らないほうがよい」とお伝えするところまでを含めた関わり方。

まとめ: 法令要件を先に確定させ、標準品で足りるかを確かめ、足りない部分だけを作る

勤怠管理システムの開発は、要件の出どころが社内ではなく法令にある——これが他の業務システムとの決定的な違いです。労働基準法施行規則54条は賃金台帳に労働日数・労働時間数・延長時間数・休日労働時間数・深夜労働時間数を記入することを求め、割増率は時間外2割5分、休日3割5分(平成6年政令第5号)、深夜2割5分、1か月60時間超は5割と別々に定められています。36協定の上限は複数月平均まで見る必要があり、年次有給休暇は年5日の時季指定義務と管理簿の作成がついてきます。記録は労働基準法109条により5年間(附則143条1項で当分の間3年間)。これらはすべて、設計に直接効く制約です。

だから順番は、費用の見積もりではなく法令要件の確定からです。自社の就業規則がどの条文に乗っているかを社会保険労務士と整理し、標準から外れる箇所を数え上げる。その結果、外れる箇所がほとんどなければパッケージやSaaSで足ります。法改正対応が月額に含まれるという一点だけで、標準的な会社は作らないほうが安く、速い。作る判断が成立するのは、制度差が複数残る場合、既存の基幹システムと一体で持つ必要がある場合、複数社の統合で就業規則が並立している場合です。

外部チームで作る場合も、線引きは変わりません。法令の解釈と自社への当てはめは発注者と社会保険労務士が持ち、開発側は解釈済みのルールを実装し、計算結果を後から検証できる形で残す。ここを曖昧にしたまま進めると、誰も責任を取れない仕様ができあがります。本記事は公開されている法令と行政資料を整理したものであり、法的助言ではありません。実装する数値とルールは、必ず自社の就業規則と社会保険労務士の確認を経てください。

あわせて、業務システム開発を外注する費用で規模別の相場と見積書に載らない費用の構造を、システム改修・開発保守の外注で法改正のような継続改修を外部チームで回す体制の作り方をご覧いただけます。

現在の体制と要件をお聞かせいただければ、勤怠管理システムを外部チームで作る場合の進め方と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。