【体験談】エンジニアが流出バグを出したらどうなるか【対応は地獄】
こんにちは、カズキです。
自分は先日こういったツイートをしました。
エンジニアの仕事の中でも最も嫌なのって、流出バグの対応かなと😔 ・まわりの視線 ・時間ない中での設計、検証 ・他チームメンバからの増員対応に🙇 ・上司からの説教 ・関係区への説明と🙇 ・客先への🙇 ・なぜなぜ分析 ・再発防止案の作成 ・ソフトの書き換え対応 羅列するだけで気分が😔😔😔
エンジニアとして、流出バグを出すとほんとにきついんですよね。。。
今回はこの件について深堀りしていきます。
これまで複数回の流出不具合を経験。また、テスト工程で見つけられた不具合も多々あり。これら苦い経験を糧に、日々開発業務を行っている。
【体験談】エンジニアが流出バグを出したらどうなるか【対応は地獄】
エンジニアが流出バグを出した場合のその後の対応の流れはこんな感じです。
- 客先からの不具合連絡で青ざめる
- 自社の環境にて再現テスト実施で不具合確定
- コードの修正作業に入る
- 修正後、テスト実施
- 関係区への説明とゴメンナサイ
- なぜなぜ分析
- 再発防止策をたてる
- 客先に報告＆ゴメンナサイ
なお、ここで紹介するのは組み込みシステム開発における流出バグの話となります。
Web系やシステム系とは少し実態が異なる部分がありますが、おおよその流れは同じかと。
客先からの不具合連絡で青ざめる
流出バグや不具合の連絡は、突然やってきます。それは、大体が客先からの連絡。
と、いうのも、
と、ある程度予測をつけた上で客先も連絡してくるからです。
この時点で青ざめます。
自社の環境にて再現テスト実施で不具合確定
とりあえず、不具合事象が再現するかを自社のテスト環境にてチェックします。
ここで再現しなければ、他のシステムが原因である可能性もでてくるので。
しかし、ここで不具合事象が再現できたら、それは今回の不具合は、自社システムの不具合であることを意味します。
こうなった際はいろいろと覚悟を決める必要がありますね。。。
コードの修正作業に入る
不具合があることが判明しましたので、ここからコードの修正に入りますが、行動の修正の前には、通常の開発時と同様、もちろん設計をする必要があります。
この時、きついのは時間軸。
何せ、すでにユーザの手に渡っている製品やサービスが当たっているのですから、流暢に時間をかけるわけにはいきません。
また、設計、コード修正をしてからは、テスト作業が控えているので、そういう意味でもここであまり時間をかけるわけにいきません。
なので、ここは本当に超特急で終わらせる必要があります。
修正した内容はすぐにまた市場に出回ることになるので、できればじっくり考えたものですが、残念ながらそういうわけにもいかないのが現状です。
修正後、テスト実施
修正したコードがきちんと修正されているかについてテストをおこないます。
そして、それと同じ位大事なのが、影響範囲のテスト。
というのも、今回のコード修正により、
- 修正箇所の確認はオッケーだった
- しかし、その修正により、もともと正しく動いていたところが動かなくなってしまった
と、いうことになる恐れがあるからです。
この確認も、通常の開発でももちろん行うのですが、先ほども述べた通り、これを時間がない中でやるので、結構な作業負荷となります。
関係区への説明とゴメンナサイ
コードを修正し、その確認も終わる位で、関係区への説明の準備をし始めます。
関係区と言うのは、主に工場などの、生産に関わる部署となります。
- 不具合のあった製品やシステムの改修
- 工場へ生産停止の連絡
これらを行います。
そして、どういう不具合が発生して、どういう風に修正したなどの説明資料の準備を行います。
なぜなぜ分析
これは組み込みシステム業界特有のものかしれませんが、今回発生した不具合について、その原因を深掘りしていく分析のことです。
例えば、
↓なぜ
設定の説明を説明資料にきちんと書いていなかったから
↓なぜ
現場の記載で担当者にも伝わると思っていたから
↓なぜ
詳細な説明を書く時間がなかったから
こんな感じで、不具合を出してしまった原因を1個ずつ深掘りしていく分析です。
これがまた辛い。
というのも、たとえば不具合の原因が単なるポカミスであっても、いわゆる精神的な内容の記載が一切できないからです。
例えば、疲れていたのでついミスをしてしまったとしても、それがたとえ事実だったとしてもかけません。
再発防止策をたてる
二度と同じミスをしないための再発防止策を求められます。
これもまた辛い。というのも、再発防止策は、大体が仕組みとして落とさないといけないので、
- チェックリスト追加
- 手順書の作成
これらが発生することで、以降の開発には開発のテーマがよりかかってしまいます。
なので、再発防止策を立てる事は、結果として、他の開発者にも迷惑がかかってしまうのです。
客先に報告＆ゴメンナサイ
これまで作業した、
- 不具合内容の説明
- コード修正内容
- 不具合の発生原因
- 再発防止策
などを客先に報告します。
この時地獄になるか否かは、客先のメンバーによります。
と、いうのも
- 開発の時にいつもやりとりをしていた担当者の場合：大体がなんやかんやでその人も社内で怒られている可能性が高いので、こちらに対してあまりきついことを言ってこないことが多い
- 普段自分がやりとりしている担当者の人の上司：基本初対面なので、なんの遠慮もなくキツイ言葉をぶつけられる
こんな感じになりそうなので。
普段の開発を全力でやることで、流出バグや不具合を防ごう
これまで、流出バグや不具合を出すとどうなってしまうのかを、体験談ベースで解説しましたが、こうならないためにも、普段の開発を全力でやり、流出バグや不具合を防ぐようにしましょう。
なぜなら、解説した通り、流出バグや不具合を出すと、プライベートも削られるし、仕事も行きにくい上に、精神的に参ってしまうからです。
そうならないためにやることはたくさんありますが、ここでは大きく下記２点を解説していきます。
- 多眼チェックをしてもらおう
- だれの指摘であれ、有益な指摘なら前向きに検討しよう
多眼チェックをしてもらおう
人間はどうしてもミスしてしまうものです。
あくまでたとえですが、めちゃくちゃ仕事ができる人でも、
- 通常時：100%の力で作業できる
- 風邪をひいたとき：60%の力しか出せなくなる
こんな感じとなるので、風邪をひいたときに実装したコードにバグを仕込んでしまう可能性も大いにあるのです。
なので、自分1人で不具合を防止すると言うのが実質不可能に近いのです。
ではどうするか、それは、自分がミスしてそれがそのまま流出しないような仕組みを作るしかありません。
そのためにはやはり多感チェックがいいのかなと。
他人にチェックしてもらうことで、自分では気づかないところに気づきを得ることができるからです。
なので、多眼チェックのように、一人のミスは組織でカバーするような体制だと、流出バグや不具合は発生しにくいのかなと。
だれの指摘であれ、有益な指摘なら前向きに検討しよう
例えばコードレビューのとき、こんなことありませんか
- 自分が嫌いな人からの指摘
- あまり仕事ができない人からの指摘
こういうとき、むっとくるのはよくあることですが、仮にそれが有益な情報だった場合は、前向きに検討するにしましょう。
というのも、言うまでもなく、その指摘により、結果として流出バグを防ぐことができる可能性があるからです。
なので、
- ×：だれが言ったか
- 〇：なにを言ったか
という考え方で、だれの指摘であれ、有益な指摘なら前向きに検討するようにしましょう。
開発に少しでもお金をかけよう
開発にはあまりお金をケチらないようにしましょう。
例えば、
- 出張にいくのをめんどくさがる
- 外注しないで無理やり社内で対応する
こういうことをした場合、結果として外注費や出張費は確かに浮きますが、仮にそれが原因で流出バグや不具合が発生した場合、その時にかかるお金は、出張費だの外注費だのの比ではありません。
と、いうのも、製品の回収費、ソフト書き換えのための対応費など、莫大なお金がかかるからです。
このような費用に比べれば、たとえば外注費、出張費のような開発のお金なんて安いもんですよね。
なので、開発にはあまりお金をケチらないようにしましょう。
今やっていることを確実にやっていきましょう
と、いうことで、エンジニアが流出バグや不具合を出した場合にどうなるかを体験ベースで解説しました。
やはり不具合対応ってのは嫌なものですが、エンジニアに確実にまとわりついてくるものです。
なので、今やっているその作業を、確実にやっていくようにしましょう。
今回は以上です。