JinJin48

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

July 19, 2026 · 17 min read

SAP SF Person

Personは、SuccessFactors Employee Centralにおいて、個人のグローバルな経歴情報を表すマスタデータオブジェクトです。これは、個人が法人（Legal Entity）と結ぶ雇用契約関係を表すEmploymentとは異なり、また、両者を基に構築された集約読み取りビューであるEmployee Profile（SF-A04-03で説明）とも異なります。これによりフェーズ3（従業員データ）が開始されます。フェーズ1では法人からポジションに至るチェーンが組織の枠組みを構築し、フェーズ2では権限グループから報酬プランに至るチェーンがアクセス制御とプロセスの枠組みを構築しますが、Personは実際の人間が初めてシステムに入力される場所です。この記事では、Personレコードとは何か、そのワーカーカテゴリとライフサイクルステータスのバリエーション、EmploymentやUserと並んで従業員データランドスケープゾーンの最上位に位置する方法、そしてEmployee Centralコンサルタントが設定するすべてのフィールドについて説明します。

パート1: 担当者 — 基本概念（全モジュール）#

1.1 担当者とは#

Personはクライアントレベル（テナントレベル）のルートオブジェクトであり、個人の生年月日や個人連絡先データを保持しますが、それ自体にはジョブ、組織配置、給与情報は含まれません。これらの詳細は、Personに紐づくEmploymentレコードに1階層下で保持されます。Personは、他のすべての従業員データオブジェクトが最終的に参照するIDであるため、従業員データゾーンにおいて意図的に最も浅く、最も安定したオブジェクトとして設計されています。氏名、生年月日、国民IDはほとんど変更されませんが、Personにぶら下がるEmploymentレコードは、個人の採用、昇格、異動、グローバルアサインメントに応じて常に変化します。

1.2 ワーカータイプとライフサイクルステータス#

Personレコード自体には「タイプ」フィールドはありませんが、それに紐づくEmploymentレコードによって、その個人がどのようなワーカーであるか、またライフサイクルのどの段階にいるかが決まります。この区別を誤ることは、このプラットフォームに不慣れなコンサルタントにとってよくある混乱の原因です。「ワーカータイプ」はPersonにあると思い込みがちですが、実際には一段階下のレベルに存在するからです。

設計原則: 再雇用や同時/グローバルアサイメントにおいて再利用されるのは「雇用」ではなく「個人」であるため、新しい個人レコードを作成する前に、必ず既存の個人レコードを検索してください。再雇用で重複した個人レコードを作成すると、その個人の履歴が2つのIDに分断され、1人の個人＝1つの連続した履歴を前提とする勤続期間、年功、履歴レポートの計算が損なわれます。

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

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

Personは、SuccessFactorsマスタデータランドスケープのテナントレベルの「従業員データ」ゾーンの最上位に位置します。これは、EmploymentとUserの両方が直接ぶら下がるハブノードであり、EmploymentはさらにJob InformationとCompensation Informationを自身の子レコードとして所有します。

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01  (1:N — home + Global Assignment records)
          │      │
          │      ├── assigned to ──> Legal Entity "LE_JP01" — Japan legal entity, Company Code JP01
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment
          │      │      ├── assigned to ──> Position "POS_SalesMgr01" — Sales Manager seat
          │      │      └── assigned to ──> Job Code "JC_SalesRep" — Sales Rep
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY
          │             └── assigned to ──> Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
          │
          └── User "USER_tyamada" — yamada@example.com  (1:1)
                 └── assigned to ──> Permission Role "PR_ESS" — Employee Self-Service

【必須】ランドスケープ検証に関する注意: モジュールMaster.mdのER図では、User ←── Person + Permission Role と描画され、PersonとPermission Roleの両方が同一行上でUserへの入力としてリストされています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンE）では、これを2つの異なるコネクタタイプに解決しています。PersonからUserへの実線の親子バスライン（Personが自身のUserレコードを所有/包含、ソースのNotesテーブル「Person 1名に対して1ユーザー」に従い1:1）と、Userカード上の別個の↗ PR_ESS参照チップ（ゾーンCを指す）です。これは矛盾ではなく、ランドスケープが真の包含関係（PersonがUserを所有）とクロスゾーン参照（UserがRBP目的でPermission Roleを指す）を区別しているものであり、Employmentの↗ LE_JP01参照（ゾーンA）やJob Informationの↗ POS_SalesMgr01 / ↗ JC_SalesRep参照（ゾーンB）に使用されているのと同じ実線対チップの慣例に従っています。

設計原則: Personは、従業員データゾーンにおいて意図的に最も浅く、最も安定したノードとして設計されています。PersonはEmploymentとUserを直接所有しますが、それ以外の外部への参照（Legal Entity、Position、Job Code、Pay Grade、Permission Role）はすべて、Person自体から直接ではなく、1レベルまたは2レベル下位で解決されます。これにより、個人の職務、組織配置、アクセス権がキャリアの中で何度変更されても、IDの安定性が保たれます。

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

Person（個人）は単独で存在するわけではありません。これは、Recruiting（リクルーティング）またはOnboarding（オンボーディング）からシステムに入ってくる個人の着地点であり、下流のすべてのEmployment（雇用）、User（ユーザー）、およびアクセス制御の解決が最終的に依存するオブジェクトです。

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

2.0 SFの所有範囲#

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

2.1 基本情報（コア識別情報）#

Biographical Information（個人基本情報）は、Person（個人）が存在するために最低限必要なレコードです。これは、システム全体におけるすべてのEmployment（雇用）、すべてのUser（ユーザー）、およびすべてのグループピッカーが最終的に参照する情報です。

2.2 国民ID情報#

National ID Informationは繰返しサブレコードです。1人のPersonが複数のNational IDを持つことができます（例：グローバルアサイメントのPersonが自国のパスポートと滞在国の住民登録を保持する場合）。

2.3 個人連絡先情報#

個人の連絡先情報は、組織配置や業務連絡先データ（雇用情報の「雇用」下にある「職務情報」に格納 — SF-A04-02参照）とは意図的に分離されています。このセクションは、現在どの雇用が有効かに関わらず、個人自身の連絡先データです。

2.4 グローバル情報（国固有拡張）#

グローバル情報は、他の3つのセクションのように固定されたフィールドリストではありません。これは、特定のフィールドが法的に必須である国に対してのみ、コアのPersonオブジェクトの上に国固有の個人フィールドを追加する拡張メカニズムです。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction