この記事は「本番環境などでやらかしちゃった人 Advent Calendar 2025」の8日目です。
はじめに
今日は、新卒1年目のときに“激ヤバプログラム”をリリースしてしまい、メールサーバー爆撃機になった話をします。
7年前の記憶を辿っているので多少脚色があるかもしれませんが、エンタメとして楽しんでください。
※ 所属していた企業が特定できるものは伏せてあります。
当時の状況
新卒で入った会社は半導体を扱う会社で社内SEをしていました。
半導体にはウエハーと呼ばれる円盤状に成形されたものの上に、無数のチップが並んでいる基盤があります。これら1つ1つに電極を刺して、正しく電流が流れるかを検証し、そのテストデータを納品するということをやっていました。
このテストをするマシン上で動作するプログラムと、社内基幹システムとの連携を行うのが私のチームの役割でした。
非常に高価なウエハ（ものによっては1枚数百万くらいします）を扱うテストであるため、非常に製品には気を使う必要があります。それゆえシステム開発においてもその制約をかなりきつく受けていたように思います。
ウエハとは
https://agus.co.jp/?p=7155
何を作りたかったのか
計測したデータを社内サーバへ出力するのですが、その計測結果に異常が起きることがあります。これはウエハー自体の問題もありますが、テストマシンにによっても発生していたようです。
異常が発生した場合人間が状態を見て再計測ということになるのですが、何千とあるウエハ上のチップのデータを目で見て異常と検知するのはかなり時間的コストがかかります。
そこで計測データの結果に対して統計的な手法を使って（たぶん標準偏差とかを使って計算してたはず）、異常値を自動で検出する仕組みを作りたいとのことでした。
要件
- 担当者にテスト結果が異常か異常なしかを通知して欲しい
- 異常値は現場で使っている指標に基づいて統計的な方法で判断してほしい
- 異常があった場合にはすぐオペレータに通達できるように、5分毎に異常をチェックし通知して欲しい（異常があった場合はすぐテストを止めて作業をしたい）
- 通知方法はメールにしてほしい
開発
社内ツールは全体的に Perl か C#.NET をメインで開発していましたが、今回は C#.NET を使って開発をしました。C#.NET を使った理由としては、上長からどっちで開発してもいいよと意見いただいたのと、個人的に Perl を書きたくなかったことにあります。（Perl は 1990 年代の古いバージョンしか使えず、機能的に結局今回独自で開発するものが大半で必要ということもあって、C#を選択した気がします。）
開発については上司から「基本一人で一案件だから頑張って！」とのことで、「俺なんもわからんけど大丈夫か？」と思いつつも、一人で設計〜リリースまで担当することになりました。
機能仕様書の作成〜リリースまで一人で実施しつつ、仕様書と動作検証観点はレビューしてもらいつつ進めました。
そして障害は起きる
金曜日の昼間にリリースを終え、その日は問題なく稼働していることを夕方までウォッチしていました。
「ああよかった、自分一人でやったから不安だったけどなんともなかったな。」と思っていました。
次の日、遊びに出掛けていた自分の携帯に見知らぬ番号から電話が。何事かと電話を取ってみると上司からでした。
上司：「なんかめっちゃメール飛んできてるけど大丈夫？」
自分：「え？」
どうやら作ったプログラムが暴走してメールを送りつけているようでした。しかも5分間隔ではなく、10秒間隔くらいで 😇
発覚した時点で8時間くらい経過していたので、この時点で3,000通くらい送信してしまっています😇
結果どうなったのか
メールサーバー爆撃機と化した私のプログラムは、その日別件で出勤していた上司によって止めていただきました。
影響範囲としては、システム部で使っているメールサーバーに大量のメールを送信したせいでメールボックスの容量を逼迫させ、部門長宛含む本プロジェクトの関係者のメールを消失させました。
幸い、部門長宛の重要なメールには他の関係者がCCされていたこともあり、転送してもらうことで大きな問題は起こらなかったようでした。
発生原因
直接原因は例外処理が不完全であったことでした。
常駐プログラムとして作っていたので
のような動作フローになってました。
この後処理に関する部分において例外が見事（？）に握りつぶされていたことから、sleep(300)が実行されず馬鹿みたいにメールを送り続ける地獄を作り出しました。
根本原因
会社への批判ではなく、当時の環境で自分とその周りの環境に何が足りていなかったかということを、今の自分視点で振り返りってみます。
例外を握りつぶすことによる問題を理解できていなかった
まず例外を握りつぶしていなければ発生していなかったわけで。
例外処理が正しくフェイルセーフとして機能していることがどれだけ大事かが理解てきていなかった。
そもそも実装の前に、ソフトウェア工学の理論からやり直すべきだったと思っています。
設計方針やコードに関するレビューが不十分だった
特定の人にドメイン知識が偏る状態になっていたこともあり、開発チームとしてコードレビューができない状態になっていた。
さすがに自分の作ったものはレビューしてもらいたいなと思っていたのですが、メンターとなる上司自体もかなりリソースが逼迫しており、レビューなどを依頼しても反応がほぼ返ってこない状況だった。（とはいえ、リリースの許可はもらっていたが、しょうがないよねでリリースしてしまった自分が一番悪い）
例外ケースがテストできていなかった
一通り必要な正常系のテストは実施できていたようですが、例外ケースに関するテストが不十分でした。テスト結果として上がってくるデータに関する例外ケースはテストできていたものの、それ以外、特にメールサーバーなどインフラが絡む部分についてのテストできていませんでした。
テストコードを一切書いていなかったことも原因として挙げられると思います。
まとめ
新卒の頃の自分は、技術力も経験も環境も足りなかった。でも振り返ると、足りなかったのはそれだけではありませんでした。
この件を思い出しながら書いていて、今自分がどうこうというよりは、開発体制について同じような過ちをしないようしたいと思った。
教育体制が整っていない現場はどこでもあるとは思いますが、自分が教育していく立場となった際に改めて思い出したい。
最後に、上司として部下を持っている方は、僕みたいなやつを正しく導いてあげてください。よろしくお願いします。