以下の記事を見て思ったことがあるので書いてみます。

記事を読んでない人のために説明すると、下記の引用した通りでコードはちゃんと書いてくれて実装も早いんだけど書いたらすぐに本番環境にデプロイしてしまい、デプロイできない不機嫌になるというエンジニアが居て困っているという話となります。

問題点について

おそらく、このエンジニアはプログラミングを得意としていて得意分野で価値を出そうとしているのかもしれませんが、その価値の出し方がビジネスルールや他の関連者への配慮に繋がっていないところが問題です。
言い換えれば、彼は「技術的な能力」は高いけれど、「業務を円滑に進めるためのコミュニケーション能力」や「ビジネスを理解し、顧客価値を生むための視野」が不足していると言えます。
※ビジネスができないエンジニアとも言える

どう変わると良いか

事業に直接関わるアプリケーションのコードを書くエンジニアはどれだけ優れた技術を持っていても、それを適切に活用してビジネスに貢献できなければ意味がありません。たとえば、「○○機能を作った」だけではなく、「○○機能を作った結果、ユーザーの作業時間が80%削減され、顧客満足度が上がった」など、成果を数値や具体的な影響とともに表現することが重要です。これはエンジニアとしての仕事だけでなく、全ての業務において求められるスキルだと考えています。

このエンジニアは「早くデプロイすること」に固執していますが、その結果がユーザー体験の混乱やカスタマーサポートへの負荷増大となって現れています。デプロイのスピードを重視するのは悪くありません。しかし、それがビジネスや他のステークホルダーにネガティブな影響を与えるのであれば、優先順位を見直すべきです。

エンジニアとしての技術力はもちろん大切ですが、それだけではなく、周囲とのコミュニケーションやビジネスの理解も大切なスキルであり、それらがバランスよく結びついたとき、事業価値の高いエンジニアになります。

このエンジニアに仮に変わってもらうことを期待するとしたら自分の行動がビジネスにどのような影響を及ぼしているか、そしてその影響がどのようにユーザーや他のステークホルダーに影響を与えているかを理解させるために、具体的なフィードバックや教育を少しずつ行っていく必要があるのかと思っています。例えば、実際にユーザーからのフィードバックを見せたり、カスタマーサポートとのミーティングに参加させるなど、自分の行動の結果を直接的に見る機会を設けて体感してもらうことを最初の方にやれればと思いました。

結局のところ、このエンジニアが成長し、自身の行動が他者にどのような影響を与えるかを理解するためには、指導と教育に加えて適切なフィードバックが必要で、彼がそのことを理解し、仮に受け入れることができればこのエンジニアの未来は明るいのではないかな思った次第です。

※画像は僕がStable Diffusionで作っている画像の一部で作りました