この記事は hacomono Advent Calendar 2025 の19日目の記事です。
こんにちは！hacomonoのQAチームに所属している「ゆう」です。
最近、平成ブームということで色々なおもちゃが流行っているそうですが、私もゲームボーイカラーやニンテンドー64などを買って子供と遊ぶことにハマってます！（同世代の方いますか？）
さて、突然ですが、皆さんは「プロジェクトの品質ってどう測るんだろう」という疑問を持ったことはありますか？
私自身、QA活動をする中でこの疑問に直面し、以下のような課題を感じていました。
背景：3つの課題感
- プロジェクト終了後の品質評価がなかった
プロジェクトが完了しても、「このプロジェクトの品質はどうだったのか」を振り返る機会がありませんでした。 - 不具合傾向の分析を始めたかった
不具合は発生するたびに対応していましたが、「どんな傾向があるのか」「次に活かせることは何か」といった分析はできていませんでした。 - 「品質ってどう測るの？」が曖昧だった
不具合の数や重要度、テストカバレッジなどの指標はいくつかあるものの、それらを総合的に判断する基準がありませんでした。
きっかけ
そんな中、参画しているチームのメンバーと1on1で「不具合の傾向を分析したいよね」という会話がありました。
そこで、AI（Cursor）に不具合分析レポートの作成を任せてみることにしました。
試してみたこと：プロンプトの作成
Cursorに不具合分析レポートを作成してもらうため、まずはプロンプトを作成しました。
渡した情報
- 開発した機能名
- 不具合のPR番号：各不具合の修正内容
- Playwrightのテストファイル名：QAエンジニアが作成したE2Eテスト
プロンプトのブラッシュアップ
最初のプロンプトでは、期待通りのレポートが生成されませんでした。品質スコアの計算基準が曖昧だったり、AIの推測が多く含まれていたりといった課題がありました。
そこで、AIと対話しながら何度もプロンプトを改善していきました。
改善したポイント
- 品質スコアの計算式を明記
「適切にスコアを算出してください」ではなく、4つの評価軸ごとに具体的な配点と計算方法を指定しました。
詳細は後述の「品質スコアの算出方法」をご覧ください。 - レポートの構成を詳細に指定
エグゼクティブサマリー、不具合分析・傾向、詳細な不具合分析、テストカバレッジサマリーなど、どんなセクションを含めるかを明確にしました。 - 分析の深さを指定
根本原因の特定（表面的な原因ではなく、なぜその実装になったのか）、影響範囲の分析、再発防止策の評価など、どこまで深く分析してほしいかを伝えました。 - 事実ベースでの分析を指示
「推論を多く入れず、コミットログやPRから読み取れる事実をもとに分析する」と明記しました。 - E2Eテストの評価方法を工夫
チームに参画しているQAメンバー内で「これ以上E2Eテストは不要」と合意した場合、その旨をチェック項目で伝えることで、AIが適切に評価できるようにしました。 - デザインのブラッシュアップ
生成されたレポートを見ながら、AIと対話式でより見やすいデザインに改善していきました。
できたこと：不具合分析レポート
試行錯誤の結果、以下のような不具合分析レポートを生成できるようになりました。
レポートはHTMLファイルとして出力され、以下の内容が含まれています。
- エグゼクティブサマリー：品質スコア、統計カード、不具合サマリー
- 不具合分析・傾向：不具合種別の分布、根本原因の分類
- 詳細な不具合分析：各不具合ごとの症状、影響、修正内容、根本原因
- テストカバレッジサマリー：Backend/Frontend/E2Eのカバレッジ状況
品質スコアによる総合評価
レポートの最大の特徴は、プロジェクトの品質を100点満点で評価し、S/A+/A/A-/B+/B以下のグレードで表示する点です。
以下は、架空のプロジェクトを想定したサンプルレポートです。
品質スコアの算出方法
品質スコアは、以下の4つの評価軸で算出しています。
| 評価軸 | 配点 | 内容 |
|---|---|---|
| テストカバレッジ | 30点 | Backend/Frontend/E2E各10点 |
| 不具合の影響度 | 30点 | 高影響度-10点、中影響度-5点、低影響度-2点（減点方式） |
| 再発防止策の充実度 | 20点 | テスト追加、プロセス改善の質と量 |
| 根本原因の質 | 20点 | 設計・仕様-6点、実装ミス-4点、テスト不足-2点（減点方式） |
グレード基準
| グレード | スコア | 説明 |
|---|---|---|
| S | 90-100点 | 極めて高品質 |
| A+ | 85-89点 | 非常に高品質 |
| A | 80-84点 | 目標水準 |
| A- | 75-79点 | 良好 |
| B+ | 70-74点 | やや良好 |
| B以下 | 69点以下 | 改善が必要 |
レポートの内容
各不具合について、以下の観点で詳細に分析されています。
- 症状：何が起きたか
- 影響：ビジネス・ユーザー・システムへの影響
- 修正内容：どう修正したか
- 根本原因：なぜ発生したか（設計/仕様理解/実装ミスなど）
- カバレッジ・再発防止分析：テストの充実度と再発防止策
以下は、レポートに含まれる不具合カードのサンプルです。
重要なのは、推論を多く入れず、コミットログやPRから読み取れる事実をもとに分析されている点です。
その他の特徴
- 視覚的でわかりやすいデザイン：不具合の種別ごとにカラーコーディング（ビジネス影響は赤、ユーザー体験影響はオレンジなど）し、カード型レイアウトで見やすく表示
- 統計情報の可視化：総不具合数、修正完了数、カバレッジなどを一目で把握
- 用語解説：冒頭に技術用語には説明を付けることで、技術的な知識がない人でも理解できるよう配慮
学び・今後の展望
学んだこと
この取り組みを通じて、以下のことを学びました。
プロンプトは「育てるもの」
最初のプロンプトで完璧なレポートが生成されることはありませんでした。AIと対話しながら、「ここの表現が曖昧だな」「この指示だと意図と違う結果になるな」といった気づきを得て、少しずつプロンプトを改善していきました。
プロンプトは一発で完璧なものを作ることではなく、継続的に育てていくものだと実感しました。
今後の展望
レポートを活用した振り返りのサイクル
今後は、プロジェクト完了時に継続してレポートを作成し、品質の振り返りを習慣化していきたいと考えています。
以下のようなサイクルを回すことで、チームの品質向上につなげたいです。
- レポートを作成：プロジェクト完了時に不具合分析レポートを生成
- 振り返りを実施：レポートをもとにチームで振り返り
- 改善策を実行：発見した課題に対してアクションを起こす
- 次のプロジェクトで確認：改善が効果を発揮したか次のレポートで確認
継続することで、以下のような価値が生まれることを期待しています。
- チームの品質改善のトレンドが見える
- 過去のプロジェクトとの比較ができる
- 品質に対する意識が高まる
リリース後の不具合の追跡と分析
現在は開発中に発見された不具合を対象にレポートを作成していますが、今後はリリース後に発見された不具合の追跡と分析にも取り組みたいと考えています。
リリース後の不具合を分析することで、「開発中のテストでは見つけられなかった問題」「実際のユーザー環境でのみ発生する問題」などを可視化し、さらなる品質向上につなげていきたいです。
おわりに
「品質ってどう測る？」という素朴な疑問から始まったこの取り組み。AIを活用することで、不具合分析レポートという形で自分なりの答えを作ることができました。
まだ始まったばかりですが、継続して改善していくことで、チームの品質向上に貢献できればと思っています。
同じような課題を感じている方の参考になれば幸いです！
