人事評価制度の設計／導入／運用 にEMとしてどう関わってきたか / How I have been involved as an EM in the design, introduction and operation of evaluation systems

人事評価制度をきっかけに組織を変革する
制度の設計／導入／運用 にEMとしてどう関わってきたか

2025/03/12 EMゆるミートアップ〜EMConf expansion〜

Transcript

1. 2025/03/12 EMゆるミートアップ〜EMConf expansion〜 Ver.1 2025.03 人事評価制度をきっかけに組織を変革する 制度の設計／導入／運用 にEMとしてどう関わってきたか
2. 2 アウトライン 1. 自己紹介／会社紹介 2. 前提共有 3. 制度設計 4. 導入 5. 運用 6. 結び
3. 3 本日の注意事項と期待する効果 注意事項 　完璧な人事評価制度はなく、組織の価値観やフェーズによって在り方を変えていくものだと考 えております。例えば、人事評価制度をあえて作らない(作り込まない)こともありえます。 一方で(自分を含め)評価制度の在り方や更新に悩む方々も多いと思います。 本発表では自分のN=1の経験を紹介することで、人事評価制度の在り方や運用・導入を考える きっかけに少しでもなれると幸いです
4. 4 About Me ➔ 推し書籍 ◆ エンジニアリング組織論への招待 ◆ アジャイルリーダーシップ ◆ チーム・ジャーニー ◆ LeanとDevOpsの科学 ◆ 急成長を導くマネージャーの型 ➔ 最近読んでぐっときた書籍 ◆ ラディカル・プロダクト・シンキング ◆ ポリティカルスキル 2023.04〜 EM @ Grooves とりい ➔ 趣味 ◆ アニメ鑑賞、絵画鑑賞 ◆ 油絵を描く
5. 5 Groovesについて ITエンジニアのキャリアに 本気で向き合う転職サイト クラウドリクルーティング サービスの構築 Forkwell フォークウェル Crowd Agent クラウドエージェント Mission: より良い未来への「きっかけ」を提供する。
6. 前提共有 01 組織がテーマの話なので、前提共有をいくつかさせてください🙏
7. 7 前職と現職の状況について 前職 • 2019.10〜2023.03 • 決算・開示業務を受託する企業にて、社内 ユーザー向けの業務自動化ツールの開発 ◦ SWE -> EM(PdM) • 要件ヒアリング、実装、運用サポートなど • DX実現に向けた内製開発組織として組成 ◦ 発足して1年足らず • 部署ごとの縦割りと目標管理が厳密 • 純粋なエンジニアは3名程度から始まり、10 名前後に成長していく • 若手採用がメインで育成の土台と体力に自信 現職 • 2023.04〜 • 中途採用領域でのWebサービスの運用開発 • プロダクト開発に関わる一連の業務 ◦ EM(マネジメント専任) • サービスの歴史は長い(10年以上) • CS部隊が整っているが、プロダクトを起点に 共通のKPIを意識 • プロダクトメンバーは20名弱で推移 ◦ プロダクト組織内に複数チームが存在 • 比較的シニアな採用がメイン 共通：チームでプロダクト開発を行い、組織として成果の最大化と成長を目指している
8. 8 更新前の評価制度概要 前職 現職 • 組織としてのKPIや目標はあり、各自で頑張るスタイル(個人目標の指針はまちまち) • 全社共通のポータブルスキルとグレードは定義されている • 年に1回その基準と照らし合わせて昇給額とグレードが決定 • EM, TechLead, ICという各職能に対して5段階の職格が用意され、職格ごとにバリューを分解した7 項目の基準が定義される • さらに技能定義という項目が職能ごとに10項目前後定義され、求められる能力の詳細が記載 • 半年ごとに個人目標を設定し、上記をすべて満たす、1/3満たすなどの条件によって昇給昇格が決定 • (複雑なため後の章で図表を用意しています🙇)
9. 9 目標―評価―報酬のラインで考えてみる 目標 • 目標〜評価のラインは原則、チームで閉じる • 報酬を除いた純粋な「評価」は評価者と被評価者 で擦り合わせが比較的容易 評価 報酬(給与) • 評価〜報酬までのラインは人事や会社都合による アンコントローラブルな影響も出てくる • 会社の売上や給与バランスなどなど (遭遇して嬉 しい話ではありませんが…) 目標―評価ー報酬のラインが 真っ直ぐつながることは現実的に(ほぼ)ないが目指すべき理想 前職(評価制度更新前) 現職(評価制度更新前) 目標 評価 報酬(給与) 報酬(給与) 評価 年間でなんとなくの行動評価が行われ、報酬が決定される 全社的な能力基準はあったが、エンジニアに合った基準は存在しない 目標設定や評価基準が厳密でボリュームが大きく、運用コストも高い 能力評価によりすぎていて、目標や業績との結びつけが難しい
10. 10 目標―評価―報酬のラインで考えてみる 目標 • 目標〜評価のラインは原則、チームで閉じる • 報酬を除いた純粋な「評価」は評価者と被評価者 で擦り合わせが比較的容易 評価 報酬(給与) • 評価〜報酬までのラインは人事や会社都合による アンコントローラブルな影響も出てくる • 会社の売上や給与バランスなどなど (遭遇して嬉 しい話ではありませんが…) 目標―評価ー報酬のラインが 真っ直ぐつながることは現実的に(ほぼ)ないが目指すべき理想 前職(評価制度更新前) 現職(評価制度更新前) 目標 評価 報酬(給与) 報酬(給与) 評価 年間でなんとなくの行動評価が行われ、報酬が決定される 全社的な能力基準はあったが、エンジニアに合った基準は存在しない 目標設定や評価基準が厳密でボリュームが大きく、運用コストも高い 能力評価によりすぎていて、目標や業績との結びつけが難しい 運用に足る制度ではなく圧倒的に要素が足りない => 足し算の方向性へ 運用にかかるコストが大きすぎる => 引き算の方向性へ
11. 設計 02 制度に期待することや設計意図について
12. 12 そもそも目標管理や評価制度に期待すること 外発的動機 • 目標管理(評価含む) • 環境　etc… • 与えられるのは影響まで • 事業の成長と個人(組織)の成長を結びつけたい ◦ 個人の方向性と会社の方向性とを極力アラインメントする ◦ 会社(事業)にとって重視している要素を正しく評価できる制度とする • 燃え尽きやマンネリ化を避け、持続的に成長可能な組織状態を作り出したい • メンバーのモチベーションやエンゲージメントを整えたい ◦ 人には外発的動機と内発的動機があり、評価制度は外発的なサポートまでしかできないのですが、 キャリア形成を支える制度でありたい • 上記を実現できる制度と運用でありたい 内発的動機 • 純粋な興味・関心 • 嗜好　etc…
13. 13 前職の評価制度 〜Before〜 そもそも発足して間もないエンジニア組織であり、エンジニア用の評価制度が整っていないのは当然 ジュニアなメンバーも多く、課題が目に見えてきた中、これを機に新たな評価制度を定義していく必要があった 概要 • 組織としてのKPIや目標はあり、各自で頑張るスタイル(個人目標の指針はまちまち) • 全社共通のポータブルスキルとグレードは定義されている • 年に1回その基準と照らし合わせて昇給額とグレードが決定 課題 • メンバー目線
 ◦ 行ってきたことが評価されない ◦ 何をどれくらい頑張れば良いのかはっきりしない • マネージャー目線 ◦ どういう観点で個人目標の設定を進めるべきかわからない ◦ 業務の難易度と個人の能力の関係をどう評価して良いかわからない
14. 14 前職の評価制度 〜After〜 概要 • 個人目標設定の軸となる評価軸を定義「開発」「ドメイン理解」「(セルフ)マネジメント」 ◦ 現在から未来にかけてチームで必要とされる人物像から想起 ◦ 各レベル・エリアでの業務例や基準例を作成 • 仮想のキャリアラダーを提示し、ジュニアな時点から各ロールまで期待されるレベル感をレーダーチャート化 ◦ 若いチームなので、ロールモデルの代わりとしたい • 目標設定と評価自体は半年に1回実施 ◦ 給与更改のタイミングは当時の 自分に変更の権限はなく 年に1回のまま 自分の関わり方 EMとして「評価ー報酬」と接続するための 「目標ー評価」の制度を新規策定、導入運用 足し算の方向性
15. 15 前職の評価制度 〜After〜　補足資料 制度と運用の具体について記載 10人規模のチームを自律自走させ、成長組織へ変革するため実践していること おまけ 「3年先を見据えた投資、エンジニアのための革新的な評価制度」株式会社 ディーバ | Forkwell Press | フォークウェルプレス
16. 16 現職の評価制度 〜Before〜 当時の制度が決して悪いわけではなく、その状況下での最善を追い求めた結果だと認識。 当時は成長や昇給の行動条件が今よりも不透明で、どういう行動と能力が必要か明示する必要があった。結果として の能力重視の評価制度であり、時間の流れと共に合わなくなってきた 概要 • EM, TechLead, ICという各職能に対して5段階の職格が用意され、職格ごとにバリューを分解した7項目の基準が 定義される • さらに技能定義という項目が職能ごとに10項目前後定義され、求められる能力の詳細が記載 • 半年ごとに個人目標を設定し、上記をすべて満たす、1/3満たすなどの条件によって昇給昇格が決定 課題 • メンバー目線
 ◦ バリューの基準項目と技能定義の数が多く、すべて満たすことが難しく感じる ◦ 形式的な項目も多く、成長を実感できない(事業成長とも連動しない) • マネージャー目線 ◦ 能力評価によりすぎて現在の会社規模や事業フェーズに合わない ◦ 確認すべき項目が多く、運用コストが高い
17. 17 現職の評価制度 〜Before〜　付録資料 メンバー、マネージャー共に各項目を覚え、それぞれについて 目標を立て日々行動するのはとても大変
18. 18 現職の評価制度 〜After〜 スタートアップのための人事制度の作り方 キャリア開発を促し、自社のバリューを浸透させる（金田 宏之） 人事制度ハンドブック - kaneda blog 概要 • 7段階のグレード定義 (G1〜G7) ※グレードによって給与レンジが決まる ◦ G3までは能力重視で評価を行い、G4以上は成果重視で評価を行う • 半年ごとに目標設定と期待値設定を行い、目標に対する期待成果からグレード内での昇給幅を決定 ◦ 目標設定と期待値のすり合わせを行い、それに対する実績でのみ評価を行う ◦ 以前の大量にあった能力項目と比較しての評価ではなくなった • 上記評価を累積した実績によってグレードの昇格を判定 • EM, TL, ICのトラックは廃止し、スペシャリストとマネジメント双方の貢献スタイルでも どちらかに専念した貢献スタイルでも、成果として発揮された実績を重視して評価 自分の関わり方 • 制度自体はプロダクトとビジネス双方の組織に精通した事業責任者が策定 • 自分はEMとして誰よりも制度を読み込み、プロダクト組織に合う形で補足資料の作成、 制度の導入と運用をリード 引き算の方向性
19. 19 現職の評価制度 〜After〜　目標設定を助ける補足資料の作成 G3グレードまでで、組織の中で自律したメンバーとして求める能力を補足。目標設定で活用
20. 20 現職の評価制度 〜After〜　目標設定を助ける補足資料の作成 G4以上には「ガイドラインとして」成果の考え方を補足。自律的に成果貢献を考えてもらうための資料
21. 21 設計意図をまとめると 前職 現職 • どういう人材がこれからのチームで求められるか評価軸を定義し、目標設定時の指針とした ◦ 目標ー評価ー報酬のラインが少しでも接続しやすい運用ができる状態を目指した • 若い組織であったため仮想のキャリアパスも定義し、目指すべきロールへのモチベーションとした • 会社のフェーズとしては、まだまだ成果を重視し、能力よりも成果に対して評価を行いたい ◦ 自律した能力をG3グレードまでに身に着け、G4グレード以上は成果重視で評価する方針 • シンプルに目標設定と期待成果で評価を行う ◦ 累積期間のグレード判定と、半年ごとの昇給判定を行うことで目標に集中できる状態を目指した 双方に共通することは、評価制度も組織的な負債に当てはまり、時間経過と共に見直しや更新に迫られる ・組織にとって、その時点から少し先の未来までフォーカスした制度を検討する ・裁量を持った自由度のある運用が可能な制度とする
22. 導入 03 影響範囲の大きい制度を導入するために
23. 23 前職での制度導入 前提 • 影響度は大きいがチーム内で閉じる制度 (※報酬体系にまで手を入れられていないため) ◦ 現場メンバー、直属の上長、それぞれとの合意形成が取れれば良い • 10名弱の関係者とは普段から一緒に働いていて信頼関係は構築済み 進め方 • たたき台を作りFBをもらう、このイテレーションを一ヶ月程度の間隔で半年繰り返した ◦ 初回は「課題」や「なぜ」「理想状態」の共有込みで全体に対して説明 ◦ 以降は関心の強いメンバーを巻き込み、資料作成と更新の繰り返し 反応 • 運用時の懸念など一定の声はあったが、「今よりは良い！」という気持ちに揃っていった ◦ (信頼関係が既にあるメンバーの集まりだからスムーズだとも思います) • チーム内であれば運用後の制度に対するFBも行いやすい チームレベル
24. 24 現職での制度導入 前提 • プロダクト組織全体に影響する制度であり、自分が普段関わらないプロダクトチームや職能メンバーも存在 ◦ マネージャーも複数存在し、そのレイヤーでの認識合わせや意思決定も必要 • いきなり全員は巻き込めず、途中状況を下手に見せても混乱や不安を与えてしまう恐れがある 進め方 • 半年後の施工を目指し、まずはマネージャー同士で制度・運用のたたき台作成と資料作成を一定の完成度まで進める ◦ 改定の目的と計画は 全体へ見える状態に • 役員陣からのFBと合意を得る • 現場への説明会を実施 • 運用開始へ 組織レベル マネージャーは他にもタスクを複数抱えて いるため、誰かが音頭を取って強い意思で 全体を進める必要がある (自身、この半年前くらいに一度頓挫して います)
25. 25 現職での制度導入　説明会に使用した資料 スライドとは別に、横断的な説明や補足がしやすいようにMiroで情報を整理 説明会から運用までは期間を設け、実施後に個別のFBや疑問点を吸い上げて回 答や資料更新できる状態を作る 会議体 ・間に質問タイムを設けながら、30〜45分で説明し、残りをその場でのFBへ ・説明会は録画し、後で自由に見返せるように
26. 26 現職での制度導入　説明会後に挙がったFBや質問の抜粋 • 結局G4以上は自分で目標設定をリードしろってことだと思うので、制度に対してというよりは実際の目 標に対して悩むことになりそうだな、という感想 • グレード降格の基準・判定方法は？ • 「重要な目標」をたてる意味とは？どれも重要だから優劣はつけられないと感じる • エンジニアメンバーにおけるPL視点って必要なのかな。エンジニアにもビジネス観点をちゃんと持って ほしい、ということであれば、最初からそう書くべきかもしれない • 目標設定時点で期待値をどれくらい作り込むのか • 途中でどのように期待を上回っているかなどお互いに調整するのか 説明会の資料をかなり作り込んだこともあり、現場目線での具体的なFBや質問をたくさんもらえた これが制度に対して、各メンバーが前向きな気持ちになるため重要だったと感じます →回答はまとめて文章化して全体へ共有
27. 27 導入の選択肢を広げるための書籍 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン • 大上段の進め方や計画から、日々のコミュニケーションや情報発信のプラクティスまで網羅的に 48のパターンとして整理 • 振り返ってみると前職では「33 みんなを巻き込む」、現職では「29 正式な推進担当者」 「28 経営層の支持者」などのパターンが当てはまる
28. 28 導入まとめ • 影響する人数やチームの数によって導入計画や周囲の巻き込み方は変わってくる • 基本的には他タスクを抱えながら進めることになるので、「やり切る」という強い意思で推進するメ ンバーが必要 • ぎりぎりすぎる計画は避けて、可能な範囲でゆとりを持つ ◦ 取締役会での承認が必要など、タイミングを逃すと月単位でずれるケースもある ◦ 関係各位がこの制度運用でトライしようと前向きに思える状態へ持って行くことが重要
29. 運用 04 結局は運用、と思えるくらい重要なこと
30. 30 前職での運用方針 目標設定 • チーム目標と評価モデルから個人目標を作成(多くても〜3,5個まで) ◦ 評価軸から少なくとも2観点はカバーする ◦ 事業方針に沿ったものとする • 可能な範囲で目標のマイルストーンや難易度も記載する ◦ 過程が見えてくるので、結果が出たか出ないかの0, 1ではなく途中状態での振り返りや評価が容易になる 評価に向けて • 定期的に目標フォローのMTGを実施 ◦ 特に外的要因で目標を見直す必要がないか ◦ ブロッカーになりうる要素はないか ◦ お互いのサプライズを極力減らす 足し算の方向性
31. 31 前職での運用から得られた知見 • 何もない頃と比べて評価者・被評価者共にやっている感は生まれモチベーションは上がった ◦ もちろん感覚だけではダメで、定期的な振り返りもあるので事業に対しての主体性が増した ◦ 「〇〇PJが外的要因で遅延しそうなので、代わりのPJやタスクを調整したいですね」 ◦ 「この負債解消を優先したいのですが、現在の目標との優先度調整を考えませんか」 • 評価軸があることで「ここをもっと伸ばしたい」「ここは必要ですか？」と具体的な話し合いが増えた • 評価制度だけが要因とは言えないですが、仮想のロールモデルが生まれることで市場価値への興味も高まり、 社内でのLT会や外部発信の機運も高まった • 報酬体系まで巻き込んだ変更はできなかったので、評価から報酬にかけてのコンフリクトはゼロにはできなかった • 定義したキャリアラダーを登れているのか証明は難しく、基準の置き方は悩み続けた • 状況やメンバーによっても運用の難易度は変わる ◦ 目標設定の難易度 ◦ 目標設定の重要性を理解してもらうこと ◦ 定期的なFBを効果的に行えるか、お互いの納得感を醸成できるか 足し算の方向性
32. 32 現職での運用方針 目標設定 • 自身のグレードに沿った目標作成(多くても3個くらいまで) ◦ G3(能力重視)まではマネージャーが主導で目標設定をリード ◦ G4(成果重視)以上はメンバーが主導で目標設定をリード ◦ チーム方針と事業方針に基づくものか双方で確認 • 目標に対する期待成果やマイルストーンも可能な範囲で記載する ◦ グレードが上がるほど、期待される業務の深さや広さが上がる ◦ 期待値を調整し続けることで評価時のサプライズをなくす 評価に向けて • 定期的に目標フォローのMTGを実施 ◦ 外的要因で目標を見直す必要がないか ◦ 状況を確認し、期待値からの大きなずれが出ていないか 制度は異なりますが、前職も現職も運用の方針や注意点には共通事項が多いです 引き算の方向性
33. 33 現職での運用から得られた知見 • これまでと比べて格段にシンプルになったため、目標に集中しやすく振り返りも行いやすくなった ◦ 事業に沿った目標に集中できるため、振り返る中でプロダクトに対するアイデアなど聞ける頻度が上がった • 運用時の裁量や自由度も増したため、柔軟な評価が可能 ◦ 項目が多いことで時々発生していた無理やり感のある評価ストーリーを減らせる ◦ 土台としてお互いの信頼関係が重要 • まだ運用としては初回なこともあり、目標設定のリードの多くは自分が巻き取ってしまった • 期待値という軸があるとはいえ、評価から報酬への接続には一定の難易度を感じた ◦ 土台としてお互いの信頼関係が重要 • 状況やメンバーによっても運用の難易度は変わる ◦ 目標設定の難易度 ◦ 目標設定の重要性を理解してもらうこと ◦ 定期的なFBを効果的に行えるか、お互いの納得感を醸成できるか 引き算の方向性 運用サイクルの経験を積み重ねた先にある知見を獲得し、評価に対してさらなる深みを持ちたい
34. 34 目標設定と振り返りを深めるための書籍 アジャイルチームによる目標づくりガイドブック OKRを機能させ成果に繋げるためのアプローチ | 翔泳社 • チームの目標づくり(とチーム運用)についての書籍ですが、個人目標設定に置き換えても参考になる 事項が多いです ◦ SMARTについて ◦ 内発的動機と外発的動機におけるエンハンス効果とアンダーマイニング効果 ◦ 目標を追えるチーム体制や運営について ◦ マインドセットの捉え方、チーム・個人との対話の仕方 ◦ などなど
35. 35 評価者として評価への向き合い方を深めるための書籍 急成長を導くマネージャーの型 ～地位・権力が通用しない時代の“イーブン”なマネジメント • マネジメントに必要な要素を型化して説明した書籍であり、評価についても多くの学びがあります ◦ メンバーの関心事である「評価(報酬)」に向き合うことの重要性 ◦ 評価が「納得解」であること ◦ 評価フィードバックのフレームワーク ▪ 有効なFBのための「事実のストック」習慣 ◦ などなど • 心に残っているメッセージを引用します 「メンバーのことを考えている」 「メンバーの成功を願っている」 それを口だけでなく、体現しましょう。遠回りなようで、一番重要な業務です。
36. 36 目標設定時に方向性を認識するためのワーク例 • 事業と個人、それぞれの方向性の認識を深めるために、Miroなどでグラフィカルなワークを行うのも一案 ◦ 例としてikigaiチャートを上げていますが、面白そうなフレームワークはたくさんありそうです • 大切なことは一方的な決定と受け取られないよう、お互いの納得感を醸成できること 参照：人生100年時代の「生きがい」を見つける方程 式 長いキャリアを楽しむための「変身資産」の考え方 | ログミーBusiness
37. 37 評価に向けた準備の例 • 定期的なFBでの具体性を増すため、各メンバーの取り組みや気づいたことを記録し続ける ◦ GitHubのPRやレビューコメント、Slackでの共有やNotionの記事作成など参考リンクがあれば控えておく ◦ 普段からメンバーに公開はせず、自分の理解やFB精度を高めるための材料として活用 ◦ (自分がマネジメント専任のため現場の解像度を深める必要があり、優先度を上げて対応している背景はあります)
38. 38 運用まとめ • 目標管理や評価制度の目的に立ち返り、それらに沿った目標設定を{リードする／リードしてもらう} ◦ 手段と目的を混同しない ▪ 事業成長と個人成長を両立させるためのもの ◦ 会社(事業)、個人の方向性を極力揃えることで一方的な目標としない • サプライズを起こさない ◦ 定期的に目標振り返りを行い、相互認識を深める ◦ 必要に応じて納得感を持てる具体的なFBを行う ▪ そのためには日々の準備と信頼関係が重要 フィードバックの実践は難しいのですが、中原淳先生の「フィードバック入門 | 書籍 | PHP研究所 」を読み、 後は日々の経験を積んでいくしかないと思っています
39. 結び 05
40. 40 これからの課題 • 評価者が増えてくると、評価者によって評価のずれが出てくる ◦ 報酬は一定のキャリブレーションが全社レベルで働くが、その前段の評価時点でのずれに 組織レベルでどう対応していくか ◦ 現職はPOと自分の実質的な2名で大半のメンバーをカバーできているため、 2名での認識合わせが密に行えていれば良い ◦ 今後、組織を拡大させ、メンバーと評価者が増えた際にどうしていくか ◦ 以下のログラス飯田さんの発表スライドなどを参考にしようとは考えています ▪ エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management - Speaker Deck ▪ マネージャー間での評価プロセスの整備とキャリブレーション実施 など • 定期的に制度と運用を更新できる体制を構築する ◦ そうしないと、未来のメンバーに負担をかけてしまう
41. 41 まとめ • 人事評価制度は組織の価値観やフェーズによって変化するものであり、完璧な制度は存在しない ◦ 定期的に運用を見直す、中長期単位で制度自体も見直す必要がある • 評価制度は事業成長と個人成長を両立させるための手段であり目的ではない ◦ 目標―評価―報酬の一貫性を目指し、メンバーと会社(事業)の方向性を整える ◦ メンバーの内発的動機を支え、持続可能な組織を目指す • 導入にあたっては計画に余裕を持ち、関係各位がこの制度運用でトライしようと 前向きに思える状態へ持って行くことが重要 • 制度だけでなく、運用が非常に重要 ◦ 定期的なフィードバックと振り返りによる納得感の醸成 ◦ EMとして会社視点、メンバー視点それぞれの折衝点を見つけ出す
42. 42 ありがとうございました！！