ソフトウェアの流出バグ原因：「おや？」って発見を無視することです
エンジニアの方：
いま開発でテストを行っているが、納期がヤバい。ってあれ？いま変な挙動があったような。
でもすぐ再現しない。。。とりあえずバグ管理票に残したほうがいいのかなぁ？
トップ画像が、女性が男性を無視するような内容でスミマセン。
今回は、女性が男性を無視する話ではなく、エンジニアが変な挙動を無視する話について解説致します。
これまでテストをしていて、「おや？」という挙動を無視したために、結果として後から不具合が発覚するという苦い経験あり。
以降、テスト中の挙動はたとえ些細なことでも原因を調べることで、バグ件数を減らしている。
ソフトウェアの流出バグ原因：「おや？」って発見を無視することです
ソフトウェア開発において、バグが開発中に見つからず、客先やユーザ、つまりは市場で見つかる「流出バグ」。
これを防止するには、開発のテスト工程において、「おや？」と感じた発見を無視せず、きちんと原因調査しましょう。
そう考える理由は下記です。
- ソフトウェアは組んだコードの通りにしか動かないから
- 今、たまたま見つかったその現象が、後々火を吹きます
ソフトウェアは組んだコードの通りにしか動きません
ソフトウェアは、書かれたコードに沿ってしか動きません。
なので、ソフトウェアは組んだコードの通りにしか動きません。
当たり前のように聞こえますが、開発をしているとこの事実を忘れてしまうことが多いです。
なぜなら、せっかくテスト中や実機動作中に変な挙動を見つけても、テスト環境のせいにすることが多々あるからです。
- 使っているPCの調子が悪いから
- 使ってる実機が試作中のものだから
- 計測器の動きがあやしいから
いろいろと言いたくなるのはわかりますが、
「ソフトは組んだ通りにしか動かない」
この原理原則をアタマに入れておくことで、このようなテスト環境のせいにすることなく、落ち着いて原因調査をできるようになるのではないでしょうか。
今、たまたま見つかったその現象が、後々火を吹きます
開発において、開発がうまくいかなくなった状態のことを「炎上」などと表現することがあります。
そして、今あなたが行っているそのテストや動作検証中に、たまたま見つかった「おや？」という現象。それを無視すると、後々から火を吹き、結果プロジェクトが炎上することとなります。
なぜなら、先ほども解説した通り、ソフトは組んだ通りにしか動かないからです。
何かしらのコード上のロジックを通った結果、その結果が出ているのです。
なので、
- 「よくわからんけどうまく再現しないし、まあいっか」
- 「なんか変な挙動したけど納期やばいし、とりあえずテスト工程が完了すればいいや」
このような姿勢では、後からそれが発覚し、結果としてそこで火が吹いて、プロジェクトが炎上してしまいます。
経験談：レアケースな懸念事項を無視した結果、量産間際で発覚、炎上した経験
下記のようなプロジェクトがありました。
- 自分がソフトウェア開発の担当でコードを組んだ
- そのコードが製品(車両に取り付けられる製品)に書かれる
このプロジェクトが、量産、つまりは、
「実際に工場でそのモノがいよいよ量産されるというフェーズ」
の、直前でバグが発覚し、工場の生産開始をストップするなど、大迷惑をかけたことがあります。
今思い返すだけでもツライです。
その原因は、「おや？」という事象を無視したことでした。
経緯はこんな感じです。
- 本番環境、すなわち実車テストにて「おや？」という挙動を発見
- きっと実車の環境のせいだろうという安易な理由で片付ける
- 自分はそれで本件closeとしていたが、一緒にいたテスターはそのことが気がかりだった
- 自分が、「これは車両の問題だから、もうそれ以上調査しなくていい」と言ったにもかかわらず、テスターが独自に調査を継続
- 量産前にその調査結果が判明
- 納期がヤバかった
- 再現性がなかった
- 納期が近かったので、「問題がありました」という報告を上司にしたくなかった
このような理由で、見つけた懸念を、安易に車両環境のせいにして済ませてしまいました。
今回のケースは、ソフトウェアが開発チームの手元から離れた後で発覚したとはいえ、ユーザの手に渡る前だったのが幸いでした。
もしユーザの手に渡ったあとだったら、下手したらリコール問題にまで発生していたかもなので。
このように、ユーザの手に渡る前だったとはいえ、せっかく見つけた懸念を無視してしまうことで、生産直前でバグが発覚し、関係区に迷惑をかけてしまいました。
なので、「おや？」と感じた事象は、ソフトが組まれたコードの通りに動いた結果なので、無視せずきちんと原因調査すべきだということを学びました。
「おや？」となった事象はとりあえずバグ管理表に書いておこう
これまで、開発のテスト工程において、「おや？」と感じた発見を無視せず、きちんと原因調査することが大事であることを解説しましたが、実際の開発は忙しいので、そうもいっていられないことってありますよね。
では、どうしたらよいのでしょうか。
それは、「おや？」となった事象はとりあえずバグ管理表に書いておくことです。
なぜなら、一度バグ管理表に書いてしまえば、少なくとも自分の手で、懸念があったこと事実を潰してしまうことがなくなるからです。
具体的に解説していきます。
バグ管理表に優先度をつけて管理する
実際の開発をしていると、今回解説したような、「おや？」と思ったがすぐに再現しないような懸念よりも、目の前の作業を片付けるのに手一杯であることって多いですよね。
それでもどんどん見つかる懸念点。
なので、見つけた懸念点は、優先度をつけて対応するしかないのかなと。
なので、
- 「おや？」という事象発見
- とりあえずバグ管理表に記載
- 優先度を振る（低優先となるでしょう）
- あとからでもいいので分析
実際はこんな流れになるのかなと。
とはいえ、このように、一度バグ管理表に書いてしまえば、どこかでその事象について検討をする機会を作らざるを得ないので、それが結果として、流出バグを防ぐことになるのではないでしょうか。
なので、懸念をバグ管理表に記載した際は、優先度を合わせてつけて管理するようにしましょう。
キレイごとを並べても仕方ないので、やり切れるやり方を見つけて対処しよう
「気になったことはしっかりと確認しましょう」
「細かいことでもそれがバグにつながるので、見つけた時点できちんと検証しましょう」
など、キレイ事を並べるのは簡単ですが、実際の開発現場ってドロドロしてますよね。
「そんなんわかってる。でもそれどころじゃない！」
コレ、エンジニアとして非常によくわかります。
今回書いたような事象もそうです。
なので、些細だと感じるような懸念点でも、
- とりあえずバグ管理表にかく
- 優先度つけて、後から検証
まずはこれらのように、「やり切れるやり方」で対処することで、流出バグを防ぐようにしましょう。
今回は以上です。