「本物のエンジニア」を見分ける

現代のビジネスはITの活用なくして成立しません。

今や、ＩＴが無くては生き残れない社会です。
当然、ＩＴエンジニアはますます引く手あまた。

優秀なエンジニアの採用は、ＩＴ企業のみならずＩＴ人材の採用に不慣れな中小企業の大きな課題になっています。

では、自社にあったエンジニアを見分けるためにはどんな点に注意すべきなのでしょうか。エンジニアの技能はピンキリで見分けるのは困難です。

それなりの実績がある紹介業者を使うなら最低限のフィルタリングはされますが、やはり「優れたエンジニアかどうかを見抜く視力」を鍛えていくことが大切です。

自ら手を動かせる技量があるか

言い換えるならば、指示するだけではなく実際に各作業ができるかということです。ＩＴ企業で3年以上の実務経験があるエンジニアの場合、そのタイプは大きく２つに分かれます。

１つはプログラミング言語の種類を問わず、自分でソースコードを書き続けてきた経験がある人材。もう１つはＩＴプロジェクトのマネジメントをメインで担当していた人材です。

開発のフェーズとして前者を「下流工程」後者を「上流工程」と呼びます。

下流工程に対しては「技術的に精通しているか」はともかく、下流工程の各作業に対して人並み以上に理解していないと上流工程に精通できません。上流工程は下流工程のノウハウを如何に使いこなすことでその本領は発揮するからです。

基礎が理解できないと応用できないのと同じ所以です。

しかし、上流工程は時代の変化に伴って修得する技術にあまり変化はありませんが、下流工程はたった３年で以前の知識が使い物にならなくなるケースも多々あります。ですから常に下流工程の技術動向の変化には敏感である必要があるのです。

また、「指導」と言う観点からも自分で手が動かせる程度の見識や理解がなければなりません。

他人をあるいは他人の成果物を評価（レビュー）する、人材を適材配置するなどを考えても、下流工程が把握できないようでは正しく測ることができませんのでいずれにしても重要となってきます。

プロ意識を身につけているか

プログラミングとはすなわち「ソースコードを書く仕事」です。

そして「ただ書くだけ」なら初心者でもそれほど難しくはありません。コピペするだけで動くプログラムもネットにたくさん落ちています。適当に書いても運が良ければプロっぽく見せることは可能です。

しかし、ビジネスなら話は違います。

趣味の延長でアマチュアレベルの自称プログラマーと、実際に利益を上げているＩＴ企業で鍛えられた本物のプログラマーでありエンジニアです。その違いは「動くかどうか」ではなく「性能、可読性、メンテナンス性」に出ます。

素人やアマチュアはただ「動けばいい」と考えます。
もしも売り切りのパッケージ製品ならそれでよかったかもしれません。

しかし、プロは「動くのは仕事として当たり前」と考え、そのうえでいかに「高速に動かすか」「読みやすく書くか」「あとで変更が容易か」を追求します。

プログラムは生き物であり、リリースしたあとも常に変化し続けます。

ランニングコストがかかりますから利益を生むためには「高速で使いやすい」ことも求められます。我流の文法で好き勝手に書かれた「汚いソースコード」はあとから参画するエンジニアにストレスを与え、開発効率を下げます。開発効率の低下はひいては利益の低下、赤字化などを招きます。

また、仕様変更への柔軟な対応を想定してプログラムが書かれているかも重要です。「わずかな機能追加でも大量のソースコードを修正しなければならない」ようなプログラムでは時間もお金もすぐに足りなくなります。

その大変さを理解しているエンジニアこそが"本物"です。

柔軟な変更要求に対応できるか

誰だって自分が作ったものを否定されるのは気分が悪いものです。
プライドの高いエンジニアほどそういう自己主張が強い傾向があります。

エンジニアでもプライドが高いタイプは「ここ、変えてくんない？」と頼んでも「いや、それは技術的に難しい」とか「今さら変更するのは不可能だ」などと拒否しがちです。

　まずいきなり否定から入る

問題、課題、ニーズを解決するエンジニアとしては最もやってはいけない対応です。性格的な面も非常に強いのかもしれませんが、すぐに「No」と言ってしまう人は正直エンジニアやチーム組織には向いていないかもしれません。

これまでも新人教育などでは、

「ビジネスパーソンになったら、Noは言わないこと。
　無条件のYesも言わないこと。
　言っていいのは、『条件付きYes』だけ」

と説明してきました。

「できる/できない」だけで言えば、大抵はなんでもできるに決まっています。ただ、できるまでの条件がいくつかあると言うだけでしかありません。

　「時間さえもらえれば出来ます」
　「今の仕事が終わってからならできます」
　「引き継ぎさえしていただければ出来ます」

条件は何であれ、できる条件を満たしさえすればなんでもできるはずです。
ゆえに依頼者が条件を満たせずNoと言うことはあっても、被依頼者がNoと言うことはありません。Noを言う時は利己的な感情が首をもたげてきた時だけです。

つまり、簡単にNoと言う人は、そういう人だと言うことです。

また、実際には「変更が不可能なプログラム」などこの世には存在しません。なんだかんだ理屈をつけて言い訳をするのは「変更できない」のではなく「変更したくない」だけなのです。そのことだけをピックアップしても、チーム活動や組織活動には向いていないことがわかります。

エンジニア自身も、ユーザーの目線で見れば

　「確かに今のままでは使いづらいから変更したほうがいい」

ことは理解していることもあると思います。それでもいざ自分がやるとなれば、面倒くささや失敗の恐怖から拒否反応を示すエンジニアがいるのです。なんでも言われた通りに対応するのがよいわけではありませんが、ユーザーの仕様変更要求に対してムッとしない、大人の対応ができるメンタリティがあることは重要です。

メンタルが子供のままでは問題を解決する立場にはなれないのです。

まとめ

現実にはこれら３つすべてを備えたエンジニアは稀でしょう。

しかし、エンジニアと名乗っておけば高単価になるから…と言って自称エンジニアを無理に活用してみたところで、期待したパフォーマンスが出せるわけではありません。結局のところ、見合った実力をつけなければ自称エンジニアは自称エンジニアのままです。

口先だけが上手くなっても、お客さまをその気にさせることができても、お客さまの問題や課題、ニーズを満たしてあげることは絶対にできません。

必ずバックボーンにはエンジニアリングできる『実力』が必要になるのです。

　「そういうのはメンバーに任せておけばいい」

と割り切ったリーダーも出てくるかもしれません。しかしそう言ったリーダーではおそらくまともにチーム運営もできません。なぜなら実力が伴っていなければただしい「評価（レビュー）」も適切な「指導」も何もできないからです。ちょっとマネジメントっぽいことをかじっていても実際にはただただ愚直でメンバーに負担ばかりかけた管理をしているリーダーもいます。結果的に、メンバーを疲弊させても自分自身は何一つ改善しようとしないリーダーもいます。それでもプライドが邪魔して自分は本物のエンジニアだと言い張り続けるのでしょう。

けれども、周囲は迷惑を被り続けるだけでいずれはメンバーだけでなくお客さますらも愛想をつかしていくことになります。