第3章: 等級制度 — 序列の軸を何にするかというスキーマ設計

等級制度は「組織のデータモデル」である

第1章で、人事制度の三本柱は等級（序列の軸）→評価（測定）→報酬（処遇反映）の順に連動すると整理しました。 この順序には理由があります。等級制度は他の2つに先行して「何を基準に人を並べるのか」を決めてしまうからです。

エンジニアの言葉に翻訳すれば、等級制度は組織のデータモデル（スキーマ）です。 従業員テーブルの序列カラムに、能力を入れるのか、職務を入れるのか、役割を入れるのか。 この一つの決定が、評価で何を測るか、報酬をどう払うか、異動をどこまで柔軟にできるかを、すべて下流に伝播させます。スキーマを間違えたアプリケーションが後からどれだけロジックを直しても救えないのと同じで、 等級の軸が事業実態とずれている制度は、評価や報酬をいくらいじっても整合しません。

等級の3類型 — 能力・職務・役割

日本の実務で使われる等級制度は、基準軸によって3つに分類できます。 歴史的には第2章で見たとおり、職能資格制度（1969年の日経連『能力主義管理』と楠田丘の理論化を起点に普及）が長く主流でした。 そこに1990年代の成果主義ブームで職務等級的な発想が持ち込まれ、 2000年代に折衷解として役割等級（ミッショングレード）が広がった、という順番です。

重要なのは、実際の日本企業はこの3類型を階層ごとに使い分けているという点です。 各種調査では非管理職は職能給が最も多く、管理職は役割給が最も多いという結果が繰り返し出ています。 つまり「若いうちは人基準で育て、責任を持つ層はポストの重さで処遇する」というレイヤーごとに異なるスキーマを積む設計が事実上の標準解になっているわけです。

graph TD
  S[等級の基準軸をどう選ぶか] --> Q1{担当する職務は<br/>安定して定義できるか}
  Q1 -->|職務が明確で<br/>異動が少ない| J[職務等級制度<br/>Job Grade]
  Q1 -->|職務が流動的で<br/>頻繁に異動する| Q2{処遇差の根拠を<br/>どこに置きたいか}
  Q2 -->|人の成長と<br/>ゼネラリスト育成| N[職能資格制度<br/>Skill Based Grade]
  Q2 -->|ポストの重さと<br/>役割の大きさ| R[役割等級制度<br/>Role Grade]
  J --> JE[前提整備<br/>JDと職務評価が必須]
  N --> NE[前提整備<br/>能力要件定義と年功化への歯止め]
  R --> RE[前提整備<br/>役割定義の定期的な見直し]

  style S fill:#10b981,stroke:#059669,color:#fff
  style Q1 fill:#f97316,stroke:#ea580c,color:#fff
  style Q2 fill:#f97316,stroke:#ea580c,color:#fff
  style J fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style N fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style R fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style JE fill:#6b7280,stroke:#4b5563,color:#fff
  style NE fill:#6b7280,stroke:#4b5563,color:#fff
  style RE fill:#6b7280,stroke:#4b5563,color:#fff

昇格の設計 — 判定ロジックをどう書くか

等級というカラムを定義したら、次は値を更新する条件を決めなければなりません。ここで用語の整理が必要です。

• 昇格: 等級が上がること。等級制度上の格付けの変更。
• 昇進: 役職（課長・部長など）が上がること。組織上のポストの変更。

職能資格制度が広く受け入れられた実務的な理由の一つが、この昇格と昇進の分離でした。 ポストの数は組織構造で決まるため有限ですが、等級は人に付くので、 「課長のポストは空いていないが能力は課長相当なので等級だけ上げる」という運用が可能になります。 処遇の逃げ道として機能した一方、ポストなき上位等級者の滞留という人件費問題も生みました。

卒業方式と入学方式

昇格の判定基準には2つの流儀があります。

実務では両者を組み合わせ、下位等級は卒業方式、管理職への登用は入学方式（アセスメントや登用試験を併用）とするケースが多く見られます。 さらに最低滞留年数（同一等級に何年在籍したら昇格候補になるか）を置く設計も一般的ですが、 これは運用を安定させる一方で、年功要素をスキーマに埋め込む行為でもあります。 滞留年数が実質的な唯一の昇格条件になった瞬間、その制度は名前が何であれ年功制です。

ブロードバンディング

等級数の設計も重要な変数です。細かく分ければ昇格の階段が近くなり動機づけしやすい反面、 等級ごとの要件定義が曖昧になり、隣接等級の違いを誰も説明できなくなります。 制度設計の実務では5〜7段階程度が扱いやすい範囲としてよく推奨されます。

この「等級を大括りにして段数を減らし、代わりに一つの等級の報酬レンジを広くとる」設計をブロードバンディング（broadbanding）と呼びます。 昇格の機会は減りますが同一等級内の昇給余地が広がるため、昇格に頼らずに処遇を伸ばせるのが利点です。 組織のフラット化やジョブ型的な運用と相性がよい一方、 レンジが広すぎると「同じ等級なのになぜあの人と差があるのか」の説明責任が重くなります（レンジ設計の定量的な扱いは第5章）。

職務評価 — 仕事の重さをどう採点するか

職務等級や役割等級を採るなら、職務評価（job evaluation）が避けられません。 これは人ではなく仕事そのものの相対的な価値を測る技法で、大きく2系統に分かれます。

Hay Guide Chart — 3因子で職務を採点する

ポイントファクター法の代表格が、Hay Group（1943年創業、Edward N. Hayらが1951年に発表）のHay Guide Chartです。世界のグローバル企業で長く使われてきた事実上の標準で、職務を次の3因子で採点します。

• Know-How（ノウハウ）: 職務遂行に必要な知識・技術の広さと深さ、マネジメントの幅、対人スキル
• Problem Solving（問題解決）: 思考の自由度（どこまで前例や指示に頼れるか）と、直面する課題の複雑さ
• Accountability（アカウンタビリティ）: 行動の自由度、職務が組織業績に与えるインパクトの大きさと直接性

この3因子は「何を知っていて、どんな難しさに向き合い、どれだけの結果に責任を負うか」という構造で、 後で見るエンジニアリングラダーの3軸と驚くほど似た形をしています。

国内では、厚生労働省がパート・有期雇用労働者の同一労働同一賃金の文脈で要素別点数法による職務評価ツールを公開しています（part-tanjikan.mhlw.go.jp）。 正社員と非正社員の職務の大きさを共通の尺度で比べ、待遇差の合理性を検証する目的で設計されているのが特徴です。 職務評価は「等級を決める道具」であると同時に、待遇差を説明する道具でもあるのです。

実装例: 富士通のGlobal Role Framework

職務等級を大規模に実装した国内事例として、政府の「ジョブ型人事指針」（内閣官房・経済産業省・厚生労働省、2024年8月28日公表、20社の事例を収録）に記載された 富士通のケースが参考になります。同社は2020年に管理職約1.5万人を対象にジョブ型を導入しました。

• Global Role Framework: 職種軸と等級軸のマトリクスで格付けする。等級はLv7からSVPまで。
• 650個のRole Profileを整備し、職種ごとの役割の型を定義した。
• 約2か月で1.5万人分の職務記述書を作成。「完成度は後からブラッシュアップする」という方針で、精度を待たずに走り出した。
• Lv12以上の管理職はシングルレート（等級ごとに単一額でレンジを持たない）。等級内での年功的な昇給運用ができない構造にした。
• 高度専門職（セキュリティ・データサイエンス・AI）は、等級の基本給に専門性加算を上乗せする別建ての仕組みを設けた。

エンジニアの目で見ると、この「2か月で1.5万件のレコードを埋め、精度は後から上げる」という進め方は示唆的です。 JDを完璧に書き切ってから移行しようとすれば着手から数年かかり、その間に事業も組織も変わってしまいます。 スキーマ移行を先に通してデータ品質は継続的に改善する、という実務的な判断がここでも採られています。

エンジニアリングラダー — scope・impact・ambiguity

テック企業の等級制度はエンジニアリングラダー（career ladder / career framework）と呼ばれ、 日本の職能資格・職務等級の議論とは独立に発展してきました。しかし興味深いことに、 多数のラダーを収集・比較したlevels.fyiの整理では、企業をまたいでほぼ共通の3軸が浮かび上がります。

具体例では、CircleCIのラダーがE1からE6までを「与えられた作業の実行」から 「他者の成果を増幅するレバレッジ」へと移行する軸で記述しています。 Dropboxのキャリアフレームワークは、役割定義に加えてscope・collaborative reach（協働の届く範囲）・impact levers（影響を生む手段）を明示する構成です。 各社のラダーはprogression.fyiなどに集約公開されており、設計時の参照実装として使えます。

注目すべきは、この3軸がHay Guide ChartのKnow-How・Problem Solving・Accountabilityとほぼ同型だという点です。 1951年の職務評価手法と現代のテックラダーが同じ構造に収束しているのは、「仕事の重さ」を測る次元がそれほど多くないことの傍証と言えるでしょう。

IC/EMデュアルラダー — 分岐を降格にしない設計

エンジニアリングラダーのもう一つの定型がデュアルラダーです。 一定の等級から先を、IC（Individual Contributor、個人貢献者）とEM（Engineering Manager、マネジメント）の2本のパスに分岐させ、同じレベルなら同じ報酬レンジとし、パス間の転換を降格として扱わない設計です。

graph TB
  E4[共通レイヤー<br/>Senior 相当まではパス共通] --> IC5[IC パス Lv5<br/>Staff Engineer]
  E4 --> EM5[EM パス Lv5<br/>Engineering Manager]
  IC5 --> IC6[IC パス Lv6<br/>Principal Engineer]
  EM5 --> EM6[EM パス Lv6<br/>Director]
  IC6 --> IC7[IC パス Lv7<br/>Distinguished Engineer]
  EM6 --> EM7[EM パス Lv7<br/>VP of Engineering]
  IC5 <-->|同一レンジ 相互転換は降格ではない| EM5
  IC6 <-->|同一レンジ 相互転換は降格ではない| EM6

  style E4 fill:#10b981,stroke:#059669,color:#fff
  style IC5 fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style IC6 fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style IC7 fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style EM5 fill:#8b5cf6,stroke:#7c3aed,color:#fff
  style EM6 fill:#8b5cf6,stroke:#7c3aed,color:#fff
  style EM7 fill:#8b5cf6,stroke:#7c3aed,color:#fff

日本のテック企業でも、この設計は広く採用されています。

• メルカリ: MG（Mercari Grade）でIC/EMのデュアルラダーを運用。MG6がPrincipal、MG7がDistinguishedに相当する上位ICパスを持つ。
• SmartHR: 2024年の制度改定で等級を5段階から7段階へ拡張し、スペシャリストとマネジメントの2パス制を採用。等級要件や評価ロジックを公開している。
• 10X: 4等級以上の構成で、ICとマネジメントの相互往来を可能にしている。
• ANDPAD: 5グレード × 3職種（IC / Manager / Director）のマトリクス構成。コンピテンシー約200項目とコミットメント評価を組み合わせる。
• GMOペパボ: 2015年からのエンジニア職位制度で、シニア以上は立候補と面談によって上位職位を判定する（4等級以上でシニア・プリンシパル・シニアプリンシパル）。会社が選ぶのではなく本人が手を挙げる入学方式の一形態です。

なぜここまで「相互転換を降格にしない」ことが強調されるのでしょうか。 マネジメントが唯一の昇進経路である組織では、優秀な技術者が処遇を上げるために不本意な管理職に就き、 結果として優れたエンジニアを失って平凡なマネージャーを得るという交換が起きます。 さらに、いったんEMになった人がICに戻りたくても、それが降格と見なされる限り戻れません。 デュアルラダーはキャリアの可逆性をスキーマレベルで保証する装置なのです。

等級制度が壊れる典型パターン

最後に、等級というスキーマが実質的に機能しなくなる典型を挙げておきます。基準軸の接ぎ木（職能資格のまま報酬だけ成果連動にする＝第2章の富士通1990年代の構造）、要件定義の陳腐化（能力要件やJDを更新せず、実際の昇格は上司の推薦で決まる）、滞留年数の実質支配、等級数の過剰、そして単線ラダー。 いずれも「明文化された制度」と「実際に動いているロジック」が乖離した状態であり、 エンジニアが仕様書とコードの乖離を警戒するのと同じ理由で危険です。

等級というスキーマが定まれば、次はその等級に照らして人をどう測るかという問題に進みます。 第4章では評価制度を、ノイズとバイアスに満ちた測定系の校正問題として分解します。