読者です 読者をやめる 読者になる 読者になる
おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

SIer では、エンジニアは評価されにくい?

つぶやき

うちの会社はそこそこ大きい SIer です。
そういう環境であることを前提に話を進めます。

とあるきっかけがあって、
プロジェクトマネージャより高評価を得るエンジニアになるにはどうすればいいか。
なんてことを考えています。

スーパープログラマ不要論

標準化や共通化が一定のレベルを越えると、暴れ馬なスーパープログラマが一人いるよりも
従順な低レベル作業者数人を厳密なルール下で強制労働させる方がよさそうに見えます。

大規模プロジェクトでは数こなして、進捗率上げるのが至上ですからね。

実際はそんなことはなく、問題が起こった時には役に立たない烏合の衆と化したり、
動くだけでなんの付加価値もない成果物ができあがったりします。

人を管理できる方が評価しやすい

とは言え、うまくいかなかった時のことなんて頭の片隅に置いておくのが世の常なので
一匹狼なエンジニアよりも、複数人を管理するプロジェクトマネージャの方が重要視されます。

もちろん、顧客をシャットダウンしてシステムしか見ないエンジニアは論外ですが、
顧客もシステムも見ながらすごいスキルを発揮するエンジニアもいるわけです。

そういうエンジニアって管理重視な視点で見ると、評価されにくくなります。
「結局あの人は進捗管理とかやっぱり弱いし、リーダー経験してないし…」
人事評価の場でそういう声をよく聞きます。マイナスポイントのほうが目立ちます。

「でも、あの時あの人がいなかったらダメだったでしょ。徹夜してがんばってくれたよ」
といった意見は加点対象にならないことが多いです。
エンジニアは技術で苦労して当然、家帰って技術書読むのも当然なのでしょう。

逆を言うと、技術を全く知らない管理者に苦労したりします。

そもそも違う役割なのだから

人を管理しているのがプロジェクトマネージャで、
一方で技術を管理しているのがエンジニアです。

あつかう対象が違うのだから、評価も違った見方で行わないといけないはず。
確かに人を管理するほうが一般的には難しいことは違いないですが。

でも、プロジェクトには役割がそれぞれ必要なわけで。
プロジェクトマネージャだけでも成り立たないし、エンジニアだけでも成り立たないです。

総じて最高責任者たるプロジェクトマネージャの評価が高くなるのは避けられないですが、
そうはいっても、エンジニアもその努力にうまくフォーカス当てて評価されるようにしたいです。

じゃあ、どうする?

エンジニアが自由に自らのスキルで持って価値を生み出せるようにしたい。
そして、それを評価されるようにしたいと思っています。
大きな会社には保守派が多くて大変ですが。

まずは自分の力でなんとか変えれる、小さな範囲から。
実例を積み上げる。