投稿者 : 藤沢瞭介(Ryosuke Hujisawa) りょすけと申します。18歳からプログラミングをはじめ、今はフロントエンドでReactを書いたり、AIの勉強を頑張っています。off.tokyoでは、ハイテクやガジェット、それからプログラミングに関する情報まで、エンジニアに役立つ情報を日々発信しています!

フリーランスエンジニアが契約を切られる理由 | フリーランスエンジニアがクビを切られる理由

更新日 :

フリーランスエンジニアとして活動をしてると、

 

稼げる単価も高い分、超シビアに自分のスキルが評価されます。

 

特にフリーランスエージェント経由で現場に入ったりすると、その傾向が顕著に出ます。

 

なので今回の記事では、現在フリーランスエンジニアとして活動してる方で、契約の延長がされず悩んでいる方へ向けて記事を書きます。

 

勿論フリーランスだけではなく「俺ってなんて仕事ができないんだ?」と悩む全てのエンジニアの役に立つと思っています。

 

頑張って記事を考えたので、よければ最後までお付き合いください。

 

大前提として、楽な現場と厳しい現場があります

 

まず、そもそも論ですが貴方が速攻クビになるか否かは、現場に寄るところも結構あります

 

これは、スマホゲームの運ガチャと似てるところもあり、最初から予測することが困難です。

 

なので、楽な現場に当たると、自分が仕事ができなくても割と簡単に契約更新になったりします。

 

逆に、エンジニアの評価がキツイところだと、割と仕事が出来てもすぐに契約終了になったりします。

 

そういう運も関わってくることを、頭に入れておいてください。

 

PMがコードが書けない&プルリクを読まない人だとクビになりにくい

 

例えば、フリーランスエンジニアに対する評価の目線があまり厳しくない現場というのは、

 

プロジェクトのマネジメントをする人間が、エンジニアとしてチームに参加してない場合が多いです。

 

コードが書けないPMが自分の評価をする場合、そもそも適切な評価が出来ないため、

 

表面的にでもタスクの前進がされてるっぽければ、評価されることが結構あります。

 

でも、逆に、自分を評価をするPMが、GitHubのプルリクとか超コードが読める人で、

 

なおかつエンジニアとして開発の中に入ってる人だと評価の目は厳しくなります

 

だから、面談で最初に、自分の契約の有無を決める人がどういう人か見定めておくと良いと思います。

 

優秀なリードエンジニアが存在しないと現場はクビになりにくい

 

また、フリーランスの現場で契約の更新が容易な場合の特徴として、

 

どのような人がリードエンジニアかという部分にあると思います。

 

何故かというと、僕らのような凡人プログラマーは、

 

チームを指揮するリードエンジニアの指示を受けてコードを開発してくと思うわけですが、

 

リードエンジニアの人がとても優しくて、プルリクの指摘も「ここのコードをこういう風に直すと治りますよ」と、

 

改善案のコードまで丁寧に書いてくれる人がいて、そういう人だとコードの修正で詰まることがないんです。

 

逆に、プルリクの修正とかで、「OOでやれ」とか「OOがおかしい」とか「OO利用しろ」とか …etc

 

抽象的な指摘しかしないリードエンジニアだと、

 

修正で詰まって仕事が遅れ、自分の立場が微妙になったりします。

 

それとか、正反対にそもそもチームに参画したときにリードエンジニアがいなくて

 

自分がチームで一番の開発者だったりすると、途中ですぐクビになる確率もかなり減ると思います。

 

何故ならば、自分一人で開発してるのであれんば、そもそも強く注意する人がいないため、

 

誰もプルリクで指摘をしてこないので、チームで自分の立場が微妙になりません。

 

こんな感じで、フリーランスエンジニアとして現場に入るっていうのは、

 

かなり自分の評価も現場の環境に左右されるということを覚えておくと良いでしょう。

 

動くコードが実装できないとオワコン

 

しかしながら、例えどのような現場であれ、問題になることがありまして、

 

それが、そもそも動くコードが実装できないという根本的な問題です。

 

そもそも全く動くコードが実装できなければ、

 

仕事が前に進まないので、優しい現場でも契約終了になる危険性があります。

 

まあ、このような問題は、もう解決方法がないため、スキル磨くしかないわけですが、

 

プログラマーとして一番辛いことが、コードが動かないってことなんですよね。

 

バックエンドエンジニアの方が厳しいと思ってます

 

私の個人的なアドバイスとしては、バックエンドよりもフロントエンドの方が

 

動くタスクが実装できない問題は減ると思ってまして、

 

それは何故かと申しますと、DBとかインフラとかあまり考えなくて良いため、

 

同期的な処理を追っていけば、いずれでデバック出来ることが多いからっていうのもありますし、

 

結局フロント側って見た目の問題なんで、とりあえず仕上げるっていうことも現場では結構出来るからです。

 

でも、バックエンド側だと非同期的にデータの流れを頭にいれないとデバッグできないことがありまして、

 

それこそフロントエンド、バックエンド、データベース、インフラ、

 

それからサードパーティ製のライブラリの動きまで読まないといけないことが多々あります。

 

特にRailsとかで、ドキュメントとか情報の少ないgemを使っててバグったりすると地獄だったので、

 

僕は現在、自分の性格的にフロント側でReactをやり始めてから仕事がかなり楽になりましたし、楽しくなりました。

 

この記事を読んでる、読者の方全員に当てはまるか分かりませんが、参考にしてみてください。

 

チームで決められたルールに従わないとクビになります

 

また、これはコードの問題でもない部分があるのですが、

 

チームが定めた仕事のやり方を忘れまくったり、従わなかったりするのは、

 

思った以上に評価が下がるかなと思っています。

 

仕事が出来ない人というのは、横着して仕事を丁寧にやらず、重大ではないが小さなミスを繰り返す人です。

 

それで、エンジニアという仕事は、

 

根本的にコードが「動く」か「動かない」かという所をクリアするのが第一ステップで、

 

その次の第二ステップでは、

 

  • そのコードは効率的に書かれているか?
  • そのコードは正しく書かれているか?
  • そのコードは正しい場所に書かれているか?
  • そのコードは綺麗に書かれているか?
  • そのコードはチームが定めた規則に従っているか?

 

みたいなザックリですが、こういうレビューを通るじゃないですか?

 

第一ステップは大前提で、それこそ出来ないなら話にならないのでクビって話になるんだけど、

 

第二ステップは、エンジニア自身の仕事に対する姿勢や、性格が問われる領域だと思うんですよ。

 

そんで、大抵は仕事が出来ないと思われる人というのは、第二ステップでよくミスを起こすのかなと思うんですよ。

 

大抵の仕事は、一応終わるんだけど、その仕事を提出されてみたら、所々に細かいミスが散見されていたり、

 

何度も何度も前の注意したミスが治ってないとか、別に重大な失態ではないんだけど、どこかボロボロ抜けてるんですよね。

 

そういう人と一緒に仕事をすると、レビューする側が疲れるし、

 

また今回はどこかミスあるのかなと思わなきゃいけないので、信頼を寄せられないっていうか、

 

そういう人は、仕事が出来ない人って思われてクビになったりします。

 

おわりに

 

以上で、今日の記事をまとめていきます。

 

今日、私が書いたことは、ぶっちゃけエンジニアとして能力が高い人であれば、全く意味のない記事だと思います。

 

でも、世の中には僕のように凡人以下のエンジニアもいて、

 

フリーランスエンジニアになったけども、中々現場でパフォーマンス出せずに、

 

クビになってしまうって悩んでる人は結構いると思うんですよね。

 

ですので、簡潔にまとめますと、

 

  • 能力が平均以下でもクビにならない現場もある
  • 動くコードを実装するにはフロントの方が良いかも
  • 仕事を丁寧にやることを気をつければ仕事に対する評価はコードの問題とは関係なく上がる

 

ここら辺を意識して欲しいなって思っています。

 

では、今日は以上になります。



コメントを残す

メールアドレスが公開されることはありません。

関連記事