クラスメソッドの評価制度を改定した話

クラスメソッド の DevelopersIO ブログ掲載記事。著者・田部井勝彦(てぃーびー)がエンジニアリング統括室から従業員体験(EX)向上ミッションの一環として、2022年10月に施行した評価制度改定の全貌を紹介する。改定の背景・課題・解決策・反省点・今後の展望を包括的に記述した一次資料。

改定前の制度(JD制度)

設計の核心

自分で自分の役割・業務を考える」を原則とした Job Description(JD)制度。設定項目は:

  • 期待する役割と主な業務(役割・業務を各自が記述)
  • 期待する定性成果
  • 期待する定量成果
  • 期待するチャレンジ行動(部門によりカルチャー体現かストレッチ目標かが異なる)

非常にシンプルかつ軽量な設計で、各部の裁量が大きかった。この「自分で役割を定める」フレームは改定後も継承。

改定前の課題

1. 全社の統一感不足

  • 全社統一基準は9グレードに1文程度の抽象的なものだけ
  • 各部で評価の進め方・シートのフォーマットがバラバラ
  • 経営・人事側から評価運用状況の把握が困難

2. 評価基準の曖昧さ

  • 部門ごとに評価方法が異なり、明確/不明確が混在
  • 目標設定の難易度・事業とのつながり・チャレンジ内容に大きなばらつき
  • 全体として評価への納得感が得られにくい

3. キャリアパスの課題

技術特化(ビジネス面は不得手だが技術で尖った実力を発揮する人材)向けのキャリアパスが存在しなかった。「歌って踊れる(技術+ビジネス双方対応)」が標準とされ、技術特化の方は「スペシャリスト」に一律分類されていた。

課題の根本

過去に詳細すぎる評価制度で失敗した経験があるため、基準の明確化と詳細化しすぎないバランスが必要だった。クラスメソッドの社風(各部・各個人の裁量が大きく、最小ガイドラインで動く)を保ちながらの改定が求められた。

改定のポイント

目標の2分割

組織の成果に関する目標(組織目標)と個人の成長に関する目標(グレード目標)を分割

  • 組織目標(OKR): 全社で OKR を導入。評価とは切り離す(OKR のストレッチ特性上、評価連動は「低い目標を設定する」アンチパターンを誘発するため)
  • グレード目標: 個人の成長目標。SmartHR の評価システムで管理、閲覧範囲制限あり

3種類の評価軸(グレード目標)

評価軸内容
行動評価行動・姿勢。ビジネス基礎スキル+マインド(カルチャー体現含む)
能力評価業務遂行能力
成績評価主にビジネス職向けの成績

3層構造の評価基準

評価制度3層構造(クラスメソッド) として詳述:

  • 1層: 全社共通基準
  • 2層: 職種グループ共通基準(エンジニア共通・ビジネス共通など。抽象度高め)
  • 3層: 個別職種の基準(各部が現場の実態に合わせて整備。3人以上同職種なら作成推奨、ただし任意)

3層を固めず、各部で柔軟に運用できる「クラスメソッドらしさ」を維持する設計。

キャリアパス(5類型)

記号名称内容
Dディレクター経営管理職
Mマネジメント管理職
Sスペシャリスト専門職(ビジネス&技術)
Eエキスパート専任職(技術特化) ← 新設
Aアソシエイト一般職(成長後に M/S/E を選択)

エキスパート(E)の新設が最大の改定ポイント。

ツール構成

  • OKR管理: Notion(全社公開前提。リレーション機能でOKR親子関係を管理)
  • グレード目標管理: SmartHR(閲覧制限付き)
  • 評価関連リファレンス: Notion に集約

評価制度改定の取り組みプロセス

2022年6〜9月の流れ:

  1. 既存制度のアンケート調査(課題再確認)
  2. 概案の詳細化(SmartHR設定・プロセス設計・登場人物の役割・権限設定)
  3. OKR管理フォーマット整備(Notion)
  4. グレード目標フォーマット整備(SmartHR)
  5. 評価関連リファレンス整備(Notion)
  6. 導入支援(マネージャー向け・全社向け説明会、Slack QAチャンネル整備、Google Meet相談)
  7. テスト実施(システムテスト3名+模擬評価:開発系3部門・営業系1部門の受け入れテスト相当)

SmartHR設定の複雑さ

権限設定項目数 = 進行プロセス数 × 登場人物数 × 設定項目数。例:10 × 3 × 20 = 600項目を手動設定・手動テスト。一度運用開始すると期中の設定変更が困難なため、事前の完璧化が必要。

反省点

段階的導入の不足

マネージャーが制度を十分に理解し、部門内の運用設計を整えられる余力を確保した段階的導入が不足。前制度の軽量さとの相対的ボリューム差 + OKR新導入が重なり、負荷が大きかった。

リファレンスの情報設計不足

情報を手厚く整備した結果、「情報が多すぎてどこを見ればいいかわからない」状態を招いた。社員が制度を利用する際のストーリー・イベント目線での導線設計が不足していた。

運用後の課題

  • 目標設定スキルの未熟さ: 軽量制度に慣れた社員が本格的な目標設定・運用に不慣れ
  • レールを引く部分と引かない部分のバランス: 詳細化しすぎると「観点を元に自ら考える」姿勢が抜け落ちる。場所によっては意図的に「薄くする」選択もあり得る

現場駆動の取り組み

制度改定に対して現場が自発的に動いた事例:

  • 制度もくもく会: 制度内容を読み合わせする会を現場自発で開催。複数部門に横展開
  • 評価制度運用資料 現場版: 各部内のNotionに部門版制度ポータルを自発的に整備
  • 個別の自発的インプット: Measure What Matters(OKR関連書籍)を自発的に読む社員が複数

今後の方針

  • 評価制度サーベイを節目ごとに実施し、継続改善
  • リファレンス導線の改善(アジャイルに小さく)
  • 4Q(4〜6月)に初年度の総括と次年度大玉改善の検討

外部専門家

株式会社ワンネス・コンサルティングの宮川 淳哉先生(「人事評価の教科書」著者)に月次で相談しながら設計・運用に取り組んだ。

関連