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