運用保守19年で一番しんどかったこと、正直に話します

「運用保守って楽そうでいいね」

正直、この言葉を聞くたびにちょっと苦笑いしてしまいます。

確かに、開発のような締め切り地獄や、深夜のリリース作業とは違う種類のしんどさかもしれません。でも、19年やってきた私にも「あのときは本当にきつかった」と今でも思い出す経験が、いくつかあります。

今回は珍しく、しんどかった話を正直に書きます。

きれいごとなしで。

しんどかったこと①：50社管理、頭の切り替えの限界

現在、私は約50社の運用保守を担当しています。

「50社」と言葉にするのは簡単ですが、実態はこういうことです。

午前中にA社の障害対応をしながら、B社の月次報告書を書いて、C社の担当者から「ちょっといいですか」と電話が来る。午後はD社の年次計画の見積を作りながら、E社のセキュリティパッチ適用の承認を取りに行く。

1日の中で、何十回も「文脈の切り替え」が発生します。

これが、じわじわとくる。

技術的な問題よりも、この「頭の切り替えコスト」が積み重なって消耗していくんです。A社の障害対応モードのまま、B社の打ち合わせに入ってしまって、的外れな返答をしてしまったこともありました。

特にしんどいのが、深刻度の違う案件が同時に走るときです。

片方では重大障害が発生していて、もう片方では来週の定例会議の資料を求められている。どちらも「相手にとっては最重要」なんです。でも自分の時間と集中力は有限です。

この問題、完全には解決していません。今でも格闘中です。

今やっている対策としては——

それでもまだ完璧じゃない。50社を一人の人間が管理することの限界を、毎日少しずつ感じています。

これは、今でも苦い記憶として残っています。

あるとき、顧客からシステムの移行プロジェクトを任されました。スケジュールはタイト、予算もギリギリ。でも「なんとかなるだろう」という楽観的な見積を出してしまった。

テスト工数を削りました。トラブル発生の余裕を見ませんでした。

結果は、案の定の炎上でした。

移行作業中に想定外のトラブルが連発。テスト不足が原因で、本番環境でしか再現しない問題が次々と出てくる。夜間対応が続き、顧客への報告が続き、チームのメンバーも疲弊していく。

あのときの教訓は、今の私の仕事の根幹になっています。

見積でテスト工数を削ってはいけない。トラブル発生を必ず織り込む。楽観的な見積は、後の炎上の導火線になる。

顧客に「もう少し予算をください」と言うのは勇気がいります。「高い」と思われるのが怖い。でも、無理な見積で請け負って炎上した方が、顧客にとっても自分にとっても、何倍もダメージが大きい。

あの炎上を経験してから、私は見積に対して必要以上に慎重になりました。「安く見せる見積」より「正直な見積」の方が、長い目で見て信頼につながると、身をもって学びました。

2つのしんどかった経験を振り返ると、共通していることがあります。

「全部が自分ごと」になる重さ、です。

SES時代は、担当作業に集中すればよかった。社内SE時代は、システム全体を見ながら動けばよかった。でもチームリーダーになると、売上も、人も、顧客満足も、全部が自分ごとになります。

誰かに「どうすればいいですか」と聞けない場面が増えます。判断を間違えたとき、その影響がチーム全体に波及します。

これが、チームリーダーという仕事の一番しんどいところだと思っています。

ここまで読んで「運用保守ってしんどそう」と思った方もいるかもしれません。

でも、私が19年続けてこられたのには理由があります。

しんどさと同じくらい、やりがいがあるからです。

炎上案件を乗り越えた後の達成感。50社を管理しながらも、顧客から「いつもありがとう」と言われる瞬間。メンバーが成長して、自分よりうまく問題を解決するようになったとき。

しんどさとやりがいは、表裏一体です。

「しんどいことがない仕事」は、やりがいもないことが多い。19年間、そう思いながらやってきました。

19年で一番しんどかったことを2つ、正直に書きました。

しんどい経験は、全部財産になっています。

「運用保守のしんどい話をもっと聞きたい」「自分もこういう経験をした」という方は、ぜひコメントや問い合わせフォームから教えてください。