読者です 読者をやめる 読者になる 読者になる

技術力評価のトライアルをチーム内でやってみたまとめ

はじめに

先日 Voyage さんの 再演: 技術力評価は難しい? に参加してきました。 それをみて弊社でもやってみたいと思ったので、とりあえず上長に許可を取りチーム内でトライアルとしてやってみました。

とりあえず条件はこんな感じ

  • 評価者: 私 + 被評価者が望むなら他の評価者をいれてもよい(ただし自分で調整する)
    • 実際は誰も他のヒトの調整がなかったので私1人でした
  • 被評価者: 10名
  • 社内 gitlab の計画リポジトリに「技術力評価」というラベルを貼って pull-request (どうでもいいですが gitlab はなんで merge-request なんだろう)
    • トライアルなので評価して欲しい項目/特に評価者のことを考えて「自信がある pull-request / プロダクト」のリンクや社外発表を記載してもらった
  • 時間の都合で30分の面談 (Voyage さんは最低2名で1時間半)
  • 面談終了後 merge-request のコメントに講評を書いて、上長に連絡
    • トライアルなので今回は「参考」と言うかたち、「評価のバイアスがかかるかもしれないくらいにしておいてね」とのこと
  • 技術力評価トライアル完了後にアンケートを回収 (アンケート項目については後述)

評価に際して

  • キャリアマップ
    • キャリア・アンカーをベースとして、技術に対する指向、姿勢を 3 (技術獲得・技術活用・技術管理) x 3 (挑戦・自律・安定) で分類したもの
  • 「採点」が目的ではなく、成長につながるような指摘やサジェスチョンをすることを主眼にした
    • 「ここができていないので、こういう風にやるとよい/このヒトが得意だから師事するとよい」とか「これはできてるんだけど、こういうこともできるとすごく信用できるようになる」とか

評価観点

  1. 価値観点
    • QCD / 技術起点の新規価値 / 迅速改善フレーム / 市場インパク
  2. グレード
    • トレーニー/一般/上級/リーダー
    • これは初期、明記してなかったけれど、面談が進むに連れて評価観点に入れた

技術力評価をやってみて(評価者観点)

  • 面談の時間は30分なら大したことはない
  • 事前のレビューがとにかく大変
    • なんだかんだ1人あたり最低30分、長い場合だと1時間半とかかかる
    • merge-request の場合は、コミットメッセージ自体・内容を表現しているかとか、実際のコードを見ればよいので楽
    • プロダクトの場合は、その全体像を把握するところから始まるので目を通す範囲がでかい
    • 自分が得手ではない言語の場合はパッケージ管理とかそういうところから始まるし、見たことがないモジュール (テストフレームワークとかもある) の使い方を調べて可読性や利得(テストを書くべきかどれくらい書くべきか)を見たり、そもそも言語の地域方言とか慣習を調べるところから始まるのが相当コスト高い
    • 中にはミドルウェアが含まれているものとかがあったりして、そうなるともう地獄
    • 大変だけど、これこそが納得力の源泉でもあると感じてる。あえてやるなら、1人で10人とか見ないような座組を考える
  • 最初、価値観点だけを想定していたんだけど、2年目の新人とかもいるとそういう観点ではまだ評価できないことが見えてきたので、グレードに応じてコメントするようにした

技術力評価結果アンケートの項目とまとめ

項目 1をつける項目 平均スコア 5をつける項目
今回の技術力評価の満足度を教えてください 不満足 3.9 満足
技術力評価自体の取り組みは継続してほしいですか 希望しない 4.2 希望する
評価者は適切でしたか 不適切 4.1 適切
評価者の所属について 自部署を希望 3.4 他部署を希望
評価は納得性がありましたか 納得していない 4 納得できた
評価者の人数は何人がよいですか 2
面談時間はいかがでしたか 短い 2.6 長い
フィードバックは成長につながると感じますか 感じない 4.2 感じる
事前の面談シートの記載量はいかがでしたか 少ない 2.8 多い
公開で実施することはいかがでしたか 非公開を希望 4.6 公開を希望
定量的な評価(例えば点数)を希望しますか 定性的 3.1 定量

まとめ

  • 取り組みとしては満足している、また継続を希望されていることがわかったのでやってよかった
  • 評価者は2人希望していて自部署と他部署1名ずつの希望されていた
    • 協力者(評価ができるヒトリストを作る必要があるなぁ
  • 事前のレジュメ記入量/面談時間については適切 (m-r で送り、30分間の面談)
  • この中で最も最高点だったのが「公開でのやり取りを希望する」というのが非常に驚きだし、心理的安全性が担保されてる一つの現れとして見えてとてもうれしい
  • 定量的な数値も欲しいと感じている。これはやっぱり難しいところだけど希望する人がいるので、なんか考えることが宿題
  • 「評価者もまた評価されている」という言葉通り、すっごい怖かった。けど、アンケートの結果をみて胸をなでおろした

  • 技術力評価に納得いってないってメンバがいたんだけど、その後にもう一度フィードバックをして、納得行くまで話すことができた。トライアルはこういうのがホント大事だと思っているので、そこまで含めて、トライアルやってよかったと思う。

今後について

  • キャリアマップをもっと活用して技術獲得・技術活用・技術管理それぞれの指向に対して、それぞれグレードを定義したい
    • 例えば技術活用の場合は「タスク(ストーリ)を任せられる」「プロダクトを任せられる」「俯瞰的なプロダクトアーキテクチャができる」とか、なんかそういうやつ
  • 評価者のリストを集めたい
  • 評価者を評価する座組も欲しい