はじめに
著者は経験役 4 年のエンジニアです。今年思い切ってフリーランスエンジニアに転身しました。
転身後まだ 1 年経っていないですが自分自身の振り返りのためにも、「フリーランス 1 年目で感じたこと・これまでの転職活動で役に立ったこと、それらを踏まえて今後何を意識していくべきか」について書いてみました。
※ フリーランスでは節税や事務タスクも大事ですが、そのあたりのことはほぼ書いていません。
今年の転職活動
もともとは事業会社のエンジニアとして従事していましたが、今年（2024 年）4 月にフリーランスに転身しました。
某エージェント経由でバックエンドの案件に参画しています。
また、別で転職ドラフトで指名いただき、今年 10 月からテクニカルアーキテクトの案件にも掛け持ちで参画しています。
ちなみに転職ドラフトでは「業務委託を正社員よりも希望する」の設定にしていたものの、これまで正社員での指名が多かったので、業務委託で指名が来た時は結構驚きでした。
フリーになって感じたこと
まず、フリーランスになって感じたことを大きく 3 つ紹介してみたいと思います。
成長のチャンスは十分ある
「雇う側は定着率の高い正社員にコストをかけるので、フリーだと成長しづらい」的な話がよくあります。
ただ今のところ肌感としては、業務委託でも技術的な成長のチャンスは全然降ってきます。
私も今の現場ではありがたいことに、新しいチームの立ち上げや、触ったことのないサービス・経験のない領域のプロジェクトにも、アサインしてもらえています。
ただしチャンスをもらうには、「こいつならいけるだろう」と信頼してもらえるように、日々の仕事に対する姿勢を持つことが必要だと思います。
例えば、毎日の勤怠・レスポンス・周囲との連携・責任を持ってタスクをやり遂げているか、などです。
個人的には、特に案件参画直後はレスポンスの速さを意識しています。（最初はドメイン知識もなく業務を 1 人で進めるのは特に難しいので）
自己成長の意識は上げないといけない
前項と一見矛盾するように見えますが、正社員時代にあった 1on1 や目標設定などの機会がフリーランスにはないです。（1on1 は現場によってはあるかも）
また、研修等も基本は正社員限定で、業務委託は受けさせてもらえないと思います。
つまり、先輩からのアドバイスやインプットの機会は放っておくと少なくなります。
そうなると無意識のうちに技術的に停滞する・視野が狭まるなどのリスクがあります。
そのため、自ら成長しようとする意識は会社員時代より必要になると思います。
たとえば私は、フリー転身移行で以下のようなことをしました。
- Connpass で興味のあるウェビナーを探して定期的に視聴する
- 習慣化アプリで日々の記録をつける（朝活・読書・GitCommit など）
- AWS Summit に参加してみる ← 初
- 技術書展に行ってみる ← これも初
健康管理は会社員時代よりも大事
フリーランスは健康診断の受診義務はなく、勤怠も厳密に会社から管理されるわけではないです。福利厚生もないため、体調を崩しても会社は助けてくれません。
そのため、自分を律して健康管理する力が必要になります。
また、体調を崩して業務に穴を空けると、現場の皆も心配してくれますが、仕事上の信頼は落ちてしまいます。結果的に前項の「成長のチャンス」は降ってきづらくなります。
私は転身してから、特に生活リズムには気を使うようになりました。
また仕事の頑張りすぎも長期的には良くないです。とはいえ大事な時期もあるので、一時的に余裕がなくなっても長期間それを続けず適切なタイミングを見計らってリフレッシュするように意識しています。
途中でまとめ
他にも色々ありますが、大きいところはこんな感じです。
一言にすると、「プロとして」の姿勢が会社員時代より求められるな、と思いました。
ついでに
フリー転身前に読んだこちらの『自分株式会社の考え方』の記事が今でも印象に残っています。
会社員で続けていくにしてもこれからの時代、市場価値を高め続けるため軸になる考え方だと思います。
転職で役に立ったこと
次に、これまでの転職活動で役立ったこと・特に評価されたなと感じたことを書いてみます。
こまめなスキルシートの見直し
転職活動は時間も取られますし、精神的にもしんどい（私は面談後は疲れ果ててしまいます）ので、短期戦が向いていると私は思います。
「転職しよう」と思ったらまずエンジニアが始めるのはスキルシートを書くことだと思います。
ただこれが前書いたのが大昔だったりすると、長時間かけてシートを書く作業から始まり、いきなり時間とエネルギーを取られてしまいます。
そのため、理想的には 1 ヶ月単位くらいでこまめにスキルシートを見直して、準備しておくのが良いです。
私は会社員時代から転職ドラフトを利用しており、（毎回ではないにしても）よく参加していました。
定期的にドラフト参加することのメリットの一つに、スキルシートを更新するモチベーションが湧くことがあります。
たくさん指名が欲しいと思って参加するわけなので、自然と完成度の高いものを書こうとなります。
フリーランスになる際も、最初からスキルシートがほぼ書けていたので、エージェントさんからスムーズに案件紹介してもらえました。
技術記事の執筆
エンジニアとして技術記事は資産にもなりますし、書く過程で記憶の定着にもつながります。
私はたくさん本数がある訳ではないですが、キャリア初期から記事を書いています。
技術記事を書くのと書かないのとでは（内容に関わらず）、周りからの印象もかなり違います。
X を見てるとエンジニアは皆すごい記事を書いているように感じてしまいますが、継続的に記事を書いているのは実際、少数派なんじゃないでしょうか。
私も、職場で自分の Qiita の記事を共有すると「記事書くなんてすげーっすね！」みたいな反応がよく返ってきます。
もちろん転職活動の面でも、例えばスカウト時に記事のことを引き合いに出していただけることもよくあります。
また以前、案件面談での技術質問が（偶然）なんとなく忘れたくないなーと思って記事に書き留めていた内容だったことがあり、瞬発的にスラスラ話すことができました。その時の先方の反応がよく、私も手応えを感じ、結果的に案件を獲得できたことがありました。
こういった体験から、「これ書いたところで誰が見るんだろ」とか「LGTM つかないだろうな」みたいなことはあまり考えず自分のために、気になったこと・学習したことは記事として残しておくのが良いと思いました。
副業
特にキャリアの浅い段階で、副業で案件を掛け持ちすることで、エンジニア経験を積む速度をブーストできます。
これも私はキャリア初期から副業で業務委託案件に参画して、週末や平日朝に作業していました。
当時本業ではインフラ（クラウド）エンジニアとして働いていましたが、開発経験も積みたいというモチベーションから探し始め、色々な媒体で募集を探して応募していました。
その頃はほぼエンジニア経験がなかったので当然ながら落ちまくっていましたが、ありがたいことにとあるベンチャー企業様のバックエンド案件に採用いただいて、開発経験を積むことができました。
本業だとどんな経験を積めるかは会社側の事情にもよりますし、個人の力では中々身動きがとりづらいので、副業で経験を積みたい領域の案件を探してどんどん応募してみるのが良いと思います。何のリスクもありません。
また事務的な面でも、確定申告や毎月の請求書発行・作業報告書提出など経験でき、フリーランスとして働く準備ができたことも、結果的によかったです。
リード経験
リード・マネジメント系の経験を少しでもしておくと、市場的に大きなアピールにもなります。
また、メンバーレベルで入ったとしても現場上長が何を求めているかをイメージしやすくなってスムーズに業務できるようになります。
私はフリーに転身する前、少数ですがインフラチームのリードをしていた時期がありました。
プロジェクトの規模が大きかったこともあり、何をするにも調整が大変で苦しい時期もありました。それでも多くのステークホルダーがいる中での仕事の進め方を学べて、貴重な経験を積めたと今では感じます。
また、その時期に私が技術面の教育していた新卒メンバーが GCP や K8s のスキルをメキメキつけていくのを見て、とても嬉しかったことを覚えています。教えることの楽しさを知れました。
業務委託ではマネジメント案件は比較的少ないので、正社員のうちにチャンスがあれば経験できると最高です。
技術以外の自分の性格的なところも把握する
転職ドラフトなどのサービスでは、単純なスキルシートだけではなく、自分の志向やパフォーマンスを出しやすい環境を書く欄があります。
これを書くためには、自分の性格や何に喜びを感じるかを把握する必要があります。
把握しておくことで結果的にミスマッチを防ぐことができ、自分が苦痛に感じる場面を減らせることができると思います。
私の場合は、他喜力・プロダクト志向などがありました。
また子供時代から飽きっぽい性格なので、縦割りではなく横断的な業務範囲を任せてもらえるような環境が好ましい旨を書く・話すことが多いです。
自己分析っぽく「昔からどういう性格だったか」から思い出してみて、業務のスタイルに結びつけていくと良いかも知れません。
技術系の資格（場合による）
これは携わる会社の業態や、任されるポジションによって評価されたりされなかったりします。
特にインフラ・SRE 領域では体系的な知識が重要なため、評価いただけることは多い印象です。
私は GCP, AWS のプロフェッショナルレベルや K8s 関連の資格（CKA, CKAD）などを保持しています。（Credly）
実際、今参画中のテクニカルアーキテクトの案件では これらの資格を持っていたことが結構効いたと思っています。（もちろんそれ以外の要素も加味されたはずですが）
ただし、資格を取る・有効状態で保持するのは結構な労力がいるので、自分が転職したり現場を移ったりして何を経験したいか、目指すエンジニア像などを考えた上で、必要に応じて適度に取得していくのが良いと思います。
現場との技術的な親和性
これは現場（プロジェクト）との相性なので狙うことはできないですが、自分は以下経験に対して親和性があると言われることが多かったです。
- クラウドネイティブ系: GCP, AWS, IaC（terraform, CFn）, K8s（GKE, EKS）
- 技術負債の解消: CI の導入・改善、継続的なツールのアップデート等
- インフラだけでなく、バックエンド開発もしていた経験
先の話に関連しますが、キャリアの浅いうちに副業を始めたことで、早い段階から幅広く技術を経験できたことが、かなり役立ったと思います。
個人的な話をすると、今後 SRE のポジションに興味があったりしますが、基本 SRE でもコーディング能力は求められると思っており、現在はバックエンドの案件に入って修行中です笑
また、SRE チームが立ち上げフェーズにあったり、会社全体の規模がまだ小さくエンジニアが少数の場合など、インフラに得意を持ちつつも開発経験もあるエンジニアは求められるケースは多い印象です。
これから意識したいこと
最後に、上記振り返りを踏まえて、今後について書いていきます。
フリーランスの働き方は、私としては性に合っており、今後もしばらく続けようと考えています。
案件を継続的に勝ち取るために、以下は意識したいです。
スキルの棚卸しをこまめにする
時間が経つと、業務について細かいことは忘れてしまいます。
前の 1 ヶ月と次の 1 ヶ月で、全く同じことをしているということはほぼ無いはずですよね。
どのような技術・ツールを使ったかはギリギリ思い出せても、その業務で何を工夫したか・何を感じたかは中々覚えられていません。
しかしながら、このあたりが書けてこそ今後のキャリアでもアピールしやすいんだと思います。
私は、転身してから半年間ほとんど棚卸しできておらず、先日久しぶりにスキルシートを更新しようとした時に筆が止まってしまったので、この点反省しました。
できれば 1 ヶ月に一回棚卸しをして、スキルシートを更新していこうと思います。
些細なことでも記事を書く
たとえば業務で「ここうまく実装できたなー」と思った箇所や、勉強していて「ここ使えそうだから覚えておきたい」と思ったことは、どんどん記事を書いていくべきだと思います。
前項に関連しますが、文字にしないと大体のことは数ヶ月後に忘れてしまうはずです。
これはあまりにももったいないので、読者にウケるかどうかは関係なく書いていくのが吉だと思います。
また転職で役に立ったことで触れたように、記事という記憶の引き出しがあることで、案件面談等のとっさの場合にうまく回答する助けにもなったりします。
新しい知見を吸収し続ける
技術的なことも、自己啓発的なことも、インプットを続けることはエンジニアとしての成長に不可欠です。
業務は重要なアウトプットですが、アウトプット過多はそれはそれで行き詰まってしまってしまいます。
過去の経験としては、一年ほど前にすごく仕事が忙しくなりそちらに重きを置きすぎて、日々のインプットを怠ってしまった時期がありました。
その時は、技術的に停滞して周囲に追い抜かれていった感覚があり、かなり反省しています。
今やってることは、習慣化アプリで読書や情報収集などを毎日記録中です。
10 月は色々行事が重なりダメダメでしたが、、まあ計測することが第一歩なので、続けていこうと思います。
ひとり OKR をやってみる
以前こちらの記事を見かけて、すごくいいなと思いました。
フリーでは、会社員時代のような目標設定がないです。
この章で書いたことを今後実行していくにしても、具体的な目標や時期の設定がないとなかなか実行できず、なんとなく期間が過ぎていくだけな気が満載です。
そのため、ひとり OKR によって、モチベーションに頼らず自分を成長させる仕組み作りができそうです。
3 ヶ月後の KeyResult や 1 週間ごとのプランニング（結構ストイックだが）の設定をとりあえずやってみようと思いました。
引き続き健康管理はしっかりと
フリーになって感じたことで書いた通り、これは引き続き最重要です。
最後に
フリーランスに転身して一年目で感じたこと・これまでの転職活動を振り返った上で、今後やっていきたいことを書いてみました。
今後フリー転身を考えている方・転職活動をされる方の参考になれば幸いです。