新卒時代にSTG環境のサーバログをふっとばした話

はじめに

この記事は
「本番環境などでやらかしちゃった人 Advent Calendar 2025」シリーズ 2の7日目
および
「株式会社Bloomix Advent Calendar 2025」の7日目
です。

※逐次修正を加えています
　読みにくさの指摘などもいただけますと幸いです

ネタバレ兼この記事を読んだ皆さんとのお約束　その１
この記事は事故経験共有の記事に見せかけたチームビルディングの記事です

ネタバレ兼この記事を読んだ皆さんとのお約束　その２
自分の現在地を正確に把握して現状を卑下したりしないでください

ネタバレ兼この記事を読んだ皆さんとのお約束　その３
わからないことは正直に周囲の人に質問をしてください
何がわからないかわからないときも素直に相談してみてください

ネタバレ兼この記事を読んだ皆さんとのお約束　その４
若手に質問や相談を促しつつ手厚くサポートしてあげてください

ネタバレ兼この記事を読んだ皆さんとのお約束　その５
既存のスクリプトを実行する時は絶対に中身を確認してから実行してください

これは2020年あたりの私が新卒だったときのお話しです。
例年、本番環境の話じゃないしなぁと書き渋ってROM専状態でしたが、
「本番環境など」という表記を見て覚悟を決めました。
仕事でやらかしたという大枠で考えるとまあある話なのかなということで、
同じ轍を踏まないよう皆さんお気をつけください・・・。

やったこと（やってしまったこと）

ショックのあまり具合的なことは覚えていませんが
機密情報のため詳細は記載できませんが
サーバアプリの性能改善のために顧客と共有で使用しているSTG環境の情報を収集する時に問題は起こったはずです起こりました。

サーバのログファイルをいくつか取得する必要があり、logsディレクトリ配下にある大量のログファイルから条件に当てはまるファイルを見つけなければいけませんでした。
そんな折に上司から
「以前類似した作業の時に使ったシェルスクリプトがあるから中身をよく確認してから適宜修正して動かしてみてね」
とスクリプトファイルを共有してもらいました。

私はスクリプトを斜め読みをして、
なるほどな〜対象ディレクトリの条件に当てはまるファイルをカレントディレクトリにコピーしてくるのか〜と理解した気になり

./nakami-wo-chanto-yome.sh

をポチッとしたわけです。

するとどうでしょう。
カレントディレクトリにはファイルがコピーされておらず、
なんでだろうとコピー元のlogsディレクトリを見るとログファイルが綺麗になっているではありませんか。

対応とその後

すぐ上司へ報告と相談をし、上司から先方へのエスカレが入りました。
幸いなことに先方や他チームもSTG環境のログまでは監視しておらず、
直近で必要としていた人もいなかったため大事にはなりませんでした。

とはいえ客先と共同で使用している環境のログファイルを事故で消してしまったため
しっかりインシデントとして始末書を書いたりヒアリングを受けたりしました。
「やっちゃったことはしょうがないけど同じミスしなければ大丈夫」と声をかけてくれた上司の顔を未だに忘れられません。

ちなみに作業再開時に上司とシェルスクリプトの中身を一緒に確認したところ、
コピー処理部分はコメントアウトされており、削除処理はご丁寧にアクティベート状態でした。

こういうことがあるから確認って大事なんですよね！（戒め）

なぜ起こったか

もちろん実行したシェルスクリプトを斜め読みしたことが悪いといえば悪いのですが、
ではなぜ斜め読み程度しかし無かったのかというところに焦点が当たります。

自分語りになってしまいますが、ご自身や周囲の方が似たような状況になった経験、
あるいはなる可能性もあるためぜひ読んでいただければと思います・・・。

端的に言うなれば謎のプライドと負のスパイラルでした。
私は学生時代から情報という学問を専門にしていたので
「勉強はしてきたんだから実務ができなきゃ恥ずかしい」という思考になっていました。
そして更に配属されたチームがなかなかにレベルの高い案件をやっているところで、
新卒にはかなり難しい案件だなと今冷静に考えても思います。
「精鋭として配属されたのであれば完璧にやらなければ」と思い込んでいたのもかなり大きいです。

新卒なんだから失敗して当たり前（だけどできるように頑張る）というのはよく聞くフレーズかなとは思いますが、
当時の上司に「新卒なんだからできなくて当たり前だよ」と言われたのが心に引っかかって「自分はできることを証明してやる」なんて思っていました。

後述しますが今となっては当時の上司の心境や発言意図もとても良くわかります
私があまりにも愚かな若者だっただけです

それ故に「わからないことを聞くのが恥ずかしい」になり、
次第に当たり前にできていたこともできないようになり「何がわからないかわからない、すべてがわからない」
という最悪な状況になっていました。

仕事の段取りや進め方もめちゃくちゃな状態になり「遅延生み出しモンスター」としてチームを荒らし、新卒であることを加味しても擁護できない問題児でした。

そうなると今度は「今の作業は早く終わらせて少しでもよく見せなきゃ」という思考になり、
斜め読みという愚かな行動をとってしまったわけです。

ということで確かに事象としては確認が甘かったゆえの事故ではあるのですが、
そもそも業務をするうえでのスタンスに致命的な欠陥だったというのが根本原因です。

※ちなみにそこから数カ月後に心がポッキリ折れてプライドを捨てたら楽になりました。

どうしたら防げるのか

先述したように私は遅延生み出しモンスターだったため、当時から上司に「どうしたら防げるか」をとにかく考えさせられていました。
クリティカルシンキングやなぜなぜ分析みたいなものをとにかく「やらされました」。
やらされていると思っている時点で効果がないんですよね。だから結局また遅延させてしまっていました。
理論値のような結論はわかるけど身の丈に合った結論なのかというものもずっと疑問でした。
確かに細かいタスクレベルまで分解をしてはいたものの自分はロボットじゃないしなぁなんて思っていましたし、
そしてその疑問も切り出せないまま時間だけ溶かしてしまっていました。

クリティカルシンキングという表現にアレルギーを起こす人もいらっしゃると思いますが、その際は「判断を最適化できる手法」と読み替えていただければと思います。

「何がわからない」かわからない人にとってクリティカルシンキングほど意味の無いものってないんですよ。
なぜならクリティカルシンキングはそれなりにある程度何かしらの理屈がわかっている人が理論値に近い結論を得るための手法であって、
何もわからない人にとっては考えるための情報という材料がないですし、どうしたらいいかわからない人にとっては集めた情報の良し悪しすら判断がつかないためです。
ちょうどこちらのツイートで同じことを書いていらっしゃる方がいました。

どこまで掘ったらいいのか、一般的・現実的な話なのか、まわりにも説明がつけられるような話なのか。
私は今回の事件までにも様々なケースをもとに「今回はこうしよう」と判断していたのですが、
それに加えてメンタルや環境も重要だなぁと思った次第です。

そして世の中的には中堅と言われるぐらいになった私は
転職やいろんな現場での経験、様々な人を見聞きしていく中で
アプリケーションエンジニアとして開発業務をするときの定石や
「企業に勤めるにおいての普通」をある程度理解してきました。
本題であったはずの事故の件も上司は自分に対してサポートの声かけはありましたし、
「まったく助けてくれなかったよ～えーん」という話ではありません。
原因はサポートを適切に頼れなかった自分と、若手に対して原因と対策が明確になれば後は大丈夫としてしまった上司の両者にありました。

結局仕事において人間に対する悩みや問題が一番大きく、
技術職いえどネックになるのはいつも人間だなぁというのを痛感しています。

前置きが長くなりましたが、
業務を行うにあたってそれぞれの対策、心構えのようなものを若手と中堅、リーダーの2つに分けてまとめます。

若手視点

• 自分が「仕事できない」と悩んだ時はそこをスタート地点にすればいいだけ
  • 「自分これ詳しくないな」に明確に気づけたら現在地点を正確に把握できた証拠
  • 最初は怖くても知ってそうな人に聞くしかない（知らなくて仕事進まない方が怖い）
  • 無知の恥は「知らないことがバレること」が恥ずかしいのではない
• 調べてもよくわからんことは素直に聞くこと
  • 調べ方がわからない場合はすぐ聞く
  • 調べてみたけどわからない時もすぐ聞く
• 何がわからないかわからない時は相談や壁打ちをお願いする
  • 上長、上司の言う「この情報集めたらわかる」をこなしても自分が理解できるとは限らない
  • 上司の「わかる」の中に言葉に表現していない文脈が潜んでいるかもしれない
  • 上司の言っていることが自分の言葉で整理できるまで質問や相談をする

中堅、リーダー視点

• 「時間が無いから端的に」を無くす
  • 現場によっては都合上難しいかもしれないが気軽に相談できる環境は事故防止につながる
    （そもそも切羽詰まってる案件に若手入れたらそりゃしんどいよ）
  • 「実はよくわかってないんですよね」が引き出せたら成功
  • こちらもざっくりとでも「そういうのが不安なんだなぁ」と把握できるだけで大きい
• 経験の浅いメンバーに「とりあえず考えてみて」で成功するのはレアケース
  • ビジネス書に騙されないように
  • 前提条件や情報は積極的に共有する
  • 「与えられるだけの人間になるのでは」は実際そうなった時に考えればいいのでは
  • 失敗を促すことも大事だが初手の失敗はトラウマになりやすい
• 壁打ちを歓迎する
  • 壁打ちいいよ～をなるべくラフに定例などでもアナウンスする
  • 言語化できていないとしてもサポートする

まとめ

以上、STG環境のログを吹っ飛ばした事故ではあるものの、
原因は新卒や若手（と中堅、リーダー）のあるあるというお話しでした。
手動オペレーション事故も手順が定まっていない他に心理的な要因があるはずです。
「いつもならこんなミスしないのに」も然りですが「いつもやっちゃうこと」にもしっかり目を向けて向き合っていくことでチーム、プロジェクト全体で事故を防止していけるのではないでしょうか。

もちろん上司に共有されたシェルスクリプトの中身をしっかり確認して処理内容を理解してから実行することは大前提です！！！
焦らず確認はしっかりしましょうね！