JinJin48

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

July 19, 2026 · 12 min read

SAP SF ジョブファミリー

Job Familyは、SuccessFactors Employee Centralのジョブ構造管理ブランチの最上位において、「営業」「エンジニアリング」「財務」などの機能分類に基づいて関連するジョブコードをグループ化するマスタデータオブジェクトです。ビジネスユニットや部門とは異なり、報告ラインやコストによって人を整理するのではなく、役割をその仕事の種類に応じて整理します。これは、法的エンティティ → ビジネスユニット → 事業部門 → 部門 → 原価センタという組織チェーンや、スタンドアロンのロケーションマスタから独立しています。この記事では、Job Familyの概要、そのブランチが本シリーズで既に文書化されている他の2つのマスタデータグループとどのように異なるか、そしてEmployee Centralコンサルタントが設定するすべてのフィールドについて説明します。

パート1: ジョブファミリー — 基本概念（全モジュール共通）#

1.1 ジョブファミリーとは#

Job Family（職務ファミリ）は分類／グループ化オブジェクトであり、場所、コストバケット、報告ラインを表すものではなく、あくまで職務のカテゴリです。Department（部門）が「どのチームか」、Location（勤務地）が「どの物理的な場所か」を表すのに対し、Job Family（職務ファミリ）は「これはどのような種類の役割か」を表します。そして、「営業担当者」から「営業部長」に至るまで、すべてのJob Code（職務コード）は、正確に1つのJob Familyに集約されることが期待されており、これにより採用、報酬、およびワークフォースレポーティングを機能別に一貫してセグメント化できます。

1.2 業務機能別のジョブファミリー例#

Job Family（職務ファミリ）は、Legal Entity（法的エンティティ）の国やCost Center（原価センタ）のカテゴリのように、SAPが提供する固定コードリストから選択されるものではなく、完全にクライアント定義の記述的分類です。グループ化を誤ると、データモデルが破綻するというよりは、主にレポートの明確さや採用検索のユーザビリティに影響します。しかし、稼働後の再グループ化は大きな混乱を招くため、ブループリント段階でリストを慎重に決定する価値があります。

設計原則: ジョップファミリ名とコードは完全にクライアント定義であり、SuccessFactorsは標準で提供されるリストを一切出荷しません。ブループリント時に一度リストを決定し、Go Live後は安定して維持してください。後からジョップファミリ間でジョップコードを再グループ化すると、レポートのトレンドラインが崩れ、影響を受けるすべてのジョップコードの再設定が必要になります。

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

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

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

Pay Grade "PG_M1" — Manager L1, 6M-9M JPY
   (sibling object in the Job & Pay Structure branch — referenced independently for salary range,
    not a child of Job Family or Job Code)

Location "LOC_TKY01" — Tokyo HQ, Asia/Tokyo TZ
   (independent tenant-level master — outside the Job & Pay Structure branch entirely)

設計原則: ジョブファミリーは、法人 → 事業部門 → 部門 → 部署 → 原価センタという組織チェーンや、スタンドアロンのロケーションマスタ（SF-A02-01～SF-A02-06参照）とは別の、独立したジョブ構造管理ブランチの最上位に位置します。ジョブファミリーが所有するのはジョブコードのみです（厳密な1:Nの親子関係）。ペイグレードとポジションはジョブコードと同じ階層またはその下位に位置しますが、ジョブファミリー自体の子ではありません。また、ポジションのレポートラインの配置は、そのジョブコードが属するジョブファミリーではなく、部署によって決定されます。

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

ジョブファミリは組織階層の連鎖の外側に位置するため、他のマスタデータとの関係のほとんどは、深いネストではなく、1ホップ（直接の子）または間接的（ジョブコード経由）であり、ジョブファミリ自体は、範囲が狭く明確に定義されたフットプリントを持つ浅いオブジェクトです。

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

2.0 SFの所有範囲#

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

2.1 コア識別#

Core Identificationは、ジョブファミリーが存在するために最低限必要なレコードです。これに割り当てられたすべてのジョブコード、およびジョブファミリーでフィルタリングされたすべてのピックリストやレポートは、このレコードに解決されます。

2.2 説明とステータス#

これらの2つのフィールドはレコードを補完します。1つはジョブファミリーが実際にカバーする範囲について人間にコンテキストを提供し、もう1つは今後も選択可能な状態を維持するかどうかを制御します。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction