QAもAI活用したい
NewsPicksでQAエンジニアをしています、西薗（@yurizono）です。
最近、Vibe Coding が流行ってますね。弊社 NewsPicks でも「【死闘20時間】バイブコーディングの「本当とウソ」」という記事で、文系でプログラミング未経験（多分）の記者がエンジニアの助けを借りながら Vibe Coding で必死でプロダクトを作ってみたという話を紹介しています。作りたいものは作れなかったようですが（リベンジに期待）、もはやプロダクトを作るのにプログラミングの知識は必須ではなくなってしまいました。世界、変わりましたよね。
QAの界隈でも、Vibe Coding 含め AI をいかに使っていくかという話題でしばらく盛り上がっているように思います。テスト教材のサンプルアプリを作ったよ、テスト設計に使ったよ、自動テスト書かせてるよ、いやバグ起票も AI にやらせたいな……等。私も御多分に漏れず AI の使い道を考えました。それが「開発者になる」です。
QAの仕事はバグを管理することですか？
みなさんバグ管理されてますか。バグチケットに書く内容を決めたり、処理プロセスを定めたり、たくさんバグチケットを集めて分析したり、多分されてますよね。あと、バグチケットに優先度をつけて、開発者に修正依頼をしたり。
私はどうもこの修正依頼というやつがしっくりきていませんでした。意外と大変なんですよね、修正を依頼するって。例えば、チケット起票自体はQA以外がすることもありますから、再現確認をしつつ再現手順や再現環境を追記します。影響度合いを判断して優先度をつけます。依頼しっぱなしではいけないのでステータスを追跡できるようにして、定期的にリマインドします。そもそも依頼先のチームも決めるために、直接原因の切り分けをします。修正にあたって仕様調整が必要そうなら、予め方針を決めてPdMやデザイナと握っておきます。……このように、やることがいっぱいです。
こうして苦労して修正依頼したバグチケットですが、緊急性の高いものを除くと、開発チームの状況次第では3ヶ月未着手のまま、ということも珍しくありません。とはいえ開発チームも放置したくて放置しているのではありません。開発プロジェクトがひと段落したタイミングで一気に片付けてくれようとしますが、その時には私も中身を忘れていて、突如発生した確認や調整タスクを捌ききれず、結局次の開発プロジェクトが始まってしまったりします。こうなるともどかしいですね。
QAがバグ修正をしたっていい
そもそもなぜ私はバグの修正を「依頼していた」のでしょう？目の前にバグがあり、優先度の問題で開発チームは着手できず、しかし確実に困っているユーザーがいて、QAの私としてはそれを治したいと思っているのだとすると、私がすべきはチケットのステータスを確認することでも定例でプッシュすることでもなく、「バグを修正すること」なのではないでしょうか。
できない理由はなんでしょう？私は幸いにも開発のバックグラウンドがあり（新卒でSIerに入り、プログラマも開発リーダーもプロマネも一応やりました）、NewsPicksのだいたい全てのドメインについてそれなりの知識を持っていて（仕様書を作ったりもしました）、GitHubリポジトリへのアクセス権もあり、PRを出せば開発者が見てくれて、目の前のバグについて現時点で一番詳しく、そしてなんと言ってもAI があります。
全てのQAエンジニアに同じことが出来るか、というとまだ微妙だなとは思いつつ、少なくとも私のケースに限って言うと、出来ない理由が特にありませんでした。
実際にバグ修正をしました
以下、ここ2ヶ月くらいでの実績です（括弧内は修正箇所）。当然ながら既存のタスク、例えばバグ管理や依頼されたテスト、プロジェクトでのQA活動など、をしながら片手間でチャレンジしました。
- WEBのPIP再生モードにあったちょっとしたバグを修正した（WEB）
- 法人向けサービスの検索フォームにあったちょっとしたバグを修正した（WEB）
- コメントのSNS連携に長らくあったバグを修正した（WEB／サーバー）
- アカウント作成直後にのみ発生していたデータ周りのバグを修正した（データ連携）
およそ、こんなプロセスで進めました。
- 修正に着手するバグを決め、 Claude Code を使って原因箇所を特定する
- 修正方針についてPdMやデザイナ、開発チームに相談する
- 方針を決めたら、 Claude Code を使って修正をする
- 動作確認をする
- PRを作り、開発チームにレビュー依頼をする
- レビューが終わったら、リリースする
Claude Code を使って、VSCode上でバグ修正をしている様子
AIを使う上での工夫
このあたりに気をつけながら使うと良さそうでした。とはいえプロンプトエンジニアリングについては詳しい書籍がありますから、そちらを読んで勉強していただくと良いでしょう。
1. バグの再現手順や再現環境はクリアにしてから着手する。
曖昧なこと言うと曖昧な答えしか返ってきません。これは人間相手の仕事でもAI相手の仕事でも一緒です。
2. バグの原因切り分けを大雑把にでも行ってから着手する。
アプリなのかサーバーなのかも分からずに始めると、おそらく辛いことになります。NewsPicksはiOSアプリ、Androidアプリ、メインのサーバー、WEB、広告といったようにリポジトリが複数集まってサービスを構成していますが、せめてそのリポジトリくらいは特定してから着手するようにしています。
3. バグの事象をいきなり伝えて修正を指示するのではなく、バグが発生している領域をAIに特定させる。
検索がうまく動かなくて〜といきなり言うのではなく、まずは「〜の検索機能を提供しているコードを探して」という指示を出します。最近のAIは勝手に依頼内容をサブタスクに分解してくれるようですが、仕事の進め方の基本までAIに任せることもないでしょう。サボらず順序立てて依頼しましょう。
4. 機能を提供している箇所を特定した上で、コンテキストにそのファイルなりを入れつつ、バグの事象を伝えて原因の特定をさせる。
可能ならAIの提示したコードを読んだ上で、事象をコードの中身に落とし込んだ上で伝えます。「検索結果がクリアされなくて〜」ではなく「検索結果をクリアする処理として clearInput があるが、これが〜のタイミングで呼ばれていないと思われる」のように当たりを付けつつ伝えると良いです。まぁ伝える時点でほぼ問題が解決していることもありますが。
5. バグの原因となったコードを読んで、分からない部分はAIに解説させつつ、自分の中で腹落ちさせてから指示を出す。
なんか分からんけど直してくれや、だとあらぬところに影響して、動作確認（テスト）をすり抜ける危険性があります。
6. あらかた不明点がクリアになったら、最後に、ジュニアなエンジニアにコードを書かせる気持ちで指示を出しながら、コードを書かせる。
ここはおそらく世のプログラマの方がたくさん記事を書かれていると思いますので、そちらに譲ります。
7. 動作確認をしっかりする。
そりゃ当たり前、なのですが、自分がテストする立場から開発する立場になると途端に正常性バイアスが働き、正常系だけ確認して安心したりするものです。テストのプロとして、しっかりテストしてから世に放ちましょう。
さいごに
単純に「バグがなおせたね、よかったね」ということに加えて、チーム間のコミュニケーションを時間軸で圧縮することによる効率化という効果もありました。
バグ修正ってそもそも、バグについて詳しいQAがいて、それをなおす開発者がいて、場合によっては仕様変更にGOを出すPdMやデザイナがいて、というちょっとしたプロジェクトなんですよね。例えば基本設計が終わった1年後に仕切り直して再開、なんてプロジェクトがおそらくうまくいかないのと同様で、QAがバグ起票してから何ヶ月も経ってしまうとバグ修正といえど簡単ではありません。しかも悪いことに、仕切り直しであれば仕切り直すための人員を計画に入れてから始めるところ、バグは3ヶ月放置されていてもふとしたきっかけで直ちに修正に着手され、突然QAに内容の確認依頼がくるものです。
推進役であるはずのQAがあやふやなことしか言えなくなる前に、さっさと着手して終わらせるのが最も効率的です。したがって、QAの記憶がフレッシュなうちに開発やPdMと必要なコミュニケーションを終わらせ、その勢いのままQA側で修正してしまえば、多少PRレビューを通すのに手間取ったとしても、結果的には効率的でしょう。
ということで、開発経験はあるけどそれを持て余しているQAエンジニアの皆様におかれましては、自動テストを書くのも良いですが、たまにはAIの力を借りつつ開発の領域へ染み出していきましょう。
リンク
タイトルはこれをもじったものです。
QAが仕様書を書いた話はこちら。