目標管理制度（笑） - カレーなる辛口Javaな加齢日記

「ITエンジニアの評価制度をどげんかせんといかん」http://kheiakiyama.hateblo.jp/entry/2013/12/22/145210
「目標管理シートドリブン開発はくそ」http://razokulover.hateblo.jp/entry/2013/12/20/084359

目標管理シートドリブン開発はくそ - razokulover publog
を読んで同意しました。

とりあえず，

作者: 城繁幸
出版社/メーカー: 光文社
発売日: 2004/07/23
メディア: 単行本
購入: 9人クリック: 261回
この商品を含むブログ (206件) を見る

でも読むと参考になると思うよ．*1

その辺りの話は，日本だとバブル崩壊後の1990年代に，既に試してみて盛大に失敗した典型的なバッドプラクティス．もし未だに同じ失敗を繰り返してる経営者がいたとしたら，とても恥ずかしくて外部の人には見せられない．

新制度導入後は，それまでチームで一つの成果を上げていた社員が，自分だけの目標に固執するようになった．この弊害がいちばん大きいですね．そもそも何が必要な作業かなんて，実際にやってみないと分からない．なのに，半年も前に目標として取り込めと言われても絶対に無理ですよ．
実際の現場では，「目標シート」に書けない隙間業務の方がむしろ多い．トラブルや仕様変更があれば，日々そういう「誰の目標にも書かれてない仕事」が発生する．でも，誰も自分からはそういう仕事をやろうとしなくなった……．職場の雰囲気はたった1年でガラリと変わってしまったんですよ．

この結果，「目標管理制度」は，全社あげての「一大減点レース」と化した．
上司との面接時に「明らかな失敗」さえなければ，普通に目標達成と認めて貰える．当然，誰もが失敗の可能性の少ない，あるいはすぐにでも達成できる目標を選ぶ．やりがいがあるが達成が難しい目標などは選ばない．
（中略）
こうして，危険な香りのする業務は，誰も目標としなくなったのである．
この点は，従来から高い目標を設定し，高い成果を上げていた上位層も変わりが無かった．もちろん，管理職によっては部下に高いハードルを与えようとする者もいたが，その結果は，彼の部下だけがボーナスで泣きを見るだけのことだった．

数字が引っかかっている人に対し「残業30時間なのにＡはないでしょう」などと，評価替えをするのである．つまり，目標が達成されていたかどうかなどはほとんどノーチェックであり，シートにある評価のＡやＢと，残業時間，年次有給休暇の消化日数，勤怠状況を付け合わせるだけだった．
「これでは目標管理なんて有名無実ではないか」
と思ったが，そんなことを口に出せるような時間的余裕も，精神的余裕も私にはなかった．

そもそも二時間の会議で全員の目標なんて見てられないし，難しい用語が多くて意味が分からないんだよ．

技術系の事業部の場合，そもそも決定権者である事業部長クラスの人間は，最新の専門用語の飛び交う中堅社員の目標シートなど，まともに読めないケースがほとんどだった．

あれ？ひょっとして「はてなブログ」はまだトラックバックがないの？一体いつになったらトラックバック対応するんだ．いくらなんでも遅すぎだろう．*2

http://b.hatena.ne.jp/entry/kheiakiyama.hateblo.jp/entry/2013/12/22/145210

id:DustOfHuman 評価って給料上げない為にやるもんなんで(震え)

id:wasai うちなんて形式だけで中身なんて何もないしなぁ

id:naoto5959 はっ、目標立てる式の謎の評価基準ある会社の社長、たいてい営業出身かも

id:coolstyle 新卒で入った会社がこんなだったな。ほんとクソな会社だった。すぐ辞めたけど

id:beakmark そうね。特に定量的とやらにするために無理しゃり数値で設定とかすると最悪。／

id:kiyo_hiko 上司が評価してくれないよりも、クラスの設計方針とかで困ったときに相談できないのがつらい

id:tenjin68k 誰もが納得する評価制度はムリだと思う。公正な評価が欲しければ個人商店を営むしかない。

id:lestructure 評価制度を理解していない。たまにおかしな評価があるだろうけど、大抵は正しく評価されているよ。それでも多くの人が納得しないんだけど、皆が納得するとかあり得ない。すごく儲かっている所ならあるかもだけど

使い古された典型的な詭弁術の一つ．二十年ほど後れてる．

誰も「全員が納得できる評価制度」なんて求めてない*3．「目標管理」というのが開発現場における失敗制度というだけで，それよりマシな制度はいくらでもある．

id:m_shige1979 顧客にとってはコードを多少うまく書けることはあまり好評価ではなく、プロジェクトを如何にうまく成功させることができるかでしょうから…

評価は顧客がするもんじゃないよ．

IT企業においてはプロジェクトを成功させる必要があり，そのためにはコードを上手く書ける能力が必須となる．だからコードを上手く書ける人に高評価を与えられない評価制度は，間接的にプロジェクトの失敗要因となっている糞制度という話．

id:sawarabi0130 最近のMS等を見ていて思うのは、技術でなく顧客のニーズを汲み取る能力を評価すべきだということ。自己満足に終始するエンジニアのなんと多いことか。売って継続受注してなんぼ。顧客の求めていない技術なんて無駄。

同様によくある詭弁．評価は外部の顧客がするものではない．これは社内の評価の話で，完全に的外れな指摘．

日本「半導体」敗戦でも取り上げられてるように，マーケティングはたしかに重要．しかしそれはマーケティング部門の評価に取り入れればいい話であって，全ての技術部門がやるべきことではないし，全ての技術部門の評価に必要な物でも無い．*4

現場レベルでは，既にその仕事を受けることが決まっていて，契約上やらざるを得ない段階になってることが一般的．「この仕事はマーケティング的に見て，意味の無い仕事だからやりたくありません」が受け入れられることはない．顧客のニーズをくみ取るとか，それは俺達の仕事じゃねーし，経営者だってそんなんこと言われたら困るだろう．*5

そもそも大半の日本企業にはマーケティング不在が問題の一つ．なんでもかんでも技術者に丸投げすんな．やって欲しいなら，その分給料くらい上げろ．

http://b.hatena.ne.jp/entry/razokulover.hateblo.jp/entry/2013/12/20/084359

id:terazzo 自分が書いてたのは実績記入時に目標変更可能だったよ。半年後に必要なものなんか分からないしね。変更理由は必要だったけど。でもそれなら最初から実績だけ記入でいいか。

id:Chisei 半期に一度、もしくは四半期に一度目標を立てたところで外部要因なんて変化しまくりなので目標管理シートに記載したことって既に古いものになってるんだよね。