新卒エンジニア3〜4カ月目。はじめての案件でつまずいた話と、そこから学んだこと

皆さん、こんにちは!

今回のブログを担当するのは、2025年に新卒エンジニアとして入社したS.T.です。今回は、私が入社して3〜4カ月が経った頃、はじめて本格的な案件に入り、正直かなりつまずいたときの話を紹介します。

私と同じようにエンジニアを目指している皆さんが、「最初にぶつかりやすいのはこういうところなんだ」と、入社後のイメージを少しでも具体的に持つヒントになれば幸いです。

目次
  1. 研修からテストを経て、案件へ
  2. 初めて案じた壁は、規模感と影響範囲
  3. 具体的につまずいたポイント
    1. ①「この修正、どの画面まで関係するの?」が分からない
    2. ②「修正すべき場所」が見つからず、調査が迷路になる
    3. ③要件が複雑になるほど、考えることが一気に増える
  4. 「調査のやり方」を型にして乗り越えた
  5. エンジニアの後輩に伝えたいこと
  6. まとめ:つまずきは、ちゃんと「理解の種」になる

研修からテストを経て、案件へ

まず私たちが入社した後はすぐに研修が始まり、RESERVA(レゼルバ)の基本的な構造や、開発の進め方を学びます。研修内容は段階的に難易度が上がっていくため、できることが増えているという実感を持ちやすい期間でもありました。

研修では、テスト(検証)の観点も学びました。研修の中で実際の画面を見ながら仕様を確認し、修正が入った箇所を追っていく中で、プロダクト全体のつながりが少しずつ見えてきます。

そして入社から3〜4カ月が経った頃、保守対応や小さな改修を経て、いよいよ案件へ合流します。

ただし、そのタイミングは人によって前後します。早い段階から現場で学べる環境のため成長スピードは上がりますが、その分、扱う範囲と責任のレイヤーが一気に広がり、私にとっては最初の大きな壁に直面することになりました。

初めて案じた壁は、規模感と影響範囲

案件に入ってつまずいた理由は、技術そのものよりも、その規模感と影響範囲でした。

研修では限られた画面や機能を題材にしていましたが、案件に入ると、扱う画面は10以上、ファイルも数百規模になります。どこから手をつければいいのか分からず、作業が止まることも少なくありませんでした。

さらに、小さな修正に見えても、別の画面や別の機能に影響が出る可能性があります。予約業務の根本を支えるRESERVAでは、特に影響範囲を読む力が求められるのだと、ここで強く意識するようになりました。

具体的につまずいたポイント

①「この修正、どの画面まで関係するの?」が分からない

案件で扱う機能は、ひとつの画面で完結することがほとんどありません。予約フォーム、予約完了画面、通知、管理画面の設定など、ユーザーの操作が連鎖しています。

当時は目の前の画面だけを見てしまい、その前後で何が起きているのかを捉えきれていませんでした。結果として、調査をやり直すことになり、同じところを何度も行き来する状態に陥っていました。

②「修正すべき場所」が見つからず、調査が迷路になる

研修中は、検索すればすぐに候補にたどり着ける場面が多かったのですが、案件ではそうはいきません。似た名前や似た処理が複数あり、候補が一気に増えます。

「ここかな」と当たりをつけて進めても外してしまい、また別の候補へ。調査が広がるばかりで時間だけが過ぎていく感覚は、当時の自分にはかなり堪えました。

③要件が複雑になるほど、考えることが一気に増える

機能が複雑になるにつれて、例外ケースや運用上の制約も増えていきます。特に、カード決済やスマートロックといった外部連携が絡むと、プロダクト側だけでは完結しません。

RESERVA Payment(レゼルバペイメント)のような決済領域は、正常系だけ動けば終わり、というわけにはいかず、失敗時の挙動やユーザーからどう見えているかまで含めて考える必要があり、常に頭をフル回転させていました。

「調査のやり方」を型にして乗り越えた

そういったつまづきから抜け出すきっかけになったのは、調査の進め方を自分なりに整理したことでした。具体的には、次の流れを意識しました。

  • まずは現象を再現し、「何が起きているか」を言葉にできる状態にする
  • どの画面、どの設定、どの操作から追うか、入口を1つに絞る
  • 原因の仮説は3つまでに絞る
  • 検証結果をメモに残し、違った点も含めて整理する

そして何より大きかったのは、上司や先輩社員に早めに相談することです。自分だけで抱えると、前提を間違えたまま時間が過ぎてしまいます。

相談するときは、「ここまで分かったこと」「試したこと」「次に試そうとしていること」をセットで伝えるようにしました。そのおかげで会話がスムーズに進み、理解も一段ずつ深まっていきました。

エンジニアの後輩に伝えたいこと

今振り返ると、当時つまずいた原因は能力不足ではなく、進め方を知らなかったことに尽きます。同じように悩んでいる後輩がいたら、次の3つを伝えたいです。

  • 最初に5分でいいので、画面の前後関係やユーザーの導線といった全体像を掴む
  • 調査は「入口→仮説→検証」を小さく回す
  • 外部連携は早めに仕様の前提を確認する

そしてもう1つ。入社3〜4カ月後の案件でつまずくのは、むしろ自然なことです。一度しっかりぶつかっておくことで、その後の伸び方が大きく変わってきます。

まとめ:つまずきは、ちゃんと「理解の種」になる

入社3〜4カ月後に案件に入って実感したのは、研修やテストで学んできたことが、実務の中でようやく一本につながり始めるということでした。

最初は分からないことが多く、調査に時間がかかるのは当然です。大事なのは、つまずいた理由を言語化し、次に同じ状況になったときの「型」を持っておくことだと思います。

ちなみに、私がはじめて担当した案件も、入社した年のうちにリリースまで進み、そのスピード感には正直驚きました。案件によっては、開発完了からテストまでが早く、数週間ほどでフィードバックが返ってくることもあります。

その中でバグが見つかったとき、「初期実装の段階でもっと考慮できたことがあったな」と気づく場面が何度もありました。ただ、落ち込むというよりも、次に同じような実装をするときの観点が一つずつ増えていく感覚に近く、そこから学べたことはとても大きかったです。

こうした気づきを早いサイクルで得られるのは、入社して間もないうちから案件に関わり、リリースまで見届けられる環境があるからこそだと感じています。

これからエンジニアを目指す皆さんにも、最初の壁はあるけれど、越えた分だけ確実に景色が変わるということが伝わってくれればうれしいです。

今回のブログは以上です!