JinJin48

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

July 19, 2026 · 21 min read

SAP SF 従業員プロファイル

従業員プロファイルは、個人の生物学的アイデンティティ（SF-A04-01で扱う「個人」）と、職務/契約の詳細（SF-A04-02で扱う「雇用」、「職務情報」、「報酬情報」）を、単一の統合画面として表示する集約読み取りビューです。従業員プロファイル自体は、個人のアイデンティティや職務配置を所有しません。これらのレコードは、それぞれ「個人」と「雇用」に属します。従業員プロファイルが所有するのは、他に格納場所がないプロファイル固有のデータ、すなわち、プロファイルヘッダ集約、職務関係（HR担当者やマトリックス管理者などの追加の関係リンク）、および職務経歴や学歴などのバックグラウンド要素です。これにより、フェーズ3（従業員データ）が完了します。フェーズ3では、「個人」がルートとなる生物学的アイデンティティとしてフェーズを開始し、「雇用」が運用上の職務/契約の詳細を担いましたが、従業員プロファイルは、その両方の上に構築されたプレゼンテーション層および拡張層です。この記事では、従業員プロファイルとは何か、そのビュータイプと可視性のバリアント、ゾーンEの「個人」/「雇用」/「職務情報」/「報酬情報」の上に位置し、独自のランドスケープノードを追加しない方法、および従業員セントラルコンサルタントがプロファイルヘッダ、職務関係、職務経歴、学歴にわたって設定するすべてのプロファイル固有のフィールドについて説明します。

パート1: 従業員プロファイル — 基本概念（全モジュール共通）#

1.1 従業員プロファイルとは#

従業員プロファイルは、PersonやEmploymentのようなマスタレコードを所有するものではありません。これは、コンサルタント、マネージャー、従業員が実際に目にする単一画面に、それらのレコードとプロファイル固有の拡張情報を集約する、リクエスト時に生成される集約レイヤーです。自身で保持する個人情報や職務データを持たないため、ある意味では従業員データゾーン内で最も「安定性」の低いオブジェクトです（基盤となるPersonやEmploymentのデータが変更されるたびに再レンダリングされます）。一方で、別の意味では最も拡張性の高いオブジェクトでもあります（ジョブリレーションシップやバックグラウンドエレメントは、PersonやEmploymentの独自のフィールドセットとは独立して、ここで設定・拡張されます）。

1.2 プロファイルビューのタイプと可視範囲#

従業員プロファイル自体には「タイプ」フィールドはありません。変化するのは、特定の閲覧者が表示を許可されている、基盤となるPerson、Employment、Background Elementデータのサブセットであり、そのサブセットは、オブジェクト自体の何かではなく、ポートレットごと、Background Elementごとに階層化されたRBPによって完全に制御されます。この違いを誤解することは、「設定したばかりのフィールドをこのマネージャーがなぜ見られないのか」というサポートチケットの一般的な原因です。なぜなら、PersonまたはJob Informationに技術的に存在するフィールドが、すべてのプロファイルビューに表示されるわけではないからです。

設計原則: あるプロファイルビューで表示される項目が、別のビューでも自動的に表示されるとは決して想定しないこと。フルプロファイル、公開プロファイル、マネージャセルフサービスプロファイルは、まったく同じ基盤となる個人/雇用/背景要素データの異なるサブセットをそれぞれ表示できます。フィールドの可視性を設定する前に、要件がどのビュータイプを説明しているかを必ず確認してください。

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

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

従業員プロファイルは、SuccessFactors マスタデータランドスケープのテナントレベルの「従業員データ」ゾーン内に専用のポジションを持ちません。つまり、このモジュールの30のセットアップフローステップの1つではありません。代わりに、概念的に既存のゾーンE構造の上位に位置し、リクエスト時にPerson、アクティブなEmployment、Job Information、Compensation Information、Userを組み立てるとともに、自身のJob Relationships（Job Information上）とBackground Elements（Person上）を個別にアタッチします。

Client (SuccessFactors Instance)
   │
   └── Person "PER_000001" — Taro Yamada, DoB 1985-04-01
          │
          ├── Employment "EMP_000001" — Full-time, hire 2020-04-01, Active
          │      │
          │      ├── Job Information "JI_001" — Sales Mgr assignment
          │      │      └── Job Relationships — HR Rep "EMP_000250", Matrix Manager "EMP_000180"
          │      │
          │      └── Compensation Information "CI_001" — Base 7.5M JPY
          │
          ├── Background Element: Work Experience "WE_001" — "XYZ Corp", Sales Associate, 2016-2020
          ├── Background Element: Education "ED_001" — Waseda University, BA Commerce, 2016
          │
          └── User "USER_tyamada" — yamada@example.com

   Employee Profile (this article)
      = the read-aggregated screen assembled from all of the above:
        Person + the active Employment's Job Information/Compensation Information
        + Person-level Background Elements + Job Information's Job Relationships
      — with no dedicated storage layer of its own beyond EmpJobRelationships
        and the Background Element entities noted above.

【必須】ランドスケープ検証に関する注意：モジュールMaster.mdのセットアップフローとER図では、フェーズ3（従業員データ）にPerson、Employment、Job Information、Compensation Information、Userの5つのオブジェクトが正確にリストされています。Employee Profileはこれらに含まれていません。これは、Employee Profileが保守対象のマスタレコードではなく、UI/読み取り集約の構造体であるためです。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンE）にも、それに対応するカードはありません。これは、SF-A04-01とSF-A04-02のそれぞれがEmployee Profileを「PersonとEmploymentの両方の上に構築された集約読み取りビュー」と説明していること、および本記事のセクション1.3の図が、新しいノードを考案するのではなく、これら2つの姉妹記事が使用するものと同一のゾーンE領域を再利用していることと整合しています。Job Relationships（Job Informationに紐付く。関連するHR担当者/マトリックス管理者は異動に伴い変更される可能性があるため）およびBackground Elements（Personに紐付く。職歴や学歴は経歴情報であり、雇用をまたいで個人に追随するため）は、真のEmployee Profile所有の拡張機能ですが、これらはセットアップフローのオブジェクトではなくコンフィギュレーションレベルの追加要素であるため、個別のランドスケープカードとしては描画されません。これらは、上記のツリー図内で、既存のゾーンEノード上のアタッチメントポイントとして明示されています。

設計原則：Employee Profileは、表示する個人情報と職務データを所有するのではなく集約するため、PersonまたはEmployment（SF-A04-01、SF-A04-02）に対する修正は、個別の更新ステップを必要とせずにEmployee Profileに即座に反映されます。しかし、Background ElementまたはJob Relationshipに対する修正は、PersonやEmploymentのフィールドテーブルには含まれていないため、Employee Profile自身のデータに対して直接行う必要があります。

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

Employee Profile（従業員プロファイル）は単独で存在するわけではありません。表示されるすべてのフィールドは、Person（個人）またはEmployment（雇用）から直接取得されるか、Employment自身の子レコードを通じて間接的に取得されるか、あるいは閲覧者がそれにアクセスするためにUser（ユーザー）に依存しています。

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

2.0 SFの所有範囲#

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

2.1 プロファイルヘッダ（集約スナップショット）#

プロファイルヘッダーは、すべての閲覧者が最初に目にするサマリーカードです。プロファイル写真という唯一の例外を除き、PersonまたはJob Informationから既に取得されているフィールド以外は、独自のフィールドを意図的に持ちません。

2.2 ジョブ関係（追加の関係）#

Job Relationshipsは、単一のプライマリマネージャフィールドを超えた報告ライン形式の接続を取得するために、Job Informationに添付される設定可能なブロックです。これは、PersonやEmploymentですでにカバーされている内容の再記述ではなく、Employee Profile独自のデータです。

2.3 背景要素 — 職務経歴#

職歴は、個人に紐付く繰り返しの背景要素です。同一人物の職歴行は、再雇用やグローバルアサインメントをまたいで保持されます。これは、職歴がいずれかの単一の雇用に結びついていないためです。

2.4 背景要素 — 教育#

教育は、Personに紐付く2つ目の繰り返し背景要素であり、職歴と同様の構造を持ちますが、学歴に特化した独自のフィールドセットを備えています。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction