--- title: "大企業の人事管理システムの選び方：グループ人事マスタ・発令履歴・給与とID連携の要件" url: "https://www.issoh.co.jp/column/details/18559/" published: 2026-10-19 updated: 2026-10-19 categories: ["人事労務"] publisher: "株式会社一創" --- # 大企業の人事管理システムの選び方：グループ人事マスタ・発令履歴・給与とID連携の要件 大企業の人事管理システム選びは、製品の機能一覧を見比べても決まりません。差が出るのは、グループ会社・多拠点・兼務や出向を抱えた組織を、1つの人事マスタでどう表現できるかという点です。本稿では、会社コードと個人IDの持ち方、発令の有効日付と履歴、人的資本開示と女性活躍推進法の公表義務に耐える集計、給与・勤怠・ID基盤との連携方向、権限分離と操作ログを順に整理します。最後に、パッケージで足りる大企業と開発を検討すべき大企業の境界を示す構成です。人事管理システムの定義や種類は[人事管理システムとは？機能・種類・労務やタレマネとの違いと導入判断](https://www.issoh.co.jp/column/details/15518/)で扱っています。 ## まとめ：大企業の人事管理システムは人事マスタの持ち方と連携の設計で決まる 結論から書きます。大企業の人事管理システムで最初に確かめるべきなのは、画面の使いやすさや評価機能ではありません。会社をまたいでも同じ人を同じ人として追えるか、過去の任意の日付時点の組織と所属を再現できるか、の2点です。この2点を満たせない製品は、グループ再編や開示対応のたびに手作業の集計が増えます。 連携は人事マスタを起点にした一方向を原則とし、給与・勤怠・評価・アカウント管理へ配ります。権限は会社・組織・項目の3軸で切り、システム管理者と人事データの閲覧者を分けてください。 パッケージの標準の組織モデルに自社の制度を寄せられるなら、パッケージで十分です。会社ごとに制度が違い、再編が続く場合は、パッケージを中核に置いたうえで連携やグループ集計の部分だけを開発する構成を比べます。 ## 大企業の人事管理システムが中小企業向けと違うのは人数より組織の複雑さ 従業員5,000人でも単一法人・単一拠点なら、人事データの構造は中小企業とそれほど変わりません。要件を押し上げるのは人数ではなく、組織の重なり方です。 ### 従業員数ではなく会社数・事業場数・雇用区分の掛け算で要件が増える 大企業の人事データは、会社数×事業場数×雇用区分の組み合わせで複雑になります。持株会社の下に10社、各社に5〜20の事業場、正社員・契約社員・嘱託・出向受入の4区分があれば、同じ「所属」でも数百通りの組み合わせが生まれます。 [労働基準法](https://laws.e-gov.go.jp/law/322AC0000000049)107条は労働者名簿を事業場ごとに作るよう求めており、記入事項は[労働基準法施行規則](https://laws.e-gov.go.jp/law/322M40000100023)53条に定められています。グループ全体で1つのデータベースを持っても、出力は事業場単位で切り出せなければなりません。中小企業での人数ラインごとの要件は[人事管理システムを中小企業が選ぶ基準](https://www.issoh.co.jp/column/details/18552/)で整理しています。 ### 人的資本開示と女活法・育介法の公表義務が人事データの粒度を決める 上場企業では、2023年1月の[企業内容等の開示に関する内閣府令等の改正](https://www.fsa.go.jp/news/r4/sonota/20230131/20230131.html)により、令和5年3月31日以後に終了する事業年度の有価証券報告書から、女性管理職比率・男性の育児休業取得率・男女間賃金格差の記載が求められています。対象は、提出会社と連結子会社のうち女性活躍推進法などで公表している会社です。 公表義務の範囲も広がりました。男性の育児休業取得率等の公表は、[2025年4月から300人超1,000人以下の企業にも義務化](https://www.mhlw.go.jp/content/11909000/001029776.pdf)されています。改正女性活躍推進法では、[2026年4月1日から101人以上の企業に男女間賃金差異と女性管理職比率の公表](https://www.mhlw.go.jp/web%5Fmagazine/series/20260220.html)が義務付けられました（2026年10月時点）。 グループ各社がそれぞれの人数で義務の有無が分かれ、親会社は連結で記載を求められます。人事管理システムには、会社別・雇用区分別・役職区分別に、期末時点の在籍者を正確に数え直せる粒度が必要です。開示の全体像は[人的資本経営とは？意味・開示義務・実践ステップ](https://www.issoh.co.jp/column/details/13383/)を参照してください。 ## グループ会社と多拠点を一つの人事マスタで扱うためのデータ設計要件 製品の説明資料に「グループ一元管理」と書かれていても、内部のデータ構造は製品ごとに違います。選定時には次の4点を、デモ環境で実際のケースを入力して確かめてください。 ### 従業員番号と会社コードを分け、転籍しても同一人物として追える設計 多くの企業は会社ごとに従業員番号を採番しています。A社からB社へ転籍すると番号が変わり、システム上は退職者1人と入社者1人になってしまいます。これでは勤続年数の通算も、グループ内の異動履歴の集計もできません。 確認すべきは、会社をまたいで不変の個人IDと、会社ごとの従業員番号を別の項目として持てるかどうかです。個人IDを持てない製品では、転籍のたびに過去データの紐付けを人手で直すことになります。 ### 発令の予約と有効日付で組織改編と異動の履歴を後から再現できる構造 大企業の4月1日付の定期異動では、数百〜数千件の発令を3月中に登録し、当日に一斉に有効化します。組織改編も同じ日に重なることが多く、部署の新設・統合・廃止と人の異動を同時に扱う必要があります。 ここで問われるのが、所属や役職を「有効開始日と有効終了日を持つ履歴」として保存しているかどうかです。上書き型の製品では、昨年3月末時点の組織図や管理職数を再現できません。前の章で触れた開示指標は期末時点の数字なので、履歴型であることは必須条件と考えてください。 ### 兼務・在籍出向・海外赴任を1人に複数の所属として持てる表現力の確認 大企業では、1人が本務と兼務で2つ以上の部署に属することが珍しくありません。在籍出向では、出向元と出向先の両方と雇用関係が続きます。海外赴任では、日本の法人に籍を残したまま現地法人で勤務する形もあります。 1人に所属を1つしか持てない製品では、こうした人を「備考欄」で管理することになり、集計から漏れます。本務・兼務・出向の区分つきで複数の所属を持てること、そして集計時にどの所属で数えるかを選べることを確かめてください。 ### 事業場単位の労働者名簿と会社単位の開示集計を同じデータから出す 労働者名簿は事業場単位、女性活躍推進法の公表は企業単位、有価証券報告書は連結単位です。同じ人事マスタから、単位の違う3種類の出力を作れることが求められます。 実務でつまずくのは、出向者をどちらの会社で数えるかという定義です。システムの機能よりも先に、グループとしての集計ルールを文書で決めておく必要があります。ルールが決まっていれば、多くのパッケージはレポート設定で対応できます。 ## 給与・勤怠・ERP・ID基盤との連携は人事マスタを起点に方向を決める 大企業では、人事管理システムが単独で動くことはまずありません。給与計算、勤怠、評価、会計・ERP、アカウント管理のそれぞれと、どちらが正のデータを持つかを決めることが連携設計の出発点です。 ### 人事マスタを正とし給与・勤怠・評価へ配る一方向連携の原則と例外 原則は、氏名・所属・役職・雇用区分などの基本情報を人事マスタで一元的に更新し、他のシステムへ配る一方向の流れです。給与側や勤怠側で所属を直接書き換えられる運用にすると、どちらが正しいか分からないデータが必ず生まれます。 例外は、勤怠の実績や評価結果のように、相手側で発生するデータです。これらは人事マスタへ戻す方向で連携します。勤怠側の要件は[大企業の勤怠管理システムとは？多拠点・複数就業規則・人事連携に強い選び方](https://www.issoh.co.jp/column/details/18248/)、評価側の多階層承認は[人事評価システムを大企業に導入するには？](https://www.issoh.co.jp/column/details/15751/)で解説しています。 ### SCIMの企業拡張スキーマで入社・異動・退職をアカウントへ反映する 入社日にメールや業務システムのアカウントを用意し、退職日に止める処理は、人事マスタとID基盤の連携で自動化できます。標準仕様の[RFC 7643（SCIM Core Schema）](https://datatracker.ietf.org/doc/html/rfc7643)は4.3節で企業向けの拡張スキーマを定めており、人事マスタの項目と次のように対応づけられます。 | 人事マスタの項目 | SCIM企業拡張の属性 | 使い道 | | -------- | -------------- | ---------- | | 従業員番号 | employeeNumber | 人とアカウントの照合 | | 原価センター | costCenter | ライセンス費の配賦 | | 会社名 | organization | グループ会社の区別 | | 本部・事業部 | division | 権限グループの付与 | | 部署 | department | 部署単位の共有設定 | | 上長 | manager | 承認者の自動設定 | 属性名がそろっていても、発令の有効日付に合わせて送れるかは製品次第です。4月1日付の異動を3月中にID基盤へ送ってしまうと、前日まで旧部署の権限が使えなくなります。SCIMの仕組みは[SCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装](https://www.issoh.co.jp/tech/details/15876/)、ID基盤側の選び方は[IDaaSとは？SSO・IdPとの違い](https://www.issoh.co.jp/tech/details/16401/)が詳しく扱っています。 ### 連携方式はAPI・ファイル・iPaaSを更新頻度と件数で選び分ける 連携方式は、更新の頻度と1回あたりの件数で決めます。入退社や異動のように1日数件〜数十件で即時性が求められるものはAPI連携が向きます。給与計算のように月1回、数千件をまとめて渡すものは、CSVなどのファイル連携でも困りません。 連携先が10を超える場合は、個別に作り込むよりiPaaS（連携基盤サービス）で中継したほうが保守しやすくなります。ただし、iPaaSで変換ロジックを書き込みすぎると、仕様を知る人がいなくなった時点で誰も直せなくなります。変換は単純な項目対応に留め、業務ルールは人事マスタ側に持たせるのが安全です。 ## 権限分離と監査で大企業の人事管理システムに求める具体的な統制の水準 人事データには、評価・給与・健康情報・家族情報などが含まれます。利用者が数百人規模になる大企業では、誰がどこまで見られるかの設計がそのまま情報漏えいのリスクの大きさになります。 ### 会社・組織・項目の3軸で閲覧範囲を切る権限設計と管理者の分離 大企業の権限設計は、どの会社のデータか、どの組織配下の人か、どの項目か、の3軸で考えます。たとえば子会社の人事担当者は自社の全員の基本情報を見られても、給与と評価は見られない、という切り方です。部門長は自部門の評価は見られても、家族情報は見られません。 もう1つの論点は、システム管理者の分離です。設定を変更できる情報システム部門の担当者が、人事データの中身まで閲覧できる状態は避けてください。製品が「設定権限」と「データ閲覧権限」を別に付与できるかを確かめます。マイナンバーと健康情報の区分、クラウドや保守が委託に当たるかの線引きは[人事管理システムのセキュリティ要件](https://www.issoh.co.jp/column/details/18561/)で解説しています。 ### 個人情報保護委員会ガイドラインの安全管理措置と操作ログの保存期間 [個人情報保護委員会のガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)は、10-6の技術的安全管理措置で「アクセス制御」と「アクセス者の識別と認証」を挙げています。10-3の組織的安全管理措置では、個人データの取扱状況を確認する手段として、ログイン実績やアクセスログを例示しています。 選定時には、閲覧の記録まで残るのか、更新の記録だけなのかを確認してください。誰がいつ誰の給与を見たかを後から追えないと、漏えいが疑われたときに範囲を特定できません。ログの保存期間と、監査担当者がログを検索できる画面の有無も比較項目に入れます。 ## 大企業がパッケージで足りる条件と人事システム開発を選ぶ境界線 大企業向けの人事管理システムには、国産の人事給与パッケージから海外のHCMスイートまで選択肢があります。製品ごとの違いは[人事管理システムの比較](https://www.issoh.co.jp/column/details/18550/)に譲り、ここでは「パッケージで足りるか」の線引きを言い切ります。 ### 標準の組織と発令のモデルに制度を寄せられるならパッケージを選ぶ グループ各社の等級・発令種別・雇用区分をそろえられる、あるいはそろえる方針が経営で決まっているなら、パッケージを選んでください。前述の有効日付つきの履歴、複数所属、3軸の権限は、大企業向けの主要製品なら標準で備えていることが多く、作る理由がありません。 制度を変えずに製品を自社に合わせる追加開発（アドオン）は、バージョンアップのたびに改修費がかかります。アドオンが画面や帳票の数十本に及ぶ見積りが出たら、制度側を変える案と並べて比べるべきです。 ### グループ再編が続き会社ごとに制度が違うなら周辺の開発を検討する M&Aで子会社が毎年増える、買収した会社の制度をすぐには統一できない、という企業では、各社が別々の人事システムを使い続ける期間が数年単位で続きます。この場合、全社を1つの製品に載せ替えるより、各社のシステムからデータを集めるグループ人事データベースと、開示用の集計を開発するほうが早く効果が出ます。 人事マスタの中核はパッケージ、連携とグループ集計は開発、という分担です。既存の人事・給与パッケージを残したまま連携やグループ集計の部分を作る構成を検討する場合は、一創の[人事・労務管理システム開発](https://www.issoh.co.jp/service/business%5Fsystem/hr-management/)で要件の整理から相談できます。 ### 全面スクラッチで作り直すのを見送るべき場面と失敗しやすい進め方 人事管理システム全体をゼロから作るのは、ほとんどの大企業で見送るべき選択です。給与計算や社会保険の手続きは法改正のたびに改修が必要で、その保守を自社で背負うことになるからです。給与計算を含む範囲を作る判断については[給与計算システムとは？](https://www.issoh.co.jp/column/details/15383/)で整理しています。 失敗しやすいのは、現行の帳票と画面をすべて再現する要件定義から始める進め方です。現行の運用を写し取ると、制度の見直しの機会を失い、アドオンの量も膨らみます。もう1つは、グループ各社の合意を取らずに親会社の制度で要件を固めることです。子会社での導入段階で例外が噴き出します。 ## 大企業で人事管理システムを選定・移行するときの手順と期間の目安 大企業の人事管理システムの導入は、選定から全社展開まで1年以上かかることが珍しくありません。期間を延ばす要因の多くは、製品の操作ではなく制度とデータの整理です。 ### 要件定義はグループ各社の人事制度と発令種別の棚卸しから始める 最初の作業は、グループ各社の等級体系・雇用区分・発令種別（昇格・異動・兼務・出向・転籍など）を一覧にすることです。会社ごとに呼び名が違うだけで中身が同じものと、本当に違うものを分けます。 1. 各社の人事制度規程と発令の実例を集め、項目の一覧表を作る 2. グループ共通のコード体系（会社・組織・等級・雇用区分）を決める 3. 出向者や兼務者をどの会社・どの所属で数えるかの集計ルールを文書化する 4. この一覧を製品のデモ環境に入力し、表現できない項目を洗い出す 手順4で表現できない項目が出たときに、制度を寄せるか、開発で補うかを判断します。費用の見積り方は[人事管理システムの費用：内訳5項目と300名・1,000名の5年総額](https://www.issoh.co.jp/column/details/18556/)を参照してください。 ### 移行は会社単位の段階展開とし、給与の締め・年末調整の時期を外す 全社を同じ日に切り替える一斉移行は避け、親会社か規模の小さい子会社から順に展開します。最初の1社で発令・連携・集計の流れを一巡させてから、残りの会社へ広げる順番です。 切り替えの時期は、4月の定期異動、7月の算定基礎届、11月から12月の年末調整を外して決めます。移行するデータは在籍者だけでなく、過去の異動履歴と退職者のうち保存期間内のものを含めるかを最初に決めてください。過去履歴を持ち込まないと、前の章で述べた時点集計が移行前の期間について出せなくなります。 ## よくある質問 大企業の人事管理システムを検討する段階で出やすい疑問に、本文の内容を踏まえて答えます。 ### 大企業向けの人事管理システムとタレントマネジメントシステムは何が違いますか？ 人事管理システムは、所属・役職・発令履歴・雇用区分などの人事の基本台帳を正しく保つための仕組みです。タレントマネジメントシステムは、その台帳の上にスキル・評価・キャリア志向などを重ね、配置や育成を考えるための仕組みです。大企業では、まず人事管理システムで正しい人事マスタを整え、タレントマネジメントはそこからデータを受け取る構成にすると、二重入力が起きません。製品によっては両方を1つで提供しています。 ### グループ会社ごとに別の人事システムを使っていても統合できますか？ 統合できます。ただし、最初から全社を1つの製品に載せ替える必要はありません。会社をまたいで不変の個人IDとグループ共通のコード体系を先に決めれば、各社のシステムからデータを集めてグループ単位の人事データベースを作れます。制度の統一が進んだ会社から順に、共通の製品へ移していく進め方が現実的です。 ### 海外子会社の従業員も同じ人事管理システムで管理すべきですか？ 給与や社会保険の手続きは国ごとに制度が違うため、海外子会社の労務は現地のシステムに任せるのが一般的です。日本側で持つべきなのは、氏名・所属・役職・等級などの基本情報と、幹部候補の人材情報です。日本の人事管理システムには基本情報だけを連携し、手続き系は現地に残すという線引きにすると、運用の負担を抑えられます。 ### 人事管理システムの導入にはどのくらいの期間がかかりますか？ グループ会社が複数ある大企業では、選定から全社展開まで1年以上かかることが多くなります。期間を左右するのは、グループ各社の制度とコード体系の整理です。1社目で発令・連携・集計の流れを一巡させ、残りの会社は1社目で作った手順を使って段階的に広げます。4月の定期異動や年末調整の時期を避けると、切り替え日の候補は年に数回に絞られます。 ### 人事管理システムの費用は大企業でどのくらいを見込めばよいですか？ クラウド型は従業員1人あたりの月額課金が中心で、人数に比例して費用が増えます。大企業では、これに初期設定・データ移行・連携開発・アドオンの費用が加わり、ライセンス費より導入費のほうが大きくなる場合もあります。比較するときは5年間の総額で見て、アドオンの改修費も含めてください。人数別の試算は[人事管理システムの費用](https://www.issoh.co.jp/column/details/18556/)で示しています。 ## 関連記事 - [人事管理システムとは？機能・種類・労務やタレマネとの違いと導入判断を開発会社が解説](https://www.issoh.co.jp/column/details/15518/)：人事管理システムの定義と種類から確認したい方向け - [人事管理システムの比較：4タイプの選び分けと公開料金の実額、業種別とオンプレミスの判断軸](https://www.issoh.co.jp/column/details/18550/)：製品タイプ別の違いを比べたい方向け - [人事管理システムを中小企業が選ぶ基準：従業員数で増える法定の人事データとExcel台帳からの段階導入](https://www.issoh.co.jp/column/details/18552/)：子会社など中小規模の会社の要件を確認したい方向け - [人事評価システムを大企業に導入するには？多階層承認・権限管理・基幹連携の要件と選び方](https://www.issoh.co.jp/column/details/15751/)：評価制度側の大企業要件を知りたい方向け - [人的資本経営とは？意味・開示義務・実践ステップを開発会社が解説](https://www.issoh.co.jp/column/details/13383/)：開示義務の全体像を押さえたい方向け --- 出典: [大企業の人事管理システムの選び方：グループ人事マスタ・発令履歴・給与とID連携の要件]()（株式会社一創）