はじめに

私は現在、新卒でQAエンジニアを目指しています。

connpassで申し込んだイベントで、西田泰明さん（株式会社TOKIUM）の「QAによるハーネスエンジニアリングとQA組織の未来像」という発表を聞きました。

テストの作成や実行をAIに任せられるようになったとき、QAエンジニアは何をする人になるのか。QAの知識をほかの職種やAIも使えるようになれば、組織の中での役割はどう変わるのか。

この記事では、発表の後半で扱われた「QA組織の未来像」をもとに、各社の事例と、自分が目指したいQAエンジニア像について考えます。

発表では、QA業務をQA以外の人も実行できる状態にし、QAエンジニアは戦略の策定や仕組みづくり、難しいテストに関わっていく未来像が示されていました。

1. 自動化される仕事があることと、QAの価値がなくなることは別

発表では、QAの業務が「代替型」と「強化型」に分けて整理されていました。

「代替型」として挙げられていたのは、仕様書からのテストケース作成、手順に沿ったテスト実行、結果の記録、テストコードの記述などです。

一方、「強化型」には、リスクベースのテスト戦略、探索的テスト、UX評価、品質メトリクスの設計、リリース判定・リスク判断などが挙げられていました。AIが人を支援しつつ、人の判断が残る領域として整理されています。

さらに、開発工程の中では、上流の「何を確かめるか」と下流の「出してよいか」に、人の判断が残るという説明がありました。

私が気になったのは、作業を進めることと、何のためにその作業をするのかを決めることが、分けて考えられていた点です。

例えばテストケースを短時間で大量に作れても、その機能で最も避けたい問題が何かを考えていなければ、どのテストを優先すべきかは分かりません。

自動化によって確認できる量が増えるなら、その確認をユーザーにとって意味のあるものにすることにも、力を使えるはずです。

そこにQAの専門性を生かせる余地があり、とても面白くてやりがいのある領域だと感じています。

2. 「仕様どおりに動くか」の前に、確かめたいことがある

長期インターンでテスト設計に取り組んだときも、仕様書を読むだけでは判断できない部分がありました。

その中で、手順や期待結果を残すだけでなく、QAが何を根拠に判断しているのかを、どう共有すればよいのかが気になっていました。

今回の発表を聞いて、その判断基準を共有する先は、QAチームの中だけに限らなくてよいのだと考えました。機能を検討する段階で開発者やPdMと共有できれば、テストの準備だけでなく、仕様を決めるためにも使えそうです。

ここからは、考えるための仮の例です。

勤怠管理サービスに「従業員の所属部署を変更する機能」があるとします。画面で部署を選び、保存後に正しく表示されることは、一つの確認です。

ただ、業務上はそれだけでは済まないかもしれません。

異動前の勤怠は、誰が参照できるのか。申請途中のものは、異動前と異動後のどちらの上司が承認するのか。所属部署を変えたことで、承認できる人がいなくならないか。

これらに一律の正解があるわけではなく、サービスの要求や利用者の運用によって決める必要があります。

画面上の変更が成功していても、その結果、承認が進まなくなって月末の締め処理が止まるなら、利用者にとっては問題です。

このときQAができるのは、曖昧な仕様を独断で補ってテストケースを作ることではないと思います。

どこが決まっていないのか、その違いによって誰が困るのかを整理し、開発者やPdMと確認する。その上で、合意した内容をテストで確かめられる形にすることです。

もちろん、こうした問いを立てるのはQAだけの仕事ではありません。それでも、利用場面や失敗したときの影響を継続的に問い、確認すべきことを具体化する役割として、QAの知識を生かせると考えています。

テストを速く作るだけでなく、作り始める前に何を明らかにするか。
AIを活用する開発でも、ここに関われるQAになりたいです。

3. 各社の事例から考えた、QA組織の変わり方

発表では、SmartHR、freee、LayerX、食べログ、メルカリ、エムスリーの取り組みが紹介されていました。

以下の6社は、その紹介内容の要約です。各社の活動全体を表すものではなく、AI導入の成果を同じ条件で比較したものでもありません。ここでは、QAの関わり方を考える材料として振り返ります。

SmartHR：チームに任せつつ、難しい場面では一緒に考える

QAの伴走を停止し、開発メンバーだけでテストを進めるチームがある一方、複雑な機能ではQAが再び関わる事例が紹介されていました。

QAが離れることをゴールにせず、チームの状況や機能の難しさに合わせて関わり方を変える点が印象に残りました。任せられることを増やしながら、難しいところは相談できる関係を作っていけたら理想的だなと思いました。

freee：プロダクトに向き合うQAと、組織を横につなぐQA

プロダクトQAと横断QAの二層体制が紹介されていました。

現場を深く理解することと、そこで得た知見をほかのチームにも広げること。両方の役割があれば、一つのプロダクトで得た経験を、組織全体の改善につなげられそうです。

LayerX：欠陥の検出から、実際の利用や価値の検証へ

確認型テスト252件で欠陥検出0件だった事例と、「検出」から「観測・価値検証」への変化が紹介されていました。

ただ、テストで問題が見つからないことと、ユーザーが困っていないことは別です。 検出数だけでなく、今のテストで何を捉えられているかを問い直したいと思いました。

食べログ：自動化によって、確認にかかる負担を減らす

紹介された事例では、テスト実行工数を52％削減し、自動化率が24％から64％に向上していました。

私も自動化に取り組む際は、削減した時間だけでなく、その余力で何を確かめたり改善したりできたかまで見たいです。

メルカリ：QAの知見を、ほかの職種も使える道具にする

受け入れ条件の作成をAIツール化し、PMやエンジニアが使う取り組みが紹介されていました。

QAが毎回条件を考えるだけでなく、ほかの職種が考えるための道具を作ることも、QAの貢献になると感じました。ただし、生成した条件の妥当性をどう確認するかも、一緒に考えていくべきだと考えます。

エムスリー：「全員QA」を支える戦略や仕組みを作る

「全員QA」を進め、QAがテスト実行者から品質の戦略家へ移っていく構想が紹介されていました。

テストを分担するだけでなく、何を優先して確認するか、どの基準で判断するかを整えることも、QAが担う役割なのだと捉えました。

サイボウズ：仕様検討から、チームの判断に関わる

ここは発表内容ではなく、私が注目しているサイボウズのQAについての補足です。

サイボウズのQAは、仕様検討からリリース後まで開発者やPdMと連携し、テストで得た情報をチームの判断材料として提供すると説明されています。

また、公式ブログには、AIの活用によって、時間やスキルの制約から手が回らなかった調査・修正にも取り組めるようになったQAの事例があります。

私が惹かれるのは、テストを効率化するだけでなく、チームへの貢献を広げている点です。AIに任せた後に、自分が品質のためにできることを増やす。 この関わり方は、私が目指したい姿に近いと感じました。

QAの価値を、自分が担当した作業だけで考えない

各社の事例を見て、「これからのQA組織は全部この形になる」とは思いませんでした。

むしろ、自分たちのプロダクトや開発体制に合わせて、QAが関わる場所や方法を変えている点が参考になりました。

QAがすべてを確認することでも、QAの作業を減らすことでもなく、チームとして必要な確認と判断ができること。そのために、自分でテストする場合もあれば、仕組みを作る場合も、ほかの人と一緒に考える場合もある。

「自分が何を担当し続けるか」より、品質上の課題に対して、どんな関わり方が役立つかを考えられるQAになりたいです。

4. QAの成果を「見つけた不具合の数」だけでは見たくない

こうした役割を考えると、QAの成果の見方も気になります。

例えば、仕様を検討している段階で承認者が不在になる条件に気づき、実装前に仕様を見直せたとします。この場合、リリース前のテストで発見した不具合としては数えられなくても、問題を防ぐための働きかけはしています。

また、判断基準やテスト基盤を共有した結果、開発者が変更の影響を自分で確認できるようになった場合、QAが直接実行したテスト件数は減るかもしれません。

それだけを見て、QAの貢献も減ったとは言えないはずです。

私なら、不具合の検出数に加えて、確認待ちがどこで起きているか、同じ問題で何度も手戻りしていないか、過去の判断を次の変更に生かせているかも見たいです。

ただし、QA工程が短くなっただけで、開発者の確認負担やリリース後の問題が増えているなら、うまくいったとは判断できません。

誰か一人の作業時間ではなく、チーム全体で何が改善し、利用者のリスクがどう変わったか。 そこまで確かめたいと思います。

また、「全員で品質を見る」が、責任の所在を曖昧にする言葉にならないようにもしたいです。

通常の確認は誰が行うのか。判断に迷った場合は誰に相談するのか。残るリスクを誰に伝え、リリースの意思決定にどう使うのか。

作業を分担することと、判断の流れを整えることは、セットで考える必要があると思いました。

5. だからこそ、実装とテストの基礎を学びたい

ここまで考えても、「これからは判断が大事だから、テストの実装や実行を学ばなくてよい」とは思いません。

判断の根拠を持つためにも、自分でテストを設計し、実行し、結果を調べる経験を積みたいです。

例えば、先ほどの部署変更の機能で「権限を確認する」と言うだけなら簡単です。

でも、具体的にはどの利用者で、どのデータに、どの操作を試すのか。画面で見えないことを確認するだけでよいのか。失敗したときに、仕様・実装・テストのどこを調べるのか。

そこまで考えようとすると、業務の理解だけでなく、実装やシステムの仕組みに関する知識も必要になります。

AIを使う場合も、生成されたテストを読んで、どこまで確認できているかを自分で追えるようになりたいです。

同時に、テストケースを残すときには、「なぜこれを確かめるのか」も一緒に残すことを意識したいと思います。

単に「異動後の権限を確認する」と書くのではなく、「部署変更によって参照権限が変わり、必要な過去データを見られなくなる可能性があるため」と理由を添える。

根拠となる仕様と、まだ確認が必要な点も分けておけば、ほかの人が見たときに、そのテストをどこまで信用してよいか考えやすくなります。

まずは個人開発や学習の中で、テストを作って終わりにせず、他の人が判断に使える形に残すところまで取り組みたいです。

おわりに

今回の発表では、QAの重心が作業から判断へ移り、戦略・仕組み・困難なテストに関わっていく未来像が示されていました。

私は「AI時代だからQAは安泰」と考えているわけではありません。QAという職種であるだけで、価値が自動的に高まるとも思いません。

ただ、AIによって作成や確認を速く進められるなら、その力を何のために使うのか、どこまで確認すれば進められるのかを、チームで判断することが大切になると考えています。

その判断に必要な情報を集め、曖昧な点を明らかにし、確認できる仕組みを作る。こうした仕事は、AIが登場して初めて必要になったものではないはずです。

だからこそ、これまでQAが培ってきた考え方を、AIと一緒に開発する環境でも生かせるのではないかと思いました。

自分がたくさんテストできることに加えて、自分が関わることで、チームが品質について判断しやすくなることも目指したい。

AIに任せられることを増やしながら、自分もできることを増やしていく。今回の発表と各社の取り組みを通して、そんなQAエンジニアとして働きたいと、改めて感じました。