分析経験がなかった私が不具合分析に挑戦してみた話

アソビュー株式会社でQAエンジニアをしている丸山です。 2023年末にアソビューにQAエンジニアとしてジョインし、約1年半になります。

昨年夏頃の記事でQA体制の変更と再始動の状況についてご紹介させていただきました。
その中で「テスト結果の履歴も蓄積ができてきて、それらを分析して各工程のプロセス品質向上のための検討が始まっています。」と書きましたが、今回はその分析についてご紹介させていただきます。
（昨年の記事はこちら：「テストエンジニアからQAへ、より高い品質を目指して」）

分析に取り組み始めた頃の状況

QA体制が刷新された2023年夏頃から1年ほどの間、私たちQAエンジニアは主にテストを中心とした品質保証活動をしてきました。しかし、全てのプロダクトに関わることは現実的に難しく、本番環境・ステージング環境それぞれで大小様々な問題が発生している状態でした。
そんな中、本番環境を含めて不具合情報については継続して情報集積をしており、2024年秋頃から集積した情報を分析してプロセス改善を行っていこうということになりました。

正直にお話しすると、私自身はこれまでテスト関連業務が中心で、不具合の集計結果の報告以上の傾向の割り出しや本格的な分析には慣れていませんでした。
アソビューでは未経験の領域に対して挑戦することを歓迎する文化がありますので、これも自分の成長の機会と思い、一から学習しながら業務に取り組んでいくことにしました。
こうした経緯の中で私が不具合分析について学んだ過程を簡単にご紹介したいと思います。

不具合情報の集積形式

不具合の分析をするにあたり、前提となる集計データについて説明させていただきます。
私が担当しているチーム内では、個別の不具合毎に以下の情報を記録し、リスト化しています。

集計項目	概要
日付	不具合が発生した（発見された）日付
開発案件	関係する開発案件
概要	不具合の概要
重大度	利用ユーザーへの影響度合い、深刻さの度合い（4段階） ※この度合いをどのように判定するかは別途基準を定義しています。
機能分類	どの機能で発生した問題か
混入プロセス	その不具合が作られたプロセス（例：仕様の取り決め、設計、実装）
発見タイミング	不具合がどの段階で発見されたか（例：開発段階のテスト、機能公開後のお問い合わせ）
流出タイミング	その問題がどの段階まで流出したのか（例：ユーザーへ公開前、ユーザーへ公開後）
不具合種別	どういった種類の不具合だったのか（例：購入エラー、表示の問題）
原因種別	問題があった技術領域（例：フロントエンド、バックエンド）

個々の項目の内容はもう少し細かく分けていますが、参考として記載しております。

不具合の分析方法

未経験で何をしていいのか手掛かりがほぼない状態、分析してみようと言われてもどこまで何をすればいいのか、全体像がわかっていません。ひとまず分析する方法について調べると、具体的な手法は色々とあるものの、主に以下の3種があることがわかりました。

統計的分析 (Statistical Analysis)：
　　過去のデータから不具合の傾向やパターンを把握する手法。
　　件数や種類別の割合をグラフ化し、客観的に捉えます。
　　記述統計や分布分析など、調べるとより具体的な様々な方法があります。

ODC分析 (Orthogonal Defect Classification) ：
　　これは原因分析にも分類されるようですが、
　　不具合を多角的な切り口（タイプ、検出契機など）で分類し、
　　開発プロセスの弱点を特定する手法です。

原因分析 (RCA)：
　　「なぜ起きたか」という根本原因を特定し、再発防止を図る手法。
　　単なる事実報告でなく、真の原因を深掘りします。

昔、資格勉強で見たような…、全然使ってこなかったなあ…。なんてことを思いながら、これらの手法の用途について調べました。
それぞれの分析手法には得意なことがあり、使い分けが重要だそうです。

統計的分析：客観的なデータに基づいて傾向を把握する
ODC分析：統計的分析と原因分析の中間的な特性があり、開発プロセス中での弱点を特定し、改善する
原因分析：個々の問題について深掘りし、根本原因を特定し、対策を講じる

これらの特徴を踏まえつつ、複数の手法を組み合わせて分析していくことになります。
社内で他のQAの方が展開していた資料では、種類別の件数や期間を通しての推移といった定量的な統計データと状況の深掘りをした定性的な情報が出ていたので、まずは定量面と定性面の情報を盛り込んだ資料を作成してみようと考えました。

それでは何から手をつけるか、です。データの数も多いので、まずは定量面での分析で大まかな傾向を掴み、件数が多いグループに絞ってから原因分析で深掘りすることにします。
調べてみたところ統計的分析に関してはヒストグラムやパレート図から作って傾向を見るのが良いということでした。今回集計元として用意しているデータはODC分析に使用できる形式で作成されていますが、統計的分析にも使用可能です。ひとまず原因の種類や発生している機能の分布等に分けて棒グラフや円グラフでの資料を作成しました。

数値資料の例
ヒストグラムは連続的な数値データを区切って表すものなので今回は使えず、棒グラフ・円グラフを使用しました。

出来上がった資料を社内のQAメンバーや開発のプロジェクトマネージャーと共有して意見を聞きながら調整していきます。
ただし、私が最初に作った資料は、集計データ内の各要素別件数が羅列されただけの資料になってしまい、見る側としてもどこから見ていいのかが分かりにくい内容となってしまいました。
その上、私自身は不具合を集計表に書き込むところから行なっているものですから、ある程度内容まで把握しているために、お互いの認識の差によって会話が進めにくい状態を作ってしまいました。
提供される側の視点が抜けており、申し訳ない気持ちになりました。

その後の話し合いで、もう少し原因に絞って比率と重大度別の件数がわかるようにしたいという要望があったので、パレート図も作成して活用していくことになりました。

この形式にすることで、原因別の件数と全体に占める割合、原因毎に内包する重大度の違いに情報が絞られて、だいぶ話がしやすくなりました。こうした調整の結果、不具合の傾向や分布はある程度見えてきます。

「どこ」から「なぜ」へ

定量的な情報がある程度出揃ってきた段階で原因分析（RCA）の考え方・手法を使って定性的な分析・原因の深掘りにも着手しました。しかし、ここでまた一つ問題に突き当たってしまいます。
定量的な分析で件数が多い原因から深掘りをしようとしたのですが、集計していた一覧では原因種別の内容が「フロントエンド実装（表示）」、「バックエンド実装（ロジック/制御）」といった形式で、「原因となった領域」に寄っていました。この情報だけでは「問題のある状態を作ってしまった原因」で傾向を捉えることが難しい状態だったのです。

原因分析（RCA）としてなぜなぜ分析や特性要因図などが有名な手法ですが、これらは「その不具合がなぜ作り込まれたのか」を探っていく手法です。集計データの段階でこの「なぜ」という点について一定のより分けができる状態にしておくことで、原因の傾向が掴みやすくなりさらなる深掘りにつながります。この時点で用意していた集計データはこの原因の傾向が把握しにくい状態でした。

品質改善の為の対策・アクションにつなげてサイクルを回していくためにも、「なぜ」問題が発生したのかを分析して根本的な原因への対策を検討できる状態にしなければならないと感じました。

例えばですが、
過去に継続して開発・改修されて仕様が複雑化した機能について、仕様情報の資料が断片的にしか残っていないので一から調べ直した。その際の調査・検討で考慮が漏れてしまっていたことで不具合を作り込んでしまった。
みたいなことって、開発現場でありがちと言えばありがちですよね。
この場合は問題が起きた機能ではなくて、考慮漏れ（さらにいえば仕様情報が把握しづらい状態だったこと）の方が本当の原因ではないでしょうか。そうした要因を集計にも反映できるようにしたかったのです。

この点については社内の他のQAメンバーも同じ課題感があったようで、共通の集計項目として調整を行いました。原因種別に「仕様理解・要件定義の問題」、「設計ミス・考慮不足」、「テスト・影響分析の不足」などといった技術領域以外の状況やプロセス面の原因も拾えるように、集計時の入力内容を変更していきました

このように手がかりとなる傾向を拾えるようにデータのより分け方法を調整、問題が起きている原因を掘り下げていき、チーム内で改善する方法がないかを検討していっています。

まとめ

以上のように、不具合の分析は傾向の分析・原因の分析を併用することで開発工程が抱えている問題を探り出し、対策を講じていくための作業です。一見ばらつきのあるデータも、案外同じ問題に根ざしていることがあります。個々の不具合への修正ではなく、共通の原因を改善することで複数の問題を効率的に解決していくための取り組みとして、今回学んだことを生かしながらより活用していけるようになりたいと思います。

過去に在籍した会社でテスト中心のQA業務を行っていた当時、「毎回同じような不具合が出ている。」「以前に同じような機能で〇〇が原因の不具合があったので、実装時は注意して欲しい。」といった会話を開発内ですることはよくありました。今回行った分析は、そうした経験・記憶ベースでふんわりと話していた内容を、定量・定性両面で補足して明確にしてくれる効果があると感じています。

問題の原因解決というのは単純な不具合への対処とはベクトルが異なり、プロセス自体の変更を伴うことが多くなります。これはQAエンジニア一人が業務の進め方を変えるだけで解決するものではなく、各開発プロセスに関わる多くのメンバーが協力しなければ解決が難しい案件がほとんどです。今後は分析で割り出した傾向等をわかりやすく提示し、チーム全体、組織全体で協力して課題に取り組めるようにしていくことが目標となっていきます。

最後に

アソビューではより良いプロダクトを世の中に届けられるよう共に挑戦していくエンジニアを募集しています。カジュアル面談も行っておりますので、お気軽にエントリーください！お待ちしております。 www.asoview.co.jp