10分で生産的なミーティングができるWebサービス「minmeeting」を開発している伊勢川です。

本日は、これまで連載で紹介してきた2年目〜5年目エンジニアが陥りがちな症状と予防を要約して、まとめ記事を書きました。
網羅的にパターンを洗い出した訳ではなく、たまにそういうやつおるなという「おるおるネタ」の7選です。
若手エンジニアの皆さんは、ぜひこのようなくだらない失敗を繰り返すことなく、よりよい20代を過ごしていただければと思います。

Google依存症

Googleを調べれば何でもでてくる便利な時代が生んだ症状です。

症例

• エラーログをGoogleで調べて出てこなかったら、それは解決方法がないと思ってしまう。
• 新しいことをやろうとして、Googleに実現方法が書いてなかったら実現不可能と思ってしまう。

予防法

• Googleは日本語が苦手なので英語で聞く。
• Googleで見つからない解決策などいくらでもある。エラーメッセージなどをしっかり理解して、理詰めで試行錯誤をして解法を見つけ出すのが本来のやり方。

参考：エンジニアの二年目病とその予防法①　Google依存症

すぐできる・なんでもできる病

それなりに仕事ができるようになった、少し意識が高めの人がなりがちな症状です。

症例

• 机上の設計で実現できそうだとわかった時点で満足してしまう。
• または、自分ならすぐできると勘違いしてしまう。

予防法

• システムは論理の世界なので、データがあってネットワークがつながればだいたい何でも理屈の上では実現できる。しかし、理論上実現可能だからといって、それが現実的なコストで実現できるとは限らない。
• それどころか、オレならすぐできる、頑張ればできるは、ほとんどの場合は間違い。やってみたら必ずうまくいかない部分が出てくる。
• 本当に実現できるかの肌感覚は、実際に自分の手を動かしてやってみることでしか身につかない。自分でやってみて、ハマって、それを解決していくことで真の実力をつけることができる。
• なおこの症状は、二年目だけではなく、コードをかかなくなったマネージャー層にもたまに見られる。そんな人にはこの記事を読ませて、所詮お前の今の実力は二年目程度だということを思い出させるとよい。

参考：エンジニアの二年目病とその予防法② すぐできる・なんでもできる病

雑用ホイホイ症候群

気が利く頑張りやさんがなりやすい症状です。

症例

• 仕事を頼まれたらこれまでやっていた仕事を放ったらかして、すぐそちらに着手してしまう。その結果、First In Last Outで以前の仕事が遅延していく。
• 雑用をホイホイ受けてしまって、自分の生産性も上がらないし、後輩の教育にもならない。

予防法

• まずは雑用の趣旨・目的・背景を理解する。
• 多少時間がかかってもよいので、練習だと思って繰り返し発生する雑用を自動化する。
• 継続する必要のない雑用はタイミングを見計らって辞めてしまう。

参考：エンジニアの二年目病とその予防法③ 雑用ホイホイ症候群

放置プレイ依存症

新人時代に先輩から放置されていた人がなりやすい症状です。

症例

• 自分が新人のときは放置されていたため、そういうもんだと思いこんで、新しく入ってきた後輩もろくな指導もせずに放置する。
• 何度か仕事を振ってみて、うまくいかなかない、なかなか勉強しようともしないからといって、すぐに見限ってしまう。

予防法

• これまで教育なんてなかったんだからそれがあたり前という考えは捨てて、負の連鎖は自分の代で断ち切る。
• 教育はエンジニアの重要な仕事の1つであることを認識する。
• 人に仕事を頼む時は、自分ができると思った時間の2〜3倍かかると想定しておく。
• 成果物のイメージが異なる場合は、半分は仕事を依頼した側の責任。伝え方を改め、中間チェックなどをこまめに行うようにする。
• 2〜3年うだつが上がらないからといって、すぐに見捨てず開花するまで丁寧に指導する。（もちろん全くやる気がない場合は、無理強いせず、本人と相談の上で異動させるなど別の策を取ったほうがいいでしょう。）

参考：エンジニアの二年目病とその予防法④ 放置プレイ依存症

オープンソース・ライブラリ依存症

オープンソースのライブラリやその辺のAPIを組み合わせればだいたいのものが実現できる便利な時代が生んだ症状です。

症例

• オープンソースのライブラリに依存し、ライブラリにできないことは実現できないと思い込んでしまう。
• 採用しているオープンソースのライブラリに起因した不具合を発見した際に、ライブラリのせいなので対応できないと諦めてしまう。

予防法

• ライブラリが対応していないからと言って、それは実現できないことではないと認識する。
• ライブラリを使わなかったらどうやって実現するか、実現コストはどのくらいか、既存ライブラリとの住み分けをどうするかなどを検討する。
• 実現コストが安ければライブラリは捨ててリライトしてもよい。
• 実現コストが非常に高い場合は、修正してpull requestを出す。pull requestをしても反応がなければ別のライブラリに置き換える。

参考：エンジニアの二年目病とその予防法⑤ オープンソース・ライブラリ依存症

似非プロフェッショナリズム病

ここからは、少し年次が上の人がなりやすい症状についてです。

症例

• 専門家としての成果のみを追求し、仕事の目的を見失う。
• 自分の仕事はここまでと自分で勝手に線を引いて、自分の守備範囲の中だけの作業だけやっていればいいと思う。

予防法

• 何のための仕事なのか、全体の目的を見直す。
• 自分が担当している範囲を効率よくやることが、全体の効率をあげるとは限らないことを認識する。
• 目的から考えて他にもっと優先すべきことがないのかを常に考え、お客様や上司に確認する。

参考：エンジニアの進化と成功を阻む5年目病とその予防法①　似非プロフェッショナリズム病

自分しかできない病

仕事ができて働き者な人がなりやすい症状についてです。

症例

• 自分しかできない仕事が増えてきたことで、自分が優秀になったと勘違いする。
• 自分しかできない仕事なので、全部自分で抱え込んでしまい、後輩の教育も疎かになっている。
• 常に自分しかできない仕事で忙しいので、本当に優先度や重要度の高い仕事に取り組めない状態が慢性的に続いている。

予防法

• エンジニアは比較的属人性の高い職種であり、普通に仕事をやっていれば自分しかできない仕事、自分がいちばん詳しい仕事が出てくるのはあたり前のことだと認識する。（別に優秀でもなんでもない）
• 人間がやる価値のある仕事であれば、部分的にでもその仕事がシェアできる人を育てておく。
• 人間がやる価値のない仕事は自動化して誰でも再現できるようにしておく。
• 普段から身軽な状態にしておいて、本当に自分がやるべきことに集中する。

参考：エンジニアの進化と成功を阻む5年目病とその予防法② 自分しかできない病