オワコンエンジニアの特徴とは？〜みんなのプログラミングチャンネル　vol.26〜

これまでミングラでは、「こういう人はエンジニアに嫌われる」とか「ベンチャーにいるエンジニアの敵」のような人を紹介してきましたが、今回は、エンジニアに業務を発注するプロダクトマネージャー側からも「エンジニアに言いたいことがある！」ということなのでご紹介します。

■プログラマーにありがちな思考と言動

先日Twitterで少し話題になったこの話を知っていますでしょうか？

画面に表示するので、読みながら聞いてみてください。

プログラマーの夫に買い物を頼んだ。

 妻「牛乳を１パック買ってきて。卵があったら６つお願い」

すると夫が牛乳を６パック買ってきた。

 妻「なんで牛乳を６パックも買ってきたのよ」

夫「だって卵があったから」

この話はプログラマーならではの行動を切り取った話なのですが、今回話を聞いたプロダクトマネージャーさん、つまり、非エンジニアからすると、「誤解するのは仕方ないとして、牛乳６本は要らないだろって気付いて声かければいいのに」と思ってしまうとのこと。

もう一つ例を挙げてみましょう。

妻が夫に「バンドエイド買ってきて」と言われたとします。

バンドエイドというのは「ジョンソンアンドジョンソン社」の商標で、、その言い方だと買ってきて欲しい商品まで指定していることになります。本当は絆創膏というのが正解です。

この場合お店に行ってバンドエイドがなかったとしたら夫はどうすれば良いでしょうか？

両方話で言えることは、「エンジニアの夫は間違ってはいない」ということです。

つまり、論理的に破綻した行動ではなかったということです。

でも、スーパーに卵があることを条件にして牛乳の購入数を増やす、という依頼は確かに不自然なわけですよね。

絆創膏をわざわざバンドエイド一択！というつもりで「バンドエイド買ってきて」ということもそんなに多くはないと思います。

このような場合は、グラさんからすると「夫の側が曖昧さを指摘してあげないとダメ」だと思います。

■「曖昧さの指摘」ができないエンジニア

開発現場でもクライアントの意向が曖昧なところはたくさんあります。

これをきっちり詰めずに「こうだろう」という憶測で開発してしまうと必ず事故ります。

新しい技術を学ぶ時であれば「だろう運転」的なアプローチが当たり前で、曖昧を許さないと学習を先に進めることができないわけですが、仕事はその逆です。

この「曖昧さの指摘」というのができないエンジニアが結構います。

非エンジニアだけではなく、クライアントの意思を汲み取る力がないエンジニアには「喝」です！

やりたいことを仕様にまで噛み砕けるクライアントは滅多にいないわけですから、ここがエンジニアの本懐とも言えるわけです。ここができないエンジニアはオワコンエンジニアということになってしまいます。

■課題を共有できるエンジニアが重宝される

ここで事故らないポイントは、クライアント側にしても開発側にしても、課題を共有するということです。クライアントは経営課題・運営課題を持ち込み、開発側はコストや納期、セキュリティ・ユーザビリティ・UXなどの課題を持ち込みます。

エンジニアの仕事はこれらの課題を、一行一行のコードで対処していくわけですから、曖昧にしたまま開発に走れば、出戻りが多く、そして仕様を変更するたびに、バグがでます。

ですから、曖昧だなと思った時点でクラアントに連絡し、「こういう課題と認識しているので、ここは、こういう仕様にしたいと思いますがいかがでしょうか？」というアプローチをするのが、エンジニアがクライアントの信頼を得る瞬間です。

クライアントがガミガミ言う前に先手を打てるエンジニアが結局、勝ち残れます。

フリーランスで勝負したい方はここがポイントです。

会社のブランドで仕事している人はこれができないエンジニアが多いのです。

「曖昧さの指摘」ができないエンジニアは、小さい頃からプログラミング教育を受けてきたデジタルネイティブ世代に簡単にとって変わられてしまうでしょう。

■「曖昧さ」がわからないオワコンエンジニア

中には「どこが曖昧なのかわからない」エンジニアもいます。

クライアントにとっては、何言っても言うこと聞いてくれないと感じます。

この人はすでに終わりなので、この市場から退場した方がいいかもしれません。

いつもミングラで言っているように、クライアント側にもリテラシーを持って欲しいですが、エンジニアもクライアントのイメージ発注を形にしてあげられるような力をつけておきたいですよね。

ということで今回は、クライアントさんの立場から、エンジニアに喝を入れてみました。