「プログラミングを始めたけれど、周りと比べて焦ってしまう」「今のやり方で本当にエンジニアとして成長できているのかな」と不安になることありませんか？実務3年目の僕が、失敗だらけだった1年目を振り返り、未経験からプロへと脱皮するための行動を僕の主観でお伝えします。
「完璧主義」という名の迷路に迷い込んでいた3年前
エンジニアになって最初の頃、僕は自分に自信がありませんでした。
「完璧なコードを書かなければいけない」「わからないことを聞くのは恥ずかしい」
そんな思い込みから、たった一行の修正に何時間も悩み、結局何も進まずに一日が終わる……なんてことがよくありました。
今振り返れば、それが一番の遠回りだったと分かります。
現場で揉まれて気づいたのは、プロの仕事は自分一人で100点を目指すことではなく 最速でフィードバックをもらいながらチームの成果を最大化すること でした。
1. 走り出しのラフ案を見せる。手戻りを防ぐタイミング
実務1年目の僕が一番やらかした大きな失敗。それは、 「完璧に完成させてから見せよう」 と意気込んで、3日間かけて一人で作り込んだ機能が、先輩の一言で「あ、方向性が全然違うね」と全ボツになったことです。
あの時の絶望感と言ったらありません。エディタの文字がかすんで見えました。
結論：本格的な実装に入る前、「設計の骨組み」が見えた瞬間にすり合わせる
効率的に動けるエンジニアは、例外なく「確認のタイミング」が絶妙です。
具体的には、コードをガリガリ書き始める前の「あらすじ」や「ロジックの構成案」ができた、いわば 方向性が完全に見えていない超・初期段階 で、一度先輩に「これで進めていいですか？」と声をかけに行きます。そこで設計の骨組みや方向性をすり合わせます。
理由：手戻りこそが、開発現場における「最大の時間泥棒」だから
100%作り込んでから「根本的に設計が違う」と指摘されると、修正にはまた100%の時間がかかります。最悪の場合、納期に間に合わなくなるリスクさえあります。でも、この「走り出しのラフ」の段階で方向性を確認しておけば、もしズレていても修正コストはほぼゼロになります。
新人の現場あるある
新人時代の僕：（丸一日かけて、ようやく自分なりに「完璧だ！」と思えるコードが書けた。自信満々でプルリクエストを送ったぞ……！）
30分後の先輩：「あー、ごめん。この機能、来週のアップデートで廃止される予定のライブラリを使っちゃってるね。あと、このままだと拡張性が低いから、別のパターンで書き直そうか」
僕：「（……白紙！？僕が必死に書いた1日は何だったんだ……！）」
意識したいポイント
「自分一人の判断」で孤立して進める時間を減らしましょう。この超・初期段階で相談することは、単なるミス防止ではありません。「私は独断で進めず、チームの状況を考えて論理的にリスクを管理する」という、プロとしての信頼を積み上げるポジティブな行動になります。
2. 暗闇の中で立ち止まらない。「まずは形にする」勇気が道を切り拓く
「技術力が足りないから、何をしていいか分からない」
そう言って手が止まってしまうことはありませんか？ 1年目の僕は、仕様書を読み込んでも全体像が見えず、真っ白なエディタを前にフリーズしていました。
結論：100点を目指さず、まずは「とりあえず動く土台」を作る
最初から100%の完成度を目指すのは、新人にとって非常にリスクが高いと思います。なぜなら、経験が浅い段階では「何が正解か」の判断基準自体が曖昧だからです。まずは「わかっている範囲」で構造を組み立て、早い段階で検証を繰り返す 「まず形にする思考（ラフ案作成）」 を取り入れましょう。
理由：動かすことで、初めて「不明点」が具体化する
停電した自分が知らない部屋の中で、玄関（目的地）を探している自分を想像してみてください。立ち止まってじっとしたり、明かりが灯るのを待ったりするのは得策ではありません。
まずは手探りでも数歩歩いてみる。すると「ここに壁がある」「こっちは段差だ」という具体的な課題が初めて浮き彫りになります。
課題が具体的になれば、先輩への質問も具体的になり、ゴールへの到達スピードは劇的に向上します。
ボールを離す技術
30分調べて解決しないことは、速やかに有識者へボールを渡して良いと思います。
「チーム全体の進捗」を優先する視点を持つこと。自分がボトルネックにならないよう、自分以外のリソースを戦略的に活用するバランス感覚こそが、1年目の終わりに大きな差となって現れます。
完璧主義は成長の敵
「完璧に理解してから動く」のではなく「動かしながら理解する」のが、不確実な現場で生き残るエンジニアの機動力になります。
3. 「教える」ことは「二度学ぶ」こと。
実務に入って数年が経つと、少しずつ後輩ができるようになります。その時、「自分の作業時間が減るから教育は負担だな」と思ってしまうのは、もったいなさすぎます。
結論：教育を「自分への投資」と捉える（時間のレバレッジ）
後輩に教えることは、自分の知識を体系化し、強固にするための最高のトレーニングです。
また、後輩がいない新人の方も、自分が学んだ知識をQiitaなどでその知識を知らない方に説明する文章を書いてアウトプットする、などでも十分トレーニングになります。
理由：曖昧な知識は教えられないから
「なんとなく」で済ませていた知識は、他人に説明しようとした瞬間にボロが出ます。
後輩に教える過程で、自分の知識の曖昧な点に気づき、それを調べ直す。この自分の中で情報をアップデートし続ける行動が、あなたのスキルを「なんとなく知っている知識」から「普遍的な論理」へと昇華させます。
4. 質問を「仕組み化」して、心理的安全性を守る
最後に、後輩が育つチームを作るためのコツを一つ。新人が質問できないのは、本人のやる気の問題ではなく、多くは「仕組み」の問題です。
「質問しやすい文化」を自ら体現する
指導者が「完璧な超人」を演じてしまうと、新人は「こんな初歩的なことを聞いたらバカにされる」と萎縮します。あえて、自分もわからないことを周囲に確認したり、「これってどうなってたっけ？」とオープンな場で会話する姿を見せましょう。
さいごに
1年目で「個人の効率」を高め、3年目で「チームの出力」を最大化する。この3年間のプロセスで身につく力は、たとえ10年後にプログラミング言語のトレンドが変わっても、あなたの市場価値を支え続ける汎用的な資産になると思います。一歩ずつ、プロフェッショナルな未来へ進んでいきましょう！
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト