QA組織に不具合分析の仕組みを導入したお話

はじめに

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

不具合分析の導入

導入の経緯

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

導入時にやったこと

① 不具合のデータ化

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

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

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

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

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

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

  1. Jira Softwareの不具合情報をdataシートに取得

    • データ更新は手動で実施すると手間がかかる部分なので、Googleのアドオンである「Jira Cloud for Sheets」を使って毎朝自動でデータが更新されるようにしています。もちろん最新のデータが必要な場合は手動での更新も可能です。
  2. 集計シートでdataシートのデータを集計

    • 集計はチーム毎、案件毎、期間毎を指定できるようにして集計範囲の自由度を高めています。もちろんチーム毎+案件毎、チーム毎+期間毎といった複数の要素を組み合わせての指定も可能です。
  3. グラフシートで集計シートの内容をグラフ化

    • カスタムフィールドの分類毎の集計はもちろん、任意のカスタムフィールドを2つ指定して自由度の高い2次元集計を可能にしたことで、より分析の精度を高められるようにしています。

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

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

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

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

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

導入後のお話し

どう活用している?

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

優先度検討の例

  • 重大な不具合(ユーザー影響が大きい)が検出されない機能は優先度を下げる

開発/テストプロセス課題可視化の例

  • 単体テストで担保すべき不具合が多く単体テストの範囲や粒度に問題があった
  • 機能仕様検討不足やコミュニケーション不足が多く情報共有に問題があった

今後の課題は?

導入はしたものの、以下の課題は見えていて積極的な活用とフィードバックや情報発信が必要になると考えています。

  • 一部のチームでしか活用できていないのでもっと範囲を広げたい
  • 開発組織全体で不具合に対する意識が高まるようにしたい
  • プロセス改善や品質改善につながるような効果を出していきたい
  • 品質のモニタリングとしての活用をしていきたい

さいごに

今回紹介した「不具合分析」は、QA組織の行動指針の中でも挙げている取り組みの一つとなります。そちらのブログも合わせて確認していただけると、QA組織の目指しているものがより鮮明に見えると思うので、お時間あれば是非ご確認ください。

tech.bm-sms.co.jp

これからプロダクトもどんどん成長していき、それに伴い一緒に働く仲間もどんどん必要になってきます。少しでも興味を持っていただけましたらカジュアル面談や選考へのご応募をよろしくお願いいたします。