ホーム / QA / 第1部 QA エンジニアとは

第1部 QA エンジニアとは・第1章

QA エンジニアとは

★★☆ 重要6トピック・面接 4問

まとめクイズ面接ではこう聞かれる（4問）

QA エンジニアの仕事の範囲と、求められる技術の全体像を押さえる。

1.1QA エンジニアの仕事と呼び名

用語★★☆ 重要

ひとことで

品質の目標を決め、テストの戦略を立て、自動化と探索的テストでリスクを減らし、品質をチームの文化にする。

QA（Quality Assurance＝品質保証）エンジニアの仕事は、「リリースしてよい品質か」をチームが判断できるようにすることです。テストを実行するのは仕事の一部で、品質の目標を決める、どこを重点的に確かめるかの戦略を立てる、テストを自動化する、不具合が入りにくい仕組みをチームに広める、までが範囲です。

QA エンジニアの仕事の範囲（テストの実行はその一部）

呼び名	主な仕事	求められる技術
QA エンジニア	品質の目標・テスト戦略を決め、プロセス全体の品質を見る	テスト設計、仕様の読み込み、リスクの判断、調整
テストエンジニア	テストケースを作って実行し、不具合を報告する	テスト設計の技法、再現手順の書き方
SET（Software Engineer in Test）	テストの自動化の仕組み・道具を作る	プログラミング、CI、テストのフレームワーク
SDET（Software Development Engineer in Test）	開発者として製品のコードも書きつつ、テストしやすい設計と自動テストを担う	開発の技術全般＋テスト

呼び名の使い分けに決まった基準はなく、会社によってまちまちです（上の表は一般的な傾向）。求人では中身（手動中心か、自動化中心か、製品のコードも書くか）を見るのが確実です。

面接ではこう答える

QA エンジニアの仕事は、チームが「リリースしてよい品質か」を判断できるようにすることです。テストを実行するのはその一部で、品質の目標を決め、リスクから「どこを厚く確かめるか」の戦略を立て、自動化で速く何度でも確かめられるようにします。さらに、仕様の段階から関わったり、振り返りで再発防止を仕組みにしたりして、不具合が入りにくいチームにしていきます。

QAとの関わり自己紹介・職務経歴の説明の土台です。手動中心か自動化中心か、どこまで関わってきたかをこの範囲で説明します。

1.2開発の段階ごとの QA の仕事（シフトレフト）

用語★★☆ 重要

ひとことで

不具合は見つかるのが遅いほど直す手間が大きいので、企画・要件の段階から QA が関わり、早く見つける（シフトレフト）。

開発の各段階での QA の仕事と、見つかる時期による直す手間の違い（イメージ）

段階	QA がすること
企画・要件	仕様のあいまいな点・抜けを質問する（「0件のときは？」「同時に押したら？」）。受け入れ条件を一緒に決める
設計	テストしやすい設計か見る（テスト用のデータを入れられるか、ログが出るか）。リスクを洗い出してテスト計画を立てる
実装	テストケースを作る。開発者の単体テストの範囲を確認し、自動テストを書く
テスト	テストの実行、探索的テスト、不具合の報告と修正の確認
リリース・運用	リリース判定の材料を出す。本番での確認、問い合わせや障害の分析、再発防止

一般に、不具合は見つかるのが遅いほど直す手間が大きくなります（作り直す範囲や、確かめ直す範囲が広がるため）。そのため、早い段階から関わること（シフトレフト）が重視されています。仕様の段階で「この場合はどうなりますか」と聞くだけで、作り直しを防げることがよくあります。

面接ではこう答える

シフトレフトは、テストや品質の活動を開発の早い段階、つまり時間軸の左側へ寄せる考え方です。不具合は見つかるのが遅いほど、作り直す範囲や確かめ直す範囲が広がって手間が大きくなります。そこで QA は、要件の段階で「0件のときは？」「同時に押したら？」とあいまいな点を質問したり、受け入れ条件を一緒に決めたりします。テストの工程を待たずに関わるのがポイントです。

QAとの関わり仕様レビューへの参加、受け入れ条件の作成、テストしやすい設計の提案など、QA の日々の動き方そのものです。

1.3QA・QC・テストの違い

用語★★☆ 重要

ひとことで

テストは動かして確かめる活動、品質管理（QC）はできたものを確かめること、品質保証（QA）は仕組みで品質を作り込むこと。

3つは似た言葉ですが、範囲が違います。一般的には、テストは品質管理の手段の1つで、品質管理（QC）は品質保証の一部、という入れ子で整理されます。

QA・QC・テストの関係（一般的な整理）

	ねらい	QA エンジニアの動き方の例
品質保証（QA）	不具合が入りにくい仕組みを作る（予防）	仕様レビューに入る、テスト戦略を決める、再発防止を仕組みにする
品質管理（QC）	できたものが基準を満たすか確かめる（検出）	テスト結果や不具合の傾向をまとめ、リリース判定の材料を出す
テスト	動かして期待どおりかを確かめる	テストケースを作って実行する、自動テストを書く

面接で「QA とテストの違い」を聞かれたら、「テストは見つける活動、QA は見つける前に防ぐ仕組みまで含む」と答えると伝わりやすいです。言葉の使い方は会社によって違うので、定義の暗記より、自分がどこまで担ってきたかを話せることが大事です。

面接ではこう答える

テストは、ソフトウェアを動かして期待どおりかを確かめる活動です。品質管理、QC は、できたものが基準を満たすかを確かめることで、テストはその手段の1つです。品質保証、QA はさらに広く、不具合が入りにくいように仕組みやプロセスを整えることまで含みます。つまり、テストは見つける活動、QA は見つける前に防ぐことまで含む、という違いです。

QAとの関わり「QA とテストの違いは？」はよく聞かれる質問です。自分の経験を「検出」と「予防」に分けて話すと、仕事の範囲の広さが伝わります。

1.4テストの7原則

用語★★☆ 重要

ひとことで

ISTQB がまとめた、テストの限界と考え方の7つの原則。「不具合がないことは示せない」「全部はテストできない」など。

テストの国際的な資格 ISTQB のシラバスにある「テストの7原則」は、テストの限界と考え方をまとめたものです。面接で直接聞かれることは多くありませんが、判断の理由を説明するときの土台になります。

原則	意味	実務での使い方
欠陥があることは示せるが、ないことは示せない	テストで不具合が見つからなくても「不具合がない」証明にはならない	リリース判定では「残るリスク」を言葉にして伝える
全部をテストすることはできない	入力・状態・環境の組み合わせは事実上無限	テスト設計の技法とリスクで絞り込む
早くテストするほど、時間と費用を節約できる	要件や設計の段階で見つけた問題は直す範囲が小さい	仕様レビューに入る（シフトレフト）
欠陥は一部に集中する	不具合は特定の機能や部品に偏りやすい	過去に不具合が多かった所を厚くテストする
同じテストは効果が薄れる	同じテストを繰り返すと、新しい不具合は見つけにくくなる（殺虫剤のパラドックス）	テストケースを定期的に見直し、探索的テストで補う
テストは状況しだい	決済と社内ツールでは、適したテストのやり方が違う	製品の性質に合わせて戦略を変える
「欠陥ゼロ」の落とし穴	不具合がなくても、利用者の役に立たなければ意味がない	仕様どおりかだけでなく、使われ方も確かめる

たとえば「全部テストしましたか？」と聞かれたら、2つ目の原則を背景に、「全部はできないので、リスクの高い所をこの技法でこう確かめた」と答えます。

面接ではこう答える

テストの7原則は、ISTQB という資格のシラバスにある、テストの基本的な考え方です。代表的なのは「テストは不具合があることは示せるが、ないことは示せない」「全部をテストすることはできない」「早くテストするほど安く済む」の3つです。だから QA は、リスクで優先順位を付けて限られた時間を配分し、リリース判定では残るリスクを言葉にして伝えます。

QAとの関わりテスト範囲を絞る理由や、「テストしたのに不具合が出た」ことの説明に使えます。

1.5チームでの QA の関わり方（体制の型）

用語★★☆ 重要

ひとことで

QA の体制には、独立した QA チーム・開発チームへの埋め込み・全員で品質（QA はコーチ役）の型がある。

QA がどこに所属し、開発とどう関わるかは会社によって違います。面接では「今の体制」と「応募先の体制」の違いを聞かれたり、逆質問で確かめたりする大事な点です。

QA の体制の3つの型（実際は組み合わせることが多い）

体制	良いところ	気をつけること
独立した QA チーム	開発から距離を置いた目で見られる。専門性を育てやすい	最後にまとめて渡されがちで、待ちと手戻りが増える
開発チームに埋め込み	仕様の段階から関われる。毎日の会話で早く直る	QA が1人だと孤立しやすい。QA 同士で知識を共有する場を作る
全員で品質（QA はコーチ）	開発者がテストを書き、速く回る	探索的テストやリスクの判断が抜けやすい。QA が戦略と仕組みを担う

どの型でも、「品質は QA だけの責任ではなく、チーム全体のもの」という考え方が今は一般的です。QA は、テストを引き受ける人というより、チームが品質を上げられるように仕組みを作る人として振る舞うと評価されます。

面接ではこう答える

QA の体制は大きく3つの型があります。独立した QA チームは客観的に見られる反面、最後にまとめて渡されて手戻りが増えがちです。開発チームに埋め込む型は、仕様の段階から関われて速く直ります。全員で品質を担う型では開発者もテストを書き、QA は戦略や仕組みづくり、探索的テストに集中します。どの型でも、品質はチーム全体の責任だという考え方が前提です。

QAとの関わり転職先を選ぶときの大事な観点です。逆質問で「QA は何人で、開発とどう関わっていますか」と聞くと、仕事の中身が分かります。

1.6向いている人とキャリア

用語★☆☆ 発展

ひとことで

「どうやったら壊れるか」を想像でき、仕組みで品質を上げるのが好きな人に向く。

向いているのは、「どうやったら壊れるか」を想像するのが好きな人、細かい違いに気づける人、そして見つけたことを相手に伝わる形で説明できる人です。不具合を見つけるだけでなく、「なぜ入ったか」「仕組みでどう防ぐか」まで考えられると、評価が大きく変わります。開発者と対立せず、同じチームとして品質を上げる姿勢も大切です。

その先のキャリア

進む先	主な仕事	QA の経験で活きること
テスト自動化（SET・SDET）	テストの仕組み・道具・CI を作る	何を自動化すべきかの判断、flaky への対処
SRE	本番の安定（監視・障害対応・リリースの安全装置）	負荷テスト、障害の分析、影響範囲の見立て
PdM（プロダクトマネージャー）	何を作るかを決める	仕様の抜けに気づく力、利用者の使い方の知識
QA のリード・マネージャー	品質の戦略と組織づくり	リスクで優先順位を付ける判断、チームの巻き込み

面接ではこう答える

QA に向いているのは、「どうやったら壊れるか」を想像するのが好きで、細かい違いに気づき、それを相手に伝わる形で説明できる人です。不具合を見つけるだけでなく、なぜ入ったのか、仕組みでどう防ぐかまで考えられると価値が上がります。キャリアは、テスト自動化の専門家、SRE、PdM、QA のリードやマネージャーなどに広がります。

QAとの関わり志望動機やキャリアの質問で、「なぜ QA なのか」「この先どうなりたいか」を話す材料になります。

この章のまとめ

🖨 まとめシート（印刷・PDF）

テストするだけでなく、品質を作り込む仕組みをチームで作る
開発の早い段階から関わる（シフトレフト）
テストの限界（全部はテストできない）を前提に、リスクで考える

QA エンジニアの仕事と呼び名：品質の目標を決め、テストの戦略を立て、自動化と探索的テストでリスクを減らし、品質をチームの文化にする。
開発の段階ごとの QA の仕事（シフトレフト）：不具合は見つかるのが遅いほど直す手間が大きいので、企画・要件の段階から QA が関わり、早く見つける（シフトレフト）。
QA・QC・テストの違い：テストは動かして確かめる活動、品質管理（QC）はできたものを確かめること、品質保証（QA）は仕組みで品質を作り込むこと。
テストの7原則：ISTQB がまとめた、テストの限界と考え方の7つの原則。「不具合がないことは示せない」「全部はテストできない」など。
チームでの QA の関わり方（体制の型）：QA の体制には、独立した QA チーム・開発チームへの埋め込み・全員で品質（QA はコーチ役）の型がある。
向いている人とキャリア：「どうやったら壊れるか」を想像でき、仕組みで品質を上げるのが好きな人に向く。

この章のクイズ

問題数苦手を優先

面接ではこう聞かれる

用語の説明（6問）も含める

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1QA として品質にどう貢献してきましたか？

模範回答

テストで不具合を見つけることに加えて、不具合が入りにくい仕組みを作ることが QA の貢献だと考えています。例えば、リリース後に見つかる不具合の多くが「仕様のあいまいさ」から来ている現場なら、仕様のレビューに QA が入り、受け入れ条件を開発者と一緒に書くようにします。

また例えば、毎回手動で2日かかる回帰テストがあれば、ログインや購入などの主要な流れから Playwright で自動化して CI に組み込み、プルリクエストごとに流れるようにします。そうするとリリース前の確認が短くなり、空いた時間を変更の大きい部分の探索的テストに使えます。実際の面接では、ここに自分の経験と、効果を示す数字（流出した不具合の数や確認にかかる時間）を入れて話します。

深掘りされたら

その取り組みで、開発者の協力はどうやって得ましたか？
効果はどの指標で確かめましたか？

見られているポイントテスト以外の仕組みづくりも含めて

Q2QA とテストの違いは何ですか？

模範回答

テストは「作ったものを動かして、期待どおりか確かめる活動」で、QA（品質保証）はそれを含む、もっと広い「品質を作り込む仕組み全体」だと考えています。テストは問題を見つけますが、QA は問題が入りにくいプロセスを作ることも目的にします。

例えば、仕様のレビューで「0 件のときはどう表示するか」を先に決める、受け入れ条件をチケットに書く、自動テストを CI に入れる、不具合の原因を振り返って再発を防ぐ、といったことはテストの実行ではありませんが、QA の仕事です。そのため QA は、テストの担当というより、チーム全体の品質の仕組みの担当だと考えています。

深掘りされたら

品質保証（QA）と品質管理（QC）の違いは説明できますか？
QA がいなくても品質を保てるチームとはどんなチームですか？

見られているポイントテストの実行だけでなく、プロセスで品質を作る視点

Q3シフトレフトとは何ですか？ QA として具体的に何をしますか？

模範回答

シフトレフトは、テストや品質の確認を開発の流れの早い段階（図で左側）に前倒しすることです。一般に、不具合は見つかるのが遅いほど、作り直しや確かめ直しの範囲が広がって直す手間が大きくなるので、早く見つけるほど安く済みます。

QA として具体的には、企画や仕様の段階でレビューに入り、境界の値やエラー時の動き、同時操作などの抜けを質問します。受け入れ条件を開発者・PdM と一緒に決め、それをそのままテストケースや自動テストの元にします。設計の段階では、テスト用のデータを入れられるか、ログが出るかなど「テストしやすい作りか」も確かめます。

深掘りされたら

シフトレフトを進めると、リリース前のテストは不要になりますか？
「シフトライト」という言葉を聞いたことはありますか？

見られているポイント早期の関与の具体的な行動（仕様レビュー・受け入れ条件）

Q4開発者に「それは仕様です」と言われたら、どうしますか？

模範回答

まず、言い争いにせず、根拠となる仕様書やチケットを一緒に確認します。本当に仕様どおりなら、その不具合の報告は取り下げます。そのうえで、利用者にとって困る動きだと思う場合は、「不具合」ではなく「仕様の改善の提案」として、PdM など仕様を決める人に判断してもらいます。

例えば、検索で 0 件のときに何も表示されないのが仕様だとしても、利用者には読み込み中なのか結果がないのか分かりません。そのときは、困る場面と影響の大きさ（問い合わせが増えそう、など）を添えて提案します。仕様が書かれていなかった場合は、今後同じことが起きないよう、受け入れ条件に書く項目を見直すきっかけにします。

深掘りされたら

PdM が「今回は直さない」と決めたら、どうしますか？

見られているポイント対立せずに根拠を確認し、判断者につなぐ姿勢