フリーランスエンジニアが契約を切られる理由、仕事ができないエンジニアの共通点
ソース ' ハイテク好きが楽しめるウェブメディア off.tokyo
フリーランスエンジニアとして活動をしてると、
報酬としていただける単価も高い分かなりシビアに自分のスキルが評価されることがあります。
特にフリーランスエージェント経由で現場に入ったりすると、その傾向が顕著に出ると思います。
なので今回の記事では、現在フリーランスエンジニアとして活動してる方で、
契約の延長が中々されず悩んでいる方へ向けて記事を書きます。
勿論、フリーランスだけではなく「俺ってなんて仕事ができないんだ？」
と悩む全てのエンジニアの役に立つと思っています。
頑張って記事を考えたので、よければ最後までお付き合いください。
現場に寄って求められる最低限のスキルが違ったりする
まず、そもそも論ですが現場で自分が速攻クビになるか否かは、現場に寄るところも結構あります。
これは、スマホゲームの運ガチャと似てるところもあるわけだが、最初から予測することも可能です。
PMがコードが書けない&プルリクを読まない人だとクビになりにくい
例えば、フリーランスエンジニアに対する評価の目線があまり厳しくない現場というのは、
プロジェクトのマネジメントをする人間が、エンジニアとしてチームに参加してない場合が多いです。
コードが書けないPMが自分の評価をする場合、そもそも適切な評価が出来ないため、
表面的にでもタスクの前進がされてるっぽければ、評価されることが結構あります。
でも、逆に、自分の評価をするPMが、GitHubのプルリクとか超コードが読める人で、
なおかつエンジニアとして開発の中に入ってる人だと評価の目は厳しくなります。
だから、面談で最初に、自分の契約の有無を決める人がどういう人か見定めておくと良いと思います。
リードエンジニアが優しい or 優秀なリードエンジニアが存在しないとクビになりにくい
また、フリーランスの現場で契約の更新が容易な場合の特徴として、
どのような人がリードエンジニアかという部分にあると思います。
何故かというと、僕らのような凡人プログラマーは、
チームを指揮するリードエンジニアの指示を受けてコードを開発してくと思うわけですが、
リードエンジニアの人がとても優しくて、プルリクの指摘も、「ここのコードをこういう風に直すと治りますよ」と、
改善案のコードまで丁寧に書いてくれる人がいて、そういう人だとコードの修正で詰まることがないんです。
逆に、プルリクの修正とかで、「OOでやれ」とか「OOがおかしい」とか「OO利用しろ」とか ...etc
抽象的な指摘しかしないリードエンジニアだと、修正で詰まって仕事が遅れ、自分の立場が微妙になったりします。
それとか、正反対にそもそもチームに参画したときにリードエンジニアがいなくて、
自分がチームで一番の開発者だったりすると、途中ですぐクビになる確率もかなり減ると思います。
何故ならば、自分一人で開発してるのであれんば、そもそも強く注意する人がいないため、
誰もプルリクで指摘をしてこないので、チームで自分の立場が微妙になりません。
こんな感じで、フリーランスエンジニアとして現場に入るっていうのは、
かなり自分の評価も現場の環境に左右されるということを覚えておくと良いでしょう。
動くコードが実装できないとオワコン
しかしながら、例えどのような現場であれ、問題になることがありまして、
それが、そもそも動くコードが実装できないという根本的な問題です。
そもそも全く動くコードが実装できなければ、仕事が前に進まないので、優しい現場でも契約終了になる危険性があります。
まあ、このような問題は、もう解決方法がないため、スキル磨くしかないわけですが、
プログラマーとして一番辛いことが、コードが動かないってことなんですよね。
バックエンドエンジニアは難しいと思う
私の個人的なアドバイスとしては、バックエンドよりもフロントエンドの方が、
動くタスクが実装できない問題は減ると思ってまして、
それは何故かと申しますと、DBとかインフラとかあまり考えなくて良いため、
同期的な処理を追っていけばいずれでデバック出来ることが多いからっていうのもありますし、
結局フロント側って見た目の問題なんで、とりあえず仕上げるっていうことも現場では結構出来るからです。
でも、バックエンド側だと、非同期的にデータの流れを頭にいれないとデバッグできないことがありまして、
それこそフロントエンド、バックエンド、データベース、インフラ、
それからサードパーティ製のライブラリの動きまで読まないといけないことが多々あります。
特にRailsとかで、ドキュメントとか情報の少ないgemを使っててバグったりすると地獄だったので、
僕は現在、自分の性格的にフロント側でReactをやり始めてから仕事がかなり楽になりましたし、楽しくなりました。
この記事を読んでる、読者の方全員に当てはまるか分かりませんが、参考にしてみてください。
チームで決められたルールに従わないとクビになります
また、これはコードの問題でもない部分があるのですが、
チームが定めた仕事のやり方を忘れまくったり、従わなかったりするのは、
思った以上に評価が下がるかなと思っています。
結構前にブログで、「仕事が出来ない人の特徴は、横着して仕事を丁寧にやらず、重大ではないが小さなミスを繰り返す人」
という記事を書いたのですが、その一部を引用しながら説明させていただきますと、
https://kyokan.fun/2021/02/14/way-you-work/
仕事が出来ない人というのは、横着して仕事を丁寧にやらず、重大ではないが小さなミスを繰り返す人です。
それで、エンジニアという仕事は、根本的にコードが「動く」か「動かない」かという所をクリアするのが第一ステップで、
その次の第二ステップでは、
そのコードは効率的に書かれているか？
そのコードは正しく書かれているか？
そのコードは正しい場所に書かれているか？
そのコードは綺麗に書かれているか？
そのコードはチームが定めた規則に従っているか？
みたいなザックリですが、こういうレビューを通るじゃないですか？
第一ステップは大前提で、それこそ出来ないなら話にならないのでクビって話になるんだけど、
第二ステップは、エンジニア自身の仕事に対する姿勢や、性格が問われる領域だと思うんですよ。
そんで、大抵は仕事が出来ないと思われる人というのは、第二ステップでよくミスを起こすのかなと思うんですよ。
大抵の仕事は、一応終わるんだけど、
その仕事を提出されてみたら、所々に細かいミスが散見されていたり、
何度も何度も前の注意したミスが治ってないとか、
別に重大な失態ではないんだけど、どこかボロボロ抜けてるんですよ、いつも。
そういう人と一緒に仕事をすると、レビューする側が疲れるし、
また今回はどこかミスあるのかなと思わなきゃいけないので、信頼を寄せられないっていうか、
そういう人は、仕事が出来ない人って思われると思います。
例えば、コードの書き方だけではなく、ちゃんと決められた日報を提出するとか、
プルリクの決められたテンプレートに従って書くとか、タスクの時間管理を漏らさないとか、
そういう真面目じゃないところは自分の評価を下げることがあるので注意です。
おわりに
以上で、今日の記事をまとめていきます。
今日、私が書いたことは、ぶっちゃけエンジニアとして能力が高い人であれば、
全く意味のない記事だと思います。
でも、世の中には僕のように凡人以下のエンジニアもいて、
フリーランスエンジニアになったけども、中々現場でパフォーマンス出せずに、
クビになってしまうって悩んでる人は結構いると思うんですよね。
ですので、簡潔にまとめますと、
能力が平均以下でもクビにならない現場もある
動くコードを実装するにはフロントの方が良いかも
仕事を丁寧にやることを気をつければ仕事に対する評価はコードの問題とは関係なく上がる
ここら辺を意識して欲しいなって思っています。
では、今日は以上になります。
