【EMの業務解剖】事業タイプ別、評価制度を整える際に押さえてほしいポイントを解説。最も重要なことは企業と社員の間の納得感。

ピープルマネージメント業務が主体となるEM業務では、採用と同じくらい大変な業務が「評価」です。

評価制度の整備は、設計にも構築にも一定の時間が掛かります。私が評価制度の設計から新制度に移行までお受けする場合、短くて1年は掛かります。歴史のある事業の場合、慎重に進めたいとなると3年ほどかけて準備する場合もあります。

今回はなぜ、評価制度が必要なのか、評価制度を整備する上で押さえておきたいポイントは何なのかということについてお話していきます。

• keyboard_arrow_down 「評価制度なし」は機能するのか？
• keyboard_arrow_down 評価制度への期待される3つのこと
• keyboard_arrow_down 評価制度設計する上で重視するポイント
• keyboard_arrow_down 事業タイプ別評価制度のポイント
• keyboard_arrow_down 評価制度の整備にゴールはない

友達の友達くらいの範囲が社員であるなど、組織が少人数のうちは評価制度がなくても短期的には成立します。

時折、「評価がない」ことをウリにする組織が登場します。こうした組織のよくある言い分は「厳選して採用をしているため、悪意のある人が居らず、規則が不要」であるのです。

しかしこれは採用に絶対的な自信がなければならず、さらに人数を拡大したタイミングで破綻しやすいものです。マネージャー層が把握しきれなくなる前には何かしらの評価制度を持つことをお勧めしています。

評価制度の話に入る前に、評価制度によって解決が期待される3つのことについてまとめます。

評価、給与に関する納得感

評価のあるべき形は「企業と社員の間の納得感」です。転職が一般的となったエンジニアバブル下では、社内で評価を上げるよりも転職した方が年収が上がるという状況が生まれてしまいました。

転職理由でよく耳にするものの一つとして「この組織では評価してもらえない」というものがあります。こうした人達の多くは「何故現職ではこの評価なのか」という腹落ちをしていない状況です。

評価制度と給与制度が紐づくことが一般的ですが、「なぜ私はこの給与なのか」というWhyに対し、明確に説明できる制度が必要です。

ジュニア層の成長マイルストーン

新卒採用を実施している組織や、ジュニア層が一定存在する組織の場合、評価制度は彼らにとってキャリアのマイルストーンになる、という役割があります。

少しでも成長意欲がある人達を採用できていると、

といったように、評価軸を明文化すれば、成長への階段（マイルストーン）が明示されることになるため、非常に有効です。

キャリアパスの明示

将来的に自社では何を目指せるのかということは非常に重要な観点となります。営業職を中心に拡大した企業の評価制度は、営業職を想定している傾向があります。直接的に売上を上げないと評価がされなくなかったり、リーダーやマネージャーを目指して組織運営に関わらなければ、キャリアが頭打ちしてしまうことが多々あります。こうした組織では転職したりフリーランスになる方が金額的に優位であるため、未経験から数えて3年程度で退職してしまう傾向にあります。

エンジニアのキャリアパスを作成する場合、技術力を高めて事業貢献することを想定とした「スペシャリストコース」をつくり、従来のマネジメントに携わっていく「マネージャーコース」と分離させる組織が多く見られます。

次に評価制度を作成する際のポイントについてお話ししていきます。

どういう人を評価したいのかという言語化

評価制度を作成する際には、まず社内においてどういった行動が推奨されるのかを言語化するところから始める必要があります。MVV（ミッション　ビジョン　バリュー）やクレド（行動指針）などがある場合は、それらをゴールイメージとして逆算し、各グレードで求めるレベル感を定義していくことになります。

MVVやクレドは組織が向かうべき北極星のような存在です。社内に存在しない場合、先にこれらを経営層が言語化して作っていくことをお勧めしています。

独自な評価制度は運用に覚悟が必要

企業の中には独自の評価制度を運用している企業もあり、それを組織の強みとしているところもあります。

例えば株式会社CARTA HOLDINGSでは、エンジニア職の評価を、技術評価会でのプレゼンテーションを通して実施しています。準備コストが発生することに加え、外部から著名なCTOなどを有償で招聘してフィードバックを実施しているようなので、工数的にも費用的にも他社では真似しにくい仕組みです。
参考：https://techblog.cartaholdings.co.jp/tech-assessment

株式会社カヤックは、給与決定の際にサイコロが登場することで有名です。月給×サイコロの出目%が賞与に付与されるため、全体的なパーセンテージとしては少ないです。一方で、月給は社員の相互評価による月給ランキング、賞与は各事業の状況に応じて割り振られた原資をプロデューサー（事業責任者）の主観によって決められます。非常にユニークな取り組みですが、普段から月給ランキングワークショップを実施するなど、この評価制度を維持するためには、一定の努力と工数が必要です。

また、ある企業では半年に一度のペースで従業員に職務経歴書を更新させ、人材紹介会社3社に想定される給与レンジの査定依頼をし、上限の平均値を出すという取り組みを取り入れていたそうです。しかし、職務経歴書の書き方が上手い人材が、事業貢献した人材よりも評価されるようになってしまったため、取りやめたと聞きます。

独自の評価制度は工数も費用も掛かります。こうしたことから、評価制度はスタンダードな階層構造を持たせることが多くの組織においては妥当です。

基本形としての行動評価、職能評価、成果評価

スタンダードな形式としては、次の2軸があります。

ボーナス制給与制度の場合、これらに加えて成果評価として給与に反映させる形となります。

評価グレードは刻めるようにする

かつて職能評価がプログラミング言語別に5段階しかない組織を見たことがあります。特にフロントエンドはjQueryの時代に作られたためバックエンドと比較すると差別されており、2段階しか存在しませんでした。そのためフロントエンド担当にされると年収がすぐに頭打ちになるため、社員もやる気が起きず、やがて転職へと繋がっていきました。

こうした解像度が荒い評価制度は時代に応じて変化させることが求められます。。後から評価の階段を足すことができたり、レベルを上方向に伸ばせるようにしておくことが必要です。

例えばグレードがAを最高位にした上で、その下にBやCを置いてしまうと、Aの上を置きたくなった時に具合が悪いです。A’などが存在する企業も見たことがあります。将来的な発展も見据えて設計するようにしましょう。

評価制度と給与制度の接続

評価制度と給与制度を連動させる必要があります。評価制度に直接基本給を接続してしまうと、今現在で問題になっているような物価高に対する給与見直しを将来的に行う際に不都合が生じます。

日本における初任給はバブル崩壊後から横ばいの状態を貫いています。そのため、給与レンジの見直しが大事化しやすい組織を多く見かけます。評価グレードと給与レンジを別テーブルで管理しないと、調整給などで誤魔化し続けなければなりません。

事業タイプによって評価制度の志向も変わっていきます。大きく自社サービスとクライアントワークに分け、それぞれのポイントについてお話をしていきます。

自社サービス

自社サービスの場合、事業貢献に繋がる目標設定をし、その達成度合いを評価することがポイントとなります。OKRのように全社目標→事業目標→開発目標などと噛み砕いてくアプローチも有効です。

目標設定は数字で表現できるものが望ましいです。ジュニア層で「⚪︎⚪︎（技術名）の習得」を目標にされる方が居られますが、2つ注意点があります。

1つはあくまでこの目標は個人学習であるため、事業貢献の観点から協議が必要です。未経験採用の場合は、最初のグレードについては評価に慣れることをゴールとする練習の位置づけに留めること。次のグレードからは事業貢献にまつわる目標設定をするのも考えられる方法です。

もう1つは何を持って習得したかという判断基準が曖昧です。目標設定の段階でチェックポイントを段階的に複数の実装目標を設定し、1段階目達成は20%、2段階目は40%…など、達成率を明示することをお勧めします。

クライアントワーク

クライアントワークの場合、社内メンバーがチームで取り組む場合と、一部のSESのように単身で他社のプロジェクトに入場する場合では事情が異なります。プログラマポジションの場合、実際のソースコードを見ないで技術評価がなされることに抵抗があるエンジニアは多いです。

チームで動く場合はリーダーがメンバーの状況を把握しやすく、評価制度に納得感が得られやすいです。GitHubなどでコミット履歴を参照し、上長チェックをクリアしてマージされた一定の難易度があるコミット数をカウントしたり、手戻りのなさを職能評価として取り上げることが想定されます。

一方で単身で他社のプロジェクトに入場する場合では、働きぶりが自社から見えないという難しさがあります。そのために評価が勤怠状況であったり、顧客に配布したアンケートをベースにされたり、帰社日への参加率を元に評価されるケースが多々見られます。これは極めて納得感が得られにくいため、育成枠から離れた3年目辺りに転職する傾向があります。チームの場合と同様に、顧客との合意を踏まえて実際に書いているソースコードの質などをチェックして評価することで納得が得られる可能性があります。

評価制度にゴールはありません。形つくられた評価制度であっても、時代の変遷や事業の状況によって変わっていく「求める人物像」に応じてアップデートする必要があります。

前述したように、評価に最も重要なことは「企業と社員の間の納得感」です。経営層や社員と対話をしながらできあがった評価制度を成長させていくようにしましょう。