「とりあえず動く」で 5 年過ごしたエンジニアの末路

この記事は約 6 分で読めます。

最初の 2 年は問題なかった

入社して最初の 2 年間、「とりあえず動くコード」を書くことは正しい戦略でした。タスクを消化し、機能をリリースし、チームに貢献する。動くコードを速く書ける人は評価されます。

問題は、3 年目以降もこのマインドセットのまま過ごしてしまうことです。

3 年目に見え始める兆候

同じ種類のバグを繰り返す

null 参照エラー、レースコンディション、メモリリーク。同じカテゴリのバグが繰り返し発生する。修正はできるが、根本原因を理解していないため、別の場所で同じバグが再発する。

コードレビューで指摘が減らない

2 年目と同じ指摘を 3 年目も受けている。「この関数は長すぎる」「命名が曖昧」「エラーハンドリングが不十分」。指摘の内容が変わらないのは、成長が止まっているサインです。

設計の議論についていけない

チームの設計会議で、先輩たちが「凝集度」「結合度」「依存性逆転」と話している。言葉の意味がわからず、議論に参加できない。

5 年目に起きること

キャリアの天井

「動くコードを書ける」だけでは、シニアエンジニアやテックリードにはなれません。これらの役割には、設計判断、技術選定、後輩の指導が求められます。いずれも「とりあえず動く」のマインドセットでは対応できません。

後輩に追い抜かれる

入社 2 年目の後輩が、設計の本を読み、テストを書き、リファクタリングを実践している。3 年後、その後輩はあなたより設計力が高く、コードレビューであなたに指摘をする側になっている。

設計の本を 1 冊読むだけで、この停滞から抜け出す第一歩を踏み出せます。

転職市場での評価

5 年の経験があっても、設計スキルが伴わなければ、転職市場での評価は「経験 2〜3 年相当」になります。年数と実力のギャップは、面接で露呈します。

なぜ「とりあえず動く」から抜け出せないのか

目の前のタスクに追われている

設計を学ぶ時間がない。毎日タスクに追われ、「動くコード」を量産することで精一杯。しかし、設計を学ばないから非効率なコードを書き、非効率だからタスクに追われる。悪循環です。

「動く」ことが評価される環境

「とりあえず動けばいい」という文化のチームでは、設計の質を追求するインセンティブがありません。しかし、その環境に 5 年いると、他の環境では通用しないスキルセットが固定化します。

何を学べばいいかわからない

「設計を学べ」と言われても、何から始めればいいかわからない。この「何を学ぶか」の判断自体に、ある程度の知識が必要です。

抜け出すための読書ロードマップ

ステップ 1: リファクタリングの本を 1 冊

「動くコード」を「良いコード」に変える具体的な手法を学びます。Extract Method、Rename Variable、Replace Conditional with Polymorphism。これらの手法を知るだけで、日々のコーディングが変わります。

ステップ 2: 設計原則の本を 1 冊

SOLID 原則、DRY、KISS。なぜリファクタリングが必要なのか、その背後にある原則を理解します。原則を知ると、「とりあえず動く」コードの何が問題なのかが言語化できるようになります。

ステップ 3: テストの本を 1 冊

テストを書く習慣は、設計を改善する最も効果的な方法の 1 つです。テストしやすいコードは、自然と設計が良くなります。

5 年目からでも遅くない

「もう 5 年も経ってしまった」と思う必要はありません。5 年分の実務経験は、読書と組み合わせると強力な武器になります。

経験がない状態で設計の本を読んでも、実感が湧きません。しかし、5 年分の「とりあえず動く」コードを書いた経験がある人が設計の本を読むと、「ああ、あのときこうすればよかったのか」と過去の経験と結びつきます。

経験があるからこそ、本の内容が深く刺さる。5 年目の読書は、1 年目の読書より何倍も効果的です。

関連記事

• 「動くコード」と「良いコード」の間にある本
• 30 代エンジニアが読書で取り戻す「設計の言語化力」

まとめ

「とりあえず動く」で 5 年過ごすと、キャリアの天井、後輩との逆転、転職市場での過小評価が待っています。抜け出すには、リファクタリング → 設計原則 → テストの順で 3 冊読む。5 年分の実務経験があるからこそ、本の内容が深く刺さります。始めるのに遅すぎることはありません。