こんにちは！hacomonoのQAチームに所属している「ゆう」です。
最近、第3子の長女が生まれ、毎日バタバタしながら日々の業務もなんとかこなしています。
仕事と育児のバランスを見極めながら両方楽しんでやっていきたいと思います！
さて、今回は2026年1月に私が所属するチームが大きく変わったことで感じた課題と、そこから始めた品質への新たな挑戦についてご紹介します。
チーム統合で見えてきたこと
私が参画しているチームは、2026年1月に4つのドメインチームが統合され、20名規模（うちQA 7名）の1つのチームとなりました。
これを機に、使用ツールやAIの活用、テスト分析の仕方などを共有しあい、そこで見えてきた課題と、解決に向けて取り組み始めた内容を共有したいと思います。
課題①：AIを使っているのに、テスト分析の品質がばらつく
チームの統合前から、他のQAメンバーがどのようにテスト分析をしていて、どう品質を担保しているか、個人的に気になっていました。
そこで、QAメンバーが7名になったことを機に、「みんなどうやってテスト分析してる？」という共有会を開くことにしました。
実際に聞いてみると、多くのメンバーがすでにAIを活用しており、NotionAI、Cursor、Copilotなど、使っているツールはさまざまでした。
また、どう活用しているかも人それぞれで、具体的には以下のような違いがありました。
- プロンプトの書き方が人によって違う
- ツールの設定機能（Cursorのルール設定など）を活用できていない
- どのモデルを使うか、明確な基準がない
結果として、テスト観点の網羅性やドキュメントの粒度に差が出ていました。
テスト実施時に「あれ、この観点が抜けてた」と気づくこともあり、結局は経験豊富なメンバーの知見に頼る場面も。
つまり、AIを使っているのに、属人化が解消されていない。
これが最初に見えてきた課題でした。
課題②：「実装ありき」のテスト分析になってしまう
もう一つ、開発エンジニアとの会話の中で気づいた課題があります。
PRなどの実装情報をAIに渡すと、「実装ありき」のテスト分析になってしまうことです。
起きること
- AIが「この実装は正しい」という前提で分析してしまう
- 仕様に書かれていないエッジケースを見落とす
- 仕様が間違ったまま実装された場合、それに気づかない
AIは与えられた情報を「正しいもの」として扱う傾向があります。実装コードを先に見せると、そのコードの挙動を追認する分析になりやすいのです。
本来テスト分析で見つけたいのは、「仕様の考慮漏れ」や「仕様と実装のズレ」です。
しかし、実装を先に見てしまうと、それが見えなくなってしまいます。
共有会で見えた「良いやり方」
課題だけでなく、良いプラクティスも見えてきました。
- PRD/PBIの情報を整理してからAIに渡す
- 仕様ベースの分析を先に行い、その後で実装を見る
- 仕様と実装を突き合わせて差分を可視化する
ただし、これを毎回手動でやると時間がかかります。また、プロンプトが統一されていないと、結局は品質がばらついてしまいます。
共有会を通じて、AIの活用度合いにはメンバーごとに差があることもわかりました。そこで、誰でも一定水準の品質を保てるような「推奨フロー」を作ることにしました。
プレイブックという発想
推奨フローを作るにあたり、「プレイブック」という形でまとめることにしました。
他のチームに参画しているQAメンバーのプロンプトも参考にしながら、AIと対話して設計していきました。
設計で意識したこと
| 課題 | プレイブックでの対応 |
|---|---|
| プロンプトが人によって違う | ルールとして統一し、ツールの設定に組み込む |
| 実装ありきになる | 仕様分析時はPRのdiffを見ないルール |
| 時間がかかる | 一度の依頼で複数ステップを自動実行 |
4-Step Flow
分析の順序を明確に定義しました。
ポイントは、Step 1で「あるべき姿」を先に分析することです。実装を見るのはStep 2以降。この順序を守ることで、「実装ありき」の分析を防ぎます。
その他の工夫
Quality Gates
AIは自信満々に間違ったことを言うことがあります。そこで、確認できない情報は「要確認」として明示させたり、推察には確信度ラベル（【確定】【推察・高/中/低】）を付与させるルールを入れました。これにより、「どこまで信頼できるか」を可視化します。
ナレッジの蓄積と活用
ドメイン知識（権限モデルや業務概念など）をあらかじめAIに読み込ませることで、担当者が変わっても同じ前提で分析できるようにしています。また、各ステップのプロンプトをチームで共有し、良いものを育てていく仕組みも取り入れました。
属人化していた知見をチームのナレッジとして蓄積し、AIがそれを活用しながら分析します。
これにより、経験の浅いメンバーでも一定水準の分析ができることを目指しています。
これからの展望
現状、プレイブックはまだチーム内に展開できていません。
これからチームに展開し、実際に使ってもらいながらブラッシュアップしていく予定です。
期待しているのは、「誰がやっても同じ品質のテスト分析ができる」こと。そして、仕様の抜け漏れや仕様と実装のズレを、テスト実施前に発見できるようになることです。
実際に品質のばらつきが減るか、分析にかかる時間はどう変わるか、メンバーからどんなフィードバックが出るか——これから検証していきたいと思います。
おわりに
AIツールを使うこと自体は、もはや当たり前になってきています。しかし、「なんとなく使う」だけでは、属人化は解消されません。
重要なのは、「AIをどう使うか」を設計することです。
- プロンプトを統一する
- 分析の順序を設計する（仕様→実装の順で見る）
- 出力の品質を担保する仕組みを入れる
- ナレッジを蓄積し、AIに活用させる
私たちの取り組みは、まだ始まったばかりなので、実際にチームで運用しながら、改善を続けていきたいと思います。
チームに展開した結果や、実際の効果については、また別の記事でご紹介できればと思います。お楽しみに！
💁 関連記事
