無能なエンジニアというのはどのようなエンジニアのことでしょうか？
答えは、この記事を書いているダメ系ITエンジニアこと私のことです。
私のような無能なエンジニアになってはいけないことの警鐘を鳴らしたいという意味でこの記事を書いてみました。
ブログ閲覧者クズだ、お前のようなエンジニアがいるからダメなんだ
という不快な思いをさせてしまった有能なエンジニアの方には申し訳ございません。
逆に共感してしまった人は無能なエンジニアになってしまう可能性を持っている人かもしれませんので、絶対に私のようなエンジニアにならないように気を付けてください。
無能なエンジニアの10の特徴
1. 仕様を理解できていない
システム開発をする上で仕様を理解することは必要なことです。
というより、仕様を理解できていないと要件定義も設計もプログラミングもテスト仕様書も作成することはできません。
私の場合は、仕様を全く理解できていないということではありませんが、なんとなくふんわりとした内容しか理解できていないので、上流工程の仕事を担当するときは一歩踏み込んだ深い仕様の設計を行う際は、いつもPMやPL頼みになってしまっています。
技術面においてもJavaにはオブジェクト指向という概念があるのですが、開発経験3年以上あっても私も場合はよく理解できていません。ふんわりとしたことは分かるような分からないような……少なくとも面談で説明して下さいと言われたら説明できないほど分かっていません。
仕様を理解できないのは地頭の悪さ、技術スキルを理解できないのは勉強不足なのかと自分では思っていますが、とにかく仕様を理解できないことがあり、無能だと感じることが多いです。
仕様が理解できていないなら聞くしかないのですが、経験年数や年齢が上がれば上がるほど
こんなことも分からないの？
と思われるのが嫌で変なプライドが邪魔して聞きたくても聞けなくなっていきますので、状況は年齢と比例して悪化していきます。
2. 何でもコピペしてしまう
プログラミングをやっていて良く感じることなのですが、コピペが癖になっていて、何でもかんでもコピー＆ペーストします。
もちろんコピペは悪ではなく効率良くやれば時間の短縮にもなってむしろ良いことになりえるのですが、コードの意味や仕様を理解できていないでコピペをしてしまうとプログラミングスキルは身に付かないですし、最悪の場合は誤ったコードをコピペしてしまうことでバグの温床になってしまいます。
また、直打ちした方が早いプログラミングの実装やGitやLinuxのコマンドを毎回いちいちネットで調べてコピペするのは効率が悪いので、無能なエンジニアがしてしまう典型的な特徴と言っても良いでしょう。
ソースコードのコピペは著作物の侵害になってしまう可能性があります。
Web上に公開されている場合でも著作権の侵害に該当する可能性がありますので、コピペする場合は著作権フリーであることが確認できた参考程度のサンプルコードのみにしておく等、十分注意するようにしましょう。
3. 勘でやってしまう
ブログ閲覧者仕様を理解できていないのに、無能だと自負しているあなたはどうやってエンジニアとして仕事をやっているの？
と思われる方もおられることでしょう。
ざっくりいうと勘でやっています。第6感的な勘です。
勘でやってしまうので、勘が当たればうまく仕事が進んでいくのですが、勘が間違っていると間違った方向に仕事が進んでしまい、取り返しのつかない事態になってしまうことも多々あります。
例えば、ウォーターフォール開発の要件定義や見積もりを勘でやって間違っていた時は下流工程のテストでその間違いが発覚した場合、要件定義からプログラミング製造からやり直しが発生し、納期までに間に合わない炎上プロジェクトになってしまいます。
有能なエンジニアではあれば勘ではやらず、要件の仕様やプログラミングをしっかり理解した上で仕事を行いますので、炎上プロジェクトのリスクを避けることができます。無能なエンジニアは良く分からないので勘に賭けてしまった挙句、悪い方向へ舵をとってしまうことが多くなりがちになります。
4. 勉強しない
IT業界は技術トレンドの移り変わりが早かったり、エンジニアは覚えることが多い職業なので、生涯学習が必要と言われているぐらい勉強することは大事なことです。
それなのに勉強しないエンジニアは成長できないですし、勉強しているエンジニアと比較すればドンドン差が開いて無能になっていってしまいます。
私の場合、できないエンジニアであるにもかかわらず、勉強しないエンジニアなので、無能でダメ系エンジニアであると自負しています。
5. 覚えたことをすぐに忘れる
アルツハイマー型認知症なんじゃないかってぐらい覚えたことを次の日には忘れてしまうことが多いです。
この忘れるというのが物凄く効率悪いと感じています。
例えば、JavaではString型の文字列を比較する際にequalsメソッドを使用する場合、以下のコードのようにequalsより前の文字列にnullが代入されている状態からメソッドを呼び出してしまうとNullPointerExceptionの例外が発生してしまいます。
String str = null;
str.equals("hoge");
例外を発生されないようにして正しく比較するようにするために、以下のコードのようにequalsでチェックするhogeのstrを逆にするだけで、strにnullが代入されていた場合でも例外が発生することなく、NullPointerExceptionを回避することができます。
String str = null;
“hoge”.equals(str);こんな簡単なことを忘れてしまって製造してしまい、テストでこの手の不具合が出ることが多々あります。
コピペのトピックでも紹介しましたが、GitやLinuxのコマンドを忘れてしまい、ネットで検索することが多いので、非効率になっていると感じています。
6. 自分で書いたソースコードを説明できない
自分で書いたソースコードにも関わらず説明できないことが多いです。
ブログ閲覧者それってありえないでしょ？自分で書いたんでしょ？どういうこと？
と思われる方もいらっしゃると思いますが、私が説明できない理由は、前のトピックで挙げたコピペと勘でやっていることが原因なのですが、説明できないことでコードレビューをしてくれる人にも迷惑かけますし、バグの温床になるのは必須ですし、作った本人が理解説明できないようなソースコードなのだから本番稼働された後にソースコードを運用保守する人もメンテナンスできないようなものになってしまいます。
せめて自分で書いたソースコードは説明できるべきでありますし、説明できないようなソースコードであればレビュー依頼してはいけません。
7. 悪い意味でめんどくさがり
エンジニアは丁寧で几帳面な性格であればあるほど向いている職業だと思います。
なぜならそういった性格の人のソースコードは綺麗でバグの温床が少なく、他の人もメンテナンスしやすいからです。
ところがめんどくさがりの性格の人がソースコードを書くとメソッド化されていなくて汚いソースコードであったり、エラーチェックが甘くバグの温床だらけで危険なプログラムになっていることが経験上多いです。
また、めんどくさがりの人に多いのがテストコードを書くのがめんどくさいから嫌という意見です。
テストコードを書くことで工数が多くなりがちですが、メンテナンスが多い案件ではテストコードを書いておくことでリグレッションの観点で改修した箇所以外の影響を回避することができたり、自動テストで正確性のあるテストが実施できてかつテストの時間を大幅に削減できたり、テストコード書いた工数以上の時間に見合ったリターンを得ることができます。
良い意味でめんどくさがりの人はシステムを自動化するエンジニアとして有能ですが、悪い意味でめんどくさがりの人はめんどくさいから自動化するシステムの構築を放棄したり、ソースコードのリファクタリングを放棄してメソッド化しなかったりでソースコードをひたすら汚くする人は無能なエンジニアといっても良いでしょう。
8. 自分に甘い
自分に甘い性格が仕事に悪影響をきたしていると思うことがあります。
これはエンジニアなのに勉強しようとしない仕事への姿勢に関してもありますが、自分で製造して自分でテストしているときに無意識のうちにバグが発見されると修正が大変だからテストが甘くなっているように感じることがあります。
テストは本番稼働前に発見することができる良い意味で最後のチャンスになるので、テストに手を抜くなんてあっていいはずがありません。
ですが、他の人がコーディングした部分と比べて自分でコーディングした部分のテストが甘くなっているように感じることがあるのです。
これは本当に最低だと思うので、自分に甘い性格は仕事で出さないようにしましょう。
9. 報連相がない
報連相（ホウレンソウ）とは「報告・連絡・相談」のことです。
できない無能なエンジニアであればあるほど、報連相を怠ってしまい、進捗を誤魔化して順調に進んでいるようにできるように見せかけておいて、納期ギリギリになって
実はできていませんでした
ということが多いように感じます。
こういった根底にあるのが、いざとなったら残業でやればいい、休日出勤してやればいいという非効率な考え方です。
業務時間内で仕事できるように意識するべきですし、もし業務時間内に終わらないようなタスクであれば、報連相はしっかりするようにしましょう。
報連相はスキルや能力とは関係しない誰でもできることなのですから。
10. できないから諦める
自分に甘い性格からきていることだと思いますが、プログラミングをしていてあるのが自分には難しかったり時間がかかってできないから諦めてしまい、効率が悪い実装だけどできる方を選択してしまうことがあります。
以前にあった例だと、バックエンドの処理で取得したJson形式の情報をフロンドエンドでグラフ描画されるという処理の実装がありました。そのままJson形式で渡して処理すれば相互でコーディング量が少なく済むのにどうしても受け渡し部分が上手くいかなかったので、Json形式で処理するのを諦めて配列形式で処理する方を選択してしまいました。
その結果、サーバサイドではJson形式から配列形式に変換する処理が必要になってしまい、さらにフロントエンドも配列形式で表示できるようにグラフ描画の実装を修正する必要が生じて、余計な工数とバグの温床となる汚いクソコードになってしまいました。
絶対にできないことならともかく、Json形式で受け渡せる方法はあるはずなので、安易にできないからという理由で諦めてしまうことは無能であると私は思います。
まとめ
この記事では、無能なエンジニアの10の特徴について紹介しました。
無能なエンジニアというよりは、私自身の特徴で悪い意味での自己紹介になってしまったかもしれません。
自分のことを有能なエンジニアだと思っている人でも紹介した無能なエンジニアの特徴に当てはまる人がいるかもしれませんので、気を付けるようにしてください。
無能なエンジニアの人であれば、悪い特徴になりますので、仕事に対しての考え方を改めるようにした方が良いでしょう。
自分でこの記事を書いていてほとほと自分に対して嫌気が指してきましたので、無能なエンジニアの特徴を一つずつ潰していけるようにしたいと思います。
