· 

エンジニアは技術力以外に○○力が必要??

 皆さん、はじめまして。ヤマモトと申します。

 

普段ブログなんてものを書いたことがないので、

読みづらいところもあると思いますがご容赦ください。

今回はエンジニアとしての技術力に関しての内容ではなく、スキルというか能力について書いてみようかなと思います。 

まずは簡単に自己紹介的から。

私は、前職を含めこのIT業界には20歳で飛び込み、早12年になりました。

なんというかあっという間に10年越えましたね。で8年間は前職なので残りの4年がエボルバです。20歳(未経験)でIT業界に入り25歳で現場リーダー、28歳でエボルバに転職して現在はチームリーダー(クライアント内で)という感じです。

有馬温泉に向かう途中の道にある看板

さてさてそれでは、今回は技術力に関しての内容ではなくスキルというか能力について書いてみようかなと思います。

 

なぜエンジニアのブログで技術ではなく能力かというと、エンジニアって技術者でありながらクライアントに一番近い営業でもあると思ってるからです。

自分が行っている業務の成果を通してクライアントとの太いパイプが築ければ、

そこから新しい案件の獲得に繋がりどんどん自社貢献につながり、最終的には自社からの評価にも繋がっていくことになります。

つまり自社・自分・クライアントで WIN/WIN/WINの関係が一番作れるわけです。

信頼を得て増員提案や単価交渉をしていく…これって営業活動の流れの1つだと思いませんか?

 

だからこそ、技術力だけではなく、その他の能力も必要だと考えているわけです。

じゃあ信頼やパイプを築くためにはどうすればいいのか。

クライアントに「出来るやつ」と思われればいいんです。エンジニアとして技術力は最低限必要です。

けれど技術力だけでは中々評価は得られないのが、悲しいですが現実です。。

 

そこで私が必要だと思う能力はシミュレーション力です。

どんな能力かというと、読んで字のごとく「シミュレーション」することなんですが、実際にプログラムを書いて・・・とは少し違って、

自身が今現在取り組んでいることに対して、脳内でシミュレーションを行いその先でとれる選択肢を複数通り用意しておく事です。

感覚的にはプログラミングをやってるひとはイメージしやすいかもしれないですが、自身が書こうとしているプログラムのダメだった時の為に、

別のアプローチ方法も予め頭の中でシミュレーションして用意しておく感じをそのまま業務でも行うわけです。(想像するのがプログラムコードか自身がとれる行動かの違い)

 

実際私はクライアント先でサービス終了する回線を後継サービスに切替えてもらえるように推進・管理する業務を行っていますが、

業務範囲は、切替施策の検討から始まり、提案活動、進捗管理、時々トラブル対応といった感じなので、

全て1から考えていてはとてもではないですが、メンバーの管理や自社のことなんて考えている余裕はありません。

しかし普段から複数通りの選択肢をもっていると、会議でも意見を求めれられればすぐにいくつかの回答ができ、資料作成についても、用意しておいた選択肢の内の適した1個を資料に落とし込めば、効率的に作成ができます。

すると周りからは「仕事が早く、修正案もすぐに出る → 頼りになる」という評価が少しずつ蓄積されていき、比例して信頼を獲得していことになります。

 

資料を見つめる男性の写真

信頼を獲得できれば先に書いた通り、

単価交渉が行えたり増員に繋がったりするので自社への貢献もでき、 

最終的に自身の評価として給与などに反映される良いループが形成されていくわけです。(ちなみに私はこれを実践したことで、請求単価UP&メンバー増員に繋がりました!よし!!)

 

評価されたときに某CMのように「想定の範囲内ですね」なんて言えればいいですね(笑)

 

今回は一例としてシミュレーション力について少し書いてみましたが、他にも色々な能力があると思います。

他人と差別化できる能力を見つけて最大限に活かすこと、それこそがエンジニアとして重要なことなのではないかと思います。

逆に言えば他人と差別化できなければいつまでも他人と同じで評価もそこまでということです。

 

もしも今、なんだかわからんけど伸び悩んでるなぁなんて感じていたら、WIN/WIN/WIN/を意識しつつ、<シミュレーション力>を一考してみたらいかがでしょうか。

今このブログを見ている方が技術力だけにとらわれることなく、いろいろな視野・視点をもって活躍し、一緒に仕事ができることを楽しみにしています!


 関連記事はコチラ↓↓↓