QA組織に不具合分析の仕組みを導入したお話 - エス・エム・エスエンジニアテックブログ

はじめに

介護事業者向け経営支援サービス「カイポケ」でQAを担当している中村です。今回の記事は少し前の取り組みなのですが、私が導入を推進した『不具合分析』について紹介したいと思います。真新しい取り組みではないのですが、本記事を通じてエス・エム・エスのQA組織のことを少しでも知ってもらえれば幸いです。

不具合分析の導入

導入の経緯

私が入社した当初、不具合分析の導入をQA組織として目指していたのですが、日々の業務に忙殺されてそこまで手が掛けられていない状況でした。前職時代に不具合分析の経験があったのと導入へのモチベーションが高かったので、志を同じくする有志のメンバーを募って導入活動を推進していくこととしました。次項からは実際の導入フローに沿って順に説明していきます。

導入時にやったこと

① 不具合のデータ化

「カイポケ」では不具合管理システム（バグトラッキングシステム）にJira Softwareを使っているのですが、その当時は記録に残すことや開発チームとの情報のやり取りが主な使用用途でデータとしての管理ができていませんでした。そこで、まずは不具合をデータとして活用するために、以下のカスタムフィールドを追加して分類毎にデータを収集できるようにしました。

カスタムフィールド一覧）

分類	説明
テストフェーズ	不具合を検出したテストフェーズを分類例）DEVテスト、STGテスト、本番テストなど
不具合種別	不具合の種別を分類例）新規、既存など
検出種別	検出した不具合の内容を分類例）機能不備、レイアウト不備、性能、ユーザビリティなど
検出分類	不具合を検出した経路を分類例）QAテストケース、QAテストケース外、開発など
原因分類	不具合が混入した原因を分類例）仕様理解不足、仕様検討不足、コミュニケーション不足、コード実装不備など

② 不具合データ集計の仕組み化

次に収集したデータを集計&グラフ生成するためのツールとしてGoogleスプレッドシートを選定しました。Jira Softwareのダッシュボードも検討の対象にあがったのですが、2次元でのグラフ表現や期間指定が思ったようにできなかったので除外となりました。

Googleスプレッドシートでは以下の仕組みで集計&グラフ生成をしています。

Jira Softwareの不具合情報をdataシートに取得
- データ更新は手動で実施すると手間がかかる部分なので、Googleのアドオンである「Jira Cloud for Sheets」を使って毎朝自動でデータが更新されるようにしています。もちろん最新のデータが必要な場合は手動での更新も可能です。
集計シートでdataシートのデータを集計
- 集計はチーム毎、案件毎、期間毎を指定できるようにして集計範囲の自由度を高めています。もちろんチーム毎＋案件毎、チーム毎＋期間毎といった複数の要素を組み合わせての指定も可能です。
グラフシートで集計シートの内容をグラフ化
- カスタムフィールドの分類毎の集計はもちろん、任意のカスタムフィールドを2つ指定して自由度の高い2次元集計を可能にしたことで、より分析の精度を高められるようにしています。

改めての説明ですが不具合データ集計の全体像は以下の通りで自動で行っています。

不具合チケット作成時にカスタムフィールドを入力
毎朝8:00にデータを取得
データを集計&グラフ生成

③ 不具合分析資料のテンプレート化

QA組織のメンバー全てが不具合分析の経験があるわけではなかったので、導入のハードルを下げる、一定品質のアウトプットが出せる、といったことを目的に不具合分析資料のテンプレートを情報共有サービスのesaを使って作成しました。テンプレートにはいくつかのグラフサンプルと分析のポイントを記載していて、テスト中のモニタリングや、テスト終了後のふりかえりでも使えるようにしてます。

テンプレート記載内容一部抜粋）

導入後のお話し

どう活用している？

現状は不具合が多く検出されたプロジェクトや案件を対象に、テスト終了後に不具合分析実施して良かった点や悪かった点がないかを確認するといった、ふりかえり目的での使用が多いです。不具合分析の結果からテストの優先度を検討する上で参考にしたり、開発/テストプロセスでの課題を可視化することができたり、といった一定の効果も見られています。また、不具合分析として活用する以外にもデータとして可視化することで全体の傾向が把握できるなど、QA組織全体で不具合に対する意識が高まったと感じています。

優先度検討の例