SESエンジニアや客先常駐先に出向、派遣されて仕事をすることになります。
そこで最も重要なことが自分にとってより良い出向、派遣先の職場の環境を引き当てること、つまり案件ガチャで当たると当てることになります。
なぜなら、常駐する派遣先の環境が良ければエンジニアとして成長できたり、プライベートと両立して安定した生活を送ることができますが、職場の環境が悪かった場合には、逆にエンジニアとして成長できなかったり、仕事が忙しすぎてプライベートが潰れてしまい、メンタルと体が病んでしまい……、なんてことだってありえます。
どんなにエンジニアとして有能でできるスキルを持っていたとしても、大ハズレの案件ガチャを引いてしまったら、今後の人生を悪い意味で左右することになってしまう取り返しのつかない事態になってしまう可能性だってあります。
そこでこの記事では、現役エンジニアの私が案件ガチャにバズレたなと思った瞬間6選を紹介します。
案件ガチャにバズレたなと思った瞬間6選
炎上プロジェクトだった
私が案件ガチャで一番ハズレだと思うのが炎上案件です。
炎上案件は、スケジュールや予算、人員などが不足し、納品やリリース・ローンチが間に合わないような継続が困難なプロジェクトのことで、忙しいプロジェクトであることがほとんどなので、毎日夜遅くまで残業が続いたり、参画したプロジェクトメンバーがイライラしていたり、余裕がないことでプロジェクトの雰囲気が悪いことが多いです。
そのため、以下の記事のようにエンジニアとしてパフォーマンスを下げてしまうといったデメリットのある案件ガチャのハズレであると私は思っています。
ただし、炎上プロジェクトは切羽詰まっている中で数多くのタスクをこなさなくてはならなかったり、不具合の多発しているシステムの火消しを行う対応力が必要になるので、炎上プロジェクトを経験したことで飛躍的に成長できる場合もあるので、一概に炎上プロジェクトがハズレだとは限りませんのであしからず。
設計書や引継ぎ資料がなかった
一般的なプロジェクトであれば、設計書や引継ぎ資料などのドキュメント類が充実していてエンジニアはいつでもできるようになっていうものです。
例えば、本番環境で稼働しているシステムで障害と思われる報告がクライアントから挙がってきた場合、ログを見て調査を行うことがありますが、設計書を見て仕様であるのか？もし仕様ではなく不具合でなかった場合、ソースコードの修正に入って障害の対応に入ります。
つまり、設計書がないと仕様であるのか判断する材料がなくなるので、ソースコードを見て処理の流れを調査する作業から入らなくてはならないので、苦労することになります。
また、設計書がないと新しい改修作業が入った場合もいちいちソースコードを直接見て解読しなくてはならないので、効率が悪くなります。
他にも新規で参画した案件で引継ぎ資料が不足していた場合、環境構築や仕様の理解で苦労することになります。
これらのことは頭が良い、悪いという問題ではなく、知っているか知っていないかの話で新しく配属されたプロジェクトのことなんて新しく配属された人だったら分からないことが当然です。
以上のことにより、設計書や引継ぎ資料がないプロジェクトに入ってしまった場合は、案件ガチャにハズレだなと私は思ってしまいます。
古い技術が使われていた
エンジニアの現場では、長時間使われている実績のある古い技術が使われていることがあります。
これは新しい技術への置き換えが不要であったり、予算の都合であることが多いのですが、その場合、例えばJavaであれば古いフレームワークが使われていたり、そもそもJavaのバージョンが古かったりすることがあります。
その案件ではそれがいいかもしれませんが、SESエンジニアであればその案件が終了して別の案件に映すときにその陳腐化された技術はあまり役に立たないことが多いです。また、Javaのバージョン一つを取っても、最新のバージョンであればできるラムダ式の書き方が古すぎるバージョンだと使えないので、知らないことが増えてスキルが今の時代についていけない時代遅れのエンジニアになってしまう可能性もあります。
他には、長年使われているけど一切テストコードがないような案件であった場合は、テストを自動化する文化がなく、プロジェクト自体が時代遅れで非効率になってしまっている可能性がありますので、最先端の現場だった人が古い現場に異動となった場合には案件ガチャにハズレたなと思ってしまうことがあります。
スキルが付かない業務しかできなかった
ウォーターフォール開発のエンジニアであれば、設計、製造、テストという流れでシステムを開発するのが一般的ですが、その中でもテストは設計や製造を比較してしまうと、エンジニアとして経験がなくてもできる業務になります。
新入社員や新人がエンジニアになって最初に与えられる業務であることも多く、逆にエンジニア歴が長く経験が豊富な人にとっては、設計やプログラムはやりたいけど、ひたすらテストを実施して結果をエビデンスとしてエクセル等に残す作業は雑務で退屈になりがちです。
良い意味でも悪い意味でもわがままなエンジニアでテストをやりたくないという人は一定数います。
そのため、プログラミングのスキルを付けないのに、プログラミングが全くできないスキルが付かない業務しかできないプロジェクトに参画されてしまったら、案件ガチャにハズレタなと思ってしまうことになります。
ただし、実際にテストはプロジェクトにおいて重要な役割を持っている工程であるため、雑務というわけなく、システムの品質を保証するテストエンジニアもいて、プロジェクトには欠かせない役割にもなります。
したがって、逆にテストをしたいエンジニアがテストをできない業務のプロジェクトに参画された場合は、案件ガチャにハズレたなということになってしまうことになります。
プログラミングコードがうんちだった
スキルが高い人のプログラミングコードは読みやすくて綺麗なコードになります。
そのため、第三者に運用保守する人にとっては読みやすく、理解しやすく、改修しやすいいいことずくめのコードになります。
これは以下の記事したリーダブルコードを読んで頂ければ具体的にどんなコードのことを言うのかお分かりいただけると思います。
逆にスキルの低い人や自分以外の人がソースコードを読むこと、将来的にシステムを運用保守する人のことを配慮できない人が書いたコードは、理解しずらく、汚いコードで、酷い場合には本人にも意味不明な複雑怪奇なコードになっていることだってあります。
そういったうんちで汚いコードが大量生産されているプロジェクトに参画されてしまうと運用保守業務で苦労することは必至だし、バグの温床だらけで改修するときに地雷を踏んでしまって新たなバグを生産しまったり、苦労することになってしまいますので、案件ガチャにハズレなと思ってしまうことでしょう。
メンバーがクソだった
プロジェクトで最も大切なことはなんですか？
私は人であると思っています。ITエンジニアとして案件に参画した場合、一人で仕事をするということはほとんどなく、チームメンバーと一緒にコミュニケーションを取りながら仕事をすることになります。
プログラマーなど開発者として参画した場合は、マネジメント業務で指揮を執るPLやPMの元で仕事をすることになりますので、PLやPMが威圧的で攻撃的なパワハラをするような人だったら楽しく仕事はできませんし、メンタルが病んでしまうことになってしまいます。一緒に仕事をする開発メンバーも同様で、プログラミングを分担したり、設計した人に仕様を聞いたり、一緒に仕様を考えたりすることは日常茶飯事なので、メンバーの性格が合わずクソだったら心理的安全性がなく、最悪な雰囲気の中、仕事をすることになってしまいます。
私ならプロジェクトに参画して自分と性格の合わない苦手な人が多数いたら、案件ガチャにハズレだなと思ってしまいます。
案件ガチャがバズレたときに取るべき行動
私が案件ガチャにハズレと悟ったら、できるだけ早くプロジェクトを退場する道を選びます。
内容にもよりますが、少なくともこの記事で紹介した、炎上プロジェクト、設計書や引継ぎ資料がない、古い技術、スキルが付かない業務、プログラミングコードがクソ、メンバーがクソというのは、自分の力ではどうにもならないからです。
設計書がないなら自分で作ればいいし、プログラミングコードがクソなら良いコードに変えればいいじゃないか？と思われるかもしれませんが、長年使われているシステムであるならすぐにできるものではありませんし、すぐにできないからこそ、今まで放置されてしまったプロジェクトになってしまっているので、どんなに有能な人であっても自分で改善できるような単純なものではありません。仮に改善できたとしても別の予算と工数が必要になるでしょう。
だったら、そんなことに時間をかけているぐらいならとっとと撤退して、案件ガチャをもう一度引き直して当たりを引けば解決できてしまうことなのですから。
ちなみに案件ガチャで当たりを引けば、無能なエンジニアでもフリーランスエンジニアへの転身ができる可能性もあります。
まとめ
この記事では、ITエンジニアの案件ガチャでハズレたなと思った瞬間6選と取るべき行動について紹介しました。
案件ガチャの当たりハズレというのは人によって異なると思います。この記事で紹介したハズレというのは私の中のハズレですので、もしかしたら、この記事を読んでいる人とっては私のハズレが当たりだったかもしませんので、もしそうであったらご了承ください。
また、参画してから案件ガチャにハズレたな？と思ってしまった場合でも遊びではなく、給料という形でお金を対価としてもらっている仕事なので、案件ガチャでハズレたとしてもある程度の範囲で我慢をしてその現場で働くことも大事なことではないか？と私は思います。
ただし、エンジニアとして成長できない、炎上プロジェクトでメンタルが病んでしまうような人生を左右するような深刻な事態になりかねない場合には、プロジェクトからの撤退も検討してみても良いでしょう。
