2023-05-23

プログラミングしか興味のないエンジニアに困っている

今年の頭にうちの会社にやってきたエンジニアの話。



彼は実装がめちゃくちゃ速く、コードもきれいテストちゃんと書く。

とてもできるエンジニアなのだが、一つだけ困っていることがある。

実装完了した機能をすぐに本番環境デプロイできないと、とても不機嫌になるのだ。


うちの会社が開発しているのはtoBシステムで、実装内容によっては営業カスタマーサポートからお客さんにアナウンスがされてからでないとデプロイができないものがある。


急にUIが変わったり新機能が追加されるとお客さんが混乱するしカスタマーサポートに問い合わせが殺到するので、デプロイ前に調整が発生するのは致し方ないことなのだが、こうした背景を説明しても彼は納得してくれない。

「とにかく早くデプロイをさせろ」の一点張りで、彼が勝手PRリリースブランチマージして、機能が出てしまたこともある。

それによってカスタマーサポートへの問い合わせが増えても、彼は知らん顔。

謝るどころか「デプロイ頻度は開発組織にとって一番大事なこと。カスタマーサポートがそれを妨害してる」などとのたまうものから、もはやカスタマーサポートから嫌われていて「あの人に重要機能は開発させないでください」とまで言われてしまっている。

きっと彼はプログラムを書くこと、自分の中で開発のサイクルを回すことが好きなだけで、運用には興味がないんだろう。

営業カスタマーサポートやお客さんなど、自分の開発するものに関わる人々にも興味がないんだろう。


うちの会社システム開発、運用とは考え方が根本的に違いすぎるので、どこかの会社に彼を引き取っていただきたい。


追記

予想外にブクマがついてしまったので追記


カナリアリリースブルーグリーンデプロイについて

カナリアリリース提案したこともあるんですが、「サポートが悪いんだからそのためにフラグを追加するのはおかしい。本質的じゃない。」と拒否されることがしばしばです。

しぶしぶ自分や他のメンバーカナリアリリース用の追加PRをつくったりしていますが、それに対しても小言が飛んでくるのでとてもやりづらい。


権限について

一般的ブランチ管理はしていて、mainへの直接マージなどもできないようになっていますが、彼がリリース担当の時に自PRをしれっとリリースブランチマージされてしまい、そのままの流れで本番公開まで至ってしまった形です。

厳格に管理してないほうが悪い的なコメントもありますが、何にどれだけ管理コストをかけるべきなのかは組織事業ステージによりけりでしょう。

gitだけでなく様々ことに管理コストをかけてまでその人を活かすべきなのかというと、現状うちの会社ではNoだと思います


職務限定することについて

彼の担当領域を社内向けのadminだけに絞る的な話は出ています

彼としては社内向けの仕事は嫌らしく、また、adminを一番使うカスタマーサポートに対して敬意がないので難しそうな気はしますが。

いろんな権限剥奪して、何かしら限定的な範囲を担ってもらうことになると思うんですが、彼の望む自由はそこにないと思うので、そのうち転職されるのではないかと思います

  • なんか前時代的な空気を感じるな カナリアリリースとかブルーグリーンとか無縁そう

  • 「デプロイ頻度は開発組織にとって一番大事なこと」 この理由を深掘りできてない。解像度が低い。

  • ソフトウェアエンジニア 竹田くん

  • このままパッチ中心開発をするだけで1日1億円(だっけ?)損するって上司を説得したプログラマの話をおもいだした

  • 業務内容を再整理して契約し直すのは無理なんかな

  • (創作でないなら)これはASDだろうねえ。

  • そんな人間おらんだろ 実在するならちゃんと意図を説明しない上司の責任 うちの会社で働けば何一つケチのつかない人材になる

  • それはプログラミングにしか興味のないエンジニアとは言わない 本番環境へのデプロイに異常に固執するルールを守れないキチガイというんだ

  • ゴミをリリースしようとするな とりあえずマージ権限取り上げておけ

  • 「デプロイ頻度は開発組織にとって一番大事なこと。カスタマーサポートがそれを妨害してる」 事業を成長させるにはカスタマーサポートを強化する必要があるということが顕在化した...

  • 即時のデプロイに固執するのが問題なのに 「プログラミングにしか興味のない」というころを問題視してしまうのは この増田にもなかなか問題がありそうだと思う。

  • 「デプロイ頻度は開発組織にとって一番大事」ってどの程度盲信してるんだろう。 通常は1回で済むデプロイでも10回に分けてデプロイした方が良いと考えてるのか。

  • プログラミングだけに興味持ってるんならデプロイなんかどうでもいいはずだが

  • こういう人って社内システムに配属されて新しいおもちゃを遊び倒させることが多かった気がするんだけど、最近はそうでもないのだろうか。

    • 😷ワイの会社は他社のシステム受注しまくってるくせに自社システム外注やで

  • 運用に興味がないエンジニアって実装よりも上の工程行った時に役立たずになるの目に見えてる

    • 向いてない工程に行かなけりゃ良くない? 上流工程に行かないと給料上がらないから向き不向きに関わらず目指さされて、結果無能ばかりになるの、本当アホらしい 向いてる仕事だけや...

  • 追記読んだら素人丸出しでワロた 自宅警備なのに頑張って書いたんだね

  • ✗プログラミングにしか興味がない ◯ビジネスを理解することができない ご愁傷さまです、つまらない仕事を与えて退職されるのを待つしかないでしょう。

  • プルリクをPRと略してるのか Pull Requestなんて一私企業であるGitHubの独自機能に過ぎないのに一般用語みたいに当たり前に使うな ハゲ

    • 多くの開発現場で利用されるGitのブランチ運用ではPullRequestではなく、MergeRequestと表現するのが正確だよね。 まぁ用語として定着しちゃったからそこをとやかく言うのもどうかどは思う...

    • SVNでも使っとるんか? あるいはそもそもバージョン管理してないとか?

  • マザー1のカナリアのローラの歌のサウンドすき

  • プログラミングにしか興味がないならリリースにこだわるわけないんだけどなあ

  • そいつはエンジニアじゃなくてバカなプログラマー。エンジニアはバカを統率してビジネスを成立させる上級職なの!

  • 過去に2回アスぺエンジニアと仕事したがチームプレイが出来なさすぎて超辛かったのを思い出した

  • 無関係だから簡単に言うけどうまく御せばこの上ない人材だから使い方が悪いよね

  • masterにだれでもマージできるようになってる時点で会社のリリース戦略が圧倒的におかしいことに気付くべき ステージングが完備されてなくてデプロイプロセスがぶっつけ本番とか、リ...

  • 元増田がカナリアリリースのことを一体何だと理解しているのか気になった

  • feature toggleとか使えば、four keysは追いながらも適切なタイミングで機能を出せるのでは

  • feature toggleとか使えば、four keysは追いながらも適切なタイミングで機能を出せるのでは

  • この方は開発組織を回す経験と知識が不足している。 技術的な部分は勿論だが、そもそもコミュニケーション力が足りていないと思われる あなたのいう「デプロイ」を、なぜ彼があなた...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん