ポンコツなエンジニアと言われないために

エンジニアが「ポンコツ」と言われるとき、 技術力が原因であることは、思ったより少ないです。

多くは進め方の問題で、そちらのほうが直しやすいです。

評価を落としている要因

上の2つが圧倒的に効きます。 技術的に優秀でも、この2つがあると評価は上がりません。逆に技術が平均的でも、この2つが無ければ「安心して任せられる人」になります。

「詰まったら相談する」では、判断が主観になって遅れます。 時間で機械的に切ったほうがよいです。

30分  自力で調べる
60分  調べ方を変える（公式ドキュメント／最小再現を作る）
90分  相談する。ここを越えて一人でやる理由はほぼ無い

90分は短く感じますが、相談される側から見れば十分長いです。 3日溶かしてから相談されるより、90分で来られるほうが圧倒的にありがたいです。

「こんなことで聞いていいのか」という迷いが、いちばん時間を溶かします。

見積もりが外れる原因は、たいてい分解の粒度が粗いことにあります。

✕ 「この機能、3日くらいです」
◎ 「設計0.5日、実装1.5日、テスト1日、レビュー対応0.5日。合わせて3.5日」

分解すると、忘れていた工程が必ず出てきます。 テスト・レビュー対応・環境構築・既存コードの読解。外れる分の多くは、この「見えていなかった工程」です。

進め方を直したうえで、それでも足りないと感じる場合。

よくある不足	効く対処
既存コードが読めない	読む練習を業務時間に組み込む。読解は書くのとは別の技能
設計の引き出しがない	手を動かす前に、似た構造を3つ探す
デバッグが遅い	最小再現を作る癖をつける。当てずっぽうをやめる

「デバッグが遅い」は、経験差がいちばん露骨に出る場所です。 そして最小再現を作る習慣だけで、かなり縮まります。

以下は個人の努力では解けません。

・レビューが機能していない（誰も見ない／指摘が人格に及ぶ）
・仕様が決まらないまま実装が始まる
・テストが無く、壊れたかどうかを確認する手段がない
・一人で全レイヤーを担当している

この状態では、誰がやっても「ポンコツ」に見える成果しか出ません。 そして、こういう現場ほど個人の責任として処理されます。

エンジニアという職種の利点をひとつ書いておきます。

身につけた技術は、その会社の外でも通用します。 評価は会社ごとにリセットされますが、技術はリセットされません。

だから、いまの評価が低くても、積み上げたものは無駄になりません。 そしてそれは、会社の評価軸に依存しない収入を作りやすいということでもあります。