はじめに
こんにちは、H×Hのセンリツ大好きエンジニアです。（同担OKです😉）
保守業務を中心で行なっている方の評価が低くなる状況は何か違うな〜、と思ったのがきっかけで評価制度のことを考えるようになってきたのですが、保守業務の評価はどのように行われているのか気になりました。🤔
僕は人事の仕事を行なっていないためただの考察になりますが、実際に携わっている方がいらっしゃれば教えていただきたいです🙇
エンジニアが行う保守業務を評価することが難しい理由
僕なりに考えた結果、以下のものが挙げられるかなと思います。
1. 目に見える成果が少ない
2. 定量評価が難しい
3. 認識の問題
1. 目に見える成果が少ない
保守はシステムの安定稼働を維持するための作業が中心なため、新機能開発や大規模な改善とは異なり、目に見える成果として現れにくいことが要因の一つだと感じます。
例）
エンジニア
🧑💻 < システムの安定稼働や体験向上のために、バグの修正であったりパフォーマンスの最適化など行いました！
評価者
🧑💼 < 技術的に難しいんですか？
🧑💼 < それで何が解決したんですか？ ビジネスインパクトありますか？
こういう会話が頭の中で聞こえてきました。😇
流石にここまでは酷くない気はしますが、イメージとしてはこんな感じですね。
さらに、保守はインシデントが発生する前に防ぐという予防的な性質があるため、上手く稼働している場合は「何も起こらない」ことが成果です。
ですので、どうしても評価が難しくなる傾向にあるのかなと思います。
例）
エンジニア
🧑💻 < 保守業務の一環としてセキュリティパッチの適用やシステムの監視を行い、潜在的な脅威を防ぐように尽力いたしました！
評価者
🧑💼 < 実際に目に見えないので何とも。。。
2. 定量評価が難しい
新規開発は完成した機能やプロジェクトの規模などで評価しやすいですが、保守業務はトラブルを未然に防ぐことや、小さな修正を繰り返すことが多く、定量的に評価するのが難しいと思います。🤔
これはエンジニアであっても、保守業務に精通している方が見ないことには分かりづらい気がします。
機能の開発と比較した場合、バグ修正などで技術力を測ることも難しいことが要因として挙げられる気もします。
例）
エンジニア
🧑💻 < バグの修正を○件行いました！特にこのバグは修正がとにかく大変で、色々なところに影響するのできちんと確認しながら行わないと。。。
評価者
🧑💼 < 修正したバグの数で判断しますね。
定量的に測れるレベルのものを取り扱うことになる気がしますので、上記のようなパターンで保守業務者の技量が判断できないこともあるかと思います。🥲
3. 認識の問題
保守業務は「現状維持」として認識されることが多く、プロダクトの新規開発といった進歩や革新と比べて評価が低くなりがちだと思います。。。
特にマネジメント層がその重要性を十分に理解していない場合、適切な評価がされにくくなります。🥶
定期的なシステムアップデートや監視体制の強化などはシステムの信頼性を高めるために不可欠ですが、これらの活動が当たり前として見られ、エンジニアの努力や貢献が十分に評価されないケースが存在していると考えられます。
エンジニア
🧑💻 < 保守業務としては、バグ修正や機能改修だけでなく、監視体制の強化や定期的なセキュリティパッチ導入など様々なことをしています！
評価者
🧑💼 < 当たり前だと思ってたので特に評価すべき点が思い当たりません。
。。。これは流石に極端な例だと思います。🙅
ただ、ゴリゴリのテックカンパニーならともかく、主力事業が技術系ではない事業会社の一部門としてエンジニア部門がある企業だと、往々にして評価者との認識の相違が発生しそうな気がします。
エンジニア部門単体では売り上げが見込めないことから、そこまでエンジニアの評価に本腰を入れる必要はないと判断されることも要因として考えられそうです。😵
（ここは特に個人的見解です。）
おわりに
ここまでお読みいただきありがとうございます！
実際の評価制度を詳しく知らないので想像にはなりますが、皆さんも一度は思ったことがあるのではないでしょうか？
ただ、あくまで想像ですので「ここは違いそう！」や「ウチではこうしてるよ！」みたいなことがあれば是非教えていただきたいです！🙇