皆さんこんにちは。今回は、Ｓｋｙスタイル部で取り組んでいるシステムの品質の見える化（不具合管理）についてご紹介します。Ｓｋｙスタイル部は、社内基幹システムの構築・管理・運用を通じて業務効率の向上や情報の安全性を確保する組織です。現在、品質をデータで評価できるよう、不具合チケットのフォーマットやワークフローの統一を進めています。これにより、品質の測定や改善箇所の特定が期待されています。
Ｓｋｙスタイル部で開発しているシステムの品質の見える化（不具合管理）への取り組み（現在進行形）について紹介します。Ｓｋｙスタイル部とは社内で利用する基幹システムの構築・管理・運用を通じて、業務効率の向上や情報の安全性を確保する組織です。
背景
Ｓｋｙスタイル部で開発しているシステムの品質について、良いのか / 悪いのかは、感覚でしかわからない。品質についてデータで語れるようにしたい。
現状
Ｓｋｙスタイル部では多くのチーム、プロジェクトがあり、不具合チケットもそれぞれで独自のフォーマットやワークフローが設定されているためデータの収集が困難。
改善
まずは以下について改善していくように進めています。
- 不具合チケットのフォーマット / ワークフローの統一
- 不具合チケットの登録粒度の統一
フォーマットの統一
開発の負担が大きくならないレベルで、必要最低限の情報の記載が行われるように、以下の項目を必須条件としたフォーマットに変更。
-
影響度
S：極めて重大な影響を与える不具合（システムダウン、データ損失、セキュリティ問題 など）
A：重要な機能に影響を与える不具合（主要な機能が使用できない、業務に大きな支障を来す など）
B：一部の機能に影響を与えるが、回避策が存在する不具合（特定の条件下で発生、一時的に回避できる問題 など）
C：影響が軽微で、業務にほとんど支障を来さない不具合（表示の誤り、軽微なUIの問題 など） -
発生フェーズ
リリース前 / リリース後 -
混入フェーズ
要件定義 / 設計 / 実装 / テスト / リリース作業 / データパッチ作業 -
不具合種別
新規 / 潜在 / デグレ
登録粒度の統一
次に、各チーム / プロジェクトで不具合チケットを登録するタイミングがバラバラだと偏りが出るため、不具合チケットを登録するタイミングについて以下のように定義しました。
-
本番リリース前（dev環境やstg環境）に見つけた不具合
→ 「発生フェーズ：リリース前」として登録をする -
本番リリース後に見つけた不具合
→ 「発生フェーズ：リリース後」として登録をする
期待する効果
不具合チケットの数から品質を測れるようにすることを期待していますが、このレベルの統一でも改善箇所の目星をつけるところまではできるかと期待しています。
例
-
リリース前に見つけた不具合より、リリース後に見つかった不具合の方が多い場合
→ リリース前の動作確認が足りていないのでは？ -
影響度の高い不具合が多い
→ ユースケースを洗い出せているか？
最後に
不具合管理の統一は始めたところなので、今後情報が蓄積され、データの分析によって改善していくべきシステムが見えてくるようになると、この取り組みの効果が感じられるようになるので楽しみです。