人材派遣とfreee人事労務 派遣先勤怠と雇用側勤怠の二重管理の整理（概念）

人材派遣業のバックオフィスにおいて、最大のボトルネックとなるのが「勤怠データの二重管理」です。派遣スタッフは「派遣先」で指揮命令を受けて働き、その実績は派遣先のタイムカードやシステムに記録されます。しかし、雇用主である「派遣元」は、給与支払いと法遵守のために自社のシステム（freee人事労務など）でその数値を確定させなければなりません。

この「派遣先の実績」と「派遣元の管理」をどう同期させるか。本記事では、freee人事労務を軸に、派遣業界特有の勤怠管理の概念を整理し、実務で即活用できるデータ統合の手順を徹底解説します。

1. 人材派遣業における「勤怠二重管理」の本質的課題

なぜ派遣業では勤怠が複雑化するのでしょうか。それは、一つの労働に対して「管理の目的」が異なる二つの組織が介在するからです。

1.1 派遣元（雇用主）と派遣先（指揮命令者）で発生する情報の非対称性

派遣元は労働契約に基づき給与を支払う義務があり、freee人事労務等のシステムで「法定労働時間」や「残業代」を正しく計算しなければなりません。一方、派遣先は「派遣先管理台帳」の作成義務があり、現場での実労働時間を把握する必要があります。多くの場合、派遣先は独自の紙のタイムシートや、自社導入済みの勤怠SaaSを使用するため、派遣元に届くデータは「確定後の数値」という形になります。この「現場の生データ」と「給与計算用データ」の乖離が、入力漏れや計算ミスの温床となります。

1.2 労働基準法と派遣法が求める「2つの記録」の整合性

労働基準法上の使用者責任は主に派遣元にありますが、休憩や休日、労働時間の制限については派遣先も責任を負います。freee人事労務で給与計算を行う際、派遣先から送られてきたエビデンス（証明書類）とfreee上の勤怠入力値が1分でもズレていれば、それはコンプライアンスリスクに直結します。これを防ぐために、多くの担当者は手入力による「転記」を行っていますが、これこそが「二重管理」の正体です。

2. freee人事労務で派遣スタッフを管理する際の基本設計

freee人事労務で派遣スタッフを管理する場合、まず「誰がどこで、どのような条件で働いているか」をシステム上に定義する必要があります。

2.1 派遣先ごとに「勤務体系」を作成するメリット・デメリット

freee人事労務では「勤務体系」を複数作成できます。派遣先によって「休憩時間（12:00〜13:00、または交代制）」「所定労働時間（7.5時間、8時間など）」が異なる場合、派遣先A用、派遣先B用として勤務体系を分けるのが一般的です。

• メリット：派遣先ごとの労働条件に合わせた残業計算が自動化される。
• デメリット：派遣先が増えるたびに設定作業が発生し、管理が煩雑になる。

小規模な派遣であれば「標準勤務体系」で運用可能ですが、中大規模の場合は、freee会計の「部門」や「メモタグ」と連動させ、コストセンター（どの派遣先で発生した給与か）を明確にすることが不可欠です。このあたりの設計思想は、下記の記事で解説している「部門別配賦」の概念と密接に関係します。

【完全版】給与ソフトからfreee会計への「部門別配賦」と仕訳連携。労務と経理の分断を解決するアーキテクチャ

2.2 freee標準打刻を利用する場合の運用フロー

派遣スタッフにfreee人事労務のモバイルアプリやPCブラウザで直接打刻させる方法です。この場合、派遣元の管理画面にはリアルタイムで勤怠が反映されます。ただし、派遣先が「自社の打刻機を使ってほしい」と要求する場合、スタッフは「派遣先の打刻」と「freeeの打刻」を2回行う必要があり、利便性が著しく低下します。

3. 派遣先勤怠データをfreee人事労務へ統合する3つの手法

実務上、最も現実的なのは「派遣先の実績を、いかに少ない工数でfreeeに取り込むか」という視点です。

3.1 【パターンA】派遣先の実績をCSVインポートで一括反映

多くの派遣先から月次で届くCSVデータを、freee人事労務のインポート形式に加工して取り込む手法です。

• 対象：派遣先が独自の勤怠システム（自社開発や古いパッケージ等）を利用している場合。
• 工数：月1回のインポート作業。
• メリット：追加のシステム利用料がかからない。

3.2 【パターンB】外部勤怠SaaSをハブにしたAPI連携

KING OF TIMEやAKASHIといった、派遣管理に強い勤怠管理SaaSを利用し、そこからfreee人事労務へAPIでデータを飛ばす手法です。

• 対象：派遣スタッフ数が多く、リアルタイムな残業管理が必要な場合。
• メリット：打刻データの自動同期が可能。派遣先ごとの複雑な丸め計算にも対応しやすい。

複数のSaaSを組み合わせる際は、アカウント管理が課題となります。退職者の削除漏れなどはセキュリティ上の大きなリスクとなるため、下記のアーキテクチャを参考に自動化を検討すべきです。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

3.3 【パターンC】freee人事労務の「権限管理」を活用した直接打刻

派遣先の担当者にfreeeの「承認者」権限、あるいは特定の閲覧権限を与え、直接システム上で実績を確認してもらう方法です。ただし、派遣先企業が他社のシステムにログインすることを嫌がるケースが多く、導入ハードルは高いと言えます。

4. 実務ステップ：派遣先CSVをfreee人事労務に取り込む具体手順

ここでは、最も汎用性が高い「パターンA：CSVインポート」の具体的な流れを解説します。

4.1 派遣先フォーマットからfreeeインポート用フォーマットへの変換

派遣先から提供されるCSVは、列順もヘッダー名もバラバラです。freee人事労務が受け付けるインポート形式（従業員番号、日付、出勤時間、退勤時間、休憩時間など）に成形する必要があります。

実務のヒント： ExcelのVLOOKUP関数やパワークエリ、あるいはGoogle WorkspaceのAppSheetなどを活用して、派遣先ごとのフォーマットをfreee形式に自動変換する「変換シート」を1つ作っておくのが定石です。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

4.2 freee人事労務での「勤怠データ取り込み」手順

1. freee人事労務のメニューから［勤怠］→［勤怠データ取り込み］を選択。
2. 「一括インポート」用テンプレートに合わせて作成したCSVを選択してアップロード。
3. エラー対応： よくあるエラーは「従業員番号の不一致」と「時刻形式の誤り（25:00等の表記）」です。freeeは原則として HH:MM 形式を求めます。
4. プレビュー画面で合計時間と派遣先からの報告値が一致しているか確認し、確定。

4.3 確定後の給与計算・仕訳連携への流れ

勤怠が確定すれば、freee人事労務上で給与計算ボタンを押すだけで、残業代や各種手当が自動算出されます。ここで算出された給与データは、freee会計に「給与手当」として自動で仕訳が飛びますが、派遣業の場合は「どのプロジェクト（派遣先）の売上原価か」を紐付ける設定が重要です。

5. 勤怠管理SaaS別・freee連携相性比較表

派遣元としてどの勤怠管理システムを選ぶべきか、主要なSaaSとfreee人事労務の親和性を比較しました。

※料金・仕様は変更される可能性があるため、必ず各社公式サイトの最新情報をご確認ください。

6. 運用上の落とし穴とセキュリティ対策

システムを繋ぐだけでは解決しない、実務上の注意点があります。

6.1 36協定・残業アラートの基準はどちらに置くべきか

派遣先での残業が法定時間を超えそうな場合、アラートが出るのは「派遣先のシステム」であることが多いです。しかし、派遣元も36協定遵守の責任があるため、freee人事労務に月次でまとめてデータを入れる運用では、「月末にインポートしたら実は超過していた」という手遅れ状態になりかねません。週次でのインポート、あるいは外部勤怠SaaSでのリアルタイム監視を推奨します。

6.2 派遣先管理台帳とfreeeデータの突合チェック

派遣法で定められた「派遣先管理台帳」には、始業・終業時刻、休憩時間を1日ごとに記載する必要があります。freee人事労務から出力した勤怠一覧が、そのまま台帳の要件を満たしているか（あるいは加工可能か）を事前に社労士等の専門家と確認しておくべきです。

7. まとめ：二重管理を「一元管理」に変えるためのロードマップ

派遣業における勤怠管理の最適解は、「現場の打刻」と「給与計算」の間のデータ移動をいかに無人化するか、に集約されます。

1. フェーズ1： 派遣先から届くデータの形式を把握し、freee人事労務へのCSVインポートをルーチン化する。
2. フェーズ2： CSV変換をAppSheetやパワークエリで自動化し、手作業による転記・加工ミスを排除する。
3. フェーズ3： スタッフ数や派遣先が増大したタイミングで、API連携可能な外部勤怠SaaSへの移行を検討する。

freee人事労務は、単なる給与計算ソフトではなく、バックオフィス全体のハブとして機能します。勤怠データの流れを整理し、二重管理のストレスから解放されることで、派遣スタッフのフォローや新規案件の開拓といった、より創造的な業務にリソースを割くことが可能になります。