　不具合の情報を見聞きするとき、「知りたい」「気になる」がしっかりおさえてあると、非常に助かる。おさえてほしいポイントは以下のとおりだ。

　・不具合発生までの具体的な手順　※誰がやっても再現できる

　・その不具合は、確実に発生するのか

　・不具合を回避する方法の有無

　・不具合が起こったあと、もとの正常な状態に戻せるかどうか

　これらの情報がそろっていると、修正の優先度が決めやすい。開発者と品質管理は、無限の時間を生きてはいない。製品開発には、必ず納期という終わりが存在するのだ。可能ならば、製品発売までに不具合ゼロを達成したい。しかし、有限の時間の中でできることには限りがある。だから、物事に優先度をつけるのだ。

　不具合が起こったとき、製品がまったく動かずどうにもならないのであれば、優先度は「もっとも重要」。たとえ不具合が起こるとわかっていても、回避する方法がある、起こったあと正常な状態に戻す方法がある、となれば、優先度は「もっとも重要でない」とできる。もちろん、不具合を回避できるからといって、なんでもよしとはできない。回避方法が複雑にすぎれば、それは「回避できない」のと大差がない。

　不具合の修正がもっとも重要かそうでないかを判断するには、くわしい情報が不可欠だ。1件や2件を議論するのではない。50件から100件、場合によっては1,000件を超える不具合報告から、修正の優先度を決めるのだ。「知りたい」「気になる」の情報は、『どうなるのですか？』と質問を受ける前に、先回りして用意しておこう。そうすれば、納期までに修正される不具合がひとつでも増えるかもしれないのだ。あなたとあなたのチームの想像力を合わせれば、きっとできる。