使えないエンジニア・・現場でそう言われないために意識すること

客先常駐で開発するタイプのシステム開発では、複数の企業が集まってプロジェクトチームを結成することも珍しくなく、別会社のエンジニアと連携を取りながらシステム開発に従事することもよくある光景です。

もしミスを犯したり、仕事の進め方が悪かったりすると、普通は上司や先輩エンジニアが本人の成長を思い、いろいろ助言や指導をしてくれるのものですが、周りが別会社のエンジニアばかりの状況では「使えないエンジニア」と影で言われて終わりです。

冷たい世の中かもしれませんが、他社のエンジニアの世話を焼くなんてのは手間でしかありませんから、それも仕方がないのでしょう。「使えないエンジニア」と言われている本人は現場での評価も下がり契約も終了してしまい、良いことはありません。

どんなエンジニアが「使えないエンジニア」と言われるのか

そこで「使えないエンジニア」と言われないためにも、そう言われてしまいがちなエンジニアの特徴をつかんでおきましょう。

勝手な解釈で作業を進めてしまう

お客様からの指摘や要望を勝手な解釈で受け取ってしまうSE。PMからの作業指示を勝手な解釈で理解したつもりになるSE。設計書に記載の仕様を勝手な解釈でコーディングするPG。いずれも使えないエンジニアと言われてしまいます。

「一を聞いて十を知る」という言葉がありますが、システム開発の現場でそれができるのは、よほど業務に精通しているベテランエンジニアぐらいでしょう。理解力の高いエンジニアと思われたくても、しっかりと相手の言うことを理解しないまま、勝手な解釈で作業を進めてしまうのはいけません。

もし間違った解釈で作業を進めてしまえば、結果として手戻り作業が発生し、大幅に工程遅れが生じてしまいます。さらにチームのメンバーに対しても迷惑をかけてしまう可能性さえ出てきます。

自分が理解している内容が、情報を伝達する側（お客様やリーダーなど）の考えと相違がないか、確認を取ってから作業を行うようにしましょう。

業務報告が適当

プロジェクトを進めていく上で、PMがしっかりと工程を管理できているかどうかは、プロジェクトを円滑に進めていくための鍵になります。しかしそれもPMの能力だけが問題ではなく、SEがしっかりと進捗報告できるかどうかも重要なのです。

もし全体の作業のうち20%しか終了していないのに、進捗率50%と報告してしまえば、PMの工程管理が狂ってしまいますし、懸案が発生しているのにそれを報告しなければ、後になって問題化する可能性もあります。

業務報告をないがしろにするのは、エンジニアのスキル不足よりも悪いことです。業務報告する際には以下の点を簡潔に報告するとよいでしょう。

• 作業全体の進捗率と今後の見通し
• 自分が抱えている懸案事項(対応策を含む)
• 作業効率を高める(工数削減)ための改善提案
• お客様からの伝達事項(追加要望や不具合報告など)

報告上手なエンジニアとなって、PMからも「使いやすいエンジニア」と言われるようになりましょう。

できると言ったのにできていない

難解なアルゴリズムのモジュール作成から、比較的簡単なツール作成まで、エンジニアであれば何かしらの仕事を任されることは日常茶飯事。仕事を与えられるときは必ず「いついつまでにやっといて」というように、期限を設けられます。

そこで「やります」や「できます」と言っておきながら、期限当日に「できていません」と報告があっては、これも使えないエンジニアの認定を受けてしまうでしょう。チーム内でのやり取りならまだしも、相手がお客様であれば、会社の信用を落としてしまうことにもなりかねません。

当初から期限内にできる見込みがなければ、安易に「できます」と返答してはいけません。「見込みではあと2日ほどかかりそうです」と自分なりの予測を提示したり、「期限内に終わらせられるか微妙なところですが、状況を見て都度報告してもよろしいでしょうか」と進め方の提案をすべきです。

もし着手してから期限内に終わらせられないことが分かれば、その見込みがついた時点で、早いうちに工程管理者へ報告すべきです。

おわりに

一度でも「使えないエンジニア」と思われてしまえば、そこから信用を取り戻すのは非常に大変です。だからこそ「できるエンジニア」のふりをして裏目に出ることがないよう、今回ご説明した事項をしっかりと意識したいものです。

それに使えないエンジニアと言われるのは、コミュニケーション能力が低いからとも言えます。技術者としてのスキルを磨くのも大切ですが、コミュニケーション能力を高めることも大事にしていきましょう。