『定量化できない貢献』が評価で損する
エンジニアの評価は『リリース機能数』『売上貢献』等の定量指標で測られがちですが、『コードレビュー品質』『ドキュメント整備』『新人指導』『技術選定の助言』等の定量化困難な貢献は評価で損するパターンが頻発します。これは個人の損失だけでなく、組織全体の生産性も下げます。本記事では編集部の取材ベースで、見えにくい貢献を『評価される形に翻訳』する実務戦略を整理します。
見えにくい貢献の5カテゴリ
- カテゴリ1: コードレビュー: 月数十件のPRレビュー・品質維持
- カテゴリ2: ドキュメント: アーキテクチャ・運用手順・トラブルシュート
- カテゴリ3: 新人指導: オンボーディング・ペアプロ・メンタリング
- カテゴリ4: 技術選定助言: 他チームへの相談対応
- カテゴリ5: 障害対応: 緊急時のオンコール・原因究明
見える化戦略1: 数値化の工夫
(1) レビュー回数: GitHubの月別レビュー回数を集計
(2) ドキュメント記事数: 社内Wiki・Notionの記事数
(3) 新人フォロー時間: 1on1・ペアプロの時間
(4) 相談対応回数: Slack/Slackのスレッド数
(5) 障害対応時間: PagerDuty/Opsgenieのアラート対応
見える化戦略2: 影響度の言語化
数値だけでなく『影響度』を言語化:
(1) PR レビューで防いだバグ: 『リリース前に発見した本番影響を防ぐ修正〇件』
(2) ドキュメントの利用度: 『新人〇人がこのドキュメントで自走可能になった』
(3) 新人成長: 『指導した新人がXX機能を1人でリリース』
(4) 技術選定の結果: 『推奨した技術選定で開発期間XX%短縮』
(5) 障害復旧時間: 『深夜障害対応でXX分で復旧』
見える化戦略3: 上司への報告タイミング
- 週次1on1: 1週間の貢献を箇条書きで報告
- 月次振り返り: 月単位の総括・貢献の言語化
- 四半期評価: 評価面談で証拠を提示
- 年次評価: 1年分の総括・自己評価
- 機会的アピール: 大きな貢献の都度Slack/上司に共有
見える化戦略4: ピアからの推薦
自己アピールだけでなく、同僚からの推薦を集める:
(1) 360度評価: 同僚・上司・部下からのフィードバック
(2) Kudos Slack: チーム内での感謝メッセージ
(3) 1on1で同僚言及: 同僚の貢献を上司に伝える文化
(4) 社内表彰: 月間MVP・年間表彰での推薦
(5) 退職者からの推薦: 元同僚からのLinkedIn推薦
見える化戦略5: ポートフォリオ化
- 個人GitHub: 個人OSSコントリビュート
- 技術ブログ: 業務での学びを発信
- 登壇: カンファレンス・社内勉強会
- 社内発表: 月1の技術発表会
- 業界ネットワーク: 外部評価の獲得
『見える化が下手なエンジニア』の特徴
- 『黙々と仕事をしている』『成果は上司が見ているはず』と考えている
- 1on1で雑談中心・自己アピール苦手
- 評価面談で具体的エピソードを思い出せない
- 同僚の貢献を称賛する文化作りに無関心
- 個人ブランディング・社外発信に消極的
『見える化が上手いエンジニア』の特徴
- 定期的に貢献を記録・可視化
- 1on1で構造的に貢献を報告
- 評価面談で具体的エピソード・数値を提示
- 同僚との相互称賛文化を作る
- 社外発信・ポートフォリオを整備
見える化スキルの長期キャリアへの影響
見える化スキルが弱いと、5年単位で年収レンジが100〜300万円差がつくケースも。同じ実力でも『評価される形』に翻訳できるかで、昇格・転職時の市場価値が大きく変わります。これはAI時代でも陳腐化しない普遍的スキルです。
関連リンク
ライティングスキルは エンジニアのライティングスキル、プロダクト思考は エンジニアのプロダクト思考、評価制度は 人事評価 を参照してください。EMの部下離脱防止は EMの部下離脱防止 もどうぞ。