QAエンジニア
QAエンジニアは、品質をスプリント末尾の関門としてではなく、一つの規律として担います。仕事は、何かが作られる前に要件を問い直すところから始まり、そもそも何をテストする価値があるかを決める段階を経て、そのリリースが利用者に届いてよい状態かについて、根拠を示せる見解にたどり着きます。本ガイドでは、仕事の範囲、それを必要にする状況、そしてリスクを考える候補者と手順書に従う候補者の見分け方を扱います。
QAエンジニアは何をする職種ですか
QAエンジニアは、ソフトウェアプロダクトがどのように壊れうるかを見極め、その失敗を利用者より先にチームが知るようにする職種です。仕事は、開発が始まる前に要件と受け入れ基準を曖昧さの観点で読むこと、リスクが実際に存在する場所を軸にテストを設計すること、台本化された検査では探そうとしなかった問題を見つけるためにプロダクトを探索すること、正しく理解され適切に優先されるだけの明瞭さで不具合を報告すること、そしてリリースの可否について助言することに及びます。本質的に判断の役割です。定義的な技能は、限られた時間の中で何に注意を向け、何には向けないかを決めることにあります。
この仕事の最も難しい部分は引き算です。網羅的なテストは実務上困難であるだけでなく、算術的に不可能です。十個の入力欄と、それぞれ数個の有効な状態を持つフォームは、どんなチームも生涯かけて実行しきれない組み合わせを生みます。したがってテストに関するあらゆる判断は配分の判断であり、二人が同じ件数を実行しても、得られる情報量はまったく異なりえます。完全なカバレッジが目標として不適切なのも同じ理由です。コードカバレッジが記録するのは、テスト実行中にどの行が動いたかであって、その結果の振る舞いが正しいか、アサーションに意味があったか、そもそも要件が正しかったかではありません。
最も価値の高い作業の多くは、コードが存在する前に起こります。不具合の大半は打ち間違いではなく理解の食い違いから生まれます。入力が空のときどうなるかを述べていない受け入れ基準、二人が別々に読む業務ルール、失敗時の挙動が一度も議論されなかった連携です。仕様がまだ書かれている段階で境界での挙動を問うことは、後で発見され、報告され、トリアージされ、修正され、レビューされ、再テストされるはずだった不具合を消し去ります。バグを見つけることはこの職種の目に見える部分で、防ぐことはより価値の高い部分です。そしてそれはほとんど目に見えないため、職務の一部として明示的に認識される必要があります。
この役割の周りには、根強い組織上の罠があります。品質がチーム全体の性質ではなく一つの部署として扱われると、QAは仕事が投げ込まれる関門になります。エンジニアは誰かが見てくれるからと自分のテストを浅くし、検証されていない作業が各スプリントの末尾に溜まり、品質を高めるはずの人は待ち行列の処理に時間を費やします。生産的な形はその逆です。チーム全体のテスト能力を上げ、リスクを早い段階で見えるようにし、他の誰にも時間も心構えもない探索と分析を行うことです。
この能力が必要になる場面
ほとんどのチームは、しばらくのあいだ自分たちの作業を十分にテストできます。以下は、その体制の限界が現れる典型的な圧力です。
流出した不具合が、いつも要件にさかのぼる
リリース後の問題が、実装の誤りではなく「何が起きるはずだったか」についての食い違いだったと判明します。スプリントに入る前に仕様を曖昧さの観点で問い直す人がいないため、同じ誤解が、サイクルの中で最も高くつく地点で繰り返し発見されます。
そのリリースを出して安全かを誰も言えない
判断は感覚か、パイプラインが緑かどうか、あるいは朝会で最も自信ありげに聞こえた人かによって下されます。あとで問題が起きても、何が分かっていて何が仮定だったかの記録がないため、次のリリースでも同じ会話が繰り返されます。
機能と機能の接点に障害が集まる
各機能は単体で見れば動き、問題はそれらの相互作用に現れます。エクスポートの内容を変えてしまう権限の変更、ある画面には効いて別の画面には効かない通貨設定です。自分の作業をテストするエンジニアがその境界をまたぐことはまれです。境界は誰のものでもないからです。
不具合の報告が、不具合そのものより高くついている
再現手順も、環境の情報も、実際の挙動と期待される挙動の記述もなく報告が届き、ときにはその挙動が誤りだという合意すらありません。エンジニアは、書かれた内容を直すよりも報告を組み立て直すことに、相当な時間を費やします。
プロダクトが、正しく動く以上の義務を負っている
アクセシビリティ適合、規制上の要件、データ取り扱いの規則、契約上のサービス水準は、機能テストが探さない類型の失敗を生みます。それらは、作っている最中の開発者が気づける位置にはありません。
チームが自分たちの期待を確認しているだけになっている
人は自分が作ろうとしたものをテストします。これは規律の問題ではなく認知の限界であり、だからこそエンジニアが自分の作業を丹念にテストしても、想像しなかったケースは抜け落ちます。予期しないものを探すことを職業上の習慣にしている人は、まったく別の類型の不具合を見つけます。
中核となる能力
リスク分析
プロダクトのどの部分が壊れたときに最も痛いか、それぞれがどの程度壊れやすいかを見極め、労力をそれに応じて配分します。ソフトウェアと同じくらい事業の理解に依存します。技術的に脆い部分と商業的に重要な部分は、しばしば別物だからです。
テスト戦略
何を自動で検査し、何を人が確かめ、何を本番の監視で検証し、何を承知のうえでテストしないかを決めます。何をテストしないかを述べていない戦略は、計画ではなく願望の一覧です。
要件と受け入れ基準の分析
仕様を「書かれていないこと」の観点で読みます。抜けている境界条件、定義されていないエラー時の挙動、順序や状態についての暗黙の前提、二人の読み手が違う意味に取るルールです。この段階の問いは、不具合を検出するのではなく取り除きます。
テスト設計技法
同値分割、境界値分析、デシジョンテーブル、状態遷移のモデリング、ペアワイズの組み合わせを用いて、不可能な入力空間を、根拠を示せるケースの集合まで絞り込みます。主張されるだけのカバレッジと、論証されたカバレッジの違いはここにあります。
探索的テスト
設計、実行、学習が同時に進む構造化された調査で、通常は明示的なチャーターを持つ時間区切りのセッションとして組み立てます。うまく行えば規律があり記録も残り、あらかじめ決めた台本では見つからない不具合を見つけます。台本は、誰かが既に思いついたことしか探さないからです。
不具合の報告と重要性の主張
初見の人が再現できる報告を書き、そのうえで、なぜその問題が重要かを説得することです。過小評価されがちなのは後半です。正しく報告された不具合でも、重大度を誤って登録されたり、利用者への影響が見えない書き方をされたりすれば、静かに後回しにされ、そのまま出荷されます。
トリアージと重大度の判断
重大度と優先度を切り分け、複数の報告が一つの原因を指していることに気づき、見た目は些細でも構造的な問題を示している報告を見抜きます。信頼できるトリアージは、不具合のバックログを墓場ではなく意思決定の道具に保ちます。
リリース判断
分かっていることと分かっていないことを、意思決定者が動ける形にまとめます。どのリスクを調べ、どれを受け入れ、何が対象外で、デプロイ後に何を見ておくべきかです。この役割は、拒否権を持つことではなく、証拠をもってリリースの判断を支えることです。
ユーザビリティとアクセシビリティの観察
技術的には正しく、実際には誤っている振る舞いに気づくことです。確認のない破壊的な操作、利用者が次に何をすべきか分からないエラーメッセージ、キーボードだけでは完了できない導線です。専門的な監査は独立した分野ですが、監査人の目に触れる前に多くを捕まえられます。
ドメインの理解
そのソフトウェアが何のためにあり、誰がそれに依存しているかを知ることです。ドメイン知識は「合計が思っていた額と違う」を「二つ目の管轄へ発送する注文で、税の丸め方が誤っている」に変えます。それは通常、QAエンジニアが持つ資産の中で最も価値の伸びが速いものです。
技術エコシステム
品質保証で一般的に用いられる技術を以下に示します。これは職種として実践されている領域の全体像を説明するものであり、特定のエンジニアが扱う技術についての主張ではありません。この職種では、多くのエンジニアリング職種に比べてツールの比重は小さくなります。仕事の実体が、特定の製品を操作することではなく分析と判断だからです。
テスト管理とトラッキング
- Jira
- TestRail
- Xray
- Zephyr
- Azure Test Plans
調査と探索
- Browser developer tools
- Postman
- Charles Proxy
- Fiddler
- SQL clients
- Feature flag consoles
仕様づくりと共同作業
- Gherkin
- Example mapping
- Confluence
- Notion
- Miro
アクセシビリティとユーザビリティの検査
- axe DevTools
- WAVE
- NVDA
- VoiceOver
- Lighthouse
本番のシグナル
- Sentry
- Datadog
- Grafana
- Kibana
- Session replay tools
端末とプラットフォームの網羅
- BrowserStack
- Sauce Labs
- Xcode Simulator
- Android Emulator
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- プロダクト
- 事業の優先順位
- ロードマップ
- アーキテクチャ
- スプリントの優先順位
- エンジニアリング標準
- 日々の技術的な協働
Talent.ID handles
- 雇用関係
- 給与支払い
- 従業員福利厚生
- タレント管理
- 継続的な従業員関係
採用時に見るべき点
QAの候補者は、誤った軸で評価されることがよくあります。ツールの習熟や資格は確かめやすい一方、予測力は弱いものです。優れたQAエンジニアと有能なQAエンジニアを分けるのは分析と伝達の力であり、それは具体を尋ねて初めて表に出ます。
リスクについての推論
ある機能領域を示し、最初に何をテストし、何には手を出さないかを尋ねてください。その答えから、結果の重さと起こりやすさで考えているのか、見えるものをすべて網羅しようとしているのかが分かります。意図的にテストしないものを挙げられない候補者は、たいてい実際の締め切りの下で働いた経験がありません。
- 壊れやすいものと、壊れたら高くつくものを区別する
- テストを提案する前に、利用者、取引の金額、規制上の影響について尋ねる
- 受け入れたリスクを挙げ、それをどう他者に見えるようにしたかを説明できる
要件への問いかけ
短く、意図的に不完全な受け入れ基準を渡して、何を尋ねるかを見てください。この職種で得られる最も情報量の多い演習です。予防にこそ投資の回収が集中しており、その技能はその場で装うことができないからです。
- 境界、空の入力、失敗時の挙動へ真っ先に向かう
- 書かれていることを確認するだけでなく、書かれていないことに気づく
- 書き手が敵対的ではなく有用と感じる形で問いを立てる
探索的テストの技能
あるセッションについて詳しく説明してもらってください。何を知ろうとして始め、何も出てこないときに進め方をどう変え、何を記録したかです。弱い候補者はあちこちクリックした話をし、優れた候補者は目的のある方法と、何を見たかの記録を語ります。
- 漠然と眺めるのではなく、チャーターや明示的な問いから始める
- ある観察がセッションの残りの方向をどう変えたかを説明できる
- 他の人が動ける記録を残す
不具合の伝え方
説得が必要だった不具合と、あえて起票しないと決めた不具合の両方を尋ねてください。前者は、ソフトウェアを見ていない人に影響を伝えられるかを示します。後者は、判断を働かせているのか、気づいたものをすべて登録しているだけなのかを示します。
- 誤った挙動だけでなく、利用者や事業への影響を語る
- 重大度と優先度を、机上の区別ではなく実務として切り分ける
- 押しの強さではなく証拠によって、不具合についての判断を変えさせた経験がある
リリースについての判断
未解決の事項が残る中で、出荷についてどう助言するかを尋ねてください。この役割を関門と捉えているか、情報源と捉えているかが表れます。残存リスクを明確に伝え、責任を持つ人に判断を委ねる人のほうが、止める人や素通しする人より役に立ちます。
- 検証したことと並べて、分かっていないことを報告する
- リリース前のテストを増やす代わりに、リリース後の監視を提案する
- 未解決の不具合があることを、自動的に失格とは扱わない
エンジニアとの関係
品質の仕事は、対立的になった時点で機能しなくなります。開発者との意見の相違をどう扱ったか、そしてチームが自分たちの作業をよりよくテストできるようどう手助けするかを尋ねてください。周囲全体の水準を上げる人は、自分だけが多くの不具合を見つける人よりはるかに価値があります。
- 自分の産出量だけでなく、チームのテストを良くすることを語る
- 引き渡しのあとではなく、実装の前から関与する
- 不具合について、立場の問題にせずに意見を異にできる
プロダクトへの関心
最良の診断的な問いは、しばしば「そのプロダクトは何をするもので、誰が使うのか」です。ドメインを理解している候補者は、テストを利用者にとっての帰結として語ります。そうでない候補者は、画面とボタンの言葉で語ります。この二つの答えの差は大きく、そして持続します。
- どうテストしたかを述べる前に、以前のプロダクトの目的を説明する
- ドメインのルールを、微妙な誤りを捕まえられる程度まで深く理解した経験がある
- ある挙動が誤ったとき、誰が損害を受けるのかを尋ねる
面接で尋ねる価値のある質問
用語ではなく推論が表に出る質問です。御社ご自身の選考プロセスの中で参考としてお使いいただくために挙げています。各候補者を面接し、誰をチームに迎えるかを決めるのは御社です。
リリースまで二日あり、やろうと思えば二日をはるかに超えるテストができます。何をテストするかをどう決めますか。
What a strong answer shows
優先順位付けが身についた習慣なのか、その場しのぎなのかが分かります。優れた回答は、変更点、結果の重さ、起こりやすさから考え、意識的に省くものを挙げ、残存リスクを黙って飲み込むのではなくどう伝えるかを述べます。
ある機能の受け入れ基準です。開発が始まる前にどんな質問をしますか。
What a strong answer shows
予防の勘です。境界、空の値と最大値、同時アクセス、依存先の障害、そして既にシステムにあるデータをどう扱うべきかを聞いてください。質問の数より、それが作り直しを招いたはずの質問かどうかが重要です。
すべての工程をすり抜けた不具合について教えてください。何が流出を許し、その後何が変わりましたか。
What a strong answer shows
流出を仕組みとして分析するのか、不運として扱うのかが分かります。最も優れた回答は、その不具合を最初に捕まえられたはずの地点を特定し、テストケースを一つ足すのではなく、その地点の変更を語ります。
テストカバレッジ100%は目指す価値のある目標ですか。その理由は。
What a strong answer shows
カバレッジが何を測っているかを理解しているかどうかです。完全なカバレッジを望む候補者は、たいてい検査群を保守した経験がありません。カバレッジを全否定する候補者は、まったく使っていないかもしれません。最良の回答は、それを未テスト領域を見つけるためのシグナルとして扱い、達成すべき目標としては扱いません。
あなたが起票した不具合について、開発者が「直す価値はない」と言いました。どう対応しますか。
What a strong answer shows
主張の仕方と、釣り合いの感覚の両方です。開発者やプロダクトオーナーが気にする言葉で影響を言い直し、筋の通った判断は受け入れ、繰り返すのではなく上申すべき場面を心得ている人を探してください。
理解していないもの——不慣れなドメインや、誰も文書化していない機能——をどうテストしますか。
What a strong answer shows
不確実さの中での進め方であり、それはこの職種の通常の状態です。優れた回答は、利用者が誰かを調べ、存在する資料を読み、意図された振る舞いのモデルを組み立て、そのモデルに対してソフトウェアをテストする、という筋道を語ります。
自分では不具合を見つけていないのに品質を高めたことは何ですか。
What a strong answer shows
この役割の投資対効果がどこで最も大きいかを理解しているかどうかです。受け入れ基準の書き直し、Example mappingの場の導入、不具合トリアージの改善などが挙がりえます。自分を不具合の件数だけで測っている候補者には、たいてい答えがありません。
未解決の問題があるにもかかわらず、リリース可能と判断したときのことを教えてください。
What a strong answer shows
規則ではなく判断に向き合えるかどうかです。リスクの明確な記述、誰がその判断を下したか、どんな監視を用意したか、そして結果を振り返ったかを見てください。既知の問題を決して受け入れられないという姿勢は、それ自体が注意すべき兆候です。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- あるチームがリリース頻度を上げようとしたところ、これまでの品質のやり方が変化に耐えないことが分かりました。検証は各サイクルの末尾にまとめて行われており、不具合は日程をずらさずに直せる時期を過ぎてから現れ、デプロイの前に何を確かめ何を確かめていないかを、プロダクトオーナーに明確に説明できる人がいません。
- Approach
- 増強された品質側の体制は、チームが既に持つデリバリープロセスの中で作業します。チケットの流れ、完了の定義、リリースの周期、品質の基準です。優先順位を決め、何を出すかを判断するのは引き続きお客様のエンジニアとプロダクトオーナーであり、増強分は、作業が通過しなければならない別の工程としてではなく、彼らと並んでリスク分析、テスト設計、探索的な作業に貢献します。
- What this adds to the team
- チームは、プロダクトの意思決定とエンジニアリング基準の主導権を保ったまま、品質面の余力を得ます。何をもってリリース可能とするかは、引き続きお客様の判断です。
Related disciplines
Frequently asked questions
- QAエンジニアとテスト自動化エンジニアは何が違いますか
- QAエンジニアは、品質を規律として担います。どのリスクが重要か、仕様が何を未定義のままにしているか、台本化された検査が決して探そうとしないものは何か、そしてそのリリースを出すべきかです。テスト自動化エンジニアは、自動テストのシステムそのものを担います。フレームワークの設計、テストデータ、環境の制御、結果を決定的に保つこと、そして待つ価値があるだけの実行速度にすることです。前者は判断の幅で定義され、後者は検査群を成果物とするエンジニアリングの職種です。両者は入れ替え可能ではなく補完的です。品質の判断なしに作られた検査群は、誤ったものを非常に確実に検査し続けます。
- QAエンジニアはコードを書く必要がありますか
- 有効に働くのに必要なだけで、それは求人票が示唆するより少ないのが通例です。コードベースを読むこと、データベースに問い合わせること、APIを直接呼ぶこと、スタックトレースをたどること、ネットワーク通信を確認することは、いずれも仕事の質を大きく高めます。自動化フレームワークの構築と保守は重心の異なる別の職務であり、QAの職に強いプログラミング能力を要求すると、この役割が最も依存する分析力と伝達力のある候補者をふるい落としがちです。
- QAエンジニアがいるとチームは遅くなりますか
- 品質が関門として配置されていれば遅くなります。作業が完了し、引き渡され、待ち行列に入り、差し戻され、やり直され、その引き渡し自体が制約になるからです。要件が書かれる段階からQAエンジニアが関わっていれば、通常は遅くなりません。そもそも作られなかった不具合こそが、最も時間を奪ったはずのものだからです。品質の人員を足してチームが遅くなったなら、原因はたいてい人ではなく配置の仕方です。
- 開発者が自分でテストすればよいのではありませんか
- 開発者は自分でテストすべきですが、それだけでは十分ではありません。開発者が自分の作業をテストするとき検証されるのは、意図したとおりに動くかどうかであり、考えもしなかったケースは手つかずのまま残ります。どれだけ入念でもその限界は消えません。それは、そのものを作った本人であることの性質だからです。QAエンジニアは、そのソフトウェアが何をするべきかについての独立したモデルと、意図されたものではなく予期しないものへ向かう習慣を持ち込みます。
- QAはエンジニアリングに属するべきですか、独立した部門であるべきですか
- QAエンジニアをデリバリーチームに埋め込むほうが、一般にうまくいきます。予防を可能にするのは近さであり、品質を引き渡しに変えてしまうのは距離だからです。大きな組織では、専門職としての水準を保つために別の報告線が役立つこともあります。しかし品質保証が、完成した作業を受け取る独立部門になると、おなじみの失敗が続きます。エンジニアのテストは浅くなり、待ち行列は伸び、品質はチームが外部に委ねたと思い込むものになります。
- 品質の仕事にはどの程度の経験が必要ですか
- どれだけが未確定かによります。確立された進め方を、よく仕様化された機能に対して実行することは、中堅の水準で十分に行えます。そもそもチームが何をテストすべきかを定めること、プロダクトオーナーとリスクを交渉すること、品質の実践が存在しないところにそれを築くことには、そうした判断が時間の中でどう転がるかを見てきた人が必要です。ここでの判断の弱さは、数か月後に、チームが気づかなくなったものの形で現れます。
- QAエンジニアは既存の開発チームとどのように働きますか
- 御社のチームに参画するQAエンジニアは、既存のデリバリープロセスに従います。ワークフロー、完了の定義、エンジニアリング基準、リリースの周期です。これは開発チームの増強という形態ですので、日々の優先順位、プロダクトの方向性、出荷の判断はすべて御社に残ります。Talent.ID側が担うのは、雇用関係、タレント管理、給与支払い、従業員福利厚生、そして継続的な従業員関係です。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.