エンジニアの成果、結局どう測ればいいのか

行数や PR 数が「嘘の指標」なのではありません。連鎖の右端にある 途中経過 なのです。 途中経過を最終成果のように扱った瞬間に、おかしなことが起こり始めます 。 測った瞬間に指標は壊れる おかしなことが起こる理由には、名前がついています。グッドハートの法則 です。 イギリスの経済学者が指摘した現象で、後に人類学者の論文に登場する簡潔な言い換えで広く知られるようになりました。 測定が目標になると、それは良い測定ではなくなる PR 数を評価に使えば、PR は不自然に細切れになります。行数なら、冗長なコードやコピペが増えます。ベロシティを目標にすれば、ストーリーポイントの見積もりが膨らみます。 誰も悪意はなくても、評価される数字に行動が最適化されるのは人間として自然なこと です。 社会科学には似た指摘としてキャンベルの法則もあります。定量的な指標が意思決定に使われるほど、その指標は腐敗圧力にさ

[favoriteonline]

順番が逆では。先に評価対象にする成果指標を決めないからこんな話を延々としているだけ。コード量で評価するって言うならコード量見りゃいいし、サービスのDAUだというならそれを見ればいいだけ。

[kobito19]

"順番が逆では" 本文読め。まさにそれがグッドハートの法則やんけ

[simplememofast]

『数字はセンサー、評価は文脈を知る人の目で』は正論だが、その文脈を持つ評価者が育たない組織ほど数字評価に逆戻りする。文脈を維持するコストこそ本丸では

[circled]

エンジニアとして大抵の成果が出る場所は散歩中、ウンコ中、サウナ中とかだからな？

[masatomo-m]

分かりやすい指標のベロシティで判断しがちだが、プロパーフルタイム社員であれば安定性や進捗が見える状態で仕事しているかが超重要。頻繁に打合せを体調不良で欠席したりチケット抱えて休む人は仲間としてキツい

[y_as]

イーロン方式（仕事から外してみて、周りから悲鳴が上がったら必要な人材だと判断する）は確実だけどデメリット大杉だしのう。しかも「必要な人材」より「必要な仕事」の検出に重きを置いてそうだし。

[toaruR]

数字に繋がりにくい大事な仕事もあるしね……他にも、あの人がいると恙なく回る的なやつとか

[showii]

この人AIで書いてるけど随分うまくなったなー。まぁまだAI臭い部分があるけど

[augsUK]

測れる数字の評価が過大になって本来の目的がおろそかになるのは、『測りすぎ』の本の中であらゆる組織で起こってしまう悪現象とあったな。//ブコメトップがまさに本文を読んでないものでなんというか。

[aalpaca375]

計測不要派のうち、従業員に向き合えておらずかつ十分な給料を払えない会社が問題。ろくに個人目標設定も合意できず、門外漢が人月で評価する組織は外部SIerに発注しているようなもの。

[pchatsu]

via https://x.com/sugarshin/status/2079897361640534165

[morita_non]

遅刻しないとか、メンタルクラッシュしない。とかでいいじゃないの。

[masatotoro]

測れない

[niam]

プログラムは短いコードでも性能がいいことは普通にあるけど、バイブコーディングは短いコードで性能いいことあんまりない気がする…

[alpon]

愚痴ばっか多いけどやることやってるメンバーいて評価低いんだけど難しいとこよな。指標はいいのに印象が悪い。結局雰囲気で査定される

[hkdn]

ソフトウェアエンジニアのことをエンジニアと呼ぶ事案がどうしても気になる

[ee83jaige]

まあどう考えても測れないので、マネージャーが気持ちで決めるしかないんだろう。仮に有能だけど嫌いな人を低く評価して、転職されたりチームが劣化したときには結局マネージャーが低評価されるから罰則はあるし。

[zakinco]

Personal Software Process で記録させて申告させて、業務命令を出した人が判断するしかない。あとはその人の責任。

[atsushieno]

担当者ごとに評価軸が違うはずで、測定できたところでその指標を比較できるのかという問題があるよな。アプリ制作チームは生産量が指標になるかもしれないがセキュリティ担当者は生産しないだろう。

[leiopathes]

短期の仕事でも長期の仕事でも、それぞれの仕事自体の価値は上で決めるしかない。直接的な機能開発以外の貢献を測りにくかったが今はAIがある。SlackもGemini議事録もあるんだから貢献度をAIが出して相対評価でいいよもう

[tk_musik]

人は見えるものしか見えないって、別に面白いことでもなんでもないと思ってしまった。だからこそ見るための方策として見せ方だの見える化だの可視化だのの言葉使ってやってきたのよね。

[jojo800]

目標と計測は必要だけどそれと評価は切り分けよう。評価はお気持ち100％でいいよ、もう。めんどい。

[achtacht88]

目標設定なしに成果を測ろうとしてる気がする。成果はなにを期待されていたかによるのでは。

[urahiroshi]

記事にあるとおり役割・期待値によって目指すべき指標は異なるので、それを期初に目標として設定し、評価でいきなり「今期、あなたの成果は何でしたか？」とならないように(マネージャーが)すべきでもある

[sionsou]

営業などと違って数値で測るのが難しい部分があるからねぇ。成果指標が定まらない企業ではだめだろうな。なおエンジニアと一括りにせずこの場合はソフトウェア開発者もしくはITエンジニアなどにしないと。

[repon]

これは「当社は成果と賃金は連動してません！」と真実を言えば終わること。逆に「クリック数で賃金が決まります！」「出社と笑顔で決まります！」で本当に賃金払うなら、クリック＆スマイルでみんなハッピーでしょ

[getcha]

高速化でコード量が減っても他の人が読んでも？なコードになったり、新しい製品出しても使用者の不満が爆発させた人を知ってる。一つの数値で機械的ではなくManager が優秀な目を持って判断するしかない。

[m50747]

会社側が採用したエンジニアに何を求めているか期待しているかが曖昧だから評価がトンチンカンになる。やることが決まっておりそれがクリアされたならステイ。力不足で遅れたらマイナス。会社の無理を聞いたらプラス

[myr]

残念ながら計れない, 以上。 冷静に考えて n次元ベクトルを1次元の「給与」みたいなモノへの写像ってだけで無理があるのはしょうがなくて, 結論は「皆良い感じに仲良くしよう」とか見も蓋もない物しかない気が...

[ledsun]

数値化して測れるのならエンジニアリングマネージャーは要らないのです。

[spray_donuts_3co]

人的評価を成果物でしか見ないのがおかしい。毎日出勤して仕事に従事してくれてりゃ100点でしょうが。測る指標がなければ0点か？

[sabinezu]

時間と燃費じゃね。アウトプットが何のためのものかを理解してるかしてないか。

[gomentic]

デザイナーの評価も数値化しづらい。参考になった。

[masayoshinym]

消化チケット数とかじゃだめなの？

[kakei-akihiko]

「測れないものは測れないと認める」ってそりゃそうだよな。事実を認めないのは現実逃避。何も良くならない。

[masalib]

「タイピング数は連鎖の右端のさらに外側、成果からもっとも遠い数字」・・・あれ・・・上場企業が採用しているKPIだったような・・・