昇進したのは最高のコーダーではなく、信頼を作れたエンジニアだった

概要¶

昇進はコーディング力だけでは決まらない。「信頼を作りやすくするエンジニア」が評価される。Abhishek Singh氏が実践から導き出した、信頼を築くエンジニアの行動パターン。

「このアーキテクチャを完全に刷新します」
→ 先にマージ済みコードを見せてから話す

エンジニアリングにおいて、約束はマージされたコードがなければ意味がない。

実践: 提案前にPoCを作る。「こういうものを作りました。これをベースに〜」という順序。

✗ 仕様が不明確 → 何もしない
✓ 仕様が不明確 → 前提を明示してPRを出し、レビューで確認

不明点があっても前に進む。前提を明示してプルリクを出し、「この前提で実装しましたが〜」とコメントする。

✗ 1000行のPR
✓ 200行×5つの小さなPR（それぞれに説明付き）

レビュアーの認知負荷を下げることが、レビューサイクルを速める。

✗「本番でエラーが出ています」
✓「本番でエラーが出ています。原因はX、対処案はA/B/Cです。Aを推奨する理由は〜」

マネージャーやリードが判断しやすい情報を添える。

隠すと信頼を失う。オープンに報告し、再発防止策を示すと信頼が上がる。

「本番デプロイで障害が出ました。原因、影響範囲、今後の対策を共有します」
→ 透明性がある人として評価される

自分のコードを仕上げるだけでなく、他の人のPRをレビューしたり、詰まっている人を助ける。シニアエンジニアとして評価されるには「チームの生産性を上げる」視点が必要。

✗「このAPIエンドポイントを実装して」→ すぐ実装
✓「このAPIエンドポイントを実装して」→ 「これはどのユースケースのために？パラメータの意図は？」

要件の背景を理解すると、より適切な実装・提案ができる。