不具合の定義

| Comments

お客さんなどから不具合を報告された場合に、なんでも優先度マックスでがむしゃらに対応するのは考えものではないかと。

個人的には、バグ自体が悪いのではなくて、お客さんや今後の開発に悪影響を与えることが悪いと思っています。

つまりは、そんなに影響ないのであれば無視すればいいのです。

不具合のパターンとして大きく3つあるかなと思っていまして、

実装ミス

テストがちゃんとできていなかったことが原因で、実行時エラーが出るパターン

「未記入だとぬるぽで落ちる。」「強制終了した」などの一般的なバグ。

UIが悪い

作ってあるものの、お客さんに理解してもらえず活かせてないパターン。

「実行ボタンが見つからない」「画面が止まった(実は裏で超計算してる)」とか。

仕様漏れ

そもそも観点から漏れてた。

「ここで帳票出したいんだけど」「20kBまでしか添付できないとか。。」


などなどあると思います。

それらについて、

  • なぜ困るのか。
  • 修正にどのくらいコストがかかるか。

を考えることが重要かなと思ってます。

ざっくり言うと、放っておいた場合、

  • 実装ミスは、お客さんに注意してもらう必要があることと、後任の開発者が混乱すること
  • UIは、お客さんにUIを理解してもらうことと、担当者が説明すること
  • 仕様漏れは、他の運用で回避すること

がコストになると思います。それらと修正コストを比較して、 直すほうがメリットが大きい物から順に修正していくとハッピ−になれるんじゃないかと思ってます。

Comments