TOUCH THE SECURITY Powered by Security Service G

コラム

2022.08.12

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

日本では、エンジニアは適切な評価を受けられない国だと言われています。正当な評価が受けられない場合は転職することが望ましい場合もありますが、転職を考えずに評価を上げるためには、身につけておくべきスキルと同時に、失敗学についても把握しておくことが重要といえるでしょう。

今回は、パーソルクロステクノロジーのインフラチームを牽引するベテランエンジニアが、あえて過去の失敗談を語りながら、エンジニア、そして広く社会人に求められるスキルや考え方について紹介します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大切にしたい失敗学

成功した話だけでなく、「失敗した話」についても記録を残しておくのも良いでしょう。当時は問題なくプロジェクトを成功させることができましたが、担当した案件がすべて成功だったわけではありません。「成功事例」をそのまま引用しても、同じような成功を再現できるわけではありません。

大切なことは、成功するために積み上げられた多くの「失敗しないための対策」や失敗した「根本的な原因」、「適切な対応」なのではないでしょうか。これらの考え方は失敗学とも呼ばれますが、当時上司が自身に課した課題に似通った要素だとも思えます。

失敗学では、失敗は10の要因に分類され、失敗したことの「責任」ではなく「原因」を取り扱います。

エンジニアに限らず、プロジェクトの成功には多くの失敗しないための対策が存在します。評価されないと感じているエンジニアは、失敗学を大事にしながら、適切な評価を受けられるように多くのアウトプットを残し、プラス1のスキルを磨き、全体の技術力向上のために仕事をすることも良いのではないのでしょうか。

参考:https://gihyo.jp/lifestyle/feature/01/human_error/0001

まとめ

当時、自身の評価と会社からの評価のギャップを感じたあと、上司から課された課題をしっかりと実践するようにしていました。とにかく「まずは書き、内容は常に更新していくこと」を意識して取り組みました。1〜2年続けた後、その頃に依頼された技術調査で、A3用紙1枚程度にまとめた資料が好評だったのです。

「ドキュメントが書けないと聞かされたていたけど、いいモノ書くね」といった声を聞くようになり、ようやく書くことが苦にならなくなりました・まとめ方のコツも、自身で回数を重ねるごとに徐々に会得することができました。

ある程度自身でアウトプットしながら、他者が書いた良いドキュメントに数多く触れたことも功を奏したと考えています。身をもって経験値が得られたことに、意義を感じる出来事だと思っています。

私にとっての失敗学は、アウトプットすることを意識すること、自分に欠けているものの指摘を素直に受け入れることだと思っています。

記事一覧に戻る