フリーランスエンジニアのアンチパターン

もう長くフリーランスエンジニアをしていても業績などの外部要因以外で契約を切られているエンジニアというのはあまり見たことがない。ただし過去に切られた人の中で共通項を書いていきたい。

コードのキレイさににこだわりが強い

コードの品質にこだわりが強くとにかくキレイにしないとストレスが貯まる人。ただこの品質というのも実際には個人視点のキレイさであって他の人が必ずしもそのキレイさに同調しているわけでもなかったりする。

また個人的にキレイなコードじゃないとストレスが貯まるし、やりたくないというの一種のワガママに見える。フリーランスのエンジニアに求めらているのは汚かった・読みづらいコードも理解してプロジェクトを進められる能力が必要である。

自分は昔いた会社のコードがまあ酷かったからある意味耐性が付いたのは不幸中の幸いだったかも。

プロジェクト・プロダクトの成功ではなく自分のやりたいことを優先する

コードのキレイさに似ているが自分がやりたいタスクや実装方法に固執する。そのためちょっとしたタスクでも勝手に大規模なリファクタリングも追加したり、費用対効果が良くわからないリファクタリングを勝手に始める。リファクタリング自体は悪いことではないが誰からの同意を得ていないこと勝手に始めると他の人のリソースを奪うのでやめたほうがいい。

プロジェクトに参加していきなりアーキテクチャの変更や既存のコードを貶す

プロジェクト参加して実力を披露したく空回りしているか、もしくは自分が好きなアーキテクチャに変更して快適にしたいパターンである。ただ新参者がよくプロジェクトの理解が浅いままやると結局のところ費用対効果が悪く、なんならマイナスのことしかない。だから企業ブログで異動・新規に参加していきなりこんな改革をしましたみたな内容を見ると本当に大丈夫かな？という印象を持つ。

アーキテクチャだったり大きな変更というのは変えた直後ではなくて、実際には半年から1年くらい時間が経過しないと効果は出ないものだから。

また既存のコードに文句を言うのはやめよう。まだ1円も売上に貢献していないタイミングでそのような発言するとデメリットしかない。(デメリットしかないという発言する時点でとくにフリーランスには向いてないが)

進捗の共有が苦手

分かりやすく自分が何をしていてどこまで進んでいるか共有するのが苦手だったり、重視してない人がいる。そのためマネージャーの人は進捗共有について時間を取ることになってしまう。結果的にマネージャーの人が負担になってしまい悪い評価になる。

これの防止はチケット管理を入れているなら進捗状況をこまめに記入するだけで良い。そうすればマイクロマネジメントもされないので快適に仕事が進められる。