障害内容をわかりやすく効果的に伝えるための 3 つのポイント
概要
開発者にバグの内容を的確に伝えてることで、対応コストの削減につとめましょう。以下の 3 つのポイントが重要です。
- 障害の内容 (エラーメッセージなど) を具体的に記述
- 本来の期待する動作を記述
- 再現手順を記述
障害管理表には、大きく分けると 2 つの目的があります。 1 つめの目的は、「管理」です。発生した障害自体を管理するため 2 つめの目的は、「障害の現象を確認して修正するため」です。この記事では、後者の目的を達成しやすくするため、障害内容をわかりやすく記述する方法について説明します。
開発者に障害内容を正しく伝えることができれば、障害の修正が容易になり、開発速度が向上します。
障害の内容 (エラーメッセージなど) を具体的に記述
障害の内容は、具体的であればあるほど相手に伝わります。「エラーが発生した」とだけ記述するのではなく、実際に発生したエラーの名称などを参考情報として「コピー」しましょう。そのときのキャプチャがあればベストです。
開発者はエスパーでないため、具体的な記述がないとあなたが行った操作によって実際に何が起こったのかを知ることが出来ません。詳細に書くのは面倒ですが、最終的には時間節約のポイントとなるので、出来るだけ詳細に書きましょう。
本来の期待する動作を記述
本来の期待する動作は、修正時に役立ちます。障害の概要に「クリックしたら白い画面がポップアップした」と書いてあっても、ではどのように修正すればよいのか、それだけではわかりません。上記に続けて、「本来なら灰色の画面がポップアップするべき」など簡単に書いていれば、間違いを理解しやすくなります。
場合によっては、開発者が正しい仕様を誤解している可能性もあります。そのような場合にも、本来の期待する動作を記述することは有効です。少なくとも、正しい仕様へのリンクを書くなど、記述コストと効果のバランスを考えましょう。
再現手順を記述
開発者が障害を認識したとき、次はその障害を再現しようとします。バグを修正するには、何度もそのバグを実行しなければなりませんので、再現手順がわからなかったり、ランダムに問題が発生したりする場合、修正が困難になります。
開発者は、再現手順がわかれば非常に安心します。そして、修正スピードも速くなります。多少の手間で格段の効果が得られますので、再現手順は是非書き加えましょう。
終わりに
今回はいつもと趣向を変え、「障害内容をわかりやすく効果的に伝えるための 3 つのポイント」と題してお伝えしました。実は、もっと書きたいことはたくさんあるのですが、あまり無駄に長く書かずポイントのみを伝えたかったため、説得力が低い文章になってしまったかもしれません。
しかし、この 3 つのポイントの大切さは紛れもない事実です。逆に言えば、これら3つのポイントが押さえられていない障害報告は、開発者にとって扱いにくいものとなり、最悪の場合、無視 (もしくは再現不能や保留など) される恐れすらあります。
是非とも効果的な報告の仕方を身につけ、会社だけでなくフリーウェアやオープンソース作者にも障害報告を行っていきましょう。障害の多いソフトウェアでも、その報告と修正がうまく実施されればよいものになっていきます。たとえプログラムが書けなくとも、『障害報告」という形で開発に関わるのもおもしろいと思います。皆さんでいいソフトウェアを作りませんか。
