不具合を成長の糧に！不具合分析でプロダクト品質を磨く～導入編～

こんにちは、QAエンジニアのえりです。
今回は、QA課で取り組んでいる不具合分析の導入についてお話ししたいと思います！

不具合分析を始めたきっかけ 💡

ソフトウェア開発において規模が大きければ大きいほど、テストフェーズで不具合が発見されることは避けられません。ただ、その不具合を修正して再確認するだけで終わらせてしまうのはもったいないと思いませんか？

ユニファに入社した当時、まだ不具合分析のフローはまだありませんでした。
私が担当するフォトプロダクトは昔からあるプロダクトのため品質としては安定していますが、他プロダクトは新しいものもあり、開発フローをブラッシュアップしている最中です。

そのため、どのプロダクトでも継続的に安定した品質を維持するためにも、なぜその不具合が発生したのか、その根本的な原因を突き止めることでプロダクトの現状を客観的に把握し、品質改善に向けた具体的なアクションを計画できるようにしたいと考えました。

また、もう1つの目的として、件数を計測して現状の「健康状態」を可視化するという点があります。今まで原因として挙がってこなかった要因で不具合件数が増えたときに、「あのフローを変えたのが原因かな？」と振り返るきっかけになると思っています。

これらを実現するため、まずはミニマムで2つのプロダクト（フォト、共通システム）に対して不具合分析の導入を試みました！

不具合分析導入への道 👣

不具合分析を効果的に進めるために、以下のステップで準備を進めました。

1.分析項目の定義：不具合を分析するために必要な項目の洗い出し

まず、不具合分析をするにあたってどのような要素が必要になるかをQA課で議論しました。
不具合の影響度や発生原因、影響範囲など、欲しい情報がいくつか出てきました。具体的に洗い出した項目は以下の表のようになります。

2. 不具合原因の定義

次に、なぜ不具合が発生したのかを分類するためのカテゴリを検討しました。この分類は企業によって異なる定義になると思いますが、ユニファでは以下のように定めました。

3. 開発リーダーへのヒアリングと成果物の確認

不具合原因のカテゴリを出し切ったところで、ふと疑問が浮かびました。
「要件把握誤り・漏れ」と書いたものの、具体的にどの成果物に対してなのか？という点です。それを明確にするため、フロント・アプリ開発リーダーそれぞれに、現状の開発フローや、開発側が作成・参照する成果物について確認していきました。

4. 関係者へのインプット

不具合分析の結果を活用してほしいのは、PdM（プロダクトマネージャー）、開発、QAの3者です。
特に不具合の原因や影響範囲などは開発チーム側で入力してもらう必要があるため、目的をしっかり説明し、協力を得るためのインプットを行いました。導入目的をまとめた資料を基に説明し、具体的なイメージ図も添えました。