見出し画像

【第1章】3ヶ月で自走するエンジニアの育て方〜コミュニケーション力基礎固め編〜


・未経験エンジニアを雇ったけど、いつまでもパフォーマンスが上がらない
・技術はわかっているっぽいけど、技術用語ばかりでコミュニケーションが取りづらい
・ミスをしたので怒ったら、数日後に辞めますと言ってきた

嗚呼、どうしてエンジニアを育てるのはこんなにも難しいのか、。

そこで簡単なようで意外と難しいエンジニアの育て方についてお話していきたいと思います。


新卒エンジニアを教育する際にまず確保するべきものはなにか・・・?

それは「コミュニケーション経路」の確立だと思います。

つまり、言いたいことをきちんと言える、聞きたいことがきちんと聞ける

スムーズな双方のコミュニケーションを確立することが

自走するエンジニアの第一歩です。


まずはよくあるトラブルTOP3についてお話ししたいと思います。

1つ目:技術的なことを教えるけれども全く理解していない

プログラムを組む際にわからないところを聞かれたので書き方も含めて色々と教えてあげてわかりましたと言っていたにもかかわらず次の日には似たような問題で再度はまっている…

そしてまた同じ指摘をするとわかったと言うけれどもまた同じところではまってしまう… .

特に新卒時代のエンジニアにはこんな問題が多いのではないでしょうか

今まで触ってきたことのないプログラミングの世界だからこそ、「なぜそうなるのか?」がなんとなくわかったようでわからないまま・・

わからないです、ともいいづらく、「後で調べよう」と思って聞き流すけど、結局よくわからない、、でまた同じことの無限ループ。。

実案件の際には、個別事例のことが多く、書籍を買ってもどう応用したらいいかわからなくて途方に暮れる。。

なんてよくある話ですよね。(実体験)


2つ目:何を言っているのか何を伝えたいのかがわからない、と言われる。

Githubがまだなかった頃・・・

コードのレビューをお願いします!
メール本文にJavaのソースコードを丸々コピペして送ってきたのはどこのどいつだい(もう古いかw)

……はい私です

メールにソースを貼り付けるロックなやり方で、それをみた上司が、呆れを通り越して爆笑する、という出来事も今や懐かしい思い出です。


新卒時代には相手に何を伝えれば自分の言いたいことが伝わるのか分からずに謎の情報連携をすることが多いのではないでしょうか


社会人になってから、名刺の渡し方やビジネスマナー、プログラムに関する研修などは手厚くあった記憶ですが


自分の状況をどうやったら適切に相手に伝わるのかは、比較的、体当たりで学ぶみたいなところが多かったかな、と思います。

3つ目:利用者のことを考えずにプログラムを組んでしまう

専門学校や少しプログラムをかじったことがあるような子に多いような気がします

プログラムを作って終わりなことが学校では多いのでその後のメンテのことを考えずに

とりあえず動けば良いプログラムを作って出来ました!と報告する傾向が強いかなと感じます。


駆け出しの頃のエンジニアにとってはプログラミング云々と言う話よりも

周りの人とのコミニュケーションに苦労することの方が多いような気がします

何がわからないのかわかればフォロー出来るし

何を言いたいのかわかればアドバイスも出来る

でも、肝心の知りたい情報が出てこない、わからない。

というところで、上司も部下もヤキモキするのではないかと思います。


ではどのようにしていくとスムーズなコミュニケーションが確立できるのでしょうか。

ポイント1:例え話を多用し脳内でイメージがわくようにしてあげる


配列であれば箱

連想配列であったらラベル付きの箱

変数のスコープをイメージするためには家の部屋の中をイメージしてもらいます


現実世界とはなじみの薄いプログラミングですから駆け出しの未経験のエンジニアに向かってプログラム用語で話しても

なかなかイメージがわかずに忘れてしまうことが多いように感じています

だからこそ視覚的に理解しやすく覚えやすい身近なものを使った例え話を使って説明すると分かったフリがかなりの確率で減ります。

ポイント2:言いたいことをこちらから言葉にして伝えてあげる

特に新卒時代のエンジニアは今起きていることをどのように伝えたら相手に伝わるのかがワカラナイ子がほとんどです。

だからこそ何を言ってるかわからないコミニュケーションをしてきた際には

辛抱強く話を聞き最後にこれってこういうことが言いたかったんだよねと自分たちが期待していた話し方言葉遣いで相手にフィードバックをしてあげます

そうすると相手の中にどのように伝えれば伝わるのかその答えができあがりコミニケーション精度が上がっていきます

ポイント3:まずはツールを作らせてみよう

独学や学生時代にプログラミングを学んでいたりしたとしても1つ作ったプログラムを長いことメンテナンスすると言う経験を積んでいる人は非常に稀です

なのでプログラムを組んだ際に運用保守と言う観点が抜けてしまうことがほとんどです

それ自体はしょうがないにしてもこの辺の感覚は口頭で言っても伝わりづらいことが多いことも事実です

ですのでまずは自分で使うツールを作ってもらいそれを定期的にメンテナンスするようなワークショップを入れていくと

自分の書いたコードがどのように運用保守を妨げるのか実体験を通して理解してもらえると、言葉をたくさんかけずとも分かってくれます。

百聞は一見にしかず

ですね。


最後に

新卒を教育する立場に立った時に気をつけるようにしていることがあります。

それは、「学習を立体的に捉えること」です。

エンジニアなんだからプログラミングを教えればいいと思いこんで、コードをひたすら書かせる方がいます。

でも、そこで書いているプログラムは、誰の為の?何のためのプログラムなのか?を理解することのほうが

実はよっぽど大事だったりします。

なので、プログラムを一辺倒の教育よりも、コミュニケーション、ビジネス理解、など周辺のスキルにも目を配り

バランス良く育てて上げるのが自走するエンジニアを育成する近道なのではないかなと思います。

今回も最後までお読みいただきありがとうございました。

それではまた次の記事でお会いしましょう。


この記事が気に入ったらサポートをしてみませんか?