再演: エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ に参加しました

connpass.com

参加しました。

エンジニアの技術力評価は難しい? @makoga

  • 自分のアウトプットをテキストにまとめる技術
  • 1時間半で説明する技術
  • 「どういう会社にしたいか」を経営層とディスカッションした(事業・サービスの理解度、プロジェクトごtの要件・制約の理解度)
    • グレードの高いエンジニアは「理解度が高い」
      • これを文化として根付かせたい
  • 短期的なアウトプットをもとめると優先度が下がりがちな「セキュリティ」「テスト容易線」は重要視したい
  • 点数とテキストの両方で評価結果をテンプレ化
    • ルールで縛ることも考えるが、「ルール守ってるんですが」のような思考停止をさせないことが大事

2年やって

  • 実現力と改善力
    • 実現力: スコープ定義/システム構築/プロジェクトマネジメント
    • 改善力: システム的な改善/ビジネス的な改善
  • 用語から文章に変更した
    • 「妥当か?」とか
  • コードレビューから「事業を支える技術」という本質的な議論ができる場になった
  • 評価をオープンにすることで評価者が真剣に取り組むようになった「評価者もまた評価されている」
    • 点数をやめて、納得するようにコメントを書くようにした

制度を改善するコツ

  • 企業文化や戦略に基づきながら改善
  • ケツ持ちを明確にする (CTO が死ぬ)

パネルディスカッション

  • @t_wada (モデレータ)
  • @teppeis
  • @mirakui
  • @makoga

まとめ

新規フェイズ(0➜1)なのか、成長フェイズ(1➜10)の組織なのか、運用フェイズ(10➜1000)の組織なのかで全然違うと思うし、組織が抱えるスペックが育成なのか力を発揮するフェイズなのかにも依存するから、自組織と向き合ってフィッティングしていく能力が求められると思う

組織が「ヒトを投資対象としてみるか」「コストとしてみるか」が大きな分岐点で、人材育成に対して「費用対効果」を問うか、「当然すべき手続き」として捉えるかでその姿勢を見ることはできると思う。有りがちなのが組織としてではなく、声のでかい既得権益を持ったおじさんがそれを問うてくることがあって、そのおじさんをなぎ倒す方法はまた一つじゃないから難しい。

その一つの方法として「な、これだけ改善しているんだから、価値あるんだよ」を定量的に見せるのはわかりやすい方法だとは思う。 本質的に、 @katzchang さんがおっしゃっていた「成長を促す行為と実際に促された」ことだけを定量化すればいいとは思う。

(「項目くらい採点基準が明確じゃない人事評価」にもかかわらずそもそも「その技術的な観点での採点の基準て適切なの?」ってのを聞いてくるおじさんはいろいろなぎ倒したい所存

オープンなことは組織成員が許容できるのであれば、本当に素晴らしい効果があると思う。 たぶん、今後考えていかないといけないのは、「では、どのようにすれば、オープンなことを許容できる組織になるか」だと思うし、1つの指針としては心理的安全性だったりだとは思う。 この心理的安全性を実現する方法自体もまた、組織のフェイズ・規模・スペックに応じて変わってくるから、適切なメソドロジを蓄積していくことが、人事・マネージャの仕事だと考えている、というところで勉強になった。