未経験・新卒1年目エンジニアが直面した4つの失敗と学び

本投稿は TECOTEC Advent Calendar 2025 の17日目の記事です。

DX本部システム開発第一事業部の吉本です。今年4月に未経験・新卒で入社しました。

普段はフロントエンドエンジニアとして、主にNuxt 2でWebアプリケーション開発を行っています。

この記事では、案件に配属されてから今までに私が直面した失敗と学びについてまとめました。

本記事の対象
失敗①：コードの可読性・保守性
- 失敗事例「コードが読みづらい」
- 読者へのメッセージ：思いやりのこころが大事！
失敗②：タスク受取時のコミュニケーション
- 失敗事例「確認してないけどいっか」
- 読者へのメッセージ：タスクをもらったら必ずゴールを確認しよう！
失敗③：レビューの反映
- 失敗事例「言われたことをそのまま反映させる」
- 読者へのメッセージ：自分の意見を持つ！
失敗④：コードの最適化
- 失敗事例「とにかく動けばいいだろう」
- 読者へのメッセージ：考えることをやめないで！
まとめ
テコテックの採用活動について

本記事の対象

新卒1年目
就活生（特に未経験）

私の経験が、少しでも皆さんの助けになれば嬉しいです！

失敗①：コードの可読性・保守性

失敗事例「コードが読みづらい」

ここで皆さんに質問です！

Vue.jsにはマスタッシュ構文（データの値を埋め込んで動的に表示を行うためのテンプレート構文）というものがあるのですが、それを以下のように書くのと

<div
  ...
  class = "..."
  style="..."
>{{ message }}</div>

以下のように書くのとどちらが読みやすいでしょうか？

<div
  ...
  class = "..."
  style="..."
>
  {{ message }}
</div>

断然後者ですよね（異論は認めます）

また、HTMLのタグに関しても同じことが言えて、

<div>
  <div
    ...
    class = "..."
    style="..."
  >今日の天気</div
></div>

と

<div>
  <div
    ...
    class = "..."
    style="..."
  >
    今日の天気
  </div>
</div>

だと後者の方が、どこまでがdivタグで囲まれているのかが分かりやすくて良いですね。

改行を適切に入れることで、コードの構造が明確になり、視覚的に理解しやすくなります。その結果、コードレビューや修正がしやすくなります。

少し整えるだけで可読性はぐんと上がりますが、当時の私は何も気にせず前者のコード（コードフォーマットツールによって自動整形されたもの）を提出していました。

未来の自分も含めて、読む人のことを考えてコードを書くことが大切ですね。

読者へのメッセージ：思いやりのこころが大事！

コードも立派なコミュニケーションだということに最近気づき始めてきました。

人と会話するときには、相手の理解に合わせて話したり、相手の状況を考慮して言葉を選びますよね。同じように、コードを書くときも、読む人の立場に立って、分かりやすく、意図が伝わるように書くことが大切だと思います。

未来の自分やチームメンバーがスムーズに理解できるコードを書くことで、開発全体の効率も向上させることができます。

失敗②：タスク受取時のコミュニケーション

失敗事例「確認してないけどいっか」

私の所属している案件のフロントエンドタスクでは、おおまかに

デザインのモック作成（デザインやレイアウトの試作品を作り、関係者と合意を取るフェーズ）
APIのフロントつなぎこみ（ロジックを調整し、サーバーサイドとデータの送受信ができるようにするフェーズ）
実装後調整

という流れで進んでいくことが多いです。

ある時、私は第1フェーズなのにロジック（第2フェーズの処理）まで実装してしまいました。

レビュアーの見る範囲が増える&異なるフェーズの実装が混ざっているので考えることが増えてしまいます。その結果、レビューにかかる労力が跳ね上がり、下手をすればレビュー時の指摘漏れが発生する可能性があります。

この失敗は、タスクのゴールについてコミュニケーションが取れていなかったことが原因だと考えます。

読者へのメッセージ：タスクをもらったら必ずゴールを確認しよう！

やり直しになる方が結果的に負担が大きくなるため、早めに確認することが重要です。「念のため」の気持ちで、ゴールが明確な場合でも、タスク管理者と確実に認識を合わせておきましょう。

聞いたら嫌な顔されるかな…と思っているそこのあなた！レビュー時に大きな指摘をする方が嫌な顔されると思います…のですぐに聞いてください。

また、口頭だと忘れてしまいそうで怖いので、できればテキストでメモを残しておきましょう。

失敗③：レビューの反映

失敗事例「言われたことをそのまま反映させる」

とあるメソッドに対してAIから「JSDocコメントつけたほうがよいですよ」と言われ、コピー&ペーストで提出。実はそのメソッドは大したことはしておらず、コメントを付けるほどではなかったため、レビュー時に指摘される、ということがありました。

読者へのメッセージ：自分の意見を持つ！

今振り返ると大問題なことをしていますね、過去の自分。。。

どれだけプログラミングに対して知識が無くても、「言われたから対応する」はNGです。（急いで過去に戻って自分に伝えたい…）

自分の意見を持ち、自分の判断で提出・修正を行えるようにならないといけませんね。

失敗④：コードの最適化

失敗事例「とにかく動けばいいだろう」

filter関数とfind関数の使い分けの失敗例

実装していた箇所では、配列から条件に合致する最初の1つの要素を取得する必要があり、以下のように実装していました。

const users = [
    { id: 1, name: 'Alice', active: true },
    { id: 2, name: 'Bob', active: false },
    { id: 3, name: 'Charlie', active: true }
];

const activeUsers = users.filter(user => user.active);
const firstActive = activeUsers[0];

この場合、filterは配列全体をループして条件に合う全ての要素を返していました。しかし、必要なのは最初の1つだけなので、不要なものまで取得してしまい非常に非効率です。また、配列の要素数が多い場合にはパフォーマンスが低下してしまいます。

より効率的な実装は以下の通りです。

const firstActive = users.find(user => user.active);

findは条件に合う最初の要素を見つけたらすぐに処理を終了するため、無駄なループがありません。

レビュー時に指摘されるまで、動けばいいという思考で、このような非効率さに気づいていませんでした。

読者へのメッセージ：考えることをやめないで！

なぜその実装・修正が必要なのかを自分で考え、確認する癖をつけましょう。自分の頭で考えることで、より効率的で正確な実装ができるようになります。

まとめ

この記事では、私がこれまでに直面した失敗を4つ紹介しました。

これらの失敗を通じて得た学びを活かし、今後も成長を続けていきたいと思います。

新卒1年目の皆さんにとって、ヒントが1つでもあればいいなと思います。

また、これから入社される方は、この記事を参考にして、最初の一歩を踏み出す際のヒントにしていただければ嬉しいです。分からないことばかりかもしれませんが、これから頑張っていきましょう！！

テコテックの採用活動について

テコテックでは新卒採用、中途採用共に積極的に募集をしています。
採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。
ご興味を持っていただけましたら是非ご覧ください。 tecotec.co.jp