火消しプロジェクトなので、毎日数十件というバグが出ていた。
BTSのようなシロモノはなく、Excelでの障害管理表という(悪い意味での)一般的なバグ管理だった。
しかし、そこに書かれているのはバグの内容ばかり。
ああ、わかっていない。
エンジニアにとって、重要なのはバグの内容でもなければ、コードを書けもしない人の原因の推測でもない。
バグの再現手順だ。
再現さえできればバグの内容なんてすぐに把握できる。
だからバグの内容なんて1行程度の概要だけでいい。
でも再現手順がなければそのバグを再現するだけで相当の工数がかかる。
たとえば、どんなユーザーでログインしたのか？
どんな画面遷移をしてその画面に行くのか？
どんなIDのデータなのか？
画面上でどんな操作をすればバグが出現するのか？
こういったことが記述され、すぐにでも再現できればバグの修正コストは相当低くなる。
そもそもの話で、管理表にバグを記入した人は、そのあとバグを修正する人が「記入した内容で何をするのか？」ということを考えなければならない。
バグを修正するためには、バグを再現して原因を追究しなければならないし、修正後に同じ手順でバグが発生しないことを確認しなければならない。
おのずとバグの再現手順が必要であることに気づく。
これはバグ管理に限ったことではなく、設計においても、プログラミングにおいてもそうだ。
自分の成果物によって、次の人が何をするのか、次の人が作業を楽に進められるためにはどういう形で成果物を作成する必要があるのかを考えなければならない。
真の意味で仕事とはそういうものだと思う。
システム開発では、自慰行為の「仕事」が多すぎる。
