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

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

「とりあえず動く」を続けた先に待つのは、キャリアの天井、後輩との力関係の逆転、そして年数が評価に結びつかなくなることの 3 つです。抜け出す順番は、リファクタリング → 設計原則 → テストの 3 冊で、実務経験が長いほど内容が刺さります。

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

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

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

3 年目に見え始める兆候

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

null 参照エラー、レースコンディション、メモリリーク。同じカテゴリのバグが繰り返し発生します。修正そのものはできても、なぜ起きたのかを説明できないままなので、別の場所で同じ形のバグが再発します。

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

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

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

チームの設計会議で、先輩たちが「凝集度」「結合度」「依存性逆転」と話しています。言葉の意味がわからないため、賛成も反対も言えないまま時間が過ぎます。

5 年目に起きること

キャリアの天井

シニアエンジニアやテックリードに求められるのは、設計判断、技術選定、後輩の指導です。どれも「動くかどうか」だけでは決められない仕事なので、「とりあえず動く」のマインドセットのままでは手が止まります。

後輩に追い抜かれる

入社 2 年目の後輩が、設計の本を読み、テストを書き、リファクタリングを実践している。そんな状況は珍しくありません。数年経つ頃には、設計の議論で後輩のほうが的確な指摘をする、という力関係の逆転が起こり得ます。

逆転が起きるのは才能の差ではなく、コードを書いた量ではなく「書いたコードを読み直して直した量」が設計力になるためです。

転職市場での評価

5 年の経験があっても、設計スキルが伴わなければ、年数がそのまま評価につながるとは限りません。「その 5 年で何を設計し、なぜその判断をしたか」を説明できないと、年数と実力のギャップが面接で露呈します。

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

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

設計を学ぶ時間がない、というのが一番よく聞く理由です。毎日タスクに追われ、「動くコード」を量産することで精一杯になります。ただ、設計を学ばないまま書くから手戻りが増え、手戻りが増えるからさらに時間がなくなる、という循環にもなっています。

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

「とりあえず動けばいい」という文化のチームでは、設計の質を追求するインセンティブがありません。しかし、その環境に 5 年いると、外に出たときに通用しない前提が身についてしまいがちです。

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

「設計を学べ」と言われても、何から始めればいいかがわかりません。「何を学ぶか」を選ぶ段階でもある程度の知識が必要になるため、入口で止まってしまいます。

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

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

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

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

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

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

テストを書く習慣は、設計の改善を後押しします。テストを書こうとすると、外部への依存を差し替えられる形に切り出さざるを得なくなります。その過程で結合度が下がるため、テストのために手を入れた結果として設計が整っていく、という順番で効いてきます。

5 年目からでも遅くない

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

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

経験があるからこそ、本の内容が深く刺さります。同じ 1 冊でも、5 年目に読むときと 1 年目に読むときでは、思い出せる実例の数が違います。

関連記事

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

まとめ

「とりあえず動く」で 5 年過ごすと、任される仕事の幅が広がらず、後輩との力関係が入れ替わり、年数が評価に結びつかなくなります。抜け出す順番は、リファクタリング → 設計原則 → テストの 3 冊です。5 年分の実務経験があるからこそ、本の内容が過去のコードと結びついて刺さります。始めるのに遅すぎることはありません。