『頑張った』は評価されない、『成果と構造』が評価される
同じ仕事をしても、提示の仕方で評価は大きく変わります。本記事では、国の賃金統計と、開発チームの成果の測り方として公開されている指標をもとに、エンジニアの人事評価対策を整理します。PDCA改善術 もご参考に。
評価の3要素
(1) 成果：定量・定性で測れる結果。(2) 行動・プロセス：成果に至る取組。(3) 影響範囲：個人/チーム/組織。(4) レベル相応性：シニアにはシニアの仕事か。(5) 会社の期待値：レベル定義と照らす。これら4軸で書類を構造化すると説得力が増します。
成果の見せ方
(1) 数値化：『p95レイテンシ300ms→100ms』。(2) ビフォーアフター：始点と終点。(3) ビジネスインパクト：技術指標→売上/コスト/CS への接続。(4) 自分の貢献度：チームの中の役割。(5) 反証への備え：なぜそれが自分の成果か。
プロセスの示し方
(1) 計画力：3ヶ月先の見通し。(2) 巻き込み力：他チームとの連携。(3) 解決力：困難な課題への対処。(4) 学習力：新しい技術の習得。(5) メンタリング：後輩への影響。行動だけでなく『なぜそうしたか』『学びは何か』も合わせて。ソフトスキル もご参考に。
キャリアレベルの理解
(1) L3 (ジュニア)：指示された範囲を着実に。(2) L4 (ミドル)：機能単位で自走。(3) L5 (シニア)：チーム全体に影響。(4) L6 (スタッフ)：複数チームに影響。(5) L7+：組織横断・戦略レベル。会社で名称・定義が違うため必ず社内定義を確認(公開情報をもとに)。
事前準備のテクニック
(1) 日次の小メモ：気付き・成果を記録。(2) 四半期サマリ：成果を整理。(3) 上司との中間チェック：期待値ズレ防止。(4) 同僚からのフィードバック：360度視点。(5) 過去の評価書類の振り返り：トレンド把握。
1on1 と評価の繋げ方
(1) 1on1 で『評価につながる成果』を意図的に共有。(2) 困難な状況の相談：上司は記憶に残る。(3) キャリア対話：四半期に1回。(4) 目標調整：半期で見直し。(5) 記録の共有：1on1メモを Doc に蓄積。1on1 活用術 もご参考に。
評価と昇進で、給料はどれだけ変わるか
評価の結果は、最終的には役職と給料に表れます。厚生労働省「令和7年賃金構造基本統計調査」で、雇用期間の定めのない一般労働者の月の賃金（所定内給与額）を役職別に見ると、次のとおりでした。
| 役職 | 月の賃金 | 非役職者を100としたとき | 平均年齢・勤続 |
|---|---|---|---|
| 非役職者 | 31.05万円 | 100 | 41.8歳・10.8年 |
| 係長級 | 39.92万円 | 128.6 | 45.4歳・17.5年 |
| 課長級 | 52.92万円 | 170.4 | 49.5歳・20.9年 |
| 部長級 | 63.58万円 | 204.8 | 53.1歳・22.6年 |
※厚生労働省「令和7年賃金構造基本統計調査の概況」第8表（男女計）。賃金は所定内給与額で、賞与や残業代は含みません。
課長級になると、月の賃金は非役職者の1.7倍です。1回の評価で劇的に変わるわけではありませんが、評価の積み重ねが役職を通じて給料の差になることが数字から分かります。エンジニアの場合も同じで、同じ調査の職種別の表で年収（残業代を含む全国平均）を見ると、40〜44歳でソフトウェア作成者が686.3万円、システムコンサルタント・設計者が1,189.0万円でした。設計やチーム全体に関わる役割を担えるかどうかが、レベルと給料の差を生んでいます。
成果を数字で書くための指標の例
「成果を数字で示して」と求められても、何を数えればよいか迷うことがあります。開発チームの成果の測り方としては、Google Cloud の DORA（DevOps Research and Assessment）が公開している4つの指標がよく使われます。
- デプロイの頻度：本番環境にどれくらいの頻度でリリースできているか
- 変更のリードタイム：コードの変更が本番に届くまでにかかる時間
- 変更による障害の割合：リリースのうち、障害や手戻りにつながった割合
- 障害からの復旧時間：問題が起きてからサービスを戻すまでの時間
4つの指標は、速さ（デプロイの頻度・リードタイム）と安定性（障害の割合・復旧時間）の2組で見るのが基本です。速さだけを伸ばして障害が増えれば、チームとしての成果にはなりません。
評価書類では、こうした指標の「始点と終点」を書くと伝わりやすくなります。たとえば「リリースの手順を自動化し、週1回だったデプロイを毎日できるようにした」のように、変化の前後と自分の役割をセットで書きます。チームの指標を自分の成果として書くときは、どこまでが自分の貢献かをはっきりさせておくと、上の節の「反証への備え」にもなります。
信頼性の仕事は「SLO」で書く
障害を防いだ・運用を安定させた、という仕事は成果が見えにくく、評価で損をしがちです。こうした仕事を数字で示す方法として、Google の SRE（サイト信頼性エンジニアリング）の考え方で広く使われているのが SLO（サービスレベル目標）とエラーバジェットです。たとえば「月の可用性99.9%」をSLOにすると、30日のうち止まってよい時間は43.2分になります（30日×24時間×60分×0.1%）。99.99%なら4.32分です。「SLOを決めて、停止時間を予算の範囲に収めた」「エラーバジェットの使い方をチームで合意した」と書けば、目立たない仕事も期待値に照らして説明できます。
失敗しがちなパターン
(1) 主観のみで書く：『頑張った』では伝わらない。(2) 数値ゼロ：説得力に欠ける。(3) 個人成果しか書かない：チーム貢献も評価対象。(4) マイナス点を隠す：成長性が見えない。(5) レベル定義を読まない：期待値とずれる。対策は、(1)事実ベース、(2)定量化、(3)他者影響も明示、(4)学びをセット、(5)レベル定義を熟読、です。評価でキャリアアップしたら次の市場価値検証を：転職サイト比較。
この記事のデータの出典
- 厚生労働省「令和7年賃金構造基本統計調査の概況」第8表（役職別賃金）、同調査 第1表・第5表（職種（小分類）、年齢階級別 きまって支給する現金給与額・年間賞与その他特別給与額）
- Google Cloud「DORA（DevOps Research and Assessment）」の4つの主要指標
