エンジニアは評価されない？評価されるエンジニアになるための失敗学

プロジェクトは成功したのに、思ったよりも評価されなかった過去

ある会社のWindows NT4.0からXPへの更新プロジェクトで、マスター設計から展開までを主担当としてやらせてもらった時の事。

30歳の頃、ある会社のWindows NT4.0からXPへの更新プロジェクトを任されました。マスター設計から展開までを主担当としてやらせていただくことになったのです。

お客様やベンダーとの交渉から始まり、当時を思い起こすと、まだ稚拙なものではあったものの、Windows XPにおける新しい思想や経験に基づく対策をしっかりと盛り込んで設計を行うなど、プロジェクト成功のために尽力し、そして無事そのプロジェクトを成功させました。

当時はかなり大きなプロジェクトの主担当を任されたこともあり、気持ちは有頂天であったものの、自身の評価と会社からの評価にはギャップがあったのです。プロジェクトの成功および実現のための技術力は評価されましたが、「これだけやったのにこの評価？」という気持ちを持つ評価を受けました。

マイナス評価の理由となっていたのは？

プロジェクトは成功したにも関わらずマイナス評価を受けていた理由は、「ドキュメントの作成をほとんどしていなかった」ことにあったのです。

当時は場当たり的な進め方が許されていた雰囲気もあり、自身もそういった社内体質に依存していたと、今考えるとそう思います。発生した事象に対して、解決策を見つけ、解決したら設計に反映させてその時点でその作業は終了。自身が問題に対応した際の状況やその解決に向けた流れなど、メモを取っておくことはしませんでした。

それを見ていた上司も、「技術面では信頼があった」反面、「ドキュメントを残す癖をつけさせないままでは、その技術のノウハウの蓄積が残せない」という危惧を持ちます。そこで上司は、自身が対応した際のメールや手順のメモなど、自分以外の誰かが再現できるレベルの資料などを提出させます。そしてその資料を、自身以外の第三者がドキュメント化させていました。

マイナス評価を受けて上司から課せられたこと

このプロジェクトが一旦終結し、その会社の運用業務に配属替えとなった際に、上司からこんな課題を与えられた。

• 人に何かを伝え、自分以外の人にやらせて、全体のクオリティを底上げすること
• アウトプットを残し、次世代につなげる体制を作ること

上述したプロジェクトが完了し、会社の運用業務に配属が変わった際に、当時、上司から下記の課題を与えられました。

エンジニアとして、より先のステップへ進むために、より適切な評価を受けるためには、自分以外の人にも業務を回し、教えながら仕事を行うことで、自身と他のメンバーの仕事のクオリティにばらつきがないようにすることが重要であると考えていたのでしょう。実際、自身とほかメンバーの技術のクオリティにばらつきがあることで、お客様に指摘されることも起きてしまいました。

また、全体の技術レベルを底上げするためのアウトプットを残さなければ、いずれどこかで失格の烙印を押されてしまう可能性も危惧していたのだと今ではそう考えています。エンジニアとしての技術は十分なのに、中途半端な存在になってしまうことは、多くのエンジニアの評価の問題にも深く関わってしまうことでしょう。

エンジニア含め社会人が身につけるべきスキル

「全体の技術力向上のためにドキュメントを残す」「独りよがりの仕事をすることで中途半端な存在にならない」ことは、エンジニアだけでなく、すべての社会人に当てはまることではないでしょうか。上司から課された課題も、エンジニアだけに当てはまるものではなく、すべての社会人が実践すべきことだと思っています。

私の会社はエンジニアという仕事に深い理解を持つ会社ですが、そうではない会社に入社し、なかなか評価が上がらないという方も多いでしょう。上司がエンジニアという仕事を理解していないと、エンジニアという仕事の特性上、自分の仕事と評価のギャップに悩む人も多いはずです。特に自分の技術が適正に評価されていないと感じる人は、以下の要素を改善しながら、会社に最適な評価をしてもらえるように交渉してみるのも良いかもしれません。

• 具体的な数値を用いて成果をアピールする
• コミュニケーション能力を身につけ、社内・外関係なく、円滑なコミュニケーションができるようになる
• リーダーシップやマネジメント能力を身につけ、自らプロジェクトを引っ張っていけるようになる

エンジニアとしての技術プラス1の要素があると、自分の仕事と評価のギャップを埋められるかもしれません。