エンジニアは「作る人」より「壊さない人」が評価されることがある

はじめに

エンジニアになったばかりの頃、私は

「すごい機能を作れる人が評価される」

と思っていました。

新しい技術を触れる人や、実装スピードが速い人に対して、

「この人すごいな」

と感じていましたし、自分自身もそういうエンジニアを目指していました。

もちろん、実装力は重要です。

ただ、実際に運用中のシステムに関わるようになってから、少し考え方が変わりました。

現場では、

「たくさん作れる人」

より、

「既存システムを壊さない人」

の方が強く信頼される場面があります。

今回は、実務を通して感じた「壊さないことの重要性」について書いてみたいと思います。

実務では“新規開発”だけではない

エンジニアというと、新しいアプリや機能をどんどん作るイメージを持たれやすいと思います。

実際、私自身もそういう印象を持っていました。

ただ、実務では「既存システムの改修」がかなり多いです。

特に運用中のシステムでは、

• 既存機能修正
• バグ修正
• 小規模改修
• 運用改善
• 障害対応

などが中心になることもあります。

このとき怖いのが、「別の機能を壊してしまうこと」です。

例えば、

• CSV出力修正したら別形式の出力が壊れる
• エラーハンドリング修正したら正常系に影響する
• DynamoDB更新処理変更したらLambda全体が失敗する

などです。

しかも、こういう問題は実装中ではなく、リリース後に発覚することもあります。

本番障害になると影響範囲も大きくなります。

そのため、現場では「新しいものを作る力」だけでなく、「既存を壊さない力」もかなり重要になります。

「動くコード」と「安全なコード」は違う

新人時代の私は、

「とりあえず動けばOK」

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

もちろん最初はそれでも成長できます。

ただ、実務では「動く」だけでは足りません。

例えば、

• 異常系考慮されているか
• ログ出力されているか
• リトライ時壊れないか
• 他機能へ影響ないか
• rollbackできるか
• 将来保守しやすいか

なども重要になります。

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

「実装が速い人」

だけではありませんでした。

むしろ、

「この人の修正は安心感がある」

という人がかなり評価されていました。

これは実務に入ってから強く感じた部分です。

本当に怖いのは“リグレッション”

実務で特に怖かったのが、リグレッションです。

リグレッションとは、修正によって別の機能が壊れることです。

例えば、1行だけ修正したつもりでも、

• 想定外データ
• 別画面
• 他バッチ
• 他Lambda

などへ影響することがあります。

しかも、システムが大きくなるほど影響範囲を把握するのは難しくなります。

私自身、

「この修正だけなら大丈夫だろう」

と思っていた部分で障害になりかけたことがあります。

それ以降、

• 影響範囲確認
• テスト
• ログ確認
• レビュー

をかなり意識するようになりました。

実務では「何を作ったか」以上に、「事故を起こさないか」が重要な場面があります。

“慎重さ”は悪ではなかった

参画初期は、

「慎重すぎる人は開発遅い」

と思っていました。

ただ、運用経験が増えるにつれて考え方が変わりました。

例えば、経験のあるエンジニアほど、

• すぐ実装しない
• まず調査する
• 影響範囲確認する
• 異常系考える
• rollback考える

という動きをしていました。

最初は、

「なんでこんな慎重なんだろう」

と思っていました。

しかし実際には、“過去に事故を経験している”から慎重でした。

本番障害が起きると、

• 利用者影響
• 調査
• 原因分析
• 再発防止
• 夜間対応

など、かなり大きなコストが発生します。

だからこそ、運用現場では「速さ」だけでなく「安全性」も重視されます。

pytestを書くようになって考え方が変わった

個人的に大きかったのが、pytestを書くようになったことです。

最初は、

「テストコード面倒だな」

と思っていました。

しかし実際には、

• リグレッション防止
• 異常系確認
• 修正への安心感

につながりました。

特に、

「この変更で別機能壊れてないかな」

という不安が減ったのは大きかったです。

また、テストを書くことで、

「この処理は何を保証したいのか」

を意識するようになりました。

結果的に、“動けばOK”から、“壊れにくい構成を考える”へ意識が変わった気がします。

まとめ

エンジニアというと、

• 新技術
• 高速実装
• 派手な開発

に注目が集まりやすいです。

もちろんそれらも重要です。

ただ、実務ではそれ以上に、

• 安定性
• 保守性
• 影響範囲理解
• 障害を出さないこと

が重視される場面があります。

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

「この人の修正なら安心」

と思われている人でした。

私自身も、最初は「作れること」が重要だと思っていました。

しかし実務経験を通して、

「壊さないこと」もエンジニアとして大きな価値なんだ

と感じるようになりました。