はじめに
こんにちは。エンジニアのNittaです。
私は、2025年4月に新卒として入社しました。
入社後はまずビジネス研修やマナー研修を受け、その後にフロントエンドのコーディング試験に臨みました。
入社前はWebの基礎を中心に学んでおり、簡単な画面を作ったりデザインを整えたりすることはできましたが、実務で求められる設計やチーム開発の経験はなく、あくまで学習レベルにとどまっていました。
研修ではReactやTypeScriptなど初めて扱う技術が多く、慣れない内容ばかりで「自分に本当にできるのだろうか」と不安でいっぱいだったのを覚えています。
そんな日々を過ごした後、ついに迎えたのが初めてのプロジェクトです。
この記事では、研修を終えたばかりの自分がどんな気持ちでプロジェクトに飛び込んだのか、そこで直面した壁や苦戦したこと、そしてそこから得られた学びについて振り返ってみたいと思います。
リリース間近の案件にアサインされてから
1ヶ月の研修を終えて、5月上旬ごろからプロジェクトにアサインされました。
ちょうどリリース直前というタイミングで、初回リリース分の実装はほとんど完了している状況でした。
最初は「どんなプロジェクトなんだろう？」と期待でワクワクしていましたが、いざコードを開いてみると本当に理解できないことだらけで、正直かなり焦りました。
特に、自分より先に案件に参加していた同期のKくんが次々とタスクをこなしていたり、Sくんが目に見えて成長している姿を横で見ると、「自分も同じくらいできなきゃヤバいんじゃないか…」というプレッシャーを感じ、不安がどんどん大きくなっていきました。
さらにこのプロジェクトは、フロントエンドだけでなくバックエンドやモバイルまで幅広く関わる必要があり、家に帰ってからもひたすらコードを追いかける日々。
プロジェクトのディレクトリ構成を見ても「feature」「atom」「schema」などの単語ばかりで意味が分からず、とりあえずファイルを開いては「？？？」となっていたのを今でも覚えています。
学んだこと
プロジェクトに参加してから特に大きな学びとなった3つのポイントをまとめます。それぞれ、具体的な体験と気づきを交えて振り返ってみます。
■ コードは読んで試してこそ理解が深まる
私の担当としてサポートしてくださったのは先輩のNさんでした。普通なら「簡単なタスクからやってみよう」という流れになりそうですが、Nさんはあえてそうはせず、最初の2週間をまるごと “コードを読む＆自分で手を動かして慣れる” ための時間として与えてくださいました。
当時の私は「自分だけこんなに時間をもらって大丈夫なのかな…」と不安に思っていましたが、今振り返ると、この2週間こそが大きな転機であり、エンジニアとしての成長の基盤になったと感じています。
初めて切ったブランチ名は「nitta-practice」。そこではとにかく色々なコードを読み、「真似してみよう」「まずは書いてみよう」という気持ちで自分なりに実装を試していました。当然のようにエラーを出しまくり、思ったように動かず苦戦することも多かったのですが、その過程で「このボタンを押すとこの処理が呼ばれるのか」「このファイルとこのファイルはこういう関係性でつながっているのか」という小さな発見が積み重なり、少しずつコード全体の流れが頭の中でつながるようになりました。
もしこの「nitta-practice」での試行錯誤がなかったら、きっと今ごろ「AIが提案してくれたコードをコピペして、動いたらOK」という浅い理解に留まっていたと思います。自分のペースでじっくり悩み、手を動かす時間をあえて確保してくれたNさんには、本当に感謝の気持ちでいっぱいです。
■ オープンな場での質問がチームとしての成長にもつながる
もうひとつ大きな学びは、「質問は個別ではなくプロジェクトのチャンネルで行う」ということです。最初は恥ずかしさもあって、つい直接聞いてしまいたくなるのですが、オープンな場で質問をすることでメリットが多いと気づきました。
例えば、質問を見た他のメンバーが回答してくれることもありますし、チャンネルを見ている人たちに自分の進捗やつまずきが自然と共有されます。結果としてチーム全体の情報の透明性が高まり、「誰がどこで困っているのか」が見えやすくなるのです。これは自分のためだけでなく、チームにとっても良いことだと強く感じました。
■ 質問の質を高めるための工夫
さらに学んだのは、質問の仕方そのものにも工夫が必要だということです。特にテキストでやり取りをするときは、どうしても説明が長くなりがちで、内容が複雑だと相手に伝わりにくくなってしまいます。
そこで意識しているのが「相手の時間を奪わない」書き方です。具体的には、質問はできるだけ簡潔にまとめ、複数の要件がある場合は番号付きリストで分けて書くようにしています。こうすることで読みやすくなり、回答する側も短時間で的確に答えやすくなります。
結果的に、自分自身も「質問を整理して文章化する」過程で頭が整理されるため、実はその時点で自己解決できてしまうこともあります。質問をする前に一度立ち止まり、相手が理解しやすい形に整えることは、自分の成長にもつながる大事な習慣だと学びました。
課題
学んだこともありましたが、同時に課題に感じた部分も多くありました。プロジェクトを進める中で浮き彫りになった課題と、それに対して取り組んだ改善策をまとめていきます。
■ AIツールとの付き合い方
入社してからAIツールを使い始め、その便利さに驚く毎日でした。わからないことを聞けばすぐに答えを返してくれるし、自分一人で悩む時間を大幅に減らしてくれる点は確かに助かりました。
しかし、気付けば自分で考える前にAIに頼ることが増えてしまい、後から「なぜこうしたのか？」と説明しようとすると、うまく言葉にできず「結局、自分の中に残っていないんだな」と痛感しました。
これでは本質的な学びにはならないと気付いてからは、必ず最初に自分の頭で考えてみることを意識するようになりました。どうしても時間がかかりそうなときは、AIにすぐ答えを求めるのではなく、自分の考えや仮説を文章にしてAIに共有し、確認するようにしています。そのプロセスを経ることで、自分なりの理解が深まり、「AIに依存する」のではなく「AIを活用する」というスタンスに少しずつ変わってきたと思います。
■ 議事録作成と確認の徹底
顧客との定例会で議事録を担当していますが、会議中に内容を十分理解できず、録画を見返してまとめ直すことが続きました。会議中に理解が追いつかないため、二度手間になってしまうのが大きな課題です。
原因は技術や業務知識の不足にあると感じており、今後は事前準備を徹底することが必要だと思いました。アジェンダを読み込み、BacklogやTeamsで関連するタスクや資料を確認してから参加することで、その場で理解できる内容を増やし、録画への依存を減らしていきたいです。
さらに、理解不足からくる思い込みにも注意しなければならないと感じています。
議事録に「今週中」と発言があったとき、自分の判断で「日曜日まで」と解釈して書いてしまったことがありました。レビューで「金曜か日曜か確認した？」と指摘され、自分が勝手に思い込んでいたことに初めて気付きました。
納期のような重要な点を曖昧にしたまま記録するのは危険であり、責任を持てない立場であるならなおさら確認が必須だと学びました。今後は少しでも不明瞭な点があれば必ず確認し、正確さを最優先にしていこうと思います。
■ 文章力の課題
これは特に議事録を作成しているときに痛感します。書いた内容が幼稚に見えたり、回りくどくなってしまい、読み手に伝わりにくいことが多くあります。
先輩Nさんにレビューをお願いすると、内容そのものよりも日本語の表記ゆれや誤字、敬語の使い方などの修正が非常に多く、自分の見直し不足を反省しました。特にテストケースでは100箇所以上修正が必要になるほどで、大きな迷惑をかけてしまいました。
それ以来、内容の修正よりもまず日本語のミスを減らすことが大事だと思い、言い回しに迷ったときはAIに相談するようにしています。その結果、少しずつ修正点も減ってきており、改善が実感できています。
■ マージリクエストと品質管理
マージリクエストを出すときに、変更によって他にどんな影響が出るかをしっかり動作確認せずに提出してしまうことがありました。その結果、レビューで不具合や影響範囲を指摘されることが多く、反省する場面が多々ありました。
またスタイル修正の際は、Figmaとの突き合わせが不十分で、自分では気付かなかった細かなデザインのズレをレビューで指摘されることが頻繁にありました。自分の中で「小さな修正だから大丈夫」と思い込んでいたことが原因です。
今後は動作確認を徹底するだけでなく、デザインの細部までFigmaでしっかり確認し、細かい部分にこだわって品質を高めていきたいと考えています。
まとめ
振り返ってみると、この3ヶ月で特に浮き彫りになったのは、自分の技術力の不足以上に、日本語の使い方や敬語、確認不足といった「社会人としての基本的な部分」でした。
技術的な課題は数えきれないほどありますが、それ以前に、言葉遣いや丁寧な見直し、確認を怠らない姿勢といった当たり前のことを意識して行動する大切さを強く感じました。これまで何となく流していた部分にきちんと向き合うことが、結果的に信頼にもつながるのだと思います。
今後は、自分の成長に素直に向き合いながら、技術力の向上はもちろん、社会人としてのマナーや基本動作も含めて、一つずつレベルアップしていけるよう努力していきたいと思います。
