基礎知識

未経験エンジニアがぶつかる壁。学習中と就業後で、つまずく場所は変わる

未経験からエンジニアを目指すとき、つまずく場所はある程度決まっています。そして学習中の壁と、仕事を始めてからの壁はまったく別物です。この記事では、段階ごとに何が起きるのかを整理します。乗り越え方も併せて書きますが、「気合いで頑張る」以外の具体策に絞ります。

壁は3段階でやってくる

未経験から入る道のりは、大きく3つの段階に分かれます。それぞれで、つまずく理由が違います。

← 横にスクロールしてご覧いただけます →

重要なのは、これらが順番にやってくるという点です。 学習中の壁を越えても、次の壁がある。それを知っておくだけで、心構えが変わります。

学習中の壁

環境構築で止まる。 プログラムを書く前の段階で挫折する人は少なくありません。手順どおりにやってもエラーが出る、自分の環境だけ違う、原因が分からない。

対処としては、最初はブラウザ上で動く環境を使うという手があります。環境構築は後回しにして、まず書くことに集中する。順序を入れ替えるだけで、越えられることがあります。

エラーが読めない。 英語のエラーメッセージに拒否反応が出る段階です。

これは慣れの問題ですが、コツもあります。エラー文の最後の行から読むこと。多くの場合、原因はそこに書かれています。長い出力の全部を理解する必要はありません。

何が分からないか分からない。 最も苦しい状態です。質問すらできません。

この状態から抜けるには、「何をしようとして、何が起きたか」を文章にすることです。書いているうちに、分からない部分が特定されます。そこまで整理できれば、調べることも質問することもできます。

作りたいものがない。 教材をなぞるだけでは身につかず、かといって作りたいものも浮かばない。

この場合、自分の面倒を減らすものを作るのが実務的です。日々の作業を自動化する小さな道具。誰かに見せるものである必要はありません。

就業直後の壁

学習と実務の間には、大きな断絶があります。

既存のコードが読めない。 学習では、自分で最初から書きました。実務では、数万行のコードに機能を追加します。「書く力」と「読む力」は別の技能です。

対処としては、全体を理解しようとしないことです。まず自分が触る範囲だけを追う。データがどこから来て、どこへ行くのか。その道筋だけを辿ります。

質問のしかたが分からない。 聞くと迷惑ではないか、こんなことも分からないのかと思われないか。この遠慮が、時間を浪費させます。

実務的な形があります。「何をしようとして、どこまで調べて、何が分からないか」を添えて聞くことです。調べた形跡があれば、答える側も答えやすくなります。「15分調べて分からなければ聞く」といった目安を自分で決めておくのも有効です。

用語が通じない。 会議で交わされる言葉が分からない。業務用語、社内用語、略語。技術以外の部分でつまずきます。

これはメモして後で調べるしかありません。 ただし、3か月もすれば大半は解消します。永続する問題ではないと知っておくことが助けになります。

自分の遅さに落ち込む。 周囲が数時間で終わることに、数日かかる。この差は事実であり、慰めても消えません。

ただし、比べる相手を間違えている可能性はあります。5年やっている人と半年の人が同じ速さで動けるわけがありません。比べるなら、3か月前の自分です。

1〜3年目の壁

手は動くようになった。しかし別の悩みが出ます。

成長している実感がない。 同じような作業の繰り返しに見える。この時期に伸びているのは、目に見えにくい部分です。エラーへの対処、既存コードの理解、他の人との連携。数値化しにくいため、実感が伴いません。

対処としては、半年前に自分が書いたコードを読み返すこと。違いが見えれば、伸びている証拠です。

設計が分からない。 言われたとおりに作れるが、どう作るべきかを決められない。

ここを越えるには、他の人の判断の理由を聞くことが最短です。レビューで指摘されたとき、直すだけでなく「なぜそうすべきか」を聞く。この蓄積が設計力になります。

次に何をすればいいか分からない。 目の前の仕事はこなせるが、この先が見えない。

この段階では、担当する工程を上げることを意識するのが有効です。実装だけを続けても、経験年数に見合った評価は得られません。設計や要件の議論に加わる機会を、自分から取りにいく必要があります。

AIがある時代の学び方

生成AIの登場で、学習の環境は大きく変わりました。

良い面。 エラーの原因を聞ける、コードの意味を説明してもらえる、書き方の例をすぐ得られる。「何が分からないか分からない」状態から抜けやすくなりました。

危うい面。 動くコードが手に入るため、理解しないまま進めてしまいます。実務では、動くコードを書くことより、なぜそう書くのかを説明できることが問われます。 ここを飛ばすと、後で行き詰まります。

使い方としては、答えをもらうのではなく、理由を聞くのが有効です。「このコードを書いて」ではなく「このコードはなぜこうなっているのか」「他の書き方との違いは何か」。この使い方なら、学習の速度を上げつつ理解も伴います。

実際、案件の募集要件にコーディングエージェントの活用経験が挙げられる例も出てきました。使えること自体が評価対象になりつつあります。

乗り越えた先にあるもの

3年ほど続けると、状況が変わります。

「何ができますか」に具体的に答えられるようになり、選べる案件が増えます。この時点で、専門を深めるか、領域を広げるかという次の選択が来ます。

ここまで来れば、市場は「未経験」ではなく「経験者」として扱います。 最初の3年は、その資格を得るための期間だと考えると、目の前の壁の意味も変わってきます。

なお、すべての壁を一人で越える必要はありません。詰まったときに聞ける相手がいるかどうかが、進む速さを大きく左右します。 環境を選ぶことも、実力のうちです。