エンジニアなら一度は悩んだことがあるんじゃないでしょうか？
私もつい先日まで目標設定に頭を悩ませていました。
来期の目標設定も震えています。
「目標管理は技術者にはク〇」というスライドが最近話題になりましたが、なぜエンジニアの目標設定が難しく感じてしまうのか考えてみることにしました。
なぜ難しいか
基本的にチームで開発していることを前提として考えてみます。
定量的に評価しづらい
まず、これに尽きると思います。
営業職のように「今月は契約〇件！」というのが決めづらいです。
エンジニアが目標設定として挙げる定量的な指標といえば
- 対応したタスクの数
- コミット数
- コード行数
- テストカバレッジ
- パフォーマンス改善
- デプロイ頻度
etc...
という感じでしょうか。
例であげたものだけですが、定量目標として適切かを考えてみると
- 対応したタスクの数
- タスク毎の工数が異なる(簡単なタスク、難しいタスク)
- 緊急対応が入る場合もある
- コミット数
- 意図的にコミットを細かくできる
- コード行数
- 意図的にコード行数を増やすこともできる
- テストカバレッジ
- カバレッジが良い=ビジネスロジックをテストで全て網羅している ではない
- そもそもの実装に考慮漏れがあればテストの意味がなくなる
- パフォーマンス改善
- 改善した内容がどれほど影響を与えたかを計測する必要があり、計測が難しい
- デプロイ頻度
- チームのパフォーマンスに左右される
不適切とはいかないまでも、正確に目標を評価できなさそうです。
ある程度ルール化できれば、それなりに評価できそうですが、悩ましいものです。
売上に直結しづらい
エンジニア個人がタスクをこなしていくうえで、売上につながることがあるかというと、そうではないことが多いと思います。
この機能を追加したら、このバグを修正したら売上が上がる！ということがあったとしても、そもそもの仮説と検証はすでに終わっていることが多く、(多少口を挟むことはあると思いますが)我々は実装をするのみです。
我々がその機能を作ったから、バグを修正したから売上が上がったとは言えないでしょう。
仮説と検証〜リリースまでのフェーズを全て担当して、かつ結果が出てこそ、売上に直結したと言えそうです。
優先順位の変動
例えば、目標を「〇〇プロジェクトを完遂する」にしたとします。
経営状況や他案件の優先順位によっては〇〇プロジェクトの優先度が下がる場合もあるでしょう。
「〇〇プロジェクトが達成できていないので今期あなたの評価はできません」は勘弁して欲しいものです。
そもそもプロジェクトの達成は個人よりチームでの成果に近いですね。
予測不可能な障害
障害予測ができたら、なんと嬉しいことでしょう。
何時何分何秒に障害が発生します！なんてことはあり得ません。
障害は我々が意識していないタイミングで急に現れます。
前兆を掴むことはある程度できそうですが、その前兆も大体急に訪れます。
その対応は誰が行うか、我々エンジニアでしょう。
サービスを早急に復旧させるため、手持ちのタスクはストップせざるを得なくなります。
そしてストップした時間、障害対応は考慮・評価されないことが多いのではないでしょうか。
(ただ評価の対象とするとマッチポンプされる可能性もあるかも...？)
スキルレベル
スキルレベルを測ることがそもそも難しいですよね。
スキルといっても技術的なものだけでなく、コミュニケーション能力などの対人に関わることもあります。
まあでもこれに関してはどの職種も同じかもしれません。
営業職の方で最初のアポイントメントがうまかったり、契約までの持っていき方がうまかったり。
頭の上にレーダーチャートでスキルレベルを出して欲しいものです。
じゃあ目標なんていらないのでは？
と思いますが、目標がないと何が困るのか考えてみます。
何を頑張ればいいのか明確にならない
何も言われなくてもキャリアパスが明確になっており、成長し続けられる超人は除きます。
言われなくても成長できるんじゃね？と思う人も多いのではないでしょうか？
私は超人ではないので、自分のキャリアを漠然とイメージしがちです。
そんなタイプの人には目標はあったほうが何を頑張ればいいのかが、目標がない場合より明確になると思います。
ただこの場合は多少抽象的でも適切な目標設定が必要です。
正しい目標設定ができていれば目標を達成した(あるいは達成に近い状況になった)時点ですでに成長しているはずです。
評価の最終決定がしづらい
評価者や評価を査定する側の都合ですが、もっともな意見です。
目標があって今期はどれだけ達成できたかを振り返り、フィードバックしたほうが評価しやすいです。
目標が設定されていない場合は、「今期オレはこれをやった！」とアピールすることしかできないので、評価基準がなく、評価が難しいです。
評価者との間では主観が入るので「今期はよく頑張ったな！」となりそうですが、これが評価を査定する部門(人事部とかそれ以上の部門)まで上がっていくと、「(この人はどの程度のことを達成しているのか...)」と漠然としていまい評価がしづらそうです。
会社の規模がどんどん大きくなっていくと、ますます大変そうです。
結局どうするべき？
私個人の意見としては、最終的な評価に納得感があれば目標はあってもなくてもいいと思います。
ただ目標をなくしたとしても評価の基準はできるだけ明確にしたり、現況と途中評価の認識を合わせる工夫はするべきだと思います。
評価には評価者の主観が間違いなく入ってしまいますので、評価者との認識がズレていると評価時に絶対揉めます。
認識のすり合わせ
週、月単位で行われることが多い1on1ミーティングの機会で認識を合わせていくのが一番手っ取り早いのではないでしょうか。
評価される側は自分の状況を共有しながら、評価される方向性で作業できているか確認できます。
評価者は評価される側の状況を知り、現状の評価を共有できますし、方向性が間違っていれば、修正の提案もできます。
この時間を使って小さな目標を立てる、また小さな目標を立てるというのを繰り返していくのもいい方法だと思います。
短い期間であれば達成すべきことを具体的に決めておくのは難しくは無さそうです。
スキル標準の定義
このレベルであればこれができるというスキル標準は作成しておくべきだと思います。
多少抽象的なスキル標準でも、そういう人材になってほしいという人物像はイメージしやすくなりますし、評価の基準にもなります。
評価されることだけしてていいのか
それも違うと思います。
会社という組織に属している以上、個人の成果より会社としての成果を最大化するべきです。
評価対象とはならない可能性のあることでも、やってみた結果、効率化に繋がったり、大きな成果になったりすることも多いにあります。
我々エンジニアはどれだけ非効率なことを無くせるかの世界で生きているようなものなので、将来的な生産性に影響を及ぼすようなことはどんどん提案して実行に移すべきです。
そして、成果につながったということが明確になるのであればそれは評価の対象とするべきです。
あんたはどうだったんだい
私の場合は...
最初に上長から今期の会社の方針と将来的に目指して欲しい姿について丁寧に説明していただきました。
そこでの疑問や腹落ちしないことは何度も話し合って目標に関して理解が深まるように協力していただきました。
そのプロセスを経た結果、自分の成長ポイントを明確にでき、目標に落とし込むことができました。
この状況は本当に恵まれていると思いますし、上長には本当に感謝しています。
まとめ
重ね重ねですが、評価者と評価される側が評価に対してお互いに納得感を持つことが大事です。
目標があってもなくても会社としての成果の最大化と個人の成長ができるのであれば、手段はなんでもいいんだと思います。
参考
参考にさせていただきました、ありがとうございます！
Discussion