第8章: 透明性とスキルベースの未来 — テック企業の三本柱

三本柱を書き換える2つの力

ここまで7章にわたって、等級・評価・報酬の三本柱を設計者の目線で分解してきました。 等級は序列の軸を定めるスキーマ、評価はノイズだらけの測定系、報酬は制約付き最適化の出力関数—— そして設計の核心は個々の柱の完成度ではなく、3つを貫く基準軸の一貫性にありました。

最終章では、この設計思想がいま2つの力によって書き換えられつつある状況を見ます。

• 透明性への圧力: 報酬の決め方を社内外にどこまで開示するのか。 テック企業の自発的な公開実験から始まり、いまは法規制として企業に迫ってきています。
• ジョブからスキルへ: 序列と配置の単位を「職務」から「スキル」へ移す構想。 ジョブ型の次の潮流として語られ、等級というスキーマの粒度そのものを問い直します。

どちらも三本柱を廃棄するものではありません。しかし前者は報酬関数の可視性を、 後者は等級スキーマの粒度を変えます。順に見ていきましょう。

給与透明性のスペクトラム — 4つの型

給与透明性（pay transparency）はしばしば「給与を公開するかどうか」の二択で語られますが、 実際の企業事例を並べると何を公開しているかが企業ごとに違うことが分かります。 公開対象は大きく、①報酬を導く数式、②等級要件とレンジという制度、③個人の実額の3層に分かれます。 この観点で整理すると、次の4つの型が見えてきます。

4つを貫く共通点は、報酬決定の属人性を減らすという第1章で挙げた課題への回答であることです。 一方でコストの所在は型によって異なります。 数式全公開型は市場が動いたときに式ごと作り替える負荷を負い、 市場価値型は毎年の市場データ更新と、社内で隣の人との差を説明する負荷を負います。 自己決定型はプロセスの運用（対話量）そのものが最大のコストです。

GitLabのCalculator廃止 — 式のシンプルさと市場の複雑さ

透明性のコストが最も分かりやすく表面化したのが、GitLabの事例です。 同社は全社リモート企業として、公開ハンドブックの中に誰でも試算できるCompensation Calculatorを置いていました。基準となる市場水準に、 居住地の係数（Location Factor）と等級の係数（Level Factor）を掛けて算出する構造で、 「どこに住んでいる誰がいくらもらうのか」を外部の人間が再現できる状態にしていたわけです。

その公開Calculatorは2025年5月30日に廃止され、現地市場データに連動したレンジへの移行が進められています。 背景を単純化すれば、係数を掛け合わせる方式では、地域ごと・職種ごとに独立して動く実際の相場を表現しきれなくなった、 ということです。ある地域のソフトウェアエンジニアの相場だけが急騰したとき、 全社共通の係数モデルはそれを局所的に反映できません。

規制としての透明性 — 選択から義務へ

ここまでは企業の自発的な選択の話でした。しかし2020年代後半に入り、透明性は法的な要求に変わりつつあります。 以下は2026年7月時点の状況です。

米国には連邦レベルの賃金透明性法はありません。代わりに州単位で立法が進み、 カリフォルニア・コロラド・ニューヨークなど11州が求人票への賃金レンジ記載を義務づけています（2026年7月時点）。 多州で採用する企業は、最も厳しい州の基準に全社を合わせるか、州ごとに求人票を作り分けるかの選択を迫られます。

日本にとってこの潮流が重いのは、開示される数字そのものが厳しいからです。 2024年時点で女性の賃金は男性を100としたとき75.8——1976年以降で最小の差ではあるものの、なお24.2%の開きがあります。 OECDの国際比較では日本のジェンダー賃金格差は約22%で、OECD平均（約11%）の2倍近く、36か国中35位という位置です。開示義務の拡大は、この数字を各社が自分の言葉で説明する場を作ることを意味します。

ジョブからスキルへ — 等級スキーマの再正規化

もう一つの潮流は、序列と配置の単位の変化です。 第6章で見たジョブ型は「職務（ジョブ）に人を当てる」という思想でしたが、 Deloitteはその職務という単位自体が人材活用の足かせになっていると論じ、 スキルを軸に人と仕事をマッチングするスキルベース組織（skills-based organization）を提唱しています。

主張の骨子はこうです。ジョブは複数のスキルの束を固定的にパッケージした単位であり、 一度定義するとその境界が人の動きを縛る。同じ人が持つスキルの一部だけを必要とするプロジェクトがあっても、 ジョブの境界がその配置を妨げる。ならば束を解いて、スキルという細かい粒度で人と仕事を突き合わせればよい——という発想です。 Deloitteは、多くの従業員が自社は学歴や経験年数をスキルより重視していると感じており、 スキルを重視する組織であれば定着したい意欲が高まると答えている、とも報告しています。

graph LR
  subgraph A[ジョブベースのモデル]
    J1[ジョブ定義<br/>職務記述書]
    J1 --> G1[ジョブグレード]
    G1 --> P1[等級別レンジ]
    J1 --> As1[配置は<br/>ジョブ単位で決まる]
  end
  subgraph B[スキルベースのモデル]
    S1[スキル辞書<br/>粒度の細かい能力単位]
    S1 --> Prof[保有スキルと熟達度]
    Prof --> G2[等級またはレベル判定]
    G2 --> P2[レンジ]
    Prof --> As2[配置は<br/>必要スキルとの照合で決まる]
  end
  A -.単位の分解.-> B

  style J1 fill:#f97316,stroke:#ea580c,color:#fff
  style G1 fill:#f97316,stroke:#ea580c,color:#fff
  style P1 fill:#f97316,stroke:#ea580c,color:#fff
  style As1 fill:#6b7280,stroke:#4b5563,color:#fff
  style S1 fill:#10b981,stroke:#059669,color:#fff
  style Prof fill:#10b981,stroke:#059669,color:#fff
  style G2 fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style P2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
  style As2 fill:#6b7280,stroke:#4b5563,color:#fff

エンジニアの語彙で言えば、これはスキーマの再正規化です。 「ジョブ」という粗いレコードを、「スキル×熟達度」という細かい属性の集合へ分解する。 分解すれば配置の柔軟性（クエリの自由度）は上がりますが、代償もあります。 スキル辞書の整備と鮮度維持というマスタデータ管理の負荷が発生し、 熟達度の判定という新しい測定問題——第4章で見た信頼性とバイアスの問題がそのまま再来します。 そして報酬の決定において、スキルの集合をどう金額に写すかという関数を新たに設計しなければなりません。

だからこそ、スキルベース組織を「ジョブ型の次に来る正解」と受け取るのは早計です。 日本の現実はむしろ揺り戻しの局面にあります。第6章で見たとおり、ジョブ型の導入率が 全体21.8%（1,000人以上企業では36.0%）へ伸びる一方で、導入に反対する回答は前年の36.2%から47.2%へ増加しました（JAC調査2025年）。 ジョブ型がまだ定着しきっていない段階で、さらに細かいスキル単位へ移るという構想が輸入されている—— これが日本企業の置かれた実際の座標です。

AIは評価の何を変え、何を壊しうるか

三本柱の運用にはすでに生成AIが入り込んでいます。調査によれば人事領域で約7割が何らかの形で生成AIを活用しているとされます（2026年7月時点）。 評価の文脈で実際に使われている用途は、おおむね次の3つです。

• 評価文面の生成支援: 箇条書きの事実メモから、フィードバック文面のドラフトを作る。 評価者の記述負荷は下がりますが、書き手の思考をスキップさせる危険もあります。
• 偏りの検出: 評価コメントの語彙や分布を横断的に分析し、 部門間の甘辛差や属性による表現の違いを可視化する。キャリブレーション（第4章）の補助として筋が良い用途です。
• スキル抽出: 職務記述書や職歴、社内のドキュメントからスキルを推定し、スキル辞書の整備を助ける。 前節のスキルベース組織が現実味を帯びてきた理由の一つがこれです。

一方で懸念は明確です。第一にブラックボックス化。 評価の根拠がモデルの出力に依存すると、被評価者への説明可能性が損なわれます。 これは前節のGitLabの話と同じ構図——表現力を上げると説明できなくなる——の再演です。 第二に学習バイアス。過去の評価データで学習させれば、 過去の偏り（特定属性への低評価）を再生産する仕組みになりかねません。 第三に、評価文面の生成が上手くなることで、評価の質が上がったように見えて実は文章の質が上がっただけという 取り違えが起きます。

歯止めとして現実的なのは、AIを判定ではなく観測に使うという線引きです。 分布の偏りを見つける、記述の抜けを指摘する、事実の抽出を助ける——ここまでは測定系の改善にあたります。 格付けそのものをモデルに委ねた瞬間、説明責任の所在が消えます。

シリーズ総括 — 制度は「作って終わり」ではない

8章を通じた主題は一貫して整合性でした。最後にもう一度たどり直します。

そして本章で見た2つの力が加わります。透明性は報酬関数の可視性を上げ、 スキルベース化は等級スキーマの粒度を細かくする。どちらも三本柱の外側から来る要求ではなく、三本柱そのものの仕様変更です。

ここから導かれる結論は一つです。人事制度は完成させるものではなく、継続的にリファクタリングし続けるプロダクトとして持つべきものだということ。 実例はすでにあります。SmartHRは2024年の制度改定で等級を5段階から7段階へ増やし、 行動評価の項目を12から8へ、スケールを5段階から3段階へ絞り、 スペシャリストとマネジメントの2パスを整えました。ANDPADは5グレード×3職種（IC／Manager／Director）の枠組みに 約200項目のコンピテンシーを載せ、コミットメント評価と組み合わせています。 こうした企業に共通するのは、制度文書を更新される前提のドキュメントとして扱っている点です。

最後に、本シリーズが繰り返し使ってきたアナロジーの限界も確認しておきます。 等級はスキーマに似ていますが、格付けされるのはレコードではなく人です。 評価はセンサーに似ていますが、測られる側が基準を読んで行動を変えます（グッドハートの法則）。 報酬は最適化問題に似ていますが、目的関数に何を置くかは技術的な問題ではなく価値判断です。 技術の道具は制度を構造として見るためには極めて有効ですが、 最後に何を選ぶかを決めるのは組織の意思です。それを引き受けたうえで構造を語ることが、 エンジニアリングの視点から人事制度に関わる意味だと思います。