では、僕がその天狗になった鼻をへし折ってあげましょう。
WEBエンジニアとしてWEB開発ができるようになってくると「何でもできるんじゃないか」という気持ちになることがあります。
それは自信につながる必要な精神ですが、一歩間違えると、勘違い野郎になってしまう恐れもあります。
今回はWEBエンジニアにとって、アンチパターンになりやすいことを取り上げます。
WEBエンジニアのアンチパターンを知ることで、以下が得られます。
- WEB開発ができる様になっても、天狗にならずにすむ。
- 見本にしてはいけない先輩像が把握できる。
- コミュニケーション力が高く評価され、必要な人材とされやすくなる。
- 人間関係が円滑になる。開発チームとしてウザがられることはない。
余計な機能を実装してしまう
プログラミングができるようになってくると、期待通りに実装ができるようになるので、楽しくなってきます。
WEBエンジニアが陥りやすいアンチパターンとして、
「余計な機能を実装してしまう」
というものがあります。
僕が今までのWEB開発業務に携わっていく中で、実際にそんな人がいました。
「あると便利だから」という、個人の主観によって実装される機能、要件にない機能を実装することは、迷惑でしかありません。
特に納品時などでは、受け入れテストがあります。
受け入れテスト - 納品間際、顧客が実際にWEBシステムを操作し、要望通りに動くかどうかをテストしていくこと。
受け入れテスト時に要望にない機能が実装されていると、
「なんでこんな機能があるの？」
という疑問を与えてしまい、問題に発展します。
受託開発の会社に所属していた時は、さすがにこんなトラブルはありませんでしたが、
社内SE時には実際にこうした問題に直面した時がありました。
もし、あなたが
「こんな機能があった方がいい」
ということに気が付けば、それは「提案」として、行動することをオススメします。
自己判断で実装してしまうことはWEBエンジニアとしては「アンチパターン」です。
顧客に提案し、「確かにその機能は便利だよね。」という話になれば、提案の価値を受け入れてもらったわけですから、あなたのWEBエンジニアとしての価値は上がります。
WEB開発に慣れてきても、自己判断で決定しないように気を付けてください。
覚えた最新スキルを使いたがる
人間や社会は「欲」で回っています。欲が人を便利にし、欲が社会の発展を促します。
勉強や自己向上も欲です。欲がなければ進歩はないです。
勉強して覚えたスキルは業務で「試してみたい」と思うのは、必然的だと思います。
ですが、 仕事とプライベートで勉強したことは全く別物です。
依頼や提案が通っていないにも関わらず、
とりあえず「新しいことをしたい」という衝動で、システム開発に学んだ技術を採用するのは、WEBエンジニアとして「アンチパターン」です。
僕が今まで経験した中でも、このパターンの人を何人か見てきました。
WEBシステムは運用が始まってからが、スタートです。保守・運用は長期的な視点で見ていかなければいけません。
新しいものばかりを取り入れた技術を採用することで、安定性がなく、バグを引き起こしたり、思いがけないトラブルに見舞われる可能性が高くなります。
WEB技術は日進月歩で、変化が激しいです。
今後、デファクトスタンダードになりえる技術なのか、長期的なサポートはあるのか。といったものを全て解決した後に採用すべきです。
WEBプログラマ・エンジニアとして、
「とりあえず覚えたから試してみたい」
という行為は、ただの自己満足だということを覚えておきましょう。
補足: 上記二つの項目は特に、陥りやすいです。
以下ツイートです。
WEB開発の仕事をしてきて、アンチパターンだと思うのは以下です。
— ふわふわしょうちゃん@WEBエンジニア・メンター (@FuwaFuwaShoChan) September 26, 2020
・「自分が便利」という観点で、要望されていない機能を実装する
・覚えたスキルを使いたくて、何も考慮せずに使う
WEB開発できるようになると、良かれと思って、結構陥る傾向があるので、気を付けるようにすれば良いかと思います😌
複雑なコードをドヤで作る
プログラミングを実装していく中で、同じような処理が必要になることが多々あります。
同じようなコードを書くため、プログラマは退屈になりがちです。
「もっとできる」という気持ちが先走り、複数行で書かれた見通しの良いコードを、無理やり1行に凝縮してしまったり、
関数を書けば、単純に解決できる問題を、正規表現を用いて、複雑に書いて見たりする傾向があります。
これは他の人が、そのコードを見て「何を書いているのか」というコードを理解する時間を費やすことになり、アンチパターンです。
プログラミングは、顧客の課題解決のための手段です。
どのように書くは、極論、顧客はどうでもいいです。
ただ、期待した通りに動けばよいのです。
長期的な運用・保守を可能にするために、メンテナンスしやすく、コードの内容がシンプルであることが大切なのです。
何がシンプルで、どう書けばよいのかは、オライリーの名著「リーダブルコード」をオススメしたいと思います。
なぜなら、多くのエンジニアが、この本を長期にわたって愛用していて、コードの書き方についてのデファクトスタンダードになりえる本だからです。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) (日本語) 単行本（ソフトカバー）– 2012/6/23
コードレビューで人を否定する
コードレビューは大切です。コードレビューは、開発メンバー全員のコーディング力の強化を促します。
そして、メンバーが、それぞれのコードに対する意見を聞くことができ、新たな発見につながります。
更に、全員が同じようなコードの書き方に変わっていき、他の人が見ても、理解しやすいコードとして運用することができます。
ですので、コードレビューは大切です。
ですが、たまに開発者の中でコードに対し、抽象的な否定をする人がいます。
「こんな書き方はダメです」とか、
「読みにくいです」
といった感じで。
コードレビューをする際は、コードの書き方がダメと感じるならば、別途コードを用意して、
「このように書けばもっとシンプルになりますよ。」とか、
「少し読みにくいのでコードをこのように変更すれば読みやすいですよ。」
と、 具体的に明示しなければいけません。
コードレビューはコードをより読みやすく指摘し合うことなのですから、
人に対しては「センシティブ」に扱わなければいけません。
指摘の仕方によって、相手を傷つけたり、やる気をなくさせたりするものです。
単に否定するだけでは人を否定するのと同等に感じてしまいます。
WEBエンジニアにとって抽象的な否定しかできない人はアンチパターンです。
気を付けるようにしてください。
開発ツールを人に強要する
僕は過去の面接時に、
「なぜEmacsを使わないの？」とか、
「なんでOS読まないの？」
と質問されたことがあります。
その時に思ったのは、
「デフォルトで使用できるviで十分解決できるので、使ったことがないだけ。」
「OSを読まないのは業務では、読む必要性がないから読んだことないだけ。」
と思いましたが、そんなことを面接で言うと、見送り確定ですので、言葉を飲み込みましたが、案の定、見送りですｗ
※そんな上司のエンジニアがいる所には、そもそも行かない方が良いですが。
その人にとっては、便利なツールかもしれませんが、人によって、便利なツールは違います。
課題解決の目的は同じなのですから、その人が使いたいツールで良いのです。
Emacsを使っていなかったらダメとか、
OSを読まなかったらダメとか、
AWSのLamda使ってなかったらAWS使ってる意味なくね？とか。
自分のレールが唯一正しい系の押し付けエンジニアはアンチパターンです。
顧客の課題解決に対し、
「その時に自分が解決できるベストがそのツールだった。」
というのが正しいです。
「どのサービスを使わなかったからNG」ではありません。
要望を叶えることができ、顧客満足ができれば、どのツールを使用したって構わないのです。
開発ツールを強要してくるWEBエンジニアは、ただの傲慢ですから、真似しないようにしましょう。
まとめ
- 機能の「あれば便利」は、全てお客様への提案にすること。そうすれば、あなたの価値が上がる。
- 最新スキルを習得することは、良いこと。だが、業務で必要になるかどうかは別の話。使いたい衝動は抑えること。
- 複雑なコードは、素人がやること。プロは常にコードがシンプル。
- コードレビューはチーム力を上げる大切な機会。だが、人を否定するような指摘は誰も望んでいない。
- 開発ツールは、単に問題解決のための手段である。「こうしなければいけない」という考えを押し付けるのは傲慢である。