テストQAからプロセスQAへ ― 過渡期にいる自分の悩みと気づき

1. はじめに
2. 昨期：テストメインで取り組んだ時期
3. 昨期のテスト経験から得た気づき
4. 今期：プロセスQAを志向し始めた時期
5. これから挑戦したいこと
6. まとめ
7. 終わりに

1. はじめに

この記事は、アソビュー！ Advent Calendar 2025 の９日目（裏面）です。

こんにちは、アソビュー株式会社でQAエンジニアをしております空です。
アソビューではQAエンジニアが各プロダクトに配置されています。
僕は昨年5月から現在のプロダクトにジョインし、品質全般に取り組んできました。
実態はテスト業務に追われ、プロダクト品質に寄った活動が中心でした。
とはいえ、プロセス品質にも取り組む必要があると感じています。
そこで今回は、昨期のテストを通じて感じたことや、過渡期にある中での悩み・気づきをまとめました。
少しでも誰かの参考になれば幸いです。

2. 昨期：テストメインで取り組んだ時期

所属するプロダクトでは、開発エンジニアが10数人、QAエンジニアが2人という体制です。
昨期は開発規模が大きい案件やクリティカルパスに関わる開発案件を中心に、テスト設計を担当していました。
テスト実行は基本的に開発エンジニアにお願いしていましたが、リソース不足の際にはQAエンジニア側で実施することもありました。
開発・QAエンジニアともに走り切ったものの、正直かなりの負荷で、チーム全体が疲弊していた時期でもあります。
例えば、設計内容を整理する時間が十分に取れないまま、実装とテスト設計が並行して進む場面もありました。
その状況では、仕様理解や既存機能の影響調査、テスト設計・確認を同時に進める必要があり、開発・QAエンジニアともに負荷が高い状態でした。

そんな中で感じたのは、「開発の性質によってテストのアプローチも大きく変わる」ということでした。
続いて、昨期に関わった開発タイプを「エンハンス開発」と「新規機能開発」の2つに分け、それぞれで感じた違いや特徴を整理します。

2.1. エンハンス開発

エンハンス開発では、既存機能の改修（例：検索条件の追加など、UI/UXが大きく変わらない変更）を対象とします。
既存機能が本番で安定して動作しているため、テストのスコープは改修箇所とその影響範囲に限定できます。
開発側も影響範囲を把握済みであるため、既存設計書をなぞるだけでも一定の品質を確保できることが多いです。

バグが検出されても想定内であることが多く、リグレッションテストではテスト技法による間引きが可能です。
そのため、エンハンス開発では比較的テスト設計・実行の負荷が小さく、効率的に進めやすい特徴があります。
しかし既存機能の中には、過去の仕様変更やリリース優先の判断によって、整理しきれていない領域が残っている部分があります。例えば、仕様が十分に整理されていなかったり、レアケースの想定が抜けたままになっている場合があり、改修時には調査や仕様理解から始める必要があります。
そのため、改修内容によっては新規開発と同程度の確認項目や工数が必要となるケースがあります。
なお、仕様理解や調査の進め方、テスト設計時の考え方など、踏み込んだ内容については重複を避けるため「2.2 新規機能開発」にまとめています。

2.2. 新規機能開発

新規機能開発は、既存サービスに新しい価値を追加する開発（例：新しいページの追加など）を対象とします。
設計や実装での想定漏れをテストでも拾うことがあり、テスト設計の精度がそのままリスクに直結します。
テスト設計の精度にはバラつきがあり、因子や水準を洗い出して抜け漏れを防ぐこと、ユースケースから考えるスキルが求められます。
観点不足は未テスト領域につながり、本番での不具合リスクを高めます。

さらに、サービス自体も過去の改修を積み重ねてきたため、影響範囲が複雑です。
どこを確認すべきかを調査・把握することも必須で、単純なテスト作業だけでは十分にカバーできません。
想定漏れによる追加改修も発生するため、QAエンジニア側だけでなく開発エンジニア側も工数負荷が大きく、余裕のない状況になりがちです。

ここまで書いてきた内容以外にも、新規開発では整理しきれない仕様や外部要因により、思いがけない挙動が発生するケースがあります。
こうした場面では、事前にすべての条件を網羅することが難しく、計画したテストだけでは拾いきれないこともあります。
この観点について、もう少し具体的に触れてみます。

偶発的な事象と探索的テスト

テスト観点を洗い出し、ユースケースや影響範囲をもとにテストケースを整理しても、テスト実行時に偶然踏んだ想定外の事象が発見されることがあります。
想定外の事象を見つける手段として、探索的テストは有効な手法です。
ただし、「どこにリスクがあり、何を確かめたいのか」を定めずに実施すると、工数だけが膨らむ一方で、本来期待している検証精度や品質向上につながりません。経験や勘所を活かして「狙いを定めた質の高い探索的テスト」を行うことが重要です。

内部レビュー・教育の重要性

また、内部レビューも欠かせません。
テスト設計のレビューを通じて、経験の浅いメンバーも観点漏れに気づけますが、すぐにスキルアップにつながるとは限りません。
それでもこのプロセスを繰り返すことで、次回以降のテスト精度や設計精度の向上に役立ちます。
単なるバグ検出にとどまらず、チーム全体の経験値向上にもつながる重要な取り組みです。

2.1と2.2の比較表（特徴・課題の整理）

両者では前提条件や必要な観点が異なります。
整理のため、特徴を比較表としてまとめました。

項目	2.1 エンハンス開発	2.2 新規機能開発
対象	既存機能の小規模改修	新しい機能やページ追加
影響範囲	単純で把握しやすい	過去改修の積み重ねで複雑
テストスコープ	改修箇所＋影響範囲に限定	設計・仕様の想定漏れを含む全体、因子・水準洗い出しも必要
テスト設計	既存資料をなぞるだけでも十分	ユースケース・影響範囲を考慮し、抜け漏れ防止の観点整理が必要
開発・QA負荷	比較的小さい	開発もQAエンジニアも工数負荷大。追加改修が発生する場合もある
バグ発生リスク	想定内が多い	想定漏れを拾う必要あり。偶発的に想定外の事象が発見されることもある
探索的テスト	基本不要	想定外の事象を補足する手段として有効。狙いを定めた実施が重要
レビュー・教育	あまり影響なし	観点漏れに気づき、次回以降のテスト設計・実装精度向上につながる
特徴まとめ	効率的にテスト可能	高精度なテスト設計と調査・確認が必須

改めて比較してみると、エンハンス開発と新規機能開発では、求められるテストの粒度や考慮すべき範囲が大きく異なることが分かります。
この違いを理解しておくことで、開発内容に応じたテスト工数や観点の深さを事前に判断しやすくなり、過不足のないテスト設計につなげられるはずです。

過剰・属人化・不明瞭が生まれる理由

実際の開発現場では、限られた時間や不確実な仕様の中でテストを設計することが多く、その結果として、リスクを過大に見積もってテストケースを作り込みすぎたり、仕様理解が不十分なまま観点を立てて抜け漏れが生じたりすることがあります。
また、個々の経験や判断に依存しすぎると、属人化が進み、品質のばらつきにもつながります。
こうした「過剰・不明瞭・属人化」といったアンチパターンについては、
別記事 👉 テスト設計アンチパターン ― 過剰・不明瞭・属人化を防ぐためにでも触れています。

3. 昨期のテスト経験から得た気づき

昨期の取り組みを振り返る中で、感じた気づきや課題がいくつかありました。
特に強く感じた課題は以下の4点でした。

QAエンジニアが疲弊する
チームとして成長しにくい
スクラムとして再現性のある品質担保が難しい
QAエンジニアが「最後の砦」になってしまう（この構造を象徴する表現）

この経験から、「設計・実装段階でリスクを潰すことの重要性」を強く実感しました。
リリース後に振り返りを行った際、開発エンジニアからも「設計レビューで早期に気づけたはずのバグがあった」という声を聞きました。
QAエンジニア側もテスト中心の受け身ではなく、もっとスクラムの中に入り込み、上流でのリスク検知に関わる必要があると痛感しました。

4. 今期：プロセスQAを志向し始めた時期

今期は、プロセスQAを意識し始めた段階として、これまで以上にスクラムの流れに関わるようになりました。
要件や設計レビューのタイミング・進め方をチームで見直す動きが出てきており、仕様の精度を高めるためのコミュニケーションが、開発の早い段階から行われるようになってきています。

また、テストケースを開発者に書いてもらうこともあり、QAエンジニア側で観点整理やレビューを行っています。
レビューやテストによる品質担保は必要ではあるものの、それだけに頼る形だと受け身になりがちです。
受け身になりすぎず、仕組みとして品質を作り込むアプローチも欠かせないと考えています。
例えば、業務要件の観点を共通チェックリストとして整理し、開発段階から確認できるようにすることで担当者依存を減らし、一定の品質基準を維持できる体制を目指しています。

「ふりかえりに活かせるデータとは？」といったテーマもチーム内で話題にし始めており、まだ具体的な収集・分析までは進められていませんが、品質を定量的に見る視点を持ち始めた段階です。

従来業務（テスト設計やE2E改修）も並行して進めているため、これらの取り組みをどこまで優先的に進めるかが今後の課題です。
補足として、従来業務もチーム皆でやる方向にシフトしております。

5. これから挑戦したいこと

「品質をあとから保証する」のではなく、「開発プロセスの中で自然と作り込まれる状態にする」。
これは、今期から意識しているテーマです。
そのために、まず意識したい方向性は3つあります。

設計・開発段階で品質を作り込む仕組みづくり
　レビューのタイミングや観点の共通認識など、再現性を持たせていきたい。
チームで取り組む小さな改善の積み重ね
　すぐにアクションにつながらなくても、気づきを共有し、認知し続けることを大事にしたい。
QAエンジニアが「テスト担当」ではなく、開発プロセスを支える役割へ進化すること
　スクラムの前工程〜後工程まで関わり方を広げ、品質が流れの中で作られる状態を目指したい。

どれも一気に進むものではありませんが、チームと一緒に試しながら、形にしていきたいと思っています。

6. まとめ

これまでの経験から、「テストするだけのQA」ではなく、「品質が流れの中で作られる状態をつくる役割」に向き合い始めています。
テストQAとしての経験があったからこそ、「どこで品質が失われるか」を知れました。
そして今、その経験を土台に、「どうすれば品質が自然と作られるか」を考えるフェーズに立っています。
この移行期はまだ続きますが、迷いや悩みも含めて、自分にとって必要な時間だと思っています。
同じように役割やスタンスが変わる過渡期にいる人の、小さな指標になれば嬉しいです。

ここで書いた気づきや考え方は、QAだけの話ではなく、開発全体に関係するものです。