やっほー！
リンクアンドモチベーションでバックエンドエンジニアをしております清水と申します（社内ではマイケルと呼ばれています）。
さて、突然ですがみなさんは普段、QAをどのように行っていますか？
専任のQAエンジニアがいるチーム、外部のQA会社に委託しているチーム、開発者自身がQAを行うチームなど、様々な形態があるかと思います。
今回は、私たちのチームがQA工数削減に向けて試行錯誤している取り組みについて共有させてください。
私たちのチームの開発プロセス
私たちのチームでは、ざっくり以下のプロセスで開発を進めています。
- 要件定義
- 実装設計
- QA設計
- 実装
- QA（QA実施、バグ修正）
ここで補足すると、専任のQAエンジニア職は置いていませんが、品質責任を軽く見ているわけではなく、チーム全体で設計・実施・改善を回しています。
そもそもの課題
QAをほぼ手動で行ない、工数が大きくなり、リードタイムが伸びていた。
これが私たちの出発点でした。
QAテストケースの管理方法
QAのテストケースはスプレッドシートで管理しており、各観点ごとにテストケースを作成しています。
主な観点は以下の通りです。
| 観点 | 説明 |
|---|---|
| 正常系 | 期待通りの入力・操作に対する動作確認 |
| 異常系 | エラーケースや境界値の確認 |
| データの状態ごとの挙動確認 | データの有無や状態による表示・動作の違い |
| デザイン | Figmaデザインとの一致確認 |
| メール | 送信メールの内容・タイミング確認 |
| 入力確認 | フォーム入力のバリデーション等 |
| 出力確認 | 画面表示やダウンロードファイルの確認 |
| アクセス権限 | ユーザー権限ごとのアクセス制御 |
| 排他制御 | 同時操作時の挙動確認 |
| 脆弱性 | セキュリティ観点のチェック |
これらの観点でテストケースを洗い出すと、多い時は1つの観点だけで600個ほどのテストケースになることもあります。
これを全て手動で実施するのは、当然ながら膨大な工数がかかります。
やったこと（やっていること）
この課題に対して、私たちは大きく2つのアプローチで工数削減に取り組んでいます。
- テスト設計の工数削減
- 手動テストの数を削減
まずは「1. テスト設計の工数削減」について説明します。
1. テスト設計の工数削減
AIによるテストケース作成
テスト設計は、AIで“たたき台”を作り、人がレビューして品質を担保する手法に切り替えました。
弊社ではAIツールとしてClaude Codeを利用しており、
以下をインプットとして、テストケースを自動生成させるようにしています。
- 要件定義書
- 実装設計書
- デザイン（Figma）
[Claude Codeへの指示イメージ]
以下のドキュメントを読み込んで、QAテストケースを作成してください。
- 要件定義書: xxx
- 実装設計書: xxx
- Figmaデザイン: xxx
観点は以下を含めてください：
- 正常系
- 異常系
- データ状態ごとの挙動
...
※ 実際のルールは.claude/agentsを利用してもっと細かいです
正直なところ
現状、そのまま採用できる品質ではないため、人のレビュー前提です（特に大規模案件では観点の抜け・粒度の揺れが出やすい）。
AIが出力したテストケースをそのまま使えるわけではなく、人間によるレビューと修正が必要です。
しかし、ゼロからテストケースを考えるよりは、たたき台があった方が効率的なのは間違いありません。
プロジェクト規模による効果の違い
小さいプロジェクトの場合
かなり役に立っています。
ちょっとした修正だけで済むので、QA設計の工数を大幅に削減できています。
大きめのプロジェクトの場合
正直なところ、まだそこまで効果を実感できていません。
原因はシンプルで、テストケースの数が多いためレビューがかなり大変になっているからです。
（AI使おうが使わまいが大変だけども）
最近の工夫：コメントベースの修正
最近試しているのが、スプレッドシートのコメントを活用した修正フローです。
- AIが出力したテストケースをスプレッドシートに反映
- レビュアーがスプレッドシート上でコメントを残す
- コメントを全部AIに与えて修正させる
[修正指示のイメージ]
以下のコメントに基づいて、テストケースを修正してください。
コメント一覧：
- A10: 「このケースは不要」
- B15: 「条件が曖昧なので具体化して」
- C20: 「権限チェックのケースが漏れている」
...
この方法だと、修正作業はかなり楽になりました。
継続的なルール改善
QA設計に関しては、精度を上げるためのルールをちょいちょいアップデートしています。
- 観点ごとのテンプレート整備
- よくある指摘事項のフィードバック
- プロジェクト固有の考慮事項の追加
地道ですが、少しずつ精度は上がってきている実感があります。
2. 手動テストの数を削減
こちらは、今まで手動テストで行っていたものを単体テストでカバーするように変えるという取り組みです。
Before（これまでの考え方）
API→画面の動作確認しているテストケースは手動テストにしよう
全てのテストケースを手動で確認していました。
After（新しい考え方）
同じAPIを利用したテストケースは、
主要なパターンだけ手動テストして、
多くのパターンはFE・BEの単体テストでカバーしよう
テストケースへのラベル付け
この考えのもと、テストケースごとに以下のラベルを付けるようにしています。
| ラベル | 説明 |
|---|---|
| 手動テスト | 実際にブラウザで操作して確認 |
| FE単体テスト | フロントエンドのユニットテストでカバー |
| BE単体テスト | バックエンドのユニットテストでカバー |
テストケースごとに、「このケースは本当に手動で確認する必要があるのか？」と思考しています。
現在の状況
この試みはQA設計で絶賛対応中です。
まだこの新しいやり方で実際にQAを実施していないので、どれくらいバグ検知率が変わるかを注視している段階です。
期待していること
実装段階でQA設計書をAIに読み込ませ、実装者が観点を意識しやすくすることで、バグ発生率を下げられると考えています。
（むしろ、なぜ今までやってなかったのか...）
実装者がQA設計書を意識して実装することで、そもそもバグを作り込まない。これが理想です。
おわりに
こんな感じで、QA工数削減を絶賛対応中です。
まだ試行錯誤の段階で、成功事例として紹介できるレベルではありませんが、同じような課題を抱えているチームの参考になれば幸いです。
また進捗があれば、続編として共有できればと思います。
この記事が参考になったら、LGTMやストックをお願いします！