えいやでバグ修正したらとんでもないことになった話（2023年5月振り返り）

※走り書きなので、内容薄い部分あるかもです。ご容赦ください。
改めて追記するかもです。

この記事は？

2023年5月に思ったこと（起きたこと）をまとめます。
僕の反省の振り返り（思い出話）をしつつ、皆さんのヒヤリハットな的ものだったり、皆さんの気づきに繋げて貰えればと思っています。
2023年5月は、フィールド障害もなく、大きなリリースもなかったので、
ヒヤヒヤすることもなく、ピリピリすることもなく、平和な日々が過ぎました。
そんな中でも、起きたことは・・・

優先度の低いバグを修正したら、重篤なデグレードが発生。それも開発期間終盤に。

【何が起きたのか】
簡単に時系列で紹介します。
まず、今回の話の前提
・結合テスト工程での検出。
・実装が遅延した煽りを受けて、結合テスト実施もスケジュールがカツカツな状態。
・ただし、バグ検出状況は落ち着いている。影響が大きいバグも出ていない。
で、具体的には、
 1. 結合テスト期間終盤にバグを検出した。
 ↓
2. そのバグは、発生条件がレアケース（特定の条件でしか発生しない）。
↓
3. 簡単に修正できると判断し、バグ修正を実施。
↓
4. 修正範囲が、実は他APIに影響していた。
↓
5. バグ修正をした結果、メインの機能が動作しなくなった（デグレードが発生した）。

【何が問題だったのか】
問題としては、主に以下の2つかなと考えています。
1. バグの優先度判断（本当に今、修正すべきなのか）を見誤った。
2. 影響範囲の確認が甘かった。

バグの優先度判断（本当に修正すべきなのか）を見誤った。
・そのバグがフィールドでユーザに迷惑をかけるのか、そのバグが起きるとどうなるのか
・修正の難易度とコスト（ここを見誤った）
・期間的なリスク（修正の難易度とスケジュールを見誤った結果（簡単にできると判断した結果）、期間的なリスクの考慮も甘くなった）
振り返ると、そのバグは正直、急いで修正しなくてもよかった（一部のユーザにしか使われない機能、特定の条件でバグは発生するが機能自体は動作する）バグでした。
また、結合テスト期間終盤でのバグ検出でしたが、スケジュールとデグレードのリスクの考慮が不十分でした（簡単に修正可能という認識が先走り、考慮する前に判断を下した）。

影響範囲の確認が甘かった。
バグ事象に集中し過ぎてしまし、影響範囲の確認が不十分な状態でした。
結合テスト担当チームには納期のプレッシャーも相当かかっていたと思います。
デグレード原因のほとんどは、影響範囲確認漏れかなと思いますが、
今回、まさにそれを引いてしまいました。。。
リリース前にデグレードを開発内部で検出できたことが不幸中の幸いと言ったところでしょうか。
デグレードが絶対に許されない時とかは、バグ修正の際は、影響する範囲、パターンを全て書き出す（因子水準表とか）くらいしてもいいかなと思いました（工数見合いもありますが）。

【QAエンジニアとして何をしたか】
結合テスト期間の後に、QAエンジニアによる総合テスト工程があるのですが、気をつけたこととしては、以下です。

・デグレードが発生したからと言って、過剰品質になるレベルでのコスト投入はしない。
仮に他のデグレードがあったり、結合テスト（前工程）までの見逃しバグがあったとしても通常のリグレッションテストでカバーできる範囲だったため、追加の強化的なリグレッションテストは実施しませんでした。

・総合テスト実施開始を早める（結合テスト実施と並行で実施する）
他にデグレードが発生していないかや拾いきれていないバグがないかを確認するために、一部総合テスト（リグレッションテスト）を先行して結合テストと並行で実施をしました。
（プログラムにこれ以上の修正が入らない見込みを確認後に、リグレッションテスト開始です。）
もちろん最終的な確認等は、結合テストの結果が問題ないことを確認後に実施です。

【まとめ】
ソフトウェア開発の中では、以下の鉄則があると思っています。
・バグ０件でのリリースは不可能
・アップデートによるバグ修正が可能

これを元に、特に開発期間終盤は、バグ修正をするのか否かの確認が重要になってくると改めて実感しました。
影響範囲の特定もバッチリで簡単に修正できるから修正してしまうというのも１つの手としてありかなとは思うのですが、
・そのバグがユーザにどこまで影響を与えるのか
　ユーザが困る内容なのか
　そのバグが残ることで何が困るのか
　そのバグを修正することで誰が喜ぶのか（ユーザにどんなメリットがあるのか）
・リリースまでの期間を見て、バグ修正とテストにバッファを含めた十分なスケジュールがあるのか
を意識する必要があるのかなと思いました。
　また、ソフトウェア開発の世界では、バグを修正しないという判断もありなんだなと改めて考えさせられました。
これまでも、コスト面を考慮したり、デグレードのリスクを考えて、あえて修正せずにバグを許容してリリースやバグがあること前提でのサービス運用を実際に行なっていはいたのですが、今回の件で改めて実感しました。
（ハードウェアの世界では一度出荷したら修正は不可なので、全くの別世界ですが、）

以上、2023年5月の振り返りということで、5月に起きた出来事の中からインパクトが大きい話をさせていただきました。
個人によって捉え方や考え方が違ってくる部分もあるかと思いますが、一意見、考え方として見て頂ければ幸いです。
では。