労務管理システムで雇用契約手続きを完結させる要件｜電子交付の条件と入社書類の設計

労務管理システムの製品サイトには「雇用契約の電子化に対応」と書かれていますが、その一文が指す範囲は製品ごとにかなり違います。労働条件通知書のPDFを作れるだけのものもあれば、本人の同意取得から入社書類の回収、人事給与への引き渡しまで一本でつながるものもあります。入社日は動かせないため、後から機能不足に気づいても運用でしのぐしかありません。ここでは製品を比べる前に自社で書き出す要件を、工程と根拠条文の側から整理しました。

まとめ：雇用契約手続きをシステムに載せる前に決める三点

先に決めるのは製品でも予算でもなく、労働条件の明示を電子で行うかどうかです。電子で行うなら労働基準法施行規則第5条第4項の二つの条件、つまり労働者本人が希望したことと、出力して書面を作成できる形式であることを、システムのどの画面とどのログで満たすのかまで落とす必要があります。この二条件は運用ルールではなく機能要件になります。

二つめは、雇用契約書に電子署名を使うか、システム上の合意記録で足りるとするか。雇用契約書そのものの交付は法律上の義務ではないため、署名の方式は自社の証拠設計で決める話になります。三つめが入社書類の回収先で、本人入力に回す項目と会社側で確定させる項目を分け、マイナンバーだけ取得経路と権限を切り離しておくところまでが入り口の設計です。

この三点が固まると、パッケージの標準機能で足りるのか連携開発へ回すのかは自然に絞れます。システム全体の機能範囲や勤怠管理との違いは労務管理システムとは？機能・勤怠管理との違いと比較の観点・個別開発の判断軸を解説【2026年】にまとめました。申請から承認、書類回収までを自社の運用に合わせて組み直したい場合はワークフローシステム開発へ相談してください。

雇用契約手続きに含まれる工程を内定通知から社会保険の届出まで分解する

「雇用契約手続き」という言葉は社内でも人によって指す範囲が違います。採用担当は内定通知から入社日までを指し、労務担当は社会保険の届出までを含めて呼ぶことが多いはずです。手続きに加えてPC・アカウントの準備や入社後3か月の面談まで含めた受け入れ全体の流れは、オンボーディングの意味と工程、システム化する範囲の判断をまとめた記事で扱っています。この認識差のまま製品を選ぶと、要件定義の途中で工程が一つ抜け落ちます。

内定から入社日までに動く書類を五つの区分へ整理し受け皿を決める

入社にまつわる書類は、性格の違う五つの区分に分かれます。区分ごとに根拠となる法令も保存年限も違うため、同じ画面にまとめて置くと後段の保存設計で必ず破綻します。

誤解が起きやすいのは上から二つの関係です。法律が義務づけているのは一段目の労働条件の明示であって、二段目の雇用契約書ではありません。雇用契約書は双方の合意を残すために実務で交わしている書面で、多くの会社は明示事項を書き込んで一枚に兼ねています。兼ねる場合は明示の要件がそのまま契約書の要件になる、という順序で考えると設計を誤りません。

電子申請の手前で止まる工程と行政側へ抜けていく工程の境目を引く

五区分のうち、社内で完結するのは上から四つまでです。五つめの資格取得届からは相手が行政機関に変わり、e-Govやマイナポータルの仕様、GビズIDの運用といった別の論点が乗ってきます。健康保険・厚生年金保険の資格取得届は事実発生から5日以内、雇用保険の資格取得届は資格取得の日の属する月の翌月10日までという期限も、社内書類とは別の時計で動きます。雇用契約の所定労働時間と更新条項から誰が加入対象になるかは、雇用保険の加入条件とシステムでの自動判定で扱っています。

要件定義では、この境目に「どの項目が行政側へ渡るか」を明示しておいてください。基礎年金番号や被扶養者の情報は社内回収の段階で集めながら、実際に使われるのは届出の場面です。行政手続き側の対応範囲と接続方式は労務管理システムの電子申請対応とは：義務化の範囲とAPI連携・GビズID運用の判断で扱いました。本記事はこの境目より手前、つまり社内で完結する四区分に絞って進めます。

労働条件明示を電子で行える条件と2024年4月に増えた四つの明示事項

労働条件の明示は労働基準法第15条第1項の義務で、違反には同法第120条第1号により30万円以下の罰金が定められています。原則は書面の交付ですが、2019年4月1日施行の労働基準法施行規則第5条第4項によって、労働者が希望した場合にはファクシミリや電子メール等の送信でも足りることになりました。ただし括弧書きに「出力することにより書面を作成することができるものに限る」という制限が付いています。

労働者本人が希望したことを記録として残す画面と同意ログの持ち方

条文が求めているのは、会社が電子交付を選んだことではなく、労働者が電子で受け取ることを希望したという事実です。ここを口頭確認で済ませている運用が実務ではかなり多く、監督署の調査で説明できません。システム側では、内定者向け画面に受け取り方法の選択肢を置き、選択した日時と選択者を消せない形で残す作りにしておきます。

2024年4月に追加された四項目をテンプレートの差し込み項目にする

2024年4月1日から、明示すべき事項に四つが加わりました。厚生労働省の案内では、就業場所・業務の変更の範囲、更新上限の有無と内容、無期転換申込機会、無期転換後の労働条件と整理されています。一つめは全ての労働者が対象で、全ての労働契約の締結時と有期労働契約の更新のタイミングごとに明示します。残る三つは有期契約労働者が対象です。

設計上で効いてくるのは、一つめの「変更の範囲」です。従来は雇入れ直後の就業場所と業務内容だけを書けば足りていたのが、将来的に変更されうる範囲まで示すことになりました。これを全社共通の固定文にすると実態と合わなくなり、社員ごとの自由入力にすると記載のばらつきが出ます。雇用区分や職種ごとに文言のパターンを持たせ、差し込みで組み立てる作りが現実的な落とし所になります。

残る三つは、通算契約期間が5年を超えて無期転換申込権が発生する更新のタイミングでのみ必要です。入社時点では出番がないものの、入社時に通算開始日を正しく記録しておかないと5年後に権利発生を検知できません。入社手続きの画面に持たせる項目は、この通算開始日だと考えてください。

SNSやチャットでの明示が実務で採れない理由と到達確認の残し方

条文の文言は「電子メール等」で、SNSのメッセージ機能なども形式上は含まれます。それでも実務で採用しにくいのは、出力して書面を作成できるかどうかの担保が弱いからです。本文に条件を直接書き込む形式だと、投稿の削除で後から再現できなくなる恐れがあります。PDFを添付する形にして、添付ファイルそのものを保存領域に残してください。

雇用契約書の電子署名は当事者型と立会人型で推定効の条件が変わる

労働条件通知書の電子交付が整理できたら、次は雇用契約書をどう締結するかです。ここで「電子契約サービスを入れるべきか」と製品の話に飛んでしまいがちですが、その前に必要な証拠の水準を決めるほうが順序として先になります。

締結の頻度が高くなるのは、定年後の再雇用で1年ごとに契約を更新する場合です。更新のたびに書面を郵送している企業は、高年齢者雇用安定法にもとづく継続雇用制度の運用とあわせて電子交付の範囲を決めておくと手戻りが出ません。

雇用契約書そのものには法律上の交付義務がないという前提から考える

労働基準法が義務づけているのは労働条件の明示であって、雇用契約書という書面の作成ではありません。雇用契約は口頭でも成立します。それでも書面を交わすのは、労働条件に合意したという事実を後から示すためです。つまり雇用契約書に求められるのは法定要件の充足ではなく、争いになったときに合意の存在を立証できるかどうかという一点になります。

当事者型と立会人型のどちらを選ぶかは入社する側の負担で決まる

電子署名には、本人が自分の電子証明書で署名する当事者型と、サービス事業者が利用者の指示を受けて署名する立会人型があります。企業間契約であれば当事者型を選ぶ場面もありますが、雇用契約では入社予定者に電子証明書を用意させることになるため現実的ではありません。実務で使われているのはほぼ立会人型です。

立会人型でも法的な効力は問題になりません。電子署名法第3条の推定効について、2020年9月4日付で総務省・法務省・経済産業省から示されたQ&Aでは、利用者の指示に基づき事業者が行う電子署名であっても、二要素認証等によって利用者の意思が確認され、事業者の行う措置に固有性が認められる場合には第3条が適用され得るとの見解が示されました。裏を返すと、メールアドレスの確認だけで署名できる設定では推定効の根拠が弱くなります。方式ごとの違いは契約書の電子署名とは？当事者型・立会人型の選び分けと署名のやり方【2026年時点】で詳しく整理しました。

電子署名を使わずシステム上の同意記録だけで足りる場面の線引き

労務管理システムの標準機能には、契約内容を画面に表示して同意ボタンを押させる方式が入っていることがあります。これは電子署名ではないため第3条の推定効は働きませんが、合意の証拠として無価値というわけでもありません。表示した契約文面のスナップショット、同意した日時、操作した端末やIPアドレス、本人認証の方式が揃っていれば、事実上の立証は可能です。

線引きの目安は、契約条件の個別性と紛争時の金額です。定型の就業条件で入社する一般社員は同意記録で運用し、個別条件を持つ層だけ電子署名サービスへ回すという二本立てが、費用と手間の面では収まりがよくなります。二本立てにする場合は、どちらの経路を通ったかを社員台帳の属性として持たせておいてください。電子契約そのものの仕組みは電子契約とは？仕組み・電子署名法による法的効力・書面契約との違いを解説にまとめています。

入社書類の回収を本人入力で受けるときの設計とマイナンバーの分離

明示と締結が終わると、次は入社書類の回収です。工数がいちばん膨らむのがこの工程で、紙で集めている会社では入社1名あたり数時間が消えていきます。転記が発生するのも、書類の不備で差し戻しが起きるのもここです。

本人入力に回してよい項目と会社側で確定させる項目を切り分ける

本人しか知らない情報は本人入力に回すのが基本です。氏名の正式表記、住所、生年月日、扶養親族の情報、給与振込口座、通勤経路と定期代、緊急連絡先が該当します。一方で、社員番号、所属部署、雇用区分、給与体系、入社日は会社側が確定させる項目で、本人入力の画面に出すべきではありません。

差し戻しの多くは、本人が判断できない項目を本人に書かせているところから生まれます。フォームの項目一覧を作る段階で、各項目に「本人」「会社」のどちらかを必ず振ってください。

マイナンバーは同じ画面で集めず取得経路と保存先の権限を分ける

マイナンバーは番号法上の特定個人情報で、他の個人情報とは扱いが分かれます。取得時には番号確認と身元確認の両方が必要で、収集した後は事務取扱担当者以外が閲覧できない状態にしなければなりません。ところが本人入力フォームを一枚で作ると、住所や口座と同じ画面に番号欄が並び、人事部の誰もが見える権限設計になってしまいます。

回避策は、番号の入力を別のフォームに切り出し、保存先も権限も分けることです。多くの労務管理システムはマイナンバー専用の格納領域を持っていて、閲覧には追加認証を求める作りになっています。この領域が用意されているか、閲覧履歴が取得できるか、退職者の番号を保管期限の到来時に削除できるかの三点は、製品選定で必ず確認しておく項目です。

扶養控除等申告書を電子で受け取るときの承認の要否と保存の扱い

給与所得者の扶養控除等申告書を電子データで受け取る場合、かつては税務署長の承認が必要でした。令和3年度の税制改正により、2021年4月1日以後に提出する源泉徴収関係書類については、この承認が不要になっています。年末調整関係の申告書も同じ扱いです。古い解説記事には承認が必要と書かれたままのものが残っているため、社内規程を作るときは現行の扱いで確認してください。

人事給与と勤怠へのデータ引き渡しで決める項目対応と締めの扱い

入社書類を集めきったら、そのデータを給与計算と勤怠管理へ渡します。ここを人手の転記で埋めている限り、前工程をどれだけ電子化しても総工数は下がりません。要件定義では、渡す項目と渡す方式とタイミングの三つを具体的に決めます。

社員番号を採番する側をどのシステムにするかで連携の向きが決まる

最初に決めるのは社員番号の採番元です。労務管理システムで採番して給与へ渡す方式と、既存の人事給与システムで採番して労務側が受け取る方式があり、どちらを採るかで連携の向きが変わります。採用管理システムを併用している会社では、応募者IDから社員番号へ切り替わる地点も決めておく必要があります。

採番元が決まっていないまま並行導入すると、同じ人に二つの番号が振られて突合作業が発生します。既存の給与システムを残す前提なら、そちらを採番元にして労務側が従う構成のほうが移行時の事故は少なくなります。給与計算側の機能範囲は給与計算システムとは？機能・種類・比較の観点から個別開発の判断まで解説で扱いました。

月の途中に入社した人の情報が給与の締め日をまたぐときの受け渡し

入社日は月初とは限りません。月の途中に入社した人の給与は日割り計算になり、勤怠の集計期間も入社日から締め日までの短い期間になります。ここでデータの到着が給与計算の締めに間に合わないと、初回給与が翌月へ繰り越されて本人からの問い合わせが発生します。

設計としては、給与計算の締め日から逆算した「労務側の確定期限」を運用ルールではなくシステムの制御として持たせるのが有効です。期限を過ぎた登録は次回反映へ回すという扱いを明示しておけば、担当者間の口頭調整が減ります。勤怠側の集計期間の考え方は勤怠管理システムとは？機能・種類・費用と失敗しない選び方を解説【2026年】にまとめてあります。

CSV連携とAPI連携で運用の手間が逆転する入社件数のめやす

連携方式はCSVの受け渡しかAPIによる自動連携のどちらかです。導入費用はCSVのほうが明らかに安く、月に数名の入社であればCSVで十分に回ります。手間が逆転するのは、入社が月に十数名を超えたあたりからです。ファイルの作成、取り込み、エラー行の修正という三手が毎回発生し、担当者一人分の時間を食い始めます。

保存年限の設計は労働関係書類の五年と税務書類の七年が混在する

入社手続きで集めた書類は、集めて終わりではありません。年限を過ぎたら消せる状態にしておくところまでが設計です。ここを詰めずに導入すると、退職者のデータが十年分たまり続ける運用になります。

労働関係の重要書類は五年で当分の間は三年という二段構えになる

労働基準法第109条は、労働者名簿、賃金台帳、雇入れ、解雇、災害補償、賃金その他労働関係に関する重要な書類を5年間保存すると定めています。ただし同法附則第143条第3項に経過措置があり、当分の間は3年間と読み替えることになっています。賃金請求権の消滅時効が2年から5年へ延びたことに合わせた改正で、経過措置の解除時期は現時点で示されていません。

実務では5年で設計しておくほうが安全です。3年で消す設定にしておくと、経過措置が解除されたときに設定変更だけでなく、すでに消したデータの説明が必要になります。起算日にも注意してください。労働者名簿は死亡・退職・解雇の日が起点で、入社日ではありません。

扶養控除等申告書だけ七年で年限が違うので保存先を別々に分ける

先に触れたとおり、扶養控除等申告書の保存期間は7年間です。労働関係書類の5年と税務関係書類の7年が同じフォルダに混ざっていると、削除処理を一括で回せません。区分ごとに保存領域を分け、それぞれに年限の属性を持たせる構造にしておくと、後から自動削除を組めます。

紙で残っている過去分の扱いは別問題として切り出してください。既存の紙書類を電子化する場合は、電子帳簿保存法のスキャナ保存要件が絡む書類とそうでない書類が混在します。判断の手順は契約書を電子化するには？スキャナ保存の要件と電子契約への移行手順【2026年時点】で整理しました。

退職者のデータをいつ消すかという規則まで入社時の設計に含める

削除設計を後回しにする会社が多いのは、入社時点では困らないからです。困り始めるのは導入から数年後で、そのころには誰も設計意図を覚えていません。入社手続きの要件定義の段階で、区分ごとの年限と起算日、削除の実行方法、削除記録の残し方までを一枚の表にしておいてください。

パッケージで足りる条件と連携開発や個別開発へ回す条件の分かれ目

ここまでの要件を並べたうえで、市販の労務管理システムをそのまま使えるかを判断します。判断材料は機能一覧の多寡ではなく、自社の運用が標準機能の想定からどれだけ外れているかです。

パッケージの標準機能のままで入社手続きが回る会社に共通する条件

標準機能のままで収まっている会社には、共通する条件が四つあります。第一に雇用形態が正社員中心で、契約書の書式が一種類か二種類に収まっていること。第二に給与計算と勤怠を同じベンダーの製品で揃えているか、標準連携が用意された組み合わせであること。第三に拠点ごとの独自ルールがなく、入社手続きの流れが全社で共通していること。第四に月あたりの入社が数名規模で、CSVの受け渡しでも運用が破綻しないことです。

雇用形態が三つ以上ある会社は書式の分岐で標準機能から外れていく

正社員、契約社員、パート・アルバイト、嘱託、再雇用と雇用形態が増えると、労働条件通知書の書式も無期転換に関する記載の要否も変わります。標準機能のテンプレート機能で吸収できる範囲を超えると、担当者が手作業でファイルを差し替える運用に戻ってしまいます。

この場合に検討するのは、システムを丸ごと個別開発することではありません。回収と承認のフローを自社の分岐に合わせて組み、書類生成の部分だけを外部の帳票基盤や電子契約サービスに接続する構成のほうが、費用と保守の両面で収まります。人事労務の業務範囲そのものの整理は労務管理とは？仕事内容の範囲と人事管理との違い・システム化の進め方を解説を参照してください。

既存の人事給与を残したまま入社手続きだけを先に載せていく順序

基幹の人事給与システムを入れ替えるとなると、稼働は年単位の話になります。入社手続きだけを先に切り出して載せる進め方なら、既存システムを触らずに数か月で回せます。渡すのは確定した社員マスタのデータだけで、接続点も一つに限定できるのが利点です。

順序としては、労働条件明示の電子交付、入社書類の本人入力による回収、給与側へのデータ引き渡し、電子署名の順で並べるのが無理のない形です。最初の二つで工数削減の効果が出るため、社内の合意も取りやすくなります。電子署名を最後に置いているのは、法務や経営層の判断が絡んで日程が読みにくいからです。先に置くと全体が止まります。

よくある質問

労働条件通知書と雇用契約書は両方必要ですか？

法律上の義務は労働条件通知書にあたる明示だけで、雇用契約書の作成は義務ではありません。実務では明示事項を盛り込んだ「労働条件通知書兼雇用契約書」を一枚にして双方が記名する形が多く採られています。一枚にする場合は明示事項の記載漏れがそのまま法違反になるため、テンプレートの項目チェック機能の有無を確認しておいてください。

労働条件をメールで送るだけで明示したことになりますか？

本人が電子での受け取りを希望している場合に限り、明示したことになります。会社の判断で一方的に送る運用は条文の要件を満たしません。加えて出力して書面を作成できる形式である必要があるため、本文に条件を書き込むだけでなくPDF等の添付にしておいてください。

電子署名がない同意ボタンだけの雇用契約は無効ですか？

無効ではありません。雇用契約は口頭でも成立するため、同意ボタンによる合意も契約としては有効です。違いが出るのは争いになったときの立証で、電子署名法第3条による真正な成立の推定が働くかどうかという点になります。同意日時、表示した文面、本人認証の方式が記録として残る作りであれば、実務上の立証は可能です。

入社書類の回収に使うシステムはマイナンバー対応が必須ですか？

入社手続きの中でマイナンバーを扱う以上、対応していない製品を選ぶと収集経路を別に用意することになります。専用の格納領域、閲覧権限の分離、閲覧履歴の取得、保管期限到来時の削除の四点が揃っているかで判断してください。

派遣社員やアルバイトも同じ手続きの流れで進められますか？

アルバイトは基本的に同じ流れで進められますが、有期契約であれば更新上限と無期転換に関する明示事項が加わります。更新のたびに発生する期限をどう検知して誰へ通知するかは労務管理システムで契約社員の更新日を通知する機能の設計で扱っています。派遣社員は自社が雇用主ではないため対象外です。派遣元との個別契約や就業条件明示書は別の管理になるので、同じ台帳に載せない前提で設計してください。

関連記事

• 労務管理システムとは？機能・勤怠管理との違いと比較の観点・個別開発の判断軸を解説【2026年】：システム全体の機能範囲と選定の観点です。
• 労務管理システムの電子申請対応とは：義務化の範囲とAPI連携・GビズID運用の判断：行政への届出側の対応範囲です。
• 契約書の電子署名とは？当事者型・立会人型の選び分けと署名のやり方【2026年時点】：署名方式ごとの効力の違いです。
• 契約書を電子化するには？スキャナ保存の要件と電子契約への移行手順【2026年時点】：既存の紙書類を電子化する手順です。
• 給与計算システムとは？機能・種類・比較の観点から個別開発の判断まで解説：引き渡し先となる給与側の機能です。