自分のソフトウェアで流出バグが出てしまった場合の対応【3つある】
エンジニアの方：
・しまった。開発した製品で流出バグを出してしまった。。。会社にいくのがつらい。どういう精神状態で会社にいけばいいんだろう・・・
・流出バグを見つけたら何をどうしたらいいんだろう
開発をしていると、避けては通れないバグの埋め込みによる苦悩。
今回は、その中でも流出バグ、即ち顧客のところに流れてからバグが発覚した際の対応について解説していきます。
この記事の目次
自分のソフトウェアで流出バグが出てしまった場合の対応【3つある】
結論を先にいうと、下記の3つです。
- 自分だけのせいではないことをアタマに叩き込む
- ほとんどの解析を終わらせた上で上司に報告する
- 2度と経験したくないという気持ちを忘れずに開発をする
自分だけのせいではないことをアタマに叩き込む
万が一、自分が作ったソフトで流出バグが発生してしまった場合、それはあなただけのせいではありません。
なぜなら、開発とは自分ひとりで行うものではなく、
- 決める人
- 作る人
- 確かめる人
- 承認する人
が、いるからです。
これだけの関係者がいるのに、バグの責任を、ソフトウェアを作った本人だけが負うというのは、冷静に考えてもおかしいですよね。
なので、流出バグは自分だけのせいではないことをまずはアタマに叩き込んでおきましょう。
自分ひとりで責任を感じ、勝手に気分をふさぎ込まず、問題の対処に集中しましょう
一人で問題に責任を感じ、ふさぎ込んでも仕方ありません。すでにそのバグが流出していることは事実だし、責任はみんなにあるからです。
なので、まずは気分をふさぎこまず、目の前の問題に集中するようにしましょう。
「なんかあのプロジェクトでバグがでたらしいよ」
「なんでこんな実装してるの。こうすればいいのにー」
などと、外野は勝手なことをいうものです。
なぜなら、自分は関係ないので。
このような輩の言うことを耳に入れ、一喜一憂している余裕はありません。
なので、そのような外野の声は無視し、目の前のやることに集中しましょう。
あくまで不具合事象に目を向け、反省はあとからやりましょう
流出バグが出てしまうと、色々と考え込んでしまいますよね。
「なぜだ？」
「ほんとに自分なのかやったのは？」
「なぜテストで発見できなかったんだ？」
色々と考え込んでしまうことが予想されますが、必要以上に考えるのはあまりよくありません。
なぜなら、いらんことを考えて、結局は自分で自分の気持ちをふさぎこんでしまい、修正作業に集中できなくなってしまうからです。
おそらく、あのときこうすればよかったなど、反省点もたくさん出てくるでしょうが、反省は後。これをやりだすと気持ちが萎えます。
なので、反省は後にして、とにかく目の前の作業に集中するようにしましょう。
ほとんどの解析を終わらせた上で上司に報告する
これまで、自分がもし流出バグを出してしまった場合のマインドについて解説しましたが、流出バグが発生した際は、すぐに上司に報告するよりも、ほとんどの解析を終わらせた上で上司に報告するようにしましょう。
なぜなら、流出バグとなると、上司も平常ではいられなくなり、慌てていろんな指示を急かしてくるからです。
それが的確なものであればよいのですが、
- 煽られ感がある
- 人によっては怒りが混まれている
このような指示の場合、ただでさえ落ち込みがちな自分、つまりは流出バグの作成者としては気が気じゃなくなってしまいます。
また、上司に報告したところで、
- なぜ？
- どうするの？
など、どのみちこれからやろうとしていることについて聞かれるだけです。
なので、流出バグが発生した際は、すぐに上司に報告するよりも、ほとんどの解析を終わらせた上で上司に報告するようにしたほうがよいのです。
事象の再現、原因、修正案、対処をある程度把握した上で上司に報告しよう
では、実際に流出バグが分かった時点でなにをするか。
手順としてはこんな感じでよいのかなと。
- 再現するかの確認
- バグ発生の原因を調べる
- ソフト修正案を検討する
- 修正後、だれに何をお願いするかを検討する
こんな感じでいいのかなと。
- バグの出現が非常にレア
- 社内環境だけでは再現できない
このような流出バグもあることが予想されます。
その場合は、再現はそこそこに、「今は○○の状態なので再現は難しいが、○○すれば事象が再現するだろう」くらいのレベルで、次の検討事項である、原因や修正案の対応に移った方がよいです。
なぜなら、再現テストに時間をかけすぎてしまうと、結果として流出バグに関する全体対応そのものが遅れてしまうからです。
流出バグは時間との勝負となるので、このように意識して、バグを再現できない場合は、先に原因、修正案の検討に入るようにしましょう。
こわいのは修正によるデグレ
流出バグの対応で恐いのは、コード修正によるデグレです。即ち、コードを修正したことで、事象は解決したが、元々うまく動いていたところが動かなくなっつぃまった、というものです。
なので、さくっと修正するのでなく、きちんと設計を行い、その中で影響解析をしておく必要があります。
流出バグの修正は、下記により、どうしてもささっと修正をやってしまいがちです。
- そもそも時間との勝負になる
- 後ろ（テスト、ユーザ部門とのやりとり）が控えている
早く修正しないといけないのは間違いないが、それにより、デグレを起こすと元も子もないので、そこだけは気を付けて、きちんと設計をやるようにしましょう。
つまりは、ミスを起こしやすい。
そして、それはチェック者も同じです。
なので、チェックは通常一人でも、流出バグの対応時は2人、３人にもてもらったほうがよいです。
なので、そういう意味でも、やはり流出バグの修正確認は、複数人にお願いしたほうが無難です。
2度と経験したくないという気持ちを忘れずに開発をする
と、いうことで、自身の苦い経験をもとに、流出バグを起こしてしまった際の対応について解説致しました。
社会人になって数年たちますが、流出バグのときのことは今でも鮮明に覚えています。
- 発覚時の焦り
- 社内での怒号
- 顧客からの冷たい視線
思い出すだけでツライです。
なので、流出バグを起こした方もそうでない方も、このような経験をしたくないという気持ちを忘れずに、日々開発業務を行いましょう。
今やっているその作業が品質を左右します
結局のところ、通常やっている業務のどこかで、何か間違いがあると、それが結果として流出し、流出バグとなってしまいます。
なので、大事なのは、今あなたがやっているその作業。
それが、その製品の品質を左右します。
そのような気持ちで、常に開発をするようにしましょう。
今回は以上です。