バグを直したその後に

引き続き、ソフトウェア開発現場の七不思議について。

> 2. 同じバグを何度も繰り返し発生させている。

日々上がってくるソフトウェア開発の障害レポートを見ていると、「よくこんなバグが見つかったな」と感心するようなものがある反面、「似たような問題を見たことがあるぞ」と既視感を覚えることも多い。プロジェクトは違う、時期も違う、担当者も違う、だけど問題の本質は同じというものだ。

開発担当者として、とにかく目の前に積み重なっているバグを直すことが最優先の作業になるけれど、バグが直ったら全ての仕事が終わったかのようにきれいサッパリ忘れてしまう人が少なくないようだ。しかし、一つのバグが発生した原因は何なのか、とことん真因を追求して対策を講じておかなければ、また同じ不具合が発生してしまうことになる。例えば、最初のアクションとして、こんな作業が必要になるだろう。

• 要求漏れの場合：要求分析担当者にクレームを投げて対策を求める。
• 仕様書の記載ミスの場合：レビュー時のチェックリストを確認し、必要に応じてリストを修正、追加する。
• 単体テスト漏れの場合：テストを追加し、リリース時のカバレッジの確認状況はどうだったのか記録を確認する。
• リリース手順に問題がある場合：作業手順書を見直したり、関連スクリプトに問題がないか確認する。

地道な作業が必要だが、本質的な問題点を改善していかないと、いつまで経ってもソフトウェアの品質は向上しない。ソフトウェア開発のプロを目指すのなら自分の作業を改善し、開発のリーダならグループ全体として取り組むことが必要だろう。障害管理表（tracならチケット）は改善活動のネタの宝庫と言える。ソフトウェアの品質は、ある日突然大きく向上することはあり得ない。一つ一つの作業の積み重ねが必要だと思う。