Webエンジニアが土日に一切勉強せず、爆速で成長する方法

2025年1月1日 12:41

はじめに

はじめまして、さいと申します。

私は社会人歴が約8年で、現在フリーランスのWebエンジニアとして働いています。

今までバリバリコードを書いてきたわけではなく、過去には

・SIerでの総合職(コードを一行も書かない)

・製薬会社の情報システム部門

・テクニカルサポート

などの非Webエンジニア職も経験してきました。

その結果、Webエンジニアとしての正味の実務経験が約2年しかなく、勤続1年未満の転職回数も3回というポンコツすぎる経歴が爆誕しました。

それでも2024年1月には月単価70万円から単価100万円(税込)の案件を獲得し、クビになることもなく1年以上働いています。

X界隈を観察している限り、月単価100万円というのは結構珍しい部類に入ると思うので、今回は私の勉強方法と成長のコツを書いていきたいと思います。

ちなみに、私は以下のようにすごく怠惰で、外部アウトプットも全くやってこなかった人間です。

・技術記事の投稿数ゼロ

・GitHubの公開リポジトリ数ゼロ

・プライベートでの年間コミット数ゼロ

・技術本の完走数ゼロ

・・・

文字に起こすと本当に何もしてなくてヤバいのですが、

「エンジニアは土日も勉強しろ！！」

と口うるさく言われると、どうも勉強する気が起きないのが人間というもの。。。

これからエンジニアになろうとしている方や若手エンジニアの方に、これからご紹介する「土日に一切勉強せず、爆速で成長する方法」がお役に立てばと思います。

結論

業務時間内での仕事そのものを、最大限の学びの場として活用していきます。

言い換えれば、日々のタスクをただこなすのではなく、「成長につながる挑戦の場に変える」というアプローチです。

そのためには、以下の5つのルールを数年単位で徹底的に守ることが重要です。

・バックエンド +α インフラを主戦場とし、フロントを専門にしない

・技術力が高い現場に、その現場の下位10%くらいの実力で飛び込む

・現場に入ったら、まずはその現場のコードを完璧にコピーできるようにする

・現場で慣れてきたら、難易度の高い作業・チケットを中心に取りまくる

・その現場で上位10%くらいの実力を付けたら、1~2年で次の現場に移る

バックエンド +α インフラを主戦場とし、フロントを専門にしない

【解説】
これはバックエンドの設計思想や技術が、時間や環境の変化に耐える汎用性があるからです。

以下のような概念やノウハウは、学べば学ぶほど次の現場でも武器になりますし、10年以上前から本質的には変わっていないものばかりです。

アーキテクチャ: クリーンアーキテクチャやドメイン駆動設計(DDD)といった設計思想は、すでに常識となった普遍的な考え方で、まずどの現場でも通用します。
高負荷・大量アクセスの処理: プログラミング言語が変わっても、負荷分散や効率的な処理のノウハウは変わらず、現場を移ってもそのまま活用できます。
データ整合性や一貫性(ACID): トランザクション管理の基本原則はどのようなシステムでも常に重要です。
テーブル設計やインデックスの最適化: 綺麗なデータ構造の設計スキルやデータベースのパフォーマンスチューニングは、ビジネスの内容にかかわらず重宝されます。

こうした技術は一度習得すれば、次の現場や新しい言語・環境でもそのまま再利用できることが多く、学び直しに多くのコストをかける必要がありません。

一方でフロントエンドは、技術の移り替わりが激しく、ReactやNext.jsの新機能、流行りのフォーム・バリデーションライブラリもキャッチアップする必要があるため、学習コストが高くなりがちです。

技術力が高い現場に、その現場の下位10%くらいの実力で飛び込む

【解説】
これは、短期間で成長できなければ現場をクビになるほどの強いプレッシャーを強制的に与え、その緊張感の中で現場のコードを叩き込むためです。

また、プログラミングで何かを高いレベルで習得したいとき、そもそも一定以上の複雑性を持ったコードの中に身を置かないと、ほとんど意味がないと思っています。

具体例を出しましょう。

「あなたがクリーンアーキテクチャについて理解し始めたのは、本やUdemyで勉強したときですか？それともクリーンアーキテクチャで書かれた現場のコードを読んで、そのコードをベースに仕事をしたときですか？」

おそらくほとんどの人が後者だと言うはずです。

プログラミング学習は、一度ルールや思想を学べば勝手にアウトプットに反映されるものではありません。

個別具体の例を何個もパターンとして経験し、その中で例外や共通点があることを学んで初めて、自分の中に普遍的な知識として落とし込まれるはずです。

学びたい対象を切り出した本やUdemyなどの教材だけで勉強することは難しく、複雑なコードベースの中で実際にどうすればいいかを学習するケースが圧倒的に足りないのです。

だからこそ、膨大な量のコードが書かれた現場の環境をそのまま利用し、加えて十分な理解がないにもかかわらず、いきなりお金をもらう仕事をスタートさせてしまうのです。

このようにハイプレッシャーな環境で2、3か月生存することができれば、他のエンジニアと遜色ないレベルで理解が進むと思います。

できなければ現場を退場させられるため、やるしかない。

現場に入ったら、まずはその現場のコードを完璧にコピーできるようにする

【解説】
この戦略では、そもそも実力より格上の現場に入ることになるため、まず既存のコードを完璧にコピーすることが無難でありながら、最高の勉強法になります。

フリーランスとして他の業務委託のエンジニアを見ていて思うのは、そもそも現場のコードをよく理解できておらず、自分の色を出したPRを作る人が意外と多いということです。

PRのレビューで

「ここは～の書き方にならってこうしてください。」

「ここは新しく関数を作るのではなく、既存のコードを流用してください。」

新しく現場に入った人が、こうした指摘を受けることは結構ありますよね？

どの現場でもコードには暗黙のルールや作法が存在しており、それを最初に理解しなければチームの一員として受け入れられません。

現場に入ったら、まずはその現場の既存コードの書き方を完璧にコピーすることに集中してください。

PRのレビューをする人が、

「これ、うちのエンジニアが普通に書いたやつと同じクオリティだな」

と思えば、信頼を得ることができます。

この信頼があることで、次に難易度の高いタスクを任せてもらえる可能性がぐっと広がるんです！！

また、コードをトレースする過程で、その現場で使われているアーキテクチャや設計思想が自然と頭に入ります。

なので、まずは素直に正確に現場のコードをコピーしてPRに乗せるようにしてください。

あなたの個性をコードに出すのは、もっと後でいいですし、そもそも格上の現場に入った場合、そんな余裕もないでしょう。

これを怠ると、「あいつはこの現場の基準値に満たない」、「実力がない」と見なされるリスクがあり、結果として速攻でクビになります。

現場で慣れてきたら、難易度の高い作業・チケットを中心に取りまくる

【解説】
土日は勉強しないのですから、業務時間だけは他の人よりも難しいことに取り組まなければなりません。

現場で仕事をしていると、簡単なチケットばかり処理して「目の前の仕事をこなしている感」に浸りがちですが、すぐに全く成長しなくなります。

難易度の高いチケットは、手を出すのに躊躇することも多いですが、達成できればそれだけ多くの学びを得られますし、死ぬ気で取り組んでみると意外とできることもあると思います。

また、わからなければちゃんと質問をしてください。

私が尊敬するエンジニアの方も、

「若い頃はあえて馬鹿になって質問しまくっていた」

と仰っていました。

成長する上で、堂々と馬鹿になって質問するのはスキルです。

逆にあなたの疑問が正しい可能性だって全然ありますので、気にしないでください！

難易度の高いチケットの具体例ですが、以下のような作業に関連したチケットがあれば、早いもの勝ちの精神で積極的にチャレンジしましょう。

・GraphQLやgRPCを使ったマイクロサービスの新規作成、コード修正

・超重く時間がかかるバッチ処理・APIのレスポンス速度改善のための並列処理導入や、コンテナのCPUやメモリ、並列起動数のチューニング

・新たなキャッシュやDBなど珍しいインフラ絡みの導入作業

重要なことは、難しいタスクをこなせれば、そこで学んだ知識やスキルは今後の案件でも通用する汎用的な武器になるということです。

難しい問題を乗り越えるたび、自己肯定感が上がり、「自分はできる」という感覚が得られるのです。

これは、つよつよエンジニアと落ち着いて話したり、面談で自分の経験を自信をもって説明する際、非常に重要なメンタルブーストになってくれます。

その現場で上位10%くらいの実力を付けたら、1~2年で次の現場に移る

【解説】
これは、ある分野のマスターに必要な経験値を10としたときに、経験値を1から8くらいまで稼ぐ努力と、8から10にまで伸ばす努力とでは、後者の方が明らかに多くの時間を必要とするからです。

以下の図を見てください。

とはいえ、ひたすら努力すれば、それだけで報われるわけではありません。「努力の限界効用は逓減する」という残酷な法則があるからです。
最初のうちは努力の効果は大きいが、上達するにつれてその効果は減っていきます。

どれだけ努力しても「大谷翔平や藤井聡太になれない」ほぼすべての人たちへ

やっと成長してくれたあなたが同じ現場に何年もいてくれることが、会社にとっての利益になることは事実です。

ですが、年収upや単価upのために、今は誰に何と言われようと達成したい目標がある人もいることでしょう。

ある程度いい待遇を獲得できたら、1つの企業や現場に最低でも2年はいた方がいいですが、一時的に成長を優先するのであれば、さらなる成長を求めて現場を移りましょう。

そもそも、ここまでのやり方を実践しても、ちゃんと成果を出していればCTOやリーダーがあなたがなぜ辞めてしまうのか、ちゃんと話を聞いてくれるはずです。

別れ際に「〇〇さんなら、どこの現場へ行っても大丈夫ですね！」とか「〇〇さんがいてくれたので、すごい助かりました！」などの言葉をもらえれば、きちんと価値提供できていたことの証明になりますので、そこまで気にすることはないと思います。

個人的には、別れるときに

①飲み会に誘われる

②飲み会の終わりで相手から握手を求められる

あたりが自分がちゃんとその現場で成果を出していたかのチェックポイントになると感じています。

【要注意】健康リスクと職務経歴がチグハグになる件

これまでに紹介したやり方は、メリットばかりではありません。

十分な実力がない状態で格上の現場に挑戦し続ける人生になるため、失敗すれば自信をなくして再起不能になってしまったり、Webエンジニアという職業そのものを辞めてしまうリスクもあります。

土日はしっかりと休みつつも、人より早い成長を狙うのですから、その歪みはかならずどこかに現れます。

また、1~2年で現場を転々とするため、繰り返すほど面談での印象は悪くなっていきます。

転職などの面談では、そうしたネガティブな印象を吹き飛ばせるだけの実績と技術への理解を見せつける必要があるのでご注意ください。

短期間での成長と引き換えに色々とリスクも大きいので、精神的に疲れたと思ったら、ジョギングやサウナなどで肉体に高負荷をかけて、心配を抱える暇もなく眠れるようにしましょう。

まとめ

土日に勉強しなくても自然と爆速で成長できるルートは
「環境選び」で全て決まります。

今の自分の実力よりちょっとハード or ベリーハードな環境を選択し続けてください。

その代わり、土日はゆっくり休みましょう。

自分を追い込むのは平日だけで十分です。

そこでの仕事が簡単に思えたら、また次のさらに「ハードで緊張感がある現場」に移りましょう。

自分も月単価100万の現場に入って最初の数か月はストレスとプレッシャーで毎朝下痢でしたが、それでもいつか慣れるもんです。

そして、その現場でのスタンダードを吸収しつつ、常に自分の限界を超え続ける。

それを何年も続けることが、Webエンジニアとしての最速の成長に直結します。

みなさんにとって、少しでもこの文章が参考になれば幸いです。