不具合分析はじめました
2021年02月26日
QAチームでは半年ほど前から不具合分析を始めました。
なぜ不具合分析？
不具合の要因を分類しその傾向を探ることで、その対策が立てられるのではないか？
対策が見つかれば不具合が減り、全体的な品質を向上できるのではないか？と思ったからです。
不具合分析の手順
今回は初めてということもあり、以下の手順でやってみました。
不具合が起こった要因を仕様検討不足、実装ミス、デグレなどに分類
↓
優先度（最高、高、中、低、最低の5段階）でも分類
※優先度は不具合を起票したタイミングで分類していることが多いですが、再度見直し
↓
不具合要因、優先度ごとに集計
やってみた結果
こちらは不具合要因ごとの集計グラフです。
案件によって不具合要因に偏りがあることがわかります。
案件の規模や、自社サービスなのか受託案件なのか等の違いもあるのですが
どのような開発プロセスを経たのかによって違いが出ているように思います。
B案件は一見、実装ミスが多かったように見受けられますが、逆に言えば設計段階での不具合がとても少ないとも言え、開発プロセスの設計工程がとても上手くいっていたということがわかります。
不具合分析というとどうしても後ろ向きなイメージを持ってしまいますが、案件ごとの良かった点を共有して前向きな改善に繋げていこうとしています。
また、こちらはA案件での優先度「最高」「高」のみに絞った集計グラフです。
先ほどの集計グラフとまた違った視点から分析することができます。
これらの結果から不具合を減らすために何か対策できることはないかを、QAチームだけでなく、全員で考えていこうとしています。
品質を高く保つにはQAチームだけでなくメンバー全員で取り組まないといけないということを認識してもらえたように思います。
今後は
分析した結果から改善できる点を洗い出し、次の案件で取り入れていこうとしています。
取り入れた結果どう変わったか、というのも分析してみたいです。
また、定期的な不具合分析会も実施していけたらいいなと思っています。
関連記事を見る
この記事を書いた人
2021年02月26日
記事のカテゴリ：Webシステム開発
STAFF募集
求人採用のお問い合わせ、ご応募はX（旧Twitter）とFacebookでも随時受付中です。
