はじめに

こんにちは、QAエンジニアの青柳です。

今回は、Wantedly Hire (採用管理システム) のE2Eテストにまつわる話を紹介します。Wantedly Hire は、導入いただいている企業様にとって、採用活動を支える業務システムの一つです。機能ごとの QA だけでは、複数の設定が絡む不具合を見落とすリスクがあり、当たり前品質を確保することが急務になりました。この取り組みは、QAチームのリーダーである自分と、Wantedly Hire の開発チームリーダーが、それぞれの専門性を持ち寄って進めたものです。

今回の取り組みでは、プロダクト仕様からテストケースを起こすのは QA 、AI が生成したコードの品質を確実にする仕組みをつくるのはエンジニア、という役割分担です。この二つの役割がどのように噛み合っていったのかを、本記事では紹介します。実際に何が起き、どう進んでいったのかを、具体的に振り返ります。

主要機能の洗い出しから、シナリオ作成まで

取り組みは、Wantedly Hire の主要機能を洗い出し、テストシナリオを用意するところから始まりました。シナリオの優先度付けとケース作成は QA が担当し、開発チームリーダーがレビューする、という役割分担です。優先順位は、日常的によく使われる機能や、リスクが高いと考えられる画面を中心に決め、すでに施策ごとの QA で確認できている領域は優先度を下げました。

シナリオ作成と並行して、E2E の土台整備は開発チームリーダーが主導していました。ログインの仕組みや、テストを実行するための環境まわりなど、QA だけでは整備が難しい部分です。QA と開発チームがそれぞれ得意な部分を分担することで、準備が同時に進んでいきました。

土台ができて、QAが実装に挑戦する

土台が整ったところで、QA がAIエージェントを使って実装に挑戦しました。自分はそれまで、AIエージェントを実装作業で使った経験がほとんどありませんでした。ここで分かったのは、AIエージェントによる実装が迷走しやすいという点でした。シンプルに実装できるはずのテストでも、複雑なロジックやフォールバックが入り込み、直しにくいコードになりがちでした。

QA チームが実装し、開発チームがレビューするという構造だと、レビューのところで一番時間がかかるようになります。もっと良いガードレールや仕組みが必要だ、という課題意識が生まれました。この課題意識が、次の取り組みにつながっていきます。

差分から見えてきた、具体的な違い

AI が実装したコードは、開発チームリーダー自身が同じ機能を実装したうえで、両方を比較するという方法でレビューされました。並べてみると、いくつもの違いが見えてきました。代表的なものを3つ挙げます。

• 要素の探し方 : AI が実装したコードは、決まった目印が見つからなければ別の目印を探し、それでもだめならさらに別の手段を試す、というように代わりの手段を何段階も積み重ねていました。開発チームリーダーの実装は、テスト用の目印 (data-testid) が一つ見つからなければ、その場でテストを失敗させるだけのシンプルな書き方でした。
• 要素の指定方法 : AI が実装したコードは、画面の見た目を決める CSS のクラス名を手がかりに要素を探していました。クラス名はデザインの変更で変わりやすいため、開発チームリーダーの実装ではテスト専用の目印だけを使っていました。
• 変更する範囲 : AI が実装したコードは、テスト本体だけでなく、プロジェクトの設定ファイルまで書き換えていました。開発チームリーダーの実装は、必要なファイルだけの変更にとどめていました。

中でも大きかったのが、要素の探し方の違いです。目印が見つからないときに無理に探し方を工夫するのではなく、目印を付けてもらってから進める方が、シンプルで確実です。この経験から、「テストは、壊れるべきときに壊れた方がよい」という考え方が、CLAUDE.md や Cursor 向けのルールとして加わりました。これは人間向けのコーディング規約ではなく、AIエージェントが実装時に参照するルールであり、フィードバックのたびに更新され続けています。

役割が噛み合っていく

ルールが積み重なっていったことで、QA はプロダクト仕様からテストケースを起こし、AI とともに E2E テストの実装を進めます。開発チームリーダーは、AI が生成したコードの品質をどう確実にするかという仕組みづくりを担います。二つの役割が、それぞれの持ち場で噛み合うようになったのです。

結果として、レビューのやり取りは減り、実装してからマージされるまでにかかる日数も短くなりました。QA が一人で AI を使って実装し、レビューを依頼し、フィードバックがあれば対応する、というサイクルで回せるようになったからです。仕様からケースを起こす人と、生成コードの品質を確実にする人、という役割分担があったからこそ、このサイクルが機能しています。

おわりに

二人のリーダーが、それぞれの専門性を持ち寄ったことで、Wantedly Hire の E2E テストは実現しました。QA はプロダクト仕様を、開発チームリーダーは AI が生成するコードの品質を、それぞれ見ています。異なる専門性が噛み合うことで、一人ではたどり着けない仕組みができました。

テストが不安定になったり、実行に時間がかかったりすることなど、課題はまだ残っています。それでも、この取り組みは、個人の学びというより、専門性の異なるリーダー同士が協働することの価値を示すものです。仕様を知る人と、コードの品質を守る人、それぞれの役割を分けて任せることが、AIとうまく付き合う一つの形になると考えています。専門領域を越えて挑戦してみたい人ほど、異なる専門性を持つ相手と組むことが、力になるはずです。