開発って何から考える？新人エンジニアが1年目に学んだ実装の基本
はじめに
こんにちは、たけとりと申します。
私は2025年にWebエンジニアに転職した新人エンジニアです。
転職してから約1年、これまでは主に開発（実装）を担当してきました。
最近は要件定義や設計にも少しずつ関わるようになり、
- なぜこの設計になっているのか
- なぜこの実装方針が選ばれているのか
を以前より意識して考えるようになってきました。
ただ、開発を始めたばかりの頃は正直、
コードは書けているはずなのに、なぜかレビューで止まる…
という経験ばかりでした。
この記事では、新人エンジニアである私が開発を1年経験して実感した「実務で通用するコードを書くために学んだこと」を、体験談をもとにまとめます。
これからエンジニアを目指す方や、私と同じような新人エンジニアの方の参考になれば嬉しいです。
大変だったこと①：「なんとなく書いたコード」は、要件を満たしていないことがある
開発を始めたばかりの頃の私は、「とりあえず動けばOK」という感覚でコードを書いていました。
その中で強く印象に残っているのが、isset と !empty を使った判定処理です。
レビューで指摘されたこと
私は何も深く考えずに isset を使って実装していました。
すると、先輩エンジニアから次のようなアドバイスをもらいました。
「入力画面で、ユーザーが一度入力したあとに削除した値って、null じゃない扱いになることがあるんだよね。
今回は“明確に値があるか”を判定したいから !empty の方が要件に合っているかもしれない」
このとき初めて、似た役割のメソッドでも要件によって選ぶべきものが変わるということを、実感をもって理解しました。
学んだこと
この経験から学んだのは、
- 「どのメソッドが正しいか」ではなく
- 「この要件で、どんな挙動が正しいか」
を考える必要がある、ということです。
技術的な知識不足というより、要件と実装をきちんと擦り合わせて考えていなかったことが一番の問題でした。
大変だったこと②：社内メソッドを理解しないと、実務では遠回りになる
次に苦労したのが、社内メソッドの扱いです。
自作してしまった失敗
開発初期の私は、社内で用意されているメソッドを十分に把握しないまま、
- 「このくらいなら自分で書いた方が早い」
- 「処理も単純そうだし…」
と思って、メソッドを自作してしまいました。
するとレビューで、
「これ、社内メソッドがあるからそっち使った方がいいよ」
と指摘を受けました。
なぜ社内メソッドを使うのか
実際に社内メソッドを使ってみると、
- デバッグがしやすい
- すでに他の機能でも使われている
- サービスの仕様に最適化されている
といったメリットがあることが分かりました。
このとき、
社内メソッドは「独自仕様」ではなく、
これまでの運用や失敗を踏まえて作られた最適解
なのだと腑に落ちました。
大変だったこと③：既存ロジックを使う勇気がなかった
新人の頃の私は、既存コードを読むより自分で書いた方が早いと思ってしまうことがありました。
追加機能で特に意識するようになったこと
しかし、追加機能を実装するようになってからは、デグレ（既存機能の不具合）を強く意識するようになりました。
新しくコードを足すほど、影響範囲は広がりますし、テスト漏れのリスクも高くなります。
そのため今は、
- 既存ロジックで対応できる部分は極力使う
- 新しく書くコードは最小限にする
という方針を意識しています。
「書かない判断」も、実務では重要な技術の一つだと感じるようになりました。
1年経って変わった「コードを書く前の考え方」
開発を1年経験して、コードを書く前の考え方が大きく変わりました。
今は実装に入る前に、次のような点を必ず確認しています。
- 似た処理がすでに実装されていないか？
- 社内メソッドを使うべき場面ではないか？
- 要件を満たす最低限の実装はどこか？
- 変更した場合の影響範囲はどこまでか？
最近、設計にも関わるようになって感じるのは、
設計を意識していると、実装で迷うポイントが圧倒的に減る
ということです。
実際に、設計を経験して学んだことについては、別の記事で詳しくまとめていますので、よければあわせて読んでみてください。
最初の頃の自分に言いたいこと
もし開発を始めたばかりの自分に声をかけられるなら、こんなことを伝えたいです。
何も考えずにコードを書き始めないでほしい。
「とりあえず動けばいい」わけではない。
チーム開発では、可読性も保守性も同じくらい大事。
既存のコードをよく読んで、
どうすれば既存機能に影響を与えず、
どうすれば一番少ない手数で実装できるかを考えてから、
コードを書き始めてほしい。
遠回りに見えても、その方が結果的に一番早かったと今は思います。
まとめ：これからは「良いコード」を言語化していきたい
1年前の私は、「正しく動くコードを書くこと」「とにかく実装を終わらせること」だけを目標にしていました。
しかし、今は以下の視点を持てるようになってきたと感じています。
- 要件に合っているか
- 既存コードと調和しているか
- 将来の修正で困らないか
ただ、「良いコードとは何か？」をまだうまく言語化できていない部分もあります。
そのため今後は、良いコードを書くための考え方を学べる技術書も読んでいく予定です。
読んだら書評としてまとめ、このブログでも紹介していきたいと思っています。
この記事とあわせて読んでいただくことで、より理解が深まるような記事にしていけたら嬉しいです。
