【リアル】エンジニア転職後に実際やっている仕事／入社前のイメージとのギャップを先に知っておく

エンジニアに転職した人が最初につまずくのは、技術力ではありません。入社前に描いていた仕事のイメージと、実際に任される仕事が違いすぎることです。1日中コードを書いていると思っていたのに、実際に手を動かしている時間は想像よりずっと短い。この落差に驚いて、数ヶ月で「向いていないのかもしれない」と口にする方を何人も見てきました。

この記事では、キャリアアドバイザーとして未経験からエンジニアに転職した方の入社後を追いかける中で聞いてきた「実際の仕事」を、時間の使い方・1年目に任される内容・スクールで学んだことの通用範囲という順番でお話しします。夢を壊すための記事ではありません。先に知っておけば、ギャップは驚きではなく想定内に変わります。そのための記事です。

未経験からエンジニアになった人が、入社後に一番驚くこと

面談で「入社して一番想像と違ったことは何ですか」と聞くと、返ってくる答えはほぼ共通しています。技術が難しかった、ではありません。コードを書く以外の仕事がこんなに多いとは思わなかったです。

勉強中は、教材を開いて手を動かす時間が学習のすべてです。だから「エンジニアの仕事＝コードを書くこと」というイメージが自然にできあがります。ところが現場に入ると、コードを書き始める前の工程が驚くほど長い。何を作るのかを確認し、既存の仕組みを読み、影響範囲を調べ、書いたあとにレビューを受ける。この流れ全体が仕事なんです。

③はとくに戸惑うポイントです。学習中は、エラーが消えれば正解でした。現場では、動くコードが何通りもあるうえに、半年後に他の人が読んで理解できるかまで含めて評価されます。動いたから終わり、にはならないんです。

ただ、これは悪い話ではありません。裏を返せば、技術力だけで評価が決まる世界ではないということです。学習期間が短くても、確認を丁寧にできる人・状況をきちんと説明できる人は、現場に入ってから伸びていきます。

エンジニアの1日はこう進む｜時間の内訳を正直に出す

具体的な話をします。転職して1年目のエンジニアの方に、1日の使い方を聞いて整理したものです。会社や職種によって差はありますが、傾向は驚くほど似ています。

8時間のうち、純粋にコードを書いている時間は多くて3時間程度です。少ないと感じるかもしれませんが、これは経験を積んでも大きくは変わりません。むしろベテランほど、書く前に考える時間と、書いたあとに確認する時間が増えていきます。

朝は前日の続きの確認から始まり、短い進捗共有をして作業に入る。午後にレビュー依頼や質問への返答が挟まり、夕方にまた確認、という流れが一般的です。まとまった集中時間が取れるのは、1日のうち午前中の数時間だけ、という職場も珍しくありません。

この内訳を先に知っておくと、入社直後に「自分は作業が遅いのでは」と焦らずに済みます。書いている時間が短いのは能力の問題ではなく、そもそも仕事の構造がそうなっているだけなんです。

「読む・調べる・確認する」時間に、実際は何をしているのか

では、コードを書いていない時間に何をしているのか。ここが一番イメージしづらい部分だと思うので、分解して説明します。

未経験の方がもっとも驚くのが1つ目です。学習中に読むコードは、せいぜい教材の数百行。現場のコードは数万行あり、しかも自分が書いたものではありません。最初の数ヶ月は、全体像がまったくつかめない状態で作業することになります。

これは能力不足ではなく、全員が通る道です。むしろ入社3ヶ月で全体を理解できている人のほうが稀で、半年から1年かけて少しずつ地図ができていく感覚に近いです。

指摘をもらうことを「怒られている」と受け取ってしまうと、この時間がつらくなります。逆に指摘は無料で受けられる添削だと捉えられる人は、半年で見違えるほど伸びます。ここは技術より、受け取り方の話です。

入社1年目に任される仕事のリアル

「未経験で入って、いきなり新しいサービスを作るんですか」と聞かれることがありますが、そうはなりません。1年目の仕事には、はっきりした順番があります。

01から始まるのには理由があります。バグ修正は、既存のコードを読まないと絶対に直せません。つまり、成果を出しながらコードを読む練習ができる、一石二鳥の仕事なんです。地味に見えますが、ここを丁寧にやった人ほど、02以降の立ち上がりが速くなります。

このズレはよく起きます。本人は「まだ大きな機能を任されていない」と焦り、現場は「確認と報告がきちんとできている」と評価している。任される仕事の大きさで自分を測ると、必要以上に落ち込むことになります。

スクールや独学で学んだことは、現場でどこまで通用するか

もっとも気になる部分だと思います。結論から言えば、学んだ知識そのものが直接使える場面は、想像より少ないです。ただし、学習が無駄だったという意味ではまったくありません。

現場には、その会社で積み上げてきた書き方の作法があります。同じ言語でも、ファイルの分け方も命名も違う。だから最初は「知っているはずなのに書けない」状態になります。ここで自信をなくす方が多いのですが、これは全員が通ります。

では何が通用するのか。エラーメッセージを読んで原因を切り分ける力、公式ドキュメントを調べる習慣、わからないことを言葉にして質問する力。この3つは、学習中に身につけていれば入社初日からそのまま通用します。逆に、答えを写して動かしてきただけの人は、ここで苦労します。

つまり学習期間にやるべきは、教材を何周もして暗記することではなく、詰まったときに自力で調べて抜け出す経験を積むことなんです。この観点で学習環境を選ぶと、入社後の伸び方がまったく変わります。

ギャップに潰れる人と、乗り越える人の差

同じギャップに直面しても、3ヶ月で立ち直る人と、辞めることを考え始める人に分かれます。追いかけていて見えてきた差は、技術力ではありませんでした。

①は本当によく起きます。現場のルールとして「15分調べてわからなければ聞く」と決めている会社もあるほどで、聞かないことのほうがコストになります。それでも新人ほど、聞くことを申し訳なく感じてしまうんです。

乗り越えた人がやっていたことは、驚くほど地味でした。

②が効きます。エンジニアの成長は目に見えにくく、比較対象を他人から過去の自分に変えるだけで、続けられる期間が伸びます。実際、1年後に活躍している方の多くが、最初の3ヶ月を「何もできなかった時期」と振り返っています。誰もが通る谷なんです。

入社前にやっておくと、入社後に差がつく準備

最後に、転職活動中の段階でできる準備をお伝えします。技術の勉強以外の部分です。

まず求人票では、開発体制・使用技術・チームの人数を見てください。ここが具体的に書かれている会社ほど、入社後の仕事も想像しやすくなります。そして、とくに逆質問は効果的です。「入社直後はどんな仕事から任せますか」「コードレビューは誰がどのくらいの頻度でしますか」。この2つを聞くだけで、教育体制があるかどうかがかなり見えます。答えが曖昧な会社は、実際に体制が整っていないことが多いです。

もうひとつ、面接で伝えるべきことがあります。学習期間に何を作ったかより、詰まったときにどう解決したかを話すほうが、採用側には響きます。現場で必要になるのはまさにその力だからです。教材通りに作った成果物より、エラーで3日悩んで解決した話のほうが評価される、というのは実際によくあります。

準備を整えて臨めば、入社後のギャップは「聞いていた通り」に変わります。ここまでの内容を、確認リストとしてまとめておきます。

まとめ：ギャップは、先に知っていれば想定内に変わる

エンジニアの仕事は、コードを書く時間より読む・調べる・確認する時間のほうが長いのが実態です。1年目はバグ修正から始まり、まとまった機能を任されるまで半年から1年かかります。学んだ知識がそのまま使える場面は少なく、通用するのは調べる力と質問する力のほうでした。それでも潰れずに続けた人は、他人ではなく過去の自分と比べていた人たちです。ギャップは先に知っておくだけで、驚きから想定内に変わります。まずは逆質問を2つ用意することから始めてみてください。

関連記事

【真実】未経験エンジニア転職後の年収は本当に上がるか／求人票と入社後の実態を正直に話す