JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 19 min read

SAP SF 従業員管理

Employment（雇用）は、個人が法的エンティティ（Legal Entity）と結ぶジョブまたは契約関係を表すマスタデータオブジェクトであり、個人のグローバルな経歴情報を表すPerson（SF-A04-01で説明）や、両者を基に構築された集約読み取りビューであるEmployee Profile（SF-A04-03）とは区別されます。Personが意図的に浅く安定した構造であるのに対し、Employmentは運用上の詳細が格納されるレコードであり、入社日（Hire Date）、雇用タイプ（Employment Type）、雇用ステータス（Employment Status）を保持し、Job Information（組織配置—ポジション、職務コード、マネージャ、勤務地）およびCompensation Information（報酬—給与グレード、基本給、通貨）の直接の親となります。この記事では、Employmentレコードの概要、そのタイプとステータスライフサイクルのバリエーション、Employee Dataランドスケープゾーン内でPersonの直下に位置し、Job InformationとCompensation Informationを子として所有する構造、そしてEmployee Centralコンサルタントがこれら3つすべてにわたって設定するすべてのフィールドについて説明します。

パート 1: 雇用 — 中核概念 (全モジュール共通)#

1.1 雇用とは何か#

雇用は契約ごとのレコードです。1人の個人（Person）は、1つの雇用（Employment）（一般的なケース）または複数の同時雇用（グローバルアサインメント。本国と派遣先の雇用が併存する場合）を保持できます。また、退職後に再雇用された個人は、通常、新しい個人としてではなく、同じ個人に新しい雇用が作成されます。雇用は、「誰が、いつから、どのような立場で、どのような状態でこの個人を雇用しているか」が実際に記録されるオブジェクトであるため、すべての職務情報（Job Information）および報酬情報（Compensation Information）レコードが有効日付とバージョン管理される対象でもあります。昇進や給与変更は、同じ雇用の下に新しい日付行を作成するものであり、新しい雇用を作成するものではありません。

1.2 雇用形態とステータスのライフサイクル#

Personレコード自体に「タイプ」フィールドがない場合（SF-A04-01のセクション1.2）、そのフィールドはまさにEmploymentに存在します。雇用タイプと雇用ステータスはどちらもEmploymentのネイティブ属性であり、ステータスのライフサイクルを誤ると（例えば、退職と休職を区別しないなど）、後続の報酬管理や福利厚生において、資格ロジックが破綻する一般的な原因となります。

設計原則: 雇用ステータス（レコード自体の存在ではない）が、ほとんどの統合や資格ルールで実際にフィルタリングされる対象であるため、「雇用が存在する」ことを「雇用が有効である」ことと決して想定してはなりません。退職済みの雇用は履歴のためにシステムに無期限に残ります。すべての下流クエリ（給与抽出、福利厚生資格、人員数レポート）は、レコードの存在のみに基づくのではなく、雇用ステータスを明示的にフィルタリングする必要があります。

1.3 組織レベルとデータ階層#

具体的な例を用いたデータ階層

雇用は、SuccessFactors マスタデータランドスケープのテナントレベルの「従業員データ」ゾーンにおいて、Person の1階層下に位置します。これは Person に所有され（1人の Person に対して N 件の雇用が存在可能）、さらに雇用は、自身の子レコードとして Job Information と Compensation Information を所有します。

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01     (1 Person : N Employments)
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01, Active   ◄── this article
          │      │
          │      ├── assigned to ──> Legal Entity "LE_JP01" — Japan legal entity, Company Code JP01
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment   (1:1 current, effective-dated history)
          │      │      ├── assigned to ──> Position "POS_SalesMgr01" — Sales Manager seat
          │      │      └── assigned to ──> Job Code "JC_SalesRep" — Sales Rep
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY   (1:1 current, effective-dated history)
          │             └── assigned to ──> Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
          │
          └── Employment "EMP_000002" — Global Assignment (host), hire 2024-01-01, Active
                 │
                 ├── assigned to ──> Legal Entity "LE_US01" — US legal entity, Company Code US01
                 │
                 ├── Job Information "JI_002" — Host-country assignment role
                 │
                 └── Compensation Information "CI_002" — Host-country pay component

【必須】ランドスケープ検証に関する注意事項: モジュールMaster.mdのER図は、Person 1:N Employment ←── Legal Entity、次にEmployment 1:1 Job Information、Employment 1:1 Compensation Informationを描いています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンE）では、これを2本の実線の親子バスライン（Person → Employment/User（y=1825）、Employment → Job Information/Compensation Information（y=2005））と、Employmentカード上のゾーンAを指す別個の↗ LE_JP01参照チップに分解しています。これはSF-A04-01で文書化されている実線対チップの規則と同じです。実線のバスラインは真の包含関係（PersonがEmploymentを所有し、EmploymentがJob InformationとCompensation Informationを所有する）を表し、チップ参照（Employmentの↗ LE_JP01、Job Informationの↗ POS_SalesMgr01 / ↗ JC_SalesRep、Compensation Informationの↗ PG_M1）はゾーン間のポインタであり、所有権ではありません。ER図の「1:1」は、Employmentごとの現在の Job Information / Compensation Information行を表しています。両オブジェクトは実際には有効日付管理されているため、単一のEmploymentは、昇格、異動、給与変更に伴い、日付付きのJob Information行とCompensation Information行の全履歴を蓄積し、任意の時点で正確に1行が有効となります。

設計原則: Employmentは、「どの法的エンティティに、いつから、どのような立場で所属しているか」を記録するレベルですが、組織上の配置や給与の詳細は意図的に保持しません。それらはさらに1レベル下のJob InformationとCompensation Informationに存在します。これにより、昇格や給与変更を、Employmentレコード（またはその上のPersonレコード）に一切触れることなく、新しい日付付きの子行として記録できるようになります。

1.4 他のマスタデータオブジェクトとの統合#

雇用は単独で存在するものではありません。雇用は正確に1つのPersonに所有され、正確に1つのLegal Entityに紐づけられ、Job InformationおよびCompensation Informationの親となります。これら2つのオブジェクトは、多くのコンサルタントが「従業員レコード」と考えるフィールドレベルの詳細を保持します。

パート 2: SF 固有のフィールド詳細#

2.0 SFの所有範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 雇用詳細（コア）#

雇用詳細は、雇用が存在するために最低限必要なレコードです。これは、その雇用がどの人物に属し、どの法的エンティティに紐づけられ、いつ関係が開始されたかを識別します。

2.2 雇用ステータスとライフサイクル#

雇用ステータスとライフサイクル項目は、個人の全体的な履歴とは独立して、特定の雇用がその独自のタイムライン上のどこにあるかを追跡します。2つの同時雇用を持つ個人は、一方が「アクティブ」で、もう一方が「採用保留中」となることがあります。

2.3 ジョブ情報#

Job Informationは、Employment自身の組織配置に関する有効日付付き子レコードです。昇進、異動、組織再編のたびに、同じEmploymentの下に新しい日付付きのJob Information行として記録され、Employmentレコード自体は変更されません。

2.4 報酬情報#

報酬情報は、雇用の有効日付を持つ給与に関する子レコードであり、ジョブ情報とは構造的に分離されています。これにより、役割変更を伴わない純粋な給与改定の場合、組織配置レコードに一切触れる必要がなくなります。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction