WEBエンジニア 中級者

こんなWEBエンジニアにはなるな!【アンチパターン】


悩む人
最近、業務にも慣れてきて、なんか開発も楽勝なんだよね。。俺、もしかして天才かも...

 

では、僕がその天狗になった鼻をへし折ってあげましょう。

 

WEBエンジニアとしてWEB開発ができるようになってくると「何でもできるんじゃないか」という気持ちになることがあります。

それは自信につながる必要な精神ですが、一歩間違えると、勘違い野郎になってしまう恐れもあります。

今回はWEBエンジニアにとって、アンチパターンになりやすいことを取り上げます。

 

WEBエンジニアのアンチパターンを知ることで、以下が得られます。

  • WEB開発ができる様になっても、天狗にならずにすむ。
  • 見本にしてはいけない先輩像が把握できる。
  • コミュニケーション力が高く評価され、必要な人材とされやすくなる。
  • 人間関係が円滑になる。開発チームとしてウザがられることはない。

 

 

余計な機能を実装してしまう

プログラミングができるようになってくると、期待通りに実装ができるようになるので、楽しくなってきます。

WEBエンジニアが陥りやすいアンチパターンとして、

 

「余計な機能を実装してしまう」

 

というものがあります。

僕が今までのWEB開発業務に携わっていく中で、実際にそんな人がいました。

 

「あると便利だから」という、個人の主観によって実装される機能、要件にない機能を実装することは、迷惑でしかありません。

特に納品時などでは、受け入れテストがあります。

 

受け入れテスト - 納品間際、顧客が実際にWEBシステムを操作し、要望通りに動くかどうかをテストしていくこと。

 

受け入れテスト時に要望にない機能が実装されていると、

 

「なんでこんな機能があるの?」

 

という疑問を与えてしまい、問題に発展します。

 

受託開発の会社に所属していた時は、さすがにこんなトラブルはありませんでしたが、

社内SE時には実際にこうした問題に直面した時がありました。

 

もし、あなたが

「こんな機能があった方がいい」

ということに気が付けば、それは「提案」として、行動することをオススメします

 

自己判断で実装してしまうことはWEBエンジニアとしては「アンチパターン」です。

顧客に提案し、「確かにその機能は便利だよね。」という話になれば、提案の価値を受け入れてもらったわけですから、あなたのWEBエンジニアとしての価値は上がります。

 

WEB開発に慣れてきても、自己判断で決定しないように気を付けてください。

 

覚えた最新スキルを使いたがる

人間や社会は「欲」で回っています。欲が人を便利にし、欲が社会の発展を促します。

勉強や自己向上も欲です。欲がなければ進歩はないです。

 

勉強して覚えたスキルは業務で「試してみたい」と思うのは、必然的だと思います。

ですが、 仕事とプライベートで勉強したことは全く別物です。

 

依頼や提案が通っていないにも関わらず、

とりあえず「新しいことをしたい」という衝動で、システム開発に学んだ技術を採用するのは、WEBエンジニアとして「アンチパターン」です。

 

僕が今まで経験した中でも、このパターンの人を何人か見てきました。

WEBシステムは運用が始まってからが、スタートです。保守・運用は長期的な視点で見ていかなければいけません。

 

新しいものばかりを取り入れた技術を採用することで、安定性がなく、バグを引き起こしたり、思いがけないトラブルに見舞われる可能性が高くなります。

 

WEB技術は日進月歩で、変化が激しいです。

 

今後、デファクトスタンダードになりえる技術なのか、長期的なサポートはあるのか。といったものを全て解決した後に採用すべきです。

 

WEBプログラマ・エンジニアとして、

 

「とりあえず覚えたから試してみたい」

 

という行為は、ただの自己満足だということを覚えておきましょう

 

補足: 上記二つの項目は特に、陥りやすいです。

以下ツイートです。

 

複雑なコードをドヤで作る

プログラミングを実装していく中で、同じような処理が必要になることが多々あります。

同じようなコードを書くため、プログラマは退屈になりがちです。

 

「もっとできる」という気持ちが先走り、複数行で書かれた見通しの良いコードを、無理やり1行に凝縮してしまったり、

関数を書けば、単純に解決できる問題を、正規表現を用いて、複雑に書いて見たりする傾向があります。

 

これは他の人が、そのコードを見て「何を書いているのか」というコードを理解する時間を費やすことになり、アンチパターンです。

 

プログラミングは、顧客の課題解決のための手段です。

どのように書くは、極論、顧客はどうでもいいです。

ただ、期待した通りに動けばよいのです。

 

長期的な運用・保守を可能にするために、メンテナンスしやすく、コードの内容がシンプルであることが大切なのです。

何がシンプルで、どう書けばよいのかは、オライリーの名著「リーダブルコード」をオススメしたいと思います。

 

なぜなら、多くのエンジニアが、この本を長期にわたって愛用していて、コードの書き方についてのデファクトスタンダードになりえる本だからです。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) (日本語) 単行本(ソフトカバー)– 2012/6/23

コードレビューで人を否定する

コードレビューは大切です。コードレビューは、開発メンバー全員のコーディング力の強化を促します。

そして、メンバーが、それぞれのコードに対する意見を聞くことができ、新たな発見につながります。

 

更に、全員が同じようなコードの書き方に変わっていき、他の人が見ても、理解しやすいコードとして運用することができます。

ですので、コードレビューは大切です。

 

ですが、たまに開発者の中でコードに対し、抽象的な否定をする人がいます。

「こんな書き方はダメです」とか、

「読みにくいです」

といった感じで。

 

コードレビューをする際は、コードの書き方がダメと感じるならば、別途コードを用意して、

「このように書けばもっとシンプルになりますよ。」とか、

「少し読みにくいのでコードをこのように変更すれば読みやすいですよ。」

と、 具体的に明示しなければいけません。

 

コードレビューはコードをより読みやすく指摘し合うことなのですから、

人に対しては「センシティブ」に扱わなければいけません

 

指摘の仕方によって、相手を傷つけたり、やる気をなくさせたりするものです。

単に否定するだけでは人を否定するのと同等に感じてしまいます。

 

WEBエンジニアにとって抽象的な否定しかできない人はアンチパターンです。

気を付けるようにしてください。

 

開発ツールを人に強要する

僕は過去の面接時に、

「なぜEmacsを使わないの?」とか、

「なんでOS読まないの?」

と質問されたことがあります。

 

その時に思ったのは、

「デフォルトで使用できるviで十分解決できるので、使ったことがないだけ。」

「OSを読まないのは業務では、読む必要性がないから読んだことないだけ。」

と思いましたが、そんなことを面接で言うと、見送り確定ですので、言葉を飲み込みましたが、案の定、見送りですw

そんな上司のエンジニアがいる所には、そもそも行かない方が良いですが。

 

その人にとっては、便利なツールかもしれませんが、人によって、便利なツールは違います。

課題解決の目的は同じなのですから、その人が使いたいツールで良いのです。

 

Emacsを使っていなかったらダメとか、

OSを読まなかったらダメとか、

AWSのLamda使ってなかったらAWS使ってる意味なくね?とか。

 

自分のレールが唯一正しい系の押し付けエンジニアはアンチパターンです

 

顧客の課題解決に対し、

「その時に自分が解決できるベストがそのツールだった。」

というのが正しいです。

 

「どのサービスを使わなかったからNG」ではありません。

 

要望を叶えることができ、顧客満足ができれば、どのツールを使用したって構わないのです。

開発ツールを強要してくるWEBエンジニアは、ただの傲慢ですから、真似しないようにしましょう。

 

まとめ

  • 機能の「あれば便利」は、全てお客様への提案にすること。そうすれば、あなたの価値が上がる。
  • 最新スキルを習得することは、良いこと。だが、業務で必要になるかどうかは別の話。使いたい衝動は抑えること。
  • 複雑なコードは、素人がやること。プロは常にコードがシンプル。
  • コードレビューはチーム力を上げる大切な機会。だが、人を否定するような指摘は誰も望んでいない。
  • 開発ツールは、単に問題解決のための手段である。「こうしなければいけない」という考えを押し付けるのは傲慢である。

-WEBエンジニア, 中級者
-

© 2021 FuwaFuwaShoChan BLOG