【SMART】エンジニアの考える人事目標設定【KPI】

【SMART】エンジニアの考える人事目標設定【KPI】付加価値
スポンサーリンク

はじめに

組織に於ける人事目標設定に対する私個人の見解となる。
当然、賛否両論はあると思ってる。

その他の付加価値系記事
https://www.simulationroom999.com/blog/category/miscellaneous-notes/added-value/

スポンサーリンク

発端

勤めている会社にて人事目標設定期間に突入。
目標設定自体が難しいことは知っているが、やや思考停止が目立つ。

  • 結果的にどうなるかわからないので、目標設定できません。
  • 目標よりも、実際にやったことを評価してくれ。

気持ちはわからなくも無いが、同じ「やる」にしても、「目標を持った上の成果」と、「できたところまでが成果」では、その後の改善の部分で大きく差が開く
「できたところまでが成果」では、そこで終了してしまうことが多いが、
「目標を持った上の成果」では「XXが足りないから、そこを補填するとうまく行くはず」「YYの部分が改善できればもっと良い成果になったはず」などの予実評価することによる次への改善活動を考えることができる

また、重要なのは目標設定そのものではなく、

  • その目標を設定するに至った理由(内部要因、外部要因)
  • 目標達成までのシナリオ

である。

これがあると、失敗したとしても失敗理由が把握し易い
つまり、目標を持つということは、失敗しても得られるものを確実に得て、失敗経験の価値を最大化することである。
失敗を帳消しにしても御釣りがくるような大成功を導き出すための、最初の一歩ということになる。

つまり、成功前提の活動ではなく、失敗前提且つ失敗を最大活用するための活動と思った方が良い。
当然、成功するに越したことは無い。成功した場合も局所的な失敗経験の価値を最大化することを忘れなければ。

とりあえず、目標設定と達成水準の考え方とやり方をゆるーい感じで書いていく。

スポンサーリンク

主な登場人物

博識フクロウのフクさん

イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1

 

 

エンジニア歴8年の太郎くん

イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1

スポンサーリンク

エンジニアにとっての評価に対する理想と現実のギャップ

エンジニアにとっての評価に対する理想と現実は以下になると思われる。

【理想】

太郎くん
太郎くん

目標設定とかいいから、
俺の技術力を評価してくれ。

 

【現実】

人事
人事

(・・・失礼な奴だな)
ちゃんと目標設定して、数値で評価できるようにしてください。

太郎くん
太郎くん

え~~~~。

スポンサーリンク

フクさんの人事目標設定講座スタート

フクさん
フクさん

エンジニアとしては、技術力で認めて欲しい
人事部門的には結果、特に数字で評価したい
技術力を数値化するには、技術力を評価する指標が必要。
しかし、そんなものはない。

太郎くん
太郎くん

あ。フクさん。

 

 
 
太郎くん
太郎くん

聞いてよー! 人事部門が意地悪するんだよ~~~

フクさん
フクさん
フクさん
フクさん

(別に意地悪ではなかろう)

フクさん
フクさん

まぁまぁ。

要は太郎くんも人事も納得できる目標設定できれば良いんだよね?

太郎くん
太郎くん

そんなのあるの?!

フクさん
フクさん

太郎くんにとって無条件でハッピーって感じは無いけど、

人事ないし組織が、どう個人を見てるかはわかると思うよ。

太郎くん
太郎くん

それでいい!それを教えて!

スポンサーリンク

組織から見た評価のポイントは何か?

フクさん
フクさん

エンジニアとしては保有スキルで評価してほしい。

しかし、それで評価すると、最悪のパターンとして

「成果が求められない組織」

になることがある。

太郎くん
太郎くん

まぁそうかも。

フクさん
フクさん

というわけで、どうしても成果(アウトプット)で評価しなければならない。

ここら辺が割と人事側とエンジニアで噛み合わない部分。

太郎くん
太郎くん

さっきの人事部門との会話そのものだ。

でも頑張っているんだから、その点を評価してもらいたいんだよ。

フクさん
フクさん

「頑張ってるから高評価にしてくれ」というのも分かるけど、

たぶん大部分の人は頑張ってると思うよ。

太郎くん
太郎くん

うーん、確かに。

フクさん
フクさん

そうなると、「みんな高評価=みんな低評価」となる。

太郎くん
太郎くん

しかもみんな、自分が一番頑張っていると思ってるから不満しか残らなそう・・・。

フクさん
フクさん

そして、組織としては貢献度で評価したくなる。
この貢献度というのが曲者。
貢献度は以下を指標にすると、評価する側としては分かり易い。

  • 売上
  • 利益
太郎くん
太郎くん

これは上司に良く言われているような。

フクさん
フクさん

エンジニアからすると、

ここを直接コントロールできる場合とそうでない場合がある
自分で案件とってくる技術営業であれば、

受注金額がそのまま売上となり評価にもなるので頑張りようもある。

しかし、

要件定義以降の開発プロセスの中で戦っている生粋のエンジニアの場合は、直接コントロールが出来ない

太郎くん
太郎くん

そうそう!売上、利益って言われても本当困るよ!

太郎くん
太郎くん

だったら、「プロジェクトを大黒字化する!」ってのはどう?

フクさん
フクさん

悪くはないけど、良くも無いかな。

太郎くん
太郎くん

どういうこと?

フクさん
フクさん

基本的に人件費はほぼ固定費なんで、一個のプロジェクトが大黒字でも実はそれほど売上、利益には影響が無いんだ。
プロジェクトが早く終わって暇になっても給料は基本変わらないでしょ?
であるが故に固定費なんだけど。

残業手当等は変動費になるけど、まぁ大概、管理上のコストは残業有り想定なことが多いので固定費と言い切っても良いと思う。

フクさん
フクさん

ただ、「万年赤字のプロジェクトを黒字化しました」であれば、利益貢献になるね。
また、このプロジェクトが毎回納期オーバーしていて、それも無くなるのであれば、機会損失抑制ということで結果的に売上貢献にもなるね。

太郎くん
太郎くん

うーん、そこまで激しい赤字プロジェクトというのも無いかなぁ。

というか巻き込まれたくない。

太郎くん
太郎くん

ところで、利益貢献、売上貢献がイマイチわからないんだけど。

フクさん
フクさん

じゃあ、そこから説明しようか。

コメント

タイトルとURLをコピーしました