JinJin48

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

July 19, 2026 · 17 min read

SAP SF 評価尺度

評価尺度は、SAP SuccessFactors パフォーマンス＆ゴール全体で、従業員が目標やコンピテンシーをどの程度達成したかを評価するために使用される、再利用可能で順序付けられた評価レベルのセット（各レベルは「5 = Outstanding」のように数値と表示ラベルをペアにしたもの）を定義するマスタデータオブジェクトです。これは、フェーズ2（権限とシステム設定）の目標・パフォーマンス設定サブブロック内で最初に設定されるオブジェクトです。すべての目標計画テンプレートとすべてのパフォーマンスフォームテンプレートは、構築前に評価尺度を必要とします。これは、尺度がマネージャーの定性的な判断を比較可能な数値に変換するものだからです。この記事では、評価尺度とは何か、その一般的なポイントカウントのバリエーション、ランドスケープのタレント＆報酬ゾーンにおける目標計画テンプレート/パフォーマンスフォームテンプレートチェーンの先頭に位置する方法、および管理センターのコンサルタントが設定するすべてのフィールドについて説明します。

パート1: 評価尺度 — 基本概念（全モジュール共通）#

1.1 評価尺度とは#

評価尺度は、クライアントレベル（テナントレベル）のファンデーションオブジェクトであり、それ自体は従業員データを一切保持しません。これは、純粋に採点の基準として存在します。単独では意味を持たず、その存在意義は、他のパフォーマンス＆ゴールテンプレートから参照されることにあります。これにより、目標、コンピテンシー、または全体的なレビューセクションを評価するすべてのマネージャーが、同じ定義されたレベルのセットに対して採点を行い、組織全体で評価を一貫して比較、分布、調整できるようになります。

1.2 評価スケールバリアント（ポイントカウントパターン）#

評価尺度のレベル数は、見た目の選択ではありません。これは、評価者の行動、キャリブレーション（調整）の難易度、そして尺度の出力が下流の報酬決定にどれだけ明確に反映されるかに直接影響を与えます。ポイント数を誤ると、中央付近への無意味な集中を生み出すか、大規模な評価者集団全体で扱いきれないキャリブレーション負荷を生み出すことになります。

設計原則: 評価尺度のレベル数とラベル文言は、フォームがアクティブなレビューサイクルで公開された後は決して変更してはなりません。完了した評価は特定のレベル値を参照しており、サイクル途中でレベル数を変更したりラベルを変更したりすると、進行中および過去のフォームデータの同期が取れなくなります。ブループリント段階で、最初のレビューサイクルが開始される前に、尺度の設計をロックしてください。

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

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

評価尺度は、SuccessFactorsマスタデータランドスケープのテナントレベルの「タレント＆報酬」ゾーンに位置し、そのゾーンにバンドルされている2つの独立したクライアントレベルチェーンのうちの1つ（本記事で取り上げるタレントチェーンと、姉妹記事が担当する並行した無関係の報酬チェーン）の先頭にあります。

Client (SuccessFactors Instance)
   │
   ├── Rating Scale "RS_5pt" — 5-level, 1 = Below Expectations – 5 = Outstanding
   │      │
   │      └── Goal Plan Template "GPT_2024" — FY2024, Performance/Behavior/Growth categories, of RS_5pt
   │             │
   │             └── Performance Form Template "PFT_Annual2024" — Annual Review, 4-section, of GPT_2024
   │
   └── Compensation Plan "CP_Merit2024" — Merit 2024, 3% budget  (Compensation chain, see SF-A03-11)
          │
          └── Compensation Template "CT_Merit" — Merit, 0-6% range, of CP_Merit2024
                 │
                 └── Eligibility Rule "ER_FT1Y" — Full-time, 1+ year, of CT_Merit

【必須】ランドスケープ検証に関する注意事項: モジュールMaster.mdのER図では、評価尺度が2つの並列な1:Nの子（目標計画テンプレートと業績フォームテンプレート）に分岐し、兄弟関係として描かれ、さらにルートマップが業績フォームテンプレートの1:Nの子としてネストされています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンD）では、両方の点が異なる形で解決されています。(1) 単一の連続した実線チェーン RS_5pt → GPT_2024 → PFT_Annual2024 が描かれており、これはセットアップフローの明示的な二重前提条件の解釈「業績フォームテンプレート ←（評価尺度、目標計画テンプレート）」と一貫しています。つまり、業績フォームテンプレートは、リンクされた目標計画テンプレートを通じて評価尺度を継承すると同時に、目標スコアリングに紐づかないセクションについては評価尺度を直接バインドすることもできます（セクション1.4参照）。(2) ルートマップは、権限ロールへの破線の参照チップ（RM_Std ↗ PR_ESS）のみを持つ独立したゾーンDノードとして配置されており、業績フォームテンプレートへの実線のコネクタはありません。これは、ER図のネストではなく、セットアップフロー自体の前提条件行「ルートマップ ←（権限ロール）」と一致しています。したがって、ルートマップはこの記事の独自の階層チェーンには含まれません。SF-A03-10を参照してください。

設計原則: 評価尺度は従業員データや独自の組織サブレベルを持たないため、階層内での位置付けは意図的に浅くなっています（クライアントレベル、単一ノード）。実際の構造的な複雑さは、目標計画テンプレートと業績評価フォームテンプレートがそれぞれ評価尺度にどのようにバインドされるか（セクション2.4）という、1階層下のレベルに存在しており、評価尺度オブジェクト自体には存在しません。

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

評価尺度は、ほとんどのフェーズ2オブジェクトよりも統合フットプリントが狭く、純粋な上流入力として機能し、正確に2つの下流テンプレートによって消費されます。例えば、権限グループがファンデーションオブジェクトからデータを引き出すような、評価尺度にフィードする基準ソースはありません。ルートマップと報酬計画は同じランドスケープゾーンに位置しますが、評価尺度との直接的なデータモデルリンクはありません。ルートマップは承認ルーティングのために権限ロールに対して独立して設定され、報酬計画のメリットガイドラインロジックは、完了した評価の結果を、実行時の下流ビジネスルールとしてのみ消費し、評価尺度オブジェクトへの格納された参照としては使用しません。

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

2.0 SFの所有範囲#

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

2.1 規模定義（コア識別）#

Scale Definition（尺度定義）とは、評価尺度が存在するために必要な最小限のレコードであり、すべての目標計画テンプレートおよび業績評価フォームテンプレートの尺度ピッカーが参照する基盤です。

2.2 評価レベル設定#

評価レベル設定は、評価者が目にする尺度とシステムが保存する数値を実際に定義する、レベルごとに1行の繰り返し可能な子レコードです。

2.3 ローカライゼーション（翻訳ラベル）#

ローカライゼーションは、スケールのレベル定義とは意図的に分離されたメンテナンスステップです。スケールは完全に設定（レベルと値が完了）されていても、このステップをスキップすれば、グローバル展開時に未翻訳のまま出荷することが可能です。

2.4 消費側テンプレートでの使用#

評価尺度自体は何もスコアリングしません。目標計画テンプレートまたは業績評価フォームテンプレートにバインドされて初めて意味を持ちます。このセクションでは、そのバインドの仕組みと、最もよくある設計上のミスが発生する箇所について説明します。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction