これは豆蔵デベロッパーサイトアドベントカレンダー2023第13日目の記事です（と言っても空いていたところを埋めたので公開日は12/25です）

今年は冬になっても暖かい日が続きあまり冬っぽさを感じないですね。クリスマスもやってきたことなので、少しで冬らしく寒さを感じてもらえるように、今回は筆者が経験したホントに怖いシステムトラブルを2つ紹介したいと思います。

いずれも当時は笑えず人様に言うなんてことはもってのほかのヤバい内容でしたが、もう30年近く前のことなので時効ですね。人の不幸は蜜の味ではないですが、寒いというよりニヤッとする人もいるかもしれませんが、それはそれで面白く読んでいただけたら幸いです。

今から約30年近く前、筆者が新卒の時にやらかした出来事です。

筆者はとあるSIerに入社し、ある銀行を担当するSEをやっていました。その当時といいますか、今でもそうだと思いますが、銀行システムといえばメインフレームでCOBOLが中心で、筆者もご多分に漏れず、COBOLからスタートしました。

ただ、同じCOBOLを使ったプログラムでも微妙なヒエラルキーというか階級があり、本番のオンラインプログラムが花形で、同じ本番プログラムでもバッチは日陰的な雰囲気があり、オンラインプログラムは羨望の的でした。（といっても後にオンラインプログラムを担当するようになりましたが、銀行システムということで絶対にミスが許されないシビアなものなので、つねに胃が痛く、バッチはよかったなぁ～、間違ったら修正してリランすればいいしなと今度はバッチが良く見えて仕方なかったですが）

そんな折、当時の上司が「今回もバッチだけど、これが終わったら次はオンラインを担当してもらうから」というじゃないですか。それを聞いて鼻をフガフガしながらやる気満々でバッチプログラムを作り終えテストを行っていたある日のこと。

マシン室にはめったにやってこない上司がやってきて開口一番「荻原さぁー、今なんのプログラムを動かしている？」というので「自分のプログラムの入力となるデータが欲しいので、開発系で○○のジョブを実行しましたよ（ﾆｺｯ」と俺ってできる部下でしょ的に答えたところ、、、

上司の顔から穏やかさが一瞬にして消え、素早く内線電話を取ったかと思うと「今本番で起きている障害ですが、間違って○○ジョブを実行して決済データファイルが消えたためと思われます。直ぐそちらに向かいます(ｶﾞｼｬ」とどこかに連絡し、走って本番マシン室に向かうではないですか。私は正直なにが起きたのか全く理解できなかったのですが、なにかとてもまずいことをやらかしてしまったことだけは分かりました。なので、これはまずいと思い、呼ばれてもないのに上司の後をついて本番マシン室に向かいました。すると、、、

パトランプがピンポン！ピンポン！とけたたましく鳴り響き、本番コンソールの前に集まった銀行のシステム部門の方たちに上司が状況を説明していると「早くリカバリしろ！」や「○○ジョブを動かしたの誰だよ！」「なんでそんなの本番で動かすんだよ！」といった怒号や罵詈雑言が聞こえ、そこはまさに世紀末の様相。もちろんそん中、「動かしたのは私です、テストで動かしちゃいました」などいう勇気は1ミリもなく、上司や先輩がリカバリ操作をしているのをマシン室の端の方で小鹿ちゃんのように震えながら見ていたのを今でもよく覚えています。

その後、上司から状況を説明してもらい銀行のある日の決済データを自分が削除してしまったことが分かりました。

メインフレームは高価なので開発系のマシンでもいざとなったら商用稼働できるようにコールドスタンバイ機として使っています（というかそうなんだというのをその時にはじめて教えてもらったのですが）。なので、区画は別なところで管理していますが、本番のジョブを起動できるスクリプト(要はJCL)が開発系にも配置され、かつ本番で使っているストレージも開発系から繋がった状態になっています。そんな開発環境で筆者は自分では色々調べて、あっ、このジョブそのまま動かせばテストデータ作ることができるじゃん！と本来は取引終了後に動く本番のジョブを無邪気に動かして、消されるハズのない決済データを消してしまった次第でした。

筆者としては知らなかったとはいえ、この件は新卒のフレッシュな時代のとても怖かった思い出として今でも昨日のことのように覚えています。そして、あまりの恐怖体験だったせいか、それからというもの本番機恐怖症となり、今でも本番機を操作するときは手が震えてコマンドをまともに打てないのは内緒です（といってもセキュリティ的に今では本番機を直接操作することはなくなりましたが）。

そんなこんな失敗もありましたが、次は筆者がめでたくオンラインプログラムを担当させてもらえるようになった時の出来事です。

今では郵便局のATMで銀行のキャッシュカードを使ってお金を下す、その反対に銀行ATMから郵便局のお金を下すということは当たり前のようにできますが、当時は郵便局は銀行ではないため（要は全銀協未加盟）、相互にATMを使うことはできませんでした。ただ、それだと不便なため、預金者の利便性を良くしようということで、銀行システムと郵貯システムをオンラインで繋げ、相互にATMを使えるようにする開発が始まりました。

当時私は銀行システムを郵貯システムに接続する中継システム（対外接続系といわれるもの）を担当し、郵貯システムから上がってきた取引電文を銀行向けに変換して勘定に中継する機能を担当していました。

開発は若干デスマりながらもなんとか予定通りリリースまで迎えることができたリリース当日、銀行さんから1本の問い合わせがありました。「お客様から100万おろしたけど残高が105円しか引かれてないという問い合わせが3件入ってるけど、中継時点で100万を105円にして送ってるとかないですよね？というか100万円のテストしてますよね？」とのこと(当時消費税は5%でした)。

銀行さんは直接的には言いませんでしたが、原因は明らかに桁落ちです。そしてお金を扱うシステムで桁落ちは万死に値します。

100万はテストはしているハズですが、改めて聞かれると自信がなくなり「もしかしたらテストしてないかもです？」というフレーズが頭をよぎりましたが、そんなこと言おうものなら居室に大勢連れてすっ飛んで来られるなとか思いながら、何と答えようかと実際は0.1秒、感覚的には10分くらい考え、結局「もちろんテストはしてます！大丈夫です！」と伝え電話を切ったその瞬間、マシン室にダッシュしました。

やったことはもちろん100万円のテストです。テストデータを作って疑似環境を立ち上げて実際に電文を投げるまでの時間が何時間にも感じたのと、レスポンスがOKで返ってきたときの喜びと安堵感は今でも忘れられません、「オレじゃなかった」と。

原因は調査の結果、勘定系が元帳を更新する際に桁落ちさせていたことだと分かりました。当時銀行のATMで1回におろせる最大の金額は100万未満(99万9千円)だったのに対して、郵便局のATMは100万円まで下すことができました。中継システムではこれに併せ銀行向けの電文も取引金額の桁数を数値3桁から4桁（千円単位なので）に拡張していましたが、それを受け取った勘定系側が元帳DBを更新する最後の最後の領域を3桁のままにしていたため、残額から1000(千円)が引かれるところを先頭の1桁桁落ちし000(千円)となり、結果1円も引かずに取引成功で応答し、利用者は1円も引かれないけど手元に100万がやってきた！という事態になりました（手数料の105円は別で更新しています）。

ちなみに、この事象は合計で4件発生していましたが、いずれも個別に訪問対応をするなどして、全員から100万円は返してもらったそうです。

筆者のホントにあった怖い話は以上ですが、いかがでしたでしょうか？筆者は30年近くエンジニアをやっているので、大なり小なり多くの失敗をしたり見たりしてきましたが、この2つ以上に怖かった経験はありません。他人の失敗を糧になどと崇高なことをいう気はさらさらありませんが、あまり派手な失敗は寿命が縮まったりトラウマになったりするので気をつけましょう！ということで冬の寒い話は終わりにしたいと思います。