『数字はセンサー、評価は文脈を知る人の目で』は正論だが、その文脈を持つ評価者が育たない組織ほど数字評価に逆戻りする。文脈を維持するコストこそ本丸では
測った瞬間に指標が壊れるグッドハートの法則はその通り。PR数で評価すると細切れPR増えるだけだしな
でも評価指標はアクティビティとアウトカムそれぞれ評価してるじゃん
そりゃその人がいなかった時のコストや損害や利益を足して数値化する
分かりやすい指標のベロシティで判断しがちだが、プロパーフルタイム社員であれば安定性や進捗が見える状態で仕事しているかが超重要。頻繁に打合せを体調不良で欠席したりチケット抱えて休む人は仲間としてキツい
順番が逆では。先に評価対象にする成果指標を決めないからこんな話を延々としているだけ。コード量で評価するって言うならコード量見りゃいいし、サービスのDAUだというならそれを見ればいいだけ。
しっかりしたレビュー通ってる状況なら、コード量でもPR数でも一定の成果は測れるのでは？／すでに凄い人って認識ある人が10万行って言えば…スゲーなってなるしね。結局ビジネスと繋げる指標じゃないとダメでしょう
指標がタイピング数は最悪の部類
エンジニアとして大抵の成果が出る場所は散歩中、ウンコ中、サウナ中とかだからな？
評価は給与に反映するためにする。ITエンジニアはどうせ転職するし、しない人は同じ給与でも被雇用し続けてくれそう。気が合うとか一緒に仕事がしたいかどうかでいいんじゃないか。
納得感のある記事だと思った。活動量とアウトカムにはタイムラグがあるからこそ評価が難しいんだよな。
勤怠しっかり目の人って、もっと評価されてもいいとは思うが、ま、そんなの当たり前だろで、一蹴されるだろうな
イーロン方式（仕事から外してみて、周りから悲鳴が上がったら必要な人材だと判断する）は確実だけどデメリット大杉だしのう。しかも「必要な人材」より「必要な仕事」の検出に重きを置いてそうだし。
数字に繋がりにくい大事な仕事もあるしね……他にも、あの人がいると恙なく回る的なやつとか
で、評価面談で何て答えればいいのですか？
正しく評価するってのが無理ゲー
諦めよ？めんどくさい
成果なんてボクに撫でられて測ればいいのに！カリカリもっともらえるかにゃ？
野球みたいな個人成績（＝能力）の単純な和で結果が決まるようなら数値評価もいいんだけどな
「「何をしたか」ではなく その結果、何が変わったか で語り直す」「行数・PR 数・タイピング数は活動量であって、成果の途中経過」「指標を評価に直結させると、グッドハートの法則で歪む」「DORA 」「SPACE」
「タイピング数は連鎖の右端のさらに外側、成果からもっとも遠い数字」・・・あれ・・・上場企業が採用しているKPIだったような・・・
この人AIで書いてるけど随分うまくなったなー。まぁまだAI臭い部分があるけど
よく「数値化できる目標」を求められますけど、結局、従業員の業務を理解する人が主観的に評価するしかないんですよね。それ以外はでたらめな指標になってしまう。報酬を他部署と取り合うために必要なんでしょうけど
「測れないものは測れないと認める」ってそりゃそうだよな。事実を認めないのは現実逃避。何も良くならない。
"順番が逆では" 本文読め。まさにそれがグッドハートの法則やんけ
消化チケット数とかじゃだめなの？
デザイナーの評価も数値化しづらい。参考になった。
時間と燃費じゃね。アウトプットが何のためのものかを理解してるかしてないか。
測れる数字の評価が過大になって本来の目的がおろそかになるのは、『測りすぎ』の本の中であらゆる組織で起こってしまう悪現象とあったな。//ブコメトップがまさに本文を読んでないものでなんというか。
人的評価を成果物でしか見ないのがおかしい。毎日出勤して仕事に従事してくれてりゃ100点でしょうが。測る指標がなければ0点か？
数値化して測れるのならエンジニアリングマネージャーは要らないのです。
残念ながら計れない, 以上。 冷静に考えて n次元ベクトルを1次元の「給与」みたいなモノへの写像ってだけで無理があるのはしょうがなくて, 結論は「皆良い感じに仲良くしよう」とか見も蓋もない物しかない気が...
会社側が採用したエンジニアに何を求めているか期待しているかが曖昧だから評価がトンチンカンになる。やることが決まっておりそれがクリアされたならステイ。力不足で遅れたらマイナス。会社の無理を聞いたらプラス
高速化でコード量が減っても他の人が読んでも？なコードになったり、新しい製品出しても使用者の不満が爆発させた人を知ってる。一つの数値で機械的ではなくManager が優秀な目を持って判断するしかない。
これは「当社は成果と賃金は連動してません！」と真実を言えば終わること。逆に「クリック数で賃金が決まります！」「出社と笑顔で決まります！」で本当に賃金払うなら、クリック＆スマイルでみんなハッピーでしょ
営業などと違って数値で測るのが難しい部分があるからねぇ。成果指標が定まらない企業ではだめだろうな。なおエンジニアと一括りにせずこの場合はソフトウェア開発者もしくはITエンジニアなどにしないと。
記事にあるとおり役割・期待値によって目指すべき指標は異なるので、それを期初に目標として設定し、評価でいきなり「今期、あなたの成果は何でしたか？」とならないように(マネージャーが)すべきでもある
目標設定なしに成果を測ろうとしてる気がする。成果はなにを期待されていたかによるのでは。
神のみぞ知る
目標と計測は必要だけどそれと評価は切り分けよう。評価はお気持ち100％でいいよ、もう。めんどい。
人は見えるものしか見えないって、別に面白いことでもなんでもないと思ってしまった。だからこそ見るための方策として見せ方だの見える化だの可視化だのの言葉使ってやってきたのよね。
計測不要派のうち、従業員に向き合えておらずかつ十分な給料を払えない会社が問題。ろくに個人目標設定も合意できず、門外漢が人月で評価する組織は外部SIerに発注しているようなもの。
短期の仕事でも長期の仕事でも、それぞれの仕事自体の価値は上で決めるしかない。直接的な機能開発以外の貢献を測りにくかったが今はAIがある。SlackもGemini議事録もあるんだから貢献度をAIが出して相対評価でいいよもう
明確な指標化はしていないが、プルリクに対する指摘の少なさや、バグの少なさ、難易度やインパクトあたりは考慮している。
担当者ごとに評価軸が違うはずで、測定できたところでその指標を比較できるのかという問題があるよな。アプリ制作チームは生産量が指標になるかもしれないがセキュリティ担当者は生産しないだろう。
Personal Software Process で記録させて申告させて、業務命令を出した人が判断するしかない。あとはその人の責任。
まあどう考えても測れないので、マネージャーが気持ちで決めるしかないんだろう。仮に有能だけど嫌いな人を低く評価して、転職されたりチームが劣化したときには結局マネージャーが低評価されるから罰則はあるし。
ソフトウェアエンジニアのことをエンジニアと呼ぶ事案がどうしても気になる
愚痴ばっか多いけどやることやってるメンバーいて評価低いんだけど難しいとこよな。指標はいいのに印象が悪い。結局雰囲気で査定される
プログラムは短いコードでも性能がいいことは普通にあるけど、バイブコーディングは短いコードで性能いいことあんまりない気がする…
測れない
遅刻しないとか、メンタルクラッシュしない。とかでいいじゃないの。
エンジニアの成果、結局どう測ればいいのか
『数字はセンサー、評価は文脈を知る人の目で』は正論だが、その文脈を持つ評価者が育たない組織ほど数字評価に逆戻りする。文脈を維持するコストこそ本丸では
測った瞬間に指標が壊れるグッドハートの法則はその通り。PR数で評価すると細切れPR増えるだけだしな
でも評価指標はアクティビティとアウトカムそれぞれ評価してるじゃん
そりゃその人がいなかった時のコストや損害や利益を足して数値化する
分かりやすい指標のベロシティで判断しがちだが、プロパーフルタイム社員であれば安定性や進捗が見える状態で仕事しているかが超重要。頻繁に打合せを体調不良で欠席したりチケット抱えて休む人は仲間としてキツい
順番が逆では。先に評価対象にする成果指標を決めないからこんな話を延々としているだけ。コード量で評価するって言うならコード量見りゃいいし、サービスのDAUだというならそれを見ればいいだけ。
しっかりしたレビュー通ってる状況なら、コード量でもPR数でも一定の成果は測れるのでは？／すでに凄い人って認識ある人が10万行って言えば…スゲーなってなるしね。結局ビジネスと繋げる指標じゃないとダメでしょう
指標がタイピング数は最悪の部類
エンジニアとして大抵の成果が出る場所は散歩中、ウンコ中、サウナ中とかだからな？
評価は給与に反映するためにする。ITエンジニアはどうせ転職するし、しない人は同じ給与でも被雇用し続けてくれそう。気が合うとか一緒に仕事がしたいかどうかでいいんじゃないか。
納得感のある記事だと思った。活動量とアウトカムにはタイムラグがあるからこそ評価が難しいんだよな。
勤怠しっかり目の人って、もっと評価されてもいいとは思うが、ま、そんなの当たり前だろで、一蹴されるだろうな
イーロン方式（仕事から外してみて、周りから悲鳴が上がったら必要な人材だと判断する）は確実だけどデメリット大杉だしのう。しかも「必要な人材」より「必要な仕事」の検出に重きを置いてそうだし。
数字に繋がりにくい大事な仕事もあるしね……他にも、あの人がいると恙なく回る的なやつとか
で、評価面談で何て答えればいいのですか？
正しく評価するってのが無理ゲー
諦めよ？めんどくさい
成果なんてボクに撫でられて測ればいいのに！カリカリもっともらえるかにゃ？
野球みたいな個人成績（＝能力）の単純な和で結果が決まるようなら数値評価もいいんだけどな
「「何をしたか」ではなく その結果、何が変わったか で語り直す」「行数・PR 数・タイピング数は活動量であって、成果の途中経過」「指標を評価に直結させると、グッドハートの法則で歪む」「DORA 」「SPACE」
「タイピング数は連鎖の右端のさらに外側、成果からもっとも遠い数字」・・・あれ・・・上場企業が採用しているKPIだったような・・・
この人AIで書いてるけど随分うまくなったなー。まぁまだAI臭い部分があるけど
よく「数値化できる目標」を求められますけど、結局、従業員の業務を理解する人が主観的に評価するしかないんですよね。それ以外はでたらめな指標になってしまう。報酬を他部署と取り合うために必要なんでしょうけど
「測れないものは測れないと認める」ってそりゃそうだよな。事実を認めないのは現実逃避。何も良くならない。
"順番が逆では" 本文読め。まさにそれがグッドハートの法則やんけ
消化チケット数とかじゃだめなの？
デザイナーの評価も数値化しづらい。参考になった。
時間と燃費じゃね。アウトプットが何のためのものかを理解してるかしてないか。
測れる数字の評価が過大になって本来の目的がおろそかになるのは、『測りすぎ』の本の中であらゆる組織で起こってしまう悪現象とあったな。//ブコメトップがまさに本文を読んでないものでなんというか。
人的評価を成果物でしか見ないのがおかしい。毎日出勤して仕事に従事してくれてりゃ100点でしょうが。測る指標がなければ0点か？
数値化して測れるのならエンジニアリングマネージャーは要らないのです。
残念ながら計れない, 以上。 冷静に考えて n次元ベクトルを1次元の「給与」みたいなモノへの写像ってだけで無理があるのはしょうがなくて, 結論は「皆良い感じに仲良くしよう」とか見も蓋もない物しかない気が...
会社側が採用したエンジニアに何を求めているか期待しているかが曖昧だから評価がトンチンカンになる。やることが決まっておりそれがクリアされたならステイ。力不足で遅れたらマイナス。会社の無理を聞いたらプラス
高速化でコード量が減っても他の人が読んでも？なコードになったり、新しい製品出しても使用者の不満が爆発させた人を知ってる。一つの数値で機械的ではなくManager が優秀な目を持って判断するしかない。
これは「当社は成果と賃金は連動してません！」と真実を言えば終わること。逆に「クリック数で賃金が決まります！」「出社と笑顔で決まります！」で本当に賃金払うなら、クリック＆スマイルでみんなハッピーでしょ
営業などと違って数値で測るのが難しい部分があるからねぇ。成果指標が定まらない企業ではだめだろうな。なおエンジニアと一括りにせずこの場合はソフトウェア開発者もしくはITエンジニアなどにしないと。
記事にあるとおり役割・期待値によって目指すべき指標は異なるので、それを期初に目標として設定し、評価でいきなり「今期、あなたの成果は何でしたか？」とならないように(マネージャーが)すべきでもある
目標設定なしに成果を測ろうとしてる気がする。成果はなにを期待されていたかによるのでは。
神のみぞ知る
目標と計測は必要だけどそれと評価は切り分けよう。評価はお気持ち100％でいいよ、もう。めんどい。
人は見えるものしか見えないって、別に面白いことでもなんでもないと思ってしまった。だからこそ見るための方策として見せ方だの見える化だの可視化だのの言葉使ってやってきたのよね。
計測不要派のうち、従業員に向き合えておらずかつ十分な給料を払えない会社が問題。ろくに個人目標設定も合意できず、門外漢が人月で評価する組織は外部SIerに発注しているようなもの。
短期の仕事でも長期の仕事でも、それぞれの仕事自体の価値は上で決めるしかない。直接的な機能開発以外の貢献を測りにくかったが今はAIがある。SlackもGemini議事録もあるんだから貢献度をAIが出して相対評価でいいよもう
明確な指標化はしていないが、プルリクに対する指摘の少なさや、バグの少なさ、難易度やインパクトあたりは考慮している。
担当者ごとに評価軸が違うはずで、測定できたところでその指標を比較できるのかという問題があるよな。アプリ制作チームは生産量が指標になるかもしれないがセキュリティ担当者は生産しないだろう。
Personal Software Process で記録させて申告させて、業務命令を出した人が判断するしかない。あとはその人の責任。
まあどう考えても測れないので、マネージャーが気持ちで決めるしかないんだろう。仮に有能だけど嫌いな人を低く評価して、転職されたりチームが劣化したときには結局マネージャーが低評価されるから罰則はあるし。
ソフトウェアエンジニアのことをエンジニアと呼ぶ事案がどうしても気になる
愚痴ばっか多いけどやることやってるメンバーいて評価低いんだけど難しいとこよな。指標はいいのに印象が悪い。結局雰囲気で査定される
プログラムは短いコードでも性能がいいことは普通にあるけど、バイブコーディングは短いコードで性能いいことあんまりない気がする…
測れない
遅刻しないとか、メンタルクラッシュしない。とかでいいじゃないの。