地味な貢献が評価されないエンジニアへ｜ドキュメント整備を例に
誰も書かなかった環境構築手順をまとめた。散らばっていた仕様を1か所に集めた。新しく入った人が、以前なら3日かかっていた立ち上がりを半日で終えるようになった。
それなのに、評価面談では「今期は目立った成果がなかったね」と言われる。この落差に覚えがある方に向けて書きます。私が管理職として評価を付ける側に回ったときに分かったのは、この種の仕事は評価されていないのではなく、評価の土俵に乗っていないということでした。
- 地味な貢献が評価シートに乗らない仕組み
- 「効いている」ことを数字に変える具体的な方法
- 採用側が地味な仕事をどう読むか
- 面談で伝えるときの言い換え
なぜドキュメント整備は評価に乗らないのか
理由は単純で、評価制度が「何が起きたか」ではなく「何が増えたか」を見る作りになっているからです。
多くの会社の評価シートには、売上、リリース数、担当機能、納期遵守といった項目が並びます。ドキュメント整備が効くのは「起きなかったこと」の側です。質問が来なかった。手戻りが起きなかった。新人が詰まらなかった。起きなかったことは記録に残りません。
さらに厄介なのは、効果が自分以外に現れる点です。あなたが書いた手順書で助かったのは他のメンバーで、その人の成果として計上されます。貢献した本人の評価シートには何も残りません。
同じ構造は、障害が起きないほど評価されないインフラの仕事にも当てはまります。こちらはインフラ担当の仕事が見えにくい問題｜障害が起きないほど評価されない構造に書きました。
「起きなかったこと」を数字にする
評価の土俵に乗せるには、起きなかったことを観測可能な形にする必要があります。完璧な計測は要りません。粗くても、前後で比較できる数字があれば十分です。
実際に使える切り口を挙げます。
| 整備したもの | 取れる数字 | 取り方 |
|---|---|---|
| 環境構築手順 | 新メンバーの立ち上がり日数 | 前回入社者と今回で比較 |
| 仕様の集約 | 同じ質問が飛ぶ回数 | Slackの検索で「これどうなってましたっけ」を数える |
| 障害対応手順 | 一次対応にかかる時間 | 障害チケットの起票から初動までの時間 |
| API仕様書 | 他チームからの問い合わせ件数 | 月あたりの件数を前後で比較 |
| 運用手順の自動化 | 手作業の時間 | 作業1回あたりの分数 × 月間回数 |
大事なのは、整備する前に数字を1つ取っておくことです。後から「たぶん減った」と言っても説得力がありません。作業前にSlackの質問件数を数えておくだけで、後から比較できます。
採用側から見ると、地味な仕事はむしろ読みやすい
社内では埋もれる仕事ですが、採用面接では逆に評価されやすい性質があります。理由は、この種の仕事がその人の判断の質を映すからです。
面接官として話を聞いていると、「誰も書かないから書きました」で止まる人と、「この部分の問い合わせが月に10件以上来ていて、内容が毎回同じだったので、そこだけ先に文書化しました」と言える人では、見え方がまったく違います。後者からは、課題を見つけて優先順位をつけて手を打てる人だと伝わります。
言い換えの例を挙げます。
- 「ドキュメントを書いていた」→ 属人化していた運用知識を棚卸しし、引き継ぎ可能な状態にした
- 「wikiを整理した」→ 情報が分散して検索性が落ちていた状態を、参照導線から設計し直した
- 「新人教育の資料を作った」→ オンボーディングの立ち上がり期間を短縮する仕組みを整えた
- 「手順書を作った」→ 特定メンバーしかできなかった作業を、チーム全員が実行できる状態にした
「書いた」ではなく「どの詰まりを解消したか」で語ると、雑務ではなく改善の実績として伝わります。
社内で扱いを変えるためにできること
転職を前提にしなくても、社内での扱いを変える余地はあります。
期初の目標に入れてしまう
評価シートに乗らない最大の理由は、期初の目標に入っていないことです。「オンボーディング期間の短縮」「問い合わせ件数の削減」といった形で目標に入れておけば、期末に評価対象になります。上司に相談するときは、やりたいことではなく、解消したい詰まりから話すと通りやすいです。
効果を報告する習慣を作る
整備した直後に、チームのチャンネルに一言残しておきます。「この手順書を置いたので、次回の環境構築は各自でできます」程度で構いません。記録が残ると、期末に自分で思い出せます。
引き受ける前に役割を確認する
地味な仕事が常に自分に回ってくる場合、役割の設計に問題があります。この状態が続くと便利屋化します。構造は役割が曖昧な会社でエンジニアが評価されにくい理由｜便利屋化する前に見ることで扱っています。
それでも評価の仕組みが変わらないなら、その会社ではこの種の仕事が制度上評価されないということです。その場合、同じ仕事を正式な役割として募集している会社が外にあるかを見てみる価値があります。
IT転職エージェント＠PRO人
ITエンジニアの転職に特化したエージェント「PRO人」。専任のキャリアアドバイザーが、経歴やスキルを踏まえた具体的な求人・条件面を提示してくれます。
- IT・Web業界の転職支援に特化
- 経歴・スキルに合わせた求人を紹介
- 年収交渉や条件面のすり合わせも相談できる
- TechGoとは別の視点で市場価値を確認できる
よくある質問
Q. 数字を取っていなかった過去の仕事は、もう実績にできませんか A. 使えます。正確な数字がなくても、「以前は毎回同じ質問が来ていたが、整備後はほぼ来なくなった」という形で、前後の変化を具体的な場面で語れば伝わります。次回からは着手前に数えておいてください。
Q. ドキュメント整備を評価してもらえるよう上司に相談しても大丈夫ですか A. 大丈夫です。ただ「評価してほしい」ではなく「この詰まりを解消したいので、期の目標に入れたい」という形で持っていくほうが通りやすいです。上司も評価シートに書ける形を求めています。
Q. 誰も読まないドキュメントを書いている気がします A. 読まれていないなら、置き場所か粒度が合っていない可能性があります。よく飛ぶ質問を先に3つ選んで、その答えだけを書くところから始めると、読まれるものになりやすいです。
まとめ
地味な貢献が評価されないのは、能力の問題ではなく、評価制度が「起きなかったこと」を拾えないためです。
- 効果は他人の成果として計上され、本人の評価シートには残らない
- 整備の前に数字を1つ取っておくと、後から比較できる
- 採用側には「どの詰まりを解消したか」で語ると伝わる
- 期初の目標に入れると、評価の土俵に乗せられる
次に何かを整備するときは、着手前にSlackの質問件数を数えておいてください。それだけで、次の評価面談で使える材料が1つ増えます。