賃金テーブルとは何か|結論
賃金テーブルとは、等級ごとに賃金の上限・下限(レンジ)や号俸を定めた一覧表であり、給与を「誰が見ても同じ基準で説明できる」状態にするための仕組みです。作り方の基本手順は、①等級フレームの確定、②レンジ・号俸の設計、③市場賃金と自社の支払い能力の突き合わせ、④昇給ルールの決定、という順で進めます。ただし、表を作ること自体はゴールではありません。等級要件・評価基準・昇給判断が連動していなければ、賃金テーブルは「作ったが使えない資料」になりがちです。この記事では作り方の手順に加え、作った後にどう回すかまで扱います。
賃金テーブルの作り方|4つのステップ
ステップ1:等級フレームを先に決める
賃金テーブルは等級の枠組みがなければ設計できません。まず「何を基準に等級を分けるか」を決めます。役割の大きさ、必要スキル、期待される成果水準などを言語化し、等級数(一般的には5〜7等級程度が中小企業では扱いやすいとされます)を仮決めします。ここで抽象的な「主体性がある」「協調性が高い」といった表現だけで等級要件を書くと、後の昇給・昇格判断で属人的になりやすいため、行動レベルまで具体化しておくことが重要です。
ステップ2:号俸・レンジ幅を設計する
等級ごとに賃金の下限・上限(レンジ)を設定します。レンジ型と号俸型の2方式が一般的です。
- レンジ型:等級ごとに下限〜上限の幅だけを決め、その中で評価に応じて昇給額を都度判断する方式。柔軟だが判断基準が曖昧になりやすい。
- 号俸型:等級内をさらに号俸(1号、2号…)に細分化し、1号あたりの昇給額をあらかじめ決めておく方式。説明はしやすいが設計・改定の手間が増える。
中小企業では、まずレンジ型で運用を始め、等級・評価制度が定着してから号俸型へ精緻化する進め方も選択肢になります。
ステップ3:市場賃金と自社の支払い能力を突き合わせる
レンジの水準は、公表されている賃金統計や求人相場などの市場情報と、自社の人件費原資(売上・粗利に対する人件費比率など)の両方を踏まえて調整します。市場水準だけを追うと人件費が支払い能力を超え、自社の実態だけを優先すると採用・定着で不利になります。どちらか一方だけで決めないことが、失敗を避ける基本的な判断基準です。
ステップ4:昇給ルールを決める
賃金テーブルができても、「誰が」「どの基準で」「いつ」昇給を判断するかが決まっていなければ機能しません。定期昇給(同一等級内でのレンジ内昇給)と昇格昇給(等級が上がる際の昇給)を分けて設計し、それぞれの判断材料(評価結果、KPI達成状況など)を明確にしておく必要があります。
等級と賃金テーブルの連動イメージ
等級・役割イメージ・賃金レンジ(月給、年1回改定を想定した目安)の関係は、下表のように整理できます。金額は業種・地域・企業規模により大きく変わるため、あくまで構造の例です。
| 等級 | 役割イメージ | 賃金レンジ(月給目安) |
|---|---|---|
| 1等級 | 基本業務の習得段階 | 下限〜上限まで幅広め |
| 2等級 | 独り立ちし主担当を持つ段階 | 1等級上限と一部重複するレンジ |
| 3等級 | 後輩育成・小規模なマネジメントを担う段階 | 2等級より上位、重複は最小限に |
等級間でレンジを大きく重複させすぎると、昇格しても給与が変わらない「昇格の形骸化」が起きやすくなります。逆に重複を全くなくすと、評価が高いのに等級が上がらない社員の昇給余地がなくなります。重複幅の設計は、この2つのリスクのバランスを取る判断になります。
賃金テーブルだけでは機能しない理由|BloomoreHRの考え方
賃金テーブルは「制度」であり、判断基準を示すものにすぎません。BloomoreHRでは、制度は5層構造(制度・CRM・AI・BPO・現場の対話と成長)の1層目にすぎないと考えます。賃金テーブルという判断基準ができても、それを動かす記録(CRM)、集計・異常検知(AI)、運用を止めない仕組み(BPO)、そして最終的に人が向き合う対話がなければ、昇給判断は毎年の恒例作業として形骸化していきます。
特に賃金は「絶対評価」の考え方と切り離せません。人と人を比べる相対評価で昇給を決めると、同じ等級・同じ役割水準に到達していても評価者や部署によって扱いが変わり、賃金テーブルの説明力が失われます。等級要件という共通基準への到達度で判断する絶対評価を土台に置くことで、賃金テーブルは初めて「説明できる仕組み」になります。
また、昇給判断をKPIと接続する設計も有効です。個人のKPI達成状況を日次・週次で可視化し、月次の対話で進捗と課題を確認し、半期の評価・目標更新の中で昇給・昇格を判断する、という時間軸を持たせることで、年に一度だけ賃金テーブルを見て判断する状態を避けられます。KPI未達を単純な減点材料にせず、原因分析や障害除去、成長課題の発見に使う視点も、賃金の納得感を左右します。
この過程でAIが担えるのは、KPIの集計、レンジと現在給与の乖離チェック、昇給検討時期のリマインドなどです。一方で、昇給額の最終判断や評価面談の中身、キャリアの意思決定は人が担うべき領域であり、AIに委ねるべきではありません。AIの役割は人を置き換えることではなく、上司が部下と向き合う時間を確保することにあります。
よくある失敗例
- 等級要件が曖昧なまま賃金レンジだけ先に決めてしまい、昇格判断の説明ができない。
- 市場賃金の情報だけを参考にし、自社の人件費原資を考慮せず、レンジが実現不可能な水準になる。
- 昇給ルールを明文化せず、結果として「上司の裁量」で運用され、絶対評価から相対評価に戻ってしまう。
- 賃金テーブルを作った初年度だけ運用し、翌年以降は評価・KPIとの接続が途切れて形骸化する。
賃金テーブル運用の判断基準
賃金テーブルが機能しているかどうかは、次の観点で定期的に確認できます。
- 等級要件と評価基準が一致しており、共通基準で説明できるか。
- 昇給判断の材料(評価結果・KPI達成状況)が記録として残り、後から確認できるか。
- レンジの重複幅が、昇格の意味を失わせるほど大きくなっていないか。
- 市場賃金の変化に対して、数年に一度は見直しの検討機会を設けているか。
- 生産性・KPI達成だけでなく、定着や成長実感にも影響が出ていないか、片方だけを追う設計になっていないか。
特に最後の観点は見落とされがちです。賃金テーブルとKPI連動を強めすぎると、短期の生産性だけが北極星になり、結果として定着率や成長実感が犠牲になる設計になっていないかを、定期的に点検する必要があります。
まとめ|次にすべきこと
賃金テーブルの作り方自体は、等級フレーム→レンジ設計→市場水準との突き合わせ→昇給ルール決定という順で整理できます。しかし、表を作った時点では制度の判断基準ができただけです。実際に機能させるには、絶対評価による共通基準、KPIの時間軸に沿った積み上げ、そして評価・記録・運用を止めない体制まで含めて設計する必要があります。まずは自社の等級要件が行動レベルまで具体化されているかを見直すところから始めることをおすすめします。人事制度設計や運用支援BPO、Human Growth Platformといった仕組みを組み合わせる際も、この順序を崩さないことが実務上の起点になります。