ここはクソみたいなインターネッツですね

逆にクソじゃないインターネッツってどこ

バグを起こしたエンジニアのリアルな感情の流れ

いやーバグ出した。 0:00から今まで対応調査してた。結構大きなバグで、売り上げ数%欠損出しちゃうくらいのバグ。

気分は当然最悪なんだけど、こういう時のエンジニアの感情とか心境とかってあんまり見る機会ないから自戒の意味も含めて書いておく。

バグってどういうもの?っていう人もいると思うので今回辿った流れにそっていく。

バグを出した時の大体のながれ

  1. バグ発覚
  2. 関係各位に連絡
  3. バグ原因/内容調査
  4. バグ対応検討
  5. バグ一時対応
  6. 顛末書/報告書内容まとめ
  7. 関係各位に正式に顛末報告
  8. リカバリープラン及び予防策検討実施

1. バグ発覚

プログラムリリースは先月。 特定の時間に動くプログラム(バッチ処理とか定期実行プログラムとか言ったりするやつ)であったため、バグが起こりそうな月またぎの実行タイミングにあらかじめ確認体制を敷いていた。 大変申し訳ないが、エンジニアの僕だけでなく実際にそのプログラムを使う方々にも深夜まで起きて確認するよう頼んでいた。 しっかり動くようテストはしたのだが、人間が作る以上バグのないプログラムなどないという言葉はやはり真理であった。案の定バグ発覚。

第一に来るのは震えと混乱。バグが起きた場合どう動くか、ということまで予め見通しを立てていたにもかかわらず、とりあえず不安で震えが止まらない。どうしよう、と一人声に出してコンソールのログイン画面を見ていた。すぐにデータの整合性とログを確認しなければいけないのに、脳が20〜30秒ほどフリーズ。 やっぱりか、という気持ちと、どうして、という気持ちと、どうしようヤバい、どうするんだっけ、とりあえず連絡しなきゃ、という気持ちがせめぎ合い訳のわからないまま逆さまのタバコに火をつけログを追い始める。

2. 関係各位に連絡

とりあえず連絡。有難く申し訳ないことに、確認体制を敷いていたおかげですぐ連絡がつく。 取り急ぎですみませんがここでこういったバグらしきものが確認できております、というような文を送る。 どんな文を書いていても「申し訳ない」という言葉を挟みそうになるのを堪える。この段階では謝罪は必要ない。それより先にやることがあるのだ。

心はこの時すでに殺しておくのが吉。自分が起こしたバグということを忘れたほうがいい。実際はむしろ殺してくれという気持ちになるが、対応と調査を待っている人がいるのでそうも言ってられない。あまりの申し訳なさからドクドク鳴ってる鼓動が「直したら死のう」という声に聞こえてくる。そうだな、とつぶやき始めるが、応える声などなく、ただひたすらに鼓動に耐えることが要求される。流していたEDMが止まる。無音が激流のように感じられ、耳元で電マが鳴っている気さえしてくる。

3. バグ原因/内容調査

バグの原因は大体くだらない。プログラム的な内容は置いておいて、バグが起きる原因なんて三つしかない。 テスト漏れ、仕様漏れ、設計ミスのどれかだ。

なんでこんなミスを、なんでこの仕様を見落としてるんだ、テストではうまくいったのになんで、と不安が不甲斐なさからの怒りに変化していく段階。この一行だけ変えておけば、とか、バグというものは大抵そんな少しのミスや抜け漏れから起こる。

原因をメモしながら影響範囲に目星をつけ始める。このあたりから損失金額が計算できてくるが、ここでも無心を貫き原因調査と内容詳細を把握する。感情の面ではこのあたりがピーク。ここで「起きてしまったものはしょうがない」という考えに至るかどうかで精神及び肉体の生き死にが変わる。おかあさん、おかあさん、おかあさん、と紫煙を吐きながら独自のメロディを口ずさむ。

4. バグ対応検討

自分の犯したミスを直視しながら、一時対応を考える。心境としては考えるもクソもない、一刻も早く正常な状態に戻さないと損失額はどんどんと増えていくのだから。 データをあるべき状態に変えるコードなりクエリなりを組み立てる。相変わらず焦る気持ちが指先を揺らし目の前を真っ白に染め上げようとするが、ここでミスを重ねることは許されない。少しでも早く完了しなければいけないが、同時に確実な仕事をしなければいけない。奥歯を噛み締めながら1文字ずつキーボードを叩く。耳鳴りで打鍵音など聞こえやしないが。

5. バグ一時対応

上司なり責任者なりの承認を受けた上で、検討した対応方法を実行する。想定通りの結果が出るかどうか、ここでもテストを行わなければならない。処刑台に上がるのではない。すでに輪は首に掛けられている。あとは床が開くかどうかを己が目で確かめるだけとなる。今回は床は開かなかった。一緒に対応体制を敷いていてくれた方々がすんでの所でそれを支えてくれていた形となる。ここでも謝罪ではなくお礼を言うこととなる。謝罪はまだだ。己の罪も知らずに行っていい行為ではない。己が犯した悪業と、そして傷つけたもの、失ったもの、失わせたものを十分に知ってから行うべき行為だ。

6. 顛末書/報告書内容まとめ

首に輪を付けたまま、自身の罪を読み上げる。発覚経緯、日時、現状、影響値、原因、対応、本対応スケジュール、再発防止策。なにをしていてもまるで世界が全て自分を責めていて、決して許されない罪を犯してしまったのではないかという恐怖と迫力を持った錯覚に見舞われる。ブンブンハローユーチューブ、という呪文を唱えながら俺は作業を完了させた。

7. 関係各位に正式に顛末報告

作業完了の旨を顛末書と一緒に報告。 ごめんなさい。ぼくはわるいことをしてしまいました。わるいこととはこういうことです。かくにんさせてごめんなさい。 ここで漸く謝罪の言葉を混ぜられる。大抵のリアクションは冷たい。そりゃそうだ。余計なバグを起こしやがってコイツ死ねばいいのにってみんな思って当たり前だ。本当俺もそう思うよ、死ねればいいのにってね。

8. リカバリープラン及び予防策検討実施

ミスを補えるように、同じミスを犯さないように、何ができるかを考え承認を貰い、その後は使えないゴミムシとして反省し続け声も小さく息もなるべくせず権利を主張せず義務のみを遂行するクソお荷物ダメ社員として生きていくことを決める。ミスは誰にでもある、次に活かせばいいと上司が言ってくれたのなら、死への助走は十分だ。使えねえな、と言われたのなら反逆か服従を選択する他ない。 しばらく、飯はくわないでいいと心に決める。後輩には会いたくなく、上には顔を見せられない。そんな人間、そんな生き物になるしかない。皆が忘れるか、自分が忘れるまでこの状況は続く。それが正しくないことだと分かっていながらも、それ以外どうしていいかわからずただただ思いを溜め込んで心を朽ち果てさせていくしかない。

以上、バグを起こしたエンジニア(俺)のリアルな心境でした。