不具合分析始めました - SPIDERPLUS Tech Blog

皆様、はじめまして。品質管理チームのいのっちです。

ソフトウェア開発プロダクトにおいて、品質の維持と向上は非常に重要です。そのためには、不具合の早期発見と効果的な是正処置が必要不可欠です。
品質保証・品質管理の活動をより強化するため体制変更された品質管理チームでは、お客様からのフィードバックや開発工程で検出される不具合について、より詳細な分析をおこなうための取り組みを始めました。
このBlogでは今、進めている不具合分析活動について内容を共有したいと思います。

なぜ不具合分析が重要なのか？

すでに不具合分析をされている方やそんなの知っているという方には言わずもがなですが、不具合分析はソフトウェアの品質を高め、リリース後の問題を減少させるための重要なステップで、下記のような効果が考えられると思います。

根本原因の特定
不具合の発生原因を明らかにし、同じ問題が再発しないように対策をおこなうことができる。
品質の向上
不具合を早期に発見し修正することで、製品の品質を高め、ユーザーの満足度を向上させることができる。
コスト削減
不具合を早期発見することで、修正コストを低減し、開発全体のコストの削減ができる。

不具合の分析の次のステップ

不具合の収集
開発プロセス中に検出された不具合、お客様からのフィードバックなど、これまでBacklog、GitHub、他ツールなどに分散していた情報を、Backlogへ一元集約し管理することにしました。
不具合ランクの設定
発見された不具合の症状に基づいて、不具合の重みづけのための不具合ランクを設定しました。
※不具合改修の優先度を管理するステイタスはありました。
原因の特定
これまで入力項目として設定はされていたが、任意項目となっており十分な情報が入力されずに、不具合処理が完了処理されていた為、不具合ごとに、詳細な原因を分析するために、混入原因、流出原因の記載を必須項目としました。
また、修正にともなう影響範囲の記載内容や、なぜなぜ分析の手法を用いて問題の根本原因を明らかにし改善施策をおこなう活動をあらためて開始しました。

※なぜなぜ分析については参考↓
https://www.ipa.go.jp/archive/files/000071988.pdf
原因分析からの解決策の策定
混入原因、流出原因にもとづき、解決策を検討を進める活動を開始しました。
不具合修正とテスト
不具合改修時のテストフローと責任範囲を見直し、単体・結合テストの観点について品質管理レビューをおこない、開発者でのテスト・影響範囲の分析結果にもとづいた影響範囲の確認をテストチームがおこなうフローとしました。
また、リリースにあわせてシステム全体への影響確認ができるように、メンテナンスされていなかったリグレッションテストの再構築を進めています。

中間成果と課題

単体・結合テストについて、品質管理レビューをおこなったことで、観点漏れの指摘から仕様の不整合や仕様考慮漏れなどの検出ができており、テストチームでの受入テスト前に課題の検出をおこなうことで手戻り工数の削減ができています。
一方で進めていく上で、課題もいくつか浮上しています。

リソースの確保
不具合分析、レビュー、テスト設計には時間とリソースが必要です。
我々のプロダクトでは、日々発生する問題への対応や不具合分析以外の活動もあり、品質管理チームでは十分なリソースを割くことが難しい状況があります。
リソースの改善に向けては、プロダクトを理解しているメンバのサポートや、中期視点ではメンバのOJTをおこなっていく予定でいます。
継続的な改善を進めていく難しさ
不具合分析を継続的におこなうためには、組織全体での意識改革とプロセスの見直しが必要です。
見直しを始めたはじめたばかりですので、活動が定着化するまで、記載内容のモニタリング、修正をはじめ、チーム、個人が不具合分析がなぜ必要かを理解して取り組めるように定期的にフィードバックをおこなっていきます。

まとめ

不具合分析は、ソフトウェア開発において品質向上とプロジェクトを円滑に進める上でとても重要なプロセスです。
品質管理チームでは、ある出来事をきっかけに、不具合分析による継続的な改善を進めるべく動き始めました。その出来事については、まだまだまとめる必要がありまして、第二弾の記事で諸々お伝えできればと思っております。