昇給・評価に納得感がない会社へ等級・評価・賃金をどうつなげるか

社員が不満なのは給与額だけではない

「頑張ったのに変わらない」「自分より後に入った人のほうが高い」。こうした声には、金額への不満だけでなく、決まり方が見えないことへの疑問も含まれます。ただし、説明すれば金額の問題が解消するとも限りません。水準と決定の仕組みは分けて確認します。

給与には、採用時の事情、過去の昇給、役職手当、経験など、複数の要素が積み重なっています。現在の差をすぐに不公平と断定する前に、その背景を調べます。社員へ説明できる理由と、以前の判断が残ったままの部分を区別すると、見直す課題が具体的になります。

「なぜこの給与なのか」を説明できるか

経営者の頭の中に基準があっても、社員や管理職に伝わっていなければ、次に何を目指せばよいかが分かりません。「総合的に判断した」という言葉だけで終わらず、期待する役割、期間中の行動や成果、賃金の決め方を分けて説明できる状態を目指します。

最初の作業は、新しい給与表を作ることではなく、現在の給与の内訳と決定理由を整理することです。基本給と各種手当が何に対して支払われているかを確認します。同じ役割でも処遇が違う場合は、入社時の条件や経緯も確かめ、説明できない差をそのまま新制度へ写さないようにします。

社員の個別情報は、検討に必要な担当者だけで扱います。制度の考え方を共有することと、個人の給与を全員に公開することは別です。納得感を高めるためにも、情報の扱い方を丁寧に決めてください。

等級制度の役割

等級は、会社が求める役割や能力の段階を整理するものです。「自分の担当作業を遂行する」「後輩を教える」「部署を運営する」といった期待の違いを示します。何を軸に分けるかは会社によって異なるため、役職名をそのまま並べるだけでは十分ではありません。

たとえば熟練技能を持つ人と、チームを管理する人では、会社への貢献の仕方が違います。管理職にならなければ処遇が上がらない仕組みでよいかも検討します。制度を複雑に増やす前に、会社に必要な役割と、社員が目指せる道筋を言葉にしましょう。

等級が上がる条件も、在籍年数だけでなく、次の段階の仕事をどこまで担えるかで考えます。ただし、任せる機会がなかった社員を不利にしないよう、経験や育成の機会をどう用意するかも一緒に決める必要があります。

評価制度の役割

評価は、一定期間に期待された役割をどう果たしたかを確かめる仕組みです。等級が期待の段階を示すのに対し、評価はその期間の行動や成果を振り返ります。この違いが曖昧だと、一度の好成績だけで昇格させるのか、継続して役割を担えることを見るのかが分からなくなります。

評価結果を伝えるときは、良かった点、改善が必要な点、その根拠を示します。点数だけでは、次に何をすればよいか伝わりません。評価者による解釈の違いや日々の記録については、評価制度を運用する方法で詳しく説明しています。

賃金制度の役割

賃金制度は、役割や評価、会社の方針を処遇へどう反映するかを定めます。等級ごとの範囲、昇給の考え方、賞与との関係などを整理します。評価が良ければ無制限に給与が上がるという設計では、長く続けることが難しくなります。

会社の支払い余力と、社員に期待する役割の両方を見る必要があります。また、基本給、手当、賞与を同じ目的で重ねていないかも確認します。採用時の条件との関係を放置すると、既存社員に説明しにくい差が広がることがあります。制度設計では個人ごとの影響と、会社全体の人件費を合わせて試算します。

3つを別々に作ると失敗する

等級では後輩育成を期待しているのに、評価は個人の生産量だけ。評価は高いのに、昇給の決まり方は説明されない。こうした食い違いがあると、社員はどの行動を大切にすればよいか迷います。

一人の社員を例に、期待する役割、評価する行動、評価結果の処遇への反映までを通して確認すると、矛盾を見つけやすくなります。その際は、昇給と昇格も区別してください。現在の段階で成果を上げることと、次の役割を担うことを、どのように扱うかをそろえます。

中小企業で現実的な制度設計とは

まず現在の役割と賃金を整理し、経営者と管理職が説明できる範囲の制度案を作ります。現行の処遇に当てはめて、誰にどんな影響が出るかを試算します。費用だけでなく、面談や評価にかかる時間も確認しましょう。

既存社員の賃金や労働条件を変える場合は、制度表の完成だけで実施できるとは限りません。厚生労働省の労働条件変更に関する案内を踏まえ、合意や就業規則、変更の合理性など、個別事情に応じた検討が必要です。移行方法は社労士や弁護士などの専門家と確認してください。

社員への説明では、新制度の目的と、何がいつ変わるかを示します。質問を受ける機会を設け、理解が揃っていない部分を確認します。仕組みを一度作って終わりにせず、運用中の疑問を集めて改善することが、納得して働ける土台につながります。