エンジニアを“マクドの店員”のように扱う会社は、結局人が消える

深夜対応。「待機」を理解できない会社は、だいたい危ない

昔、とあるエンタメ系サービスの保守開発を受けていた。

いわゆる運用保守案件だったのだが、毎月1回、どうしても「締め処理」が必要だった。 ユーザーへのポイント付与や精算処理みたいなものだ。

今なら「そんなの自動化しろ」と言われるだろうし、実際その通りだと思う。 毎月深夜作業が必要になる設計は、理想ではない。

ただ、現実問題として、どうしても夜間でしか切れないデータや、月次締めという業務都合は存在する。

だから毎月、月末になると、私と同僚エンジニア数人が深夜にオフィスへ集まっていた。

実際には、ほぼ何も起きない

誤解されがちなのだが、こういう深夜対応というのは、別に毎回大変な作業をしているわけではない。

ほとんどはシステマチックに流れる。 ボタンを押して、ログを確認して、異常がないか監視する。

なので極論を言えば、出社する必要すらない。

ただし、何かあった時は即対応。 つまり「作業」というより、「待機」に近い。

でも、この空気は嫌いじゃなかった。

締め処理が無事終わると、もう実質やることはない。 始発まで、オフィスで酒とつまみを広げて、ダラダラ雑談していた。

「あのシステム古いよな」 「次、何の技術触る？」 「最近のフレームワーク意味わからん」

そんな話をしながら、2時から5時くらいまで過ごす。

もちろん帰る前には、空き缶やゴミをちゃんと片付ける。 そこは社会人として重要だ。

そしてその日は当然、午後出社だった。

まぁ、普通に考えればそうなる。

「朝から来い」が始まった

ところが、ある時から空気が変わる。

社長が変わった。

新しい社長は、エンジニアリングに全く理解がない人だった。

そして、こう言い始める。

「深夜作業の次の日も、朝から来てください」

意味がわからなかった。

深夜対応というのは、「作業時間」だけの問題ではない。 精神的にも、神経を張っている。

何か障害が起きれば即対応。 実際には何も起きなくても、“待機”自体が仕事なのだ。

でも、技術を知らない管理職からすると、

「別に座ってただけでしょ？」

に見えてしまう。

たぶん、あれがその会社を辞めようと思った最初のきっかけだった。

工数管理しか見ない人が来ると、現場は死ぬ

その後、さらに決定的な出来事が起きる。

技術のわかる偉い人がクビになった。

代わりに来たのが、 「技術職ではあるが、実質的には工数管理しかできないタイプ」の大規模案件系マネージャーだった。

とにかく「工数、工数」。

でも、その割に技術トレンドには興味がない。

新しい技術を学ぶこと自体に否定的。

「それ、今のやり方で十分だよね？」 「新しいもの覚える必要ある？」 「工数増えるだけじゃん」

そんな空気になっていった。

でも、エンジニアというのは、本来かなり技術への好奇心で動いている生き物だ。

新しいものを触りたい。 改善したい。 もっと楽にしたい。

そこを完全否定されると、現場は急速に腐る。

結果として、かなりのエンジニアが辞めた。

私も辞めた。

エンジニアは「交換可能部品」ではない

時々、経営側で勘違いしている人がいる。

エンジニアを、完全に交換可能な労働力だと思っている。

極端な言い方をすれば、

「辞めたら次を入れればいい」

という発想だ。

もちろん、どんな仕事にも代替可能な側面はある。 それは飲食だろうが、小売だろうが同じだ。

ただ、ITの現場、とくに長年運用されているサービスは、人間関係・暗黙知・過去の障害履歴・設計思想みたいなものが複雑に積み重なっている。

「このSQL、触ると死ぬ」 「このバッチ、月末だけ変な動きする」 「このAPI、昔の仕様が残ってる」

そういう知識は、マニュアル化されていない。

だから、現場を軽視すると、一気に崩れる。

エンジニアを“マクドの店員みたいに替えが効く”と思っている職場は、だいたいうまくいかない。

……いや、マクドナルドに失礼かもしれない。 あのレベルのオペレーションを維持するのも、相当高度だ。