「仕事ができる人」はコード以外に何を見ているのか

はじめに

エンジニアとして働き始めた頃、私は

「技術力が高い人 = 仕事ができる人」

だと思っていました。

難しいコードを書ける人や、新しい技術を知っている人を見ると、

「すごいな」

と感じていましたし、自分もそうなりたいと思っていました。

もちろん、技術力は重要です。

ただ、実際に現場で働く中で少し考え方が変わりました。

本当に信頼されている人は、コードそのものだけではなく、“周囲やシステム全体”を見て動いていることが多かったです。

今回は、実務を通して感じた「仕事ができる人は何を見ているのか」について書いてみたいと思います。

コードを書く前に“影響範囲”を見ている

最初の頃の私は、

「まず実装しよう」

というタイプでした。

ただ、経験のあるエンジニアほど、すぐにはコードを書き始めません。

まず、

• どこへ影響するか
• 他機能と競合しないか
• 運用へ影響ないか
• 障害時どうなるか

などを確認していました。

最初は、

「慎重すぎるのでは？」

と思っていました。

しかし実際には、システムは複数機能が複雑につながっています。

そのため、1箇所の修正で別機能が壊れることもあります。

実務では「実装すること」より、「安全に変更すること」の方が重要な場面も多いです。

そのため、仕事ができる人ほど“変更の影響”をかなり見ています。

“今”だけではなく“運用後”を見ている

これはかなり印象的でした。

新人時代の私は、

「とりあえず動けばOK」

という考え方をしていました。

しかし経験のある人ほど、

• 将来保守しやすいか
• 障害時調査できるか
• ログ足りているか
• 他人が読めるか
• 引き継ぎできるか

など、“運用後”を意識していました。

例えばログ出力1つでも、

新人時代の私：
「エラーだけ出ればよくない？」

実務で見た人：
「後から原因追えるように情報残そう」

という違いがありました。

特に障害対応を経験すると、

「あとで困らないように作る」

重要性をかなり感じます。

“相談タイミング”を見ている

実務でかなり驚いたのが、仕事ができる人ほど相談が早いことでした。

最初の頃の私は、

「自分で解決してから報告しよう」

と思っていました。

ただ実際には、それで状況が悪化することもあります。

例えば、

• 調査に半日使っていた
• 実は別チーム既知問題だった
• 仕様認識がズレていた

などです。

仕事ができる人は、

• どこまで自分で調べるか
• どのタイミングで相談するか

の判断がかなり上手でした。

特に印象的だったのは、

「まだ確定じゃないけど共有だけしておきます」

という動きです。

これによって周囲も早く動けます。

実務では“問題を抱え込まない”こともかなり重要なんだと感じました。

“相手がどう受け取るか”を見ている

これはレビューや説明で特に感じました。

例えば、仕事ができる人は、

• 相手の知識レベル
• チーム状況
• 緊急度

を見ながら説明していました。

技術力が高い人でも、専門用語だけで説明すると伝わらないことがあります。

逆に、本当に仕事ができる人は、

「相手に伝わる形」

をかなり意識していました。

例えばレビューでも、

ただ指摘するだけではなく、

• なぜ危ないか
• 将来どう困るか
• 代替案

まで含めて説明していました。

これはかなり勉強になりました。

“システム全体”を見ている

新人時代は、自分の担当箇所だけを見がちでした。

ただ、経験のある人ほど、

• AWS構成
• 運用
• バッチ
• 監視
• 他チーム
• リリース

など、全体を見ながら動いていました。

例えばLambda修正1つでも、

• CloudWatch影響
• DynamoDB負荷
• S3イベント連携
• 他バッチ影響

まで考えていました。

そのため、単純な実装力だけではなく、

「システム全体を俯瞰する力」

もかなり重要なんだと感じました。

“速さ”より“安定性”を見ている

最初の頃は、

「作業が速い人 = 優秀」

だと思っていました。

もちろん速さは重要です。

ただ、実務では“速いけど事故る”より、“安定している”方が信頼されることがあります。

実際、現場で信頼されている人は、

• レビュー丁寧
• 調査冷静
• 障害時落ち着いている
• 変更慎重
• 確認漏れ少ない

という特徴がありました。

派手ではないですが、

「この人なら安心」

と思われる強さがあります。

これは実務に入ってかなり印象が変わった部分でした。

まとめ

エンジニアというと、

• 実装力
• 新技術
• コード量

に目が行きやすいと思います。

私自身も最初はそうでした。

ただ、実際に現場で信頼されている人は、

• 影響範囲
• 運用
• 周囲との連携
• 障害時対応
• 将来保守

など、“コード以外”もかなり見ていました。

特に実務では、

「自分だけ分かればいい」

では仕事が回りません。

システムもチームも、複数人で長く運用されていきます。

だからこそ、本当に仕事ができる人は、

「今コードを書くこと」

だけではなく、

「その後どうなるか」

まで見ながら動いているのだと思います。