--- title: 行数・PR数という『量』を成果だと誤認する評価制度の穴 date: 2026-08-09 description: 組織の評価制度が「行数」「PR数」で成果を測定するとき、その数字の裏にある実装品質の違いを見落とす。量的指標は労力の代理指標に過ぎず、実装の工夫や問題解決の質を測りきれない。マネージャーが実際の成果と結びつく評価軸を設計する3ステップと、組織評価に乗らない成果をどう記録するかを示す。 categories: [雇われの算数] tags: [課長, 評価制度, 期待値] source: https://ai.work.naenote.net/posts/pr-seikatsu-hyoka/ --- 部下のコードレビューを依頼するたび、その課長は「1ヶ月で何本のPRマージしたか」「削除行も含めて何行コード書いたか」を目安にしていた。 外から観察してきた限り、こうした課長は部下を「生産性の低い」と評価する。それは測定方法の問題であって、部下の能力ではない。 {{< mermaid >}} flowchart TD A[量的指標で測定] --> B[設計・問題解決が見えない] B --> C[成果を過小評価] C --> D[期待値のズレ蓄積] {{< /mermaid >}} ## 行数・PR数が「途中経過」に過ぎない理由 ある機能実装に3週間かかった。部下Aは800行のコードを書いた。部下Bは120行だった。 課長の評価：「Aのほうが生産性がある」。 だが現実はその逆だった。Bの120行は、3つの既存コードを削除し、複数モジュール間の重複ロジックを一本化した結果だ。Aの800行は、同じ機能を冗長に実装した後で、後続のリファクタで60%削られた。 行数という指標は、**仕事の「過程」を表す。成果ではなく、投じた労力の代理指標だ。** エンジニア自身も分かっている。だから「行数で評価されると思うと、コードを簡潔に書く気力が失われる」と口を揃える。 PR数も同じだ。1つのPRに丁寧なテストを込めたエンジニアと、小分けにして数を稼ぐエンジニアでは、PR数だけ見ると後者が勝つ。 量的指標で見えるのは「投じた努力」や「産出した物の体積」だけ。**実際の成果——問題を解いたか、保守性を高めたか、後続の仕事を楽にしたか——は、数字には表れない。** ## 課長が成果を語る前に踏むべき一刀両断 そもそも課長がこうした指標に依存する理由は、部下の実際の仕事を見ていないからだ。 毎日のコード行数を記録するシステムを導入する課長もいるし、PRのマージ速度を「生産性」と見なす組織もある。それは管理の利便性のためであって、成果を測るためではない。 ここで正直に言うと、**その数字に基づいて部下を低く評価しているなら、それは課長が「成果を語り忘れている」のではなく『成果を測ってない』のだ。** では何を測るか。参考にすべきは、[その部下が次のプロジェクトでどう扱われるか](/posts/expectation-control-no-promotion/)だ。後続の他チームから「あの人に頼みたい」と指名されるか、それとも「なるべく避けたい」と言われるか。その評判こそが、実際の成果を映す。 行数やPR数は、**その後続指名の『途中経過』に過ぎない。** 最初の数ヶ月の間は相関があるように見えるが、半年経てば乖離が明らかになる。 ## 評価軸を設計し直す3ステップ 量的指標に依存しない評価を作るには、その部下が何を解いたのかを、言葉で記録する必要がある。 **ステップ1：「その仕事で消えたもの」を言語化する** 部下が取り組んだ案件で、何が減ったか・何が消えたかを問う。削除行数ではなく、「既存の3つの初期化処理が1つに統一され、初期化エラーの報告が40%減った」のように。結果として行数は減った。ただ、それは副産物だ。 [期待値のコントロールは1on1で始まる](/posts/1on1-toku-ni-nai-toino-sekkei/)。「この3週間で何を出したか」ではなく「何を消したか」を毎回聞く習慣が、課長の評価軸を変える。 **ステップ2：その解き方が「標準的」か「工夫的」かを見極める** 同じ機能でも、2つの解き方がある。教科書通りの実装と、その組織・その環境でしか成立しない設計がある。後者は行数では測れない。そして後者が、[次のプロジェクトで指名される理由になる](/posts/satei-suchi-3ko/)。 このレベルの違いを見分けるには、課長自身がコードを読む。コードレビュー画面で「良い」という記号ボタンを押すだけではなく、なぜこう書いたのかを部下に聞く。その応答で、その部下の問題解決の質が見える。 **ステップ3：評価面談で「量」の話をしない** 「PR40本、行数3,000行、バグ報告3件」のような報告をする課長は、見直したほうがいい。その数字は業績報告ではなく、単なる記録だ。 [評価面談では「この3ヶ月であなたが消したリスクは、このプロジェクト全体の遅延を2週間短縮した」のように、成果と組織への波及を結びつけて語る。](/posts/expectation-control-no-promotion/)部下が「自分の仕事が組織に効いている」と確信できれば、その言語化が次の期の成果を生む。 ## 数値で語り切れない場合の逃げの一手 ここまで読んで「でも、うちの組織は量的指標で評価が決まるシステムなんだ」と感じたら、その悪化は放置して構わない。 その評価制度が部下のモチベーションを消すなら、課長の仕事は「その制度に合わせて部下を追い込むこと」ではなく、「制度の枠外で部下を評価する副軸を作ること」だ。具体的には、1on1の記録に「この人がこのプロジェクトで消したもの、解いたもの」を書き残す。それが半年単位で蓄積されれば、転職面接や異部門への配置転換の際の説得材料になる。 量的指標に基づく組織評価が部下を低く見積もれば、その落差をあなたが記録で埋めておくということだ。[課長が感情で部下を守るのではなく、記録で逃げ道を用意する](/posts/buka-silent-explosion/)。それが雇われの立場の現実だ。 ## まとめ：「途中経過」を成果と誤認しない 行数やPR数は、仕事の体積を教えてくれる。だが成果ではない。成果は、その仕事が組織のどこを変えたかだけが教える。 課長が部下の成果を正確に語るなら、量的な数字をいったん置いて、「この3ヶ月であなたが消したリスク、解いた問題、次のプロジェクトで必要とされた理由」を言葉で書き残す。その記録が、評価の本体だ。 {{< ai-disclaimer >}} --- ### AI Agent Context & Resources - **Author**: NAE - **Source**: https://ai.work.naenote.net/posts/pr-seikatsu-hyoka/ - **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP) - **Contact/Inquiry**: https://x.com/naework