はじめに

私は正社員経験なしのままフリーランスエンジニアになりフルリモートでWEB開発のフルスタックエンジニアとして働いています。

一度も正社員等の育成対象枠で働いていないので王道のエンジニア転身ルートではないと思いますが、現場に出てみて感じたのは「いきなりフルリモートだから難しい」のではなく、自走力がないと厳しい、という一点でした。

私が言う自走力は、特別な才能の話では絶対にありません。
誰も正解をくれない状況でも、腐らずに、止まらずに、不完全でも自分なりの答えを出し続ける力のことです。

この記事では、正社員を経ずにフリーランスとして現場に出た私が、なぜ大きくつまずかずにやれているのか、そして、その中で見えてきた「再現できる部分」を整理してみたいと思います。

スクールは「教えてもらう場所」ではなく「レビューを受ける場所」

私が感じているShiftBの一番の価値は、教えてもらうことではありません。
自分で出したアウトプットに対して現役エンジニアにレビューをもらえることです。

知識を教えてもらうだけなら、動画教材や書籍、今ならAIでも十分です。
でも、自分のコードに対して人からレビューが返ってくる環境は、独学では基本手に入りません。
その環境だと動けばOKになってしまいます。
なぜその実装にしたのか、別案はなかったのかを振り返る機会がほとんどありません。

ShiftBがPRベースの学習になっているのも、現場にかなり近い形だと思っています。

自分で考えて実装 → PRとして出す → レビューを受ける → 自分で直す

これは完全に普通のWEB開発の擬似体験のような経験になっています。
チーム開発はまた違う部分もありますが基本的な操作はほんとに同じです。

私と同時期に入った人がgithubの使い方知らずに1ヶ月契約だったが2週間で切ったと言う話も聞きました。業務委託はこれが現実です。

この一連の流れが回せるかどうかが、現場でエンジニアとして通用するかどうかの分かれ道です。
質問できる環境は当然あります。でも使い方が重要です。

質問するということ

誤解してほしくないのですが、「質問するな」と言いたいわけではありません。
どうにもならないときに聞ける環境は、間違いなく大切です。

ただ私の感覚では、質問は最終手段くらいに思っておいた方がいいと感じています。

現場では、「これどうすればいいですか？」と聞いたらちょっとこの人不安だなって思われちゃうんじゃないかなと思います（もちろん、仕様の確認や前提のすり合わせは別です）。

問題なのは、考えた形跡がないまま答えを求めてしまうことです。

だからスクールでも、一度はコード汚くてもミスってもいいから1回自分で書く。正解じゃなくていいから仮説を出す。

この姿勢がないと、せっかくのレビュー環境を活かしきれません。
レビュー受けてもそもそも自分で書いてなければ何言われてるかわからないですよね。

最初は3日くらい(合計12時間くらい)は一つのことを解決できないで頭を抱えるみたいなことは普通にありました。
でも結局なんとかなることが多かった気がします。(記憶を美化してる説あり)
なんでダメだったのか忘れない経験になるのでハマるのもいい経験だと思います。

なぜ私は、ほぼ未経験からフリーランスでも通用したのか

今振り返ってうまくいった理由を考えると、やはり自走する前提で学習していたことかなと思います。

TA制度もまだなく、わからなければDMでぶべさんに聞くことはできましたがDMで聞くのちょっとハードル高いと感じていたような気がします。
正確な答えを得るために必要な前提条件を並べるのが結構大変なのでハードル高く、基本面談でのみ解決していましたが、面談は半分以上残して完走しました。

つまり全て自分でやる前提でかつ、生成AIもまだなかった(多分)ので、自分でどうにかするしかない時間が長かったと思います。

でも今思うと、それが自走力を育てるにはかなり良かったと思います。

また、最近CTOに言われて知ったのですが、私が前職で3年くらいしていた業務内容がSIer（いわゆる受託開発系の現場）のエンジニアがやってるようなことみたいで、DB設計周りは特に地雷を踏み歩いてきました。
こうするとどう詰みそうかといった臭いを嗅ぎ分けるようなことも自然とできるようになっていたようで、今仕事に完全に活きているなって思います。

コードレビューについて

正解を教えてもらうものでも、ダメ出しされるものでもありません。
自分の考えを整えてもらうための材料だと思っていました。

だから、指摘されたコードをそのままコピペで直すとか、表面的に通すということは、しないようにしていました。

時間はかかっても、なぜそう言われたのかを自分の頭で一度噛み砕くと言った、この姿勢は、現場でそのまま役に立っています。

かなり踏み込んだレビューをしてもらわないと、なかなか成長しません。それは独学ではまず無理です。
また、運よく現場に入れてもレビューは人格否定ではないとわかっていても、あんまり指摘されることが多いと心病む人もいるみたいなので学習段階で慣れておくと良いと思います。

フルリモートでも、関係性は自分で作る

基本はフルリモートですが、可能なら一度はオフラインで会うようにしていました。
これは営業や媚びではなく、あとで困らないための前払いのような感覚です。

一度顔を合わせて話すだけで、テキストの温度感が伝わりやすくなり、レビューの意図も汲み取りやすくなります。

フルリモートは人と関わらなくていい働き方ではありません。
関わり方を自分で設計する働き方だと思っています。やりようによっては楽にもなるし苦痛にもなりえます。

個々の性格や特性、環境も当然あると思います

ソフトスキルも重要

正直に言うと、私が順調なのはCTOに信頼してもらえているのも大きいです。
これは運の要素もあります。

ただ、フルリモートだからこそ信頼してもらうために意識している振る舞いがあります。

進捗を先回りして共有
判断を丸投げしない
自分案と相談をセットで出す
レビューでは、相手が次に動ける書き方と柔らかく伝わるように意識する
離席(外出)時には一言言う
期待値を上げすぎず、期待以上の成果を出す（上手くいけばこれ最強ですw）

これらはすべて行動の積み重ねです。

自走力を育てるために

スクールの意味を履き違えると育たないと思います。
正解をもらう場所ではなく、自分の不完全な答えを正しい方向へ導いてくれる場所です。

ここで自走力を壊さずに育った人は、正社員を経なくても、フリーランスでも、現場でちゃんと通用すると思います。今まで通りにやるだけって感覚になると思います。

まとめ

フルリモートで、正社員を経ずにフリーランスエンジニアとして働くこと自体が、特別に難しいわけではないと感じています。
ただし、誰も正解を用意してくれない環境になるため、自走力がないと厳しいのも事実です。

ShiftBは、教えてもらうための場所というより、自分のアウトプットにレビューをもらい、考え方を修正していくための場所だと思っています。
この使い方ができていれば、フリーランスでも、フルリモートでも現場で求められることは大きく変わりません。

ShiftBにいる今の時間を自走力を育てる期間として使ってもらえたら嬉しいです。