JinJin48

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

July 19, 2026 · 17 min read

SAP SF ポジション

Position（ポジション）は、組織構造における単一の埋め可能な席を表すマスタデータオブジェクトであり、ジョブコード（業務内容）と部門（組織上の所属）を組み合わせて、従業員のジョブ情報レコードが占めるアドレス可能なスロットを形成します。これはSuccessFactors Employee Centralのジョブ構造管理ブランチの末端ノードです。ジョブファミリーやジョブコードが抽象的に業務を分類するのに対し、Positionは具体的であり、空席、充足済み、凍結、または将来の採用に先立って計画することができ、部門階層とは独立した自身の報告ライン（「報告先」）を持ちます。この記事では、Positionとは何か、ジョブファミリー→ジョブコード→Positionの連鎖を終端させると同時に従業員データから直接参照される方法、そしてEmployee Centralコンサルタントが設定するすべてのフィールドについて説明します。

パート 1: ポジション — 基本概念（全モジュール共通）#

1.1 ポジションとは#

Position（ポジション）は座席オブジェクトであり、Job Code（ジョブコード）のように職務内容を分類するものではなく、Department（部門）のように組織上の配置を分類するものでもありません。これは、両方を組み合わせた具体的でアドレス可能な単位です。各ポジションは、職務内容に対して正確に1つのJob Codeを指し、組織上の配置に対して正確に1つのDepartmentを指します。従業員のJob Information（職務情報）レコードが、その座席に採用または異動された際に占有するのは、この組み合わされた単位（Job CodeやDepartment単独ではありません）です。

1.2 ポジション設定バリアント#

Position（ポジション）は、例えばEEOカテゴリのようにSAPが提供する固定のタイプリストから取得されるわけではありません。すべてのポジションはクライアントが作成する「席」です。異なるのは、その席の現在の状態とレポート設定であり、これらを誤ると直接的で目に見える結果が生じます。空席（Vacant Position）にフラグが立てられていないと人員数レポートが歪み、凍結（Frozen Position）がアクティブのままになると、実際には承認されていない人員枠に対してリクルーティングが要求を開始できてしまいます。

設計原則: クライアントがポジション中心（ポジション管理有効、すべての採用が既存のポジションに紐づく）で運用するか、ポジションレス（職務情報がジョブコードと部門を直接保持し、ポジション層を持たない）で運用するかは、基本的な設計上の判断であり、気軽に見直せるトグルではありません。すでに稼働中のポジションレス環境に後からポジション管理を導入するには、現在の全従業員に対して1件ずつポジションレコードを遡って作成する必要があります。

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

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

Client (SuccessFactors Instance)
   │
   └── Job Family "JF_Sales" — Sales family, Job group
          │
          └── Job Code "JC_SalesRep" — Sales Representative, of JF_Sales
                 │
                 └── Position "POS_SalesMgr01" — Sales Manager, seat
                        │
                        └── assigned to ──> Department "DEPT_S01" — Sales Team 1 (org hierarchy chain, Zone A)

Employment "EMP_000001" (Employee Data branch, Zone E)
   │
   └── Job Information "JI_001" — Sales Mgr assignment
          ├── references ──> Position "POS_SalesMgr01" (seat occupied)
          └── references ──> Job Code "JC_SalesRep" (job content, direct — not resolved only through Position)

【必須】ランドスケープ検証に関する注意事項: モジュールMaster.mdのセットアップフローとER図では、「Position ← (Job Code, Department)」および「Job Information ← (Employment, Position, Job Code)」が文章で説明されています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html）は、両方とも図示されたとおり正確に確認しています。ゾーンB内ではJob CodeからPositionへの実線の親子コネクタが、ゾーンA内ではPositionからDepartmentへの↗ DEPT_S01参照チップが、そしてゾーンEからは、Job Informationが2つの独立した参照チップ（↗ POS_SalesMgr01および↗ JC_SalesRep）を持ちます。これは、Job InformationがPositionを経由してJob Codeを解決するのではなく、PositionとJob Codeを独立して参照することを意味します。SF-A02-08とSF-A02-09の両方で確認されたJob Code↔Pay Gradeの不一致とは異なり、Positionについてはソースの文章と図示されたトポロジーの間に不一致は見られません。注目すべき発見事項が1つあります。ランドスケープは、PositionとPay Gradeの間にコネクタを一切描画していません。つまり、ポジションの報酬範囲はPositionを通じて解決されることはなく、そのポジションを占有する従業員に対してCompensation Informationが入力され、Pay Gradeを直接参照した場合にのみ解決されます。

設計原則: ポジションは、ジョブ構造管理ブランチ（ジョブファミリー → ジョブコード → ポジション）の末端ノードであり、従業員データブランチから参照される同ブランチ内で唯一のオブジェクトでもあります。従業員に席を割り当てるすべてのジョブ情報レコードは、ポジションを直接指し示します。ポジションは2つの上流オブジェクト（ジョブ内容のためのジョブコード、組織配置のための部門）から供給されますが、下流の従業員データオブジェクトから参照されるため、ポジションの再設計（1つの席を2つに分割する、または席の所属部門を変更する）は、まずアクティブなジョブ情報参照を確認して評価するのが最善であり、従業員に影響を与えない設定のみの変更として扱うべきではありません。

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

Position（ポジション）は分岐点に位置しています。ジョブ構造管理ブランチにおいて、参照を消費する（ジョブコードと部門から）と同時に、それ自体が参照によって消費される（ジョブ情報から）唯一のオブジェクトです。そのため、組織図や人員数レポートは、ジョブコードや部門を個別に参照するのではなく、実際にはこのオブジェクトをキーとして使用することになります。

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

2.0 SFの所有範囲#

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

2.1 コア識別#

Core Identification（コア識別）は、ポジションが存在するために必要な最小限のレコードです。これは、そのポジションを占めるすべてのジョブ情報レコード、およびポジションでフィルタリングされた組織図や人員数レポートが、最終的に参照するものです。

2.2 組織割当とレポート割当#

このセクションは、実際にポジションを組織図および報告ライン構造に配置するものです。これは、コア識別の職務内容フィールドとは別のものです。

2.3 人員数とステータス#

これらのフィールドは、ポジションが現在補充可能かどうか、消費する人員数を決定し、どのような雇用形態を想定しているかを管理します。つまり、ワークフォースプランニングとリクルーティングは、ポジションを公開できるかどうかを判断する際に、実際にこれらのフィールドを参照します。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction