エンジニアという仕事自社プロダクトのQAエンジニア
自社プロダクトのQAエンジニア
自社サービスの品質を、企画・開発の初期段階から関わって作り込んでいく仕事です。単にリリース前にテストを実行するだけでなく、仕様レビューでの問題発見や、テスト自動化の推進、品質指標のモニタリングなど、プロダクト開発チームの一員として品質そのものを設計します。
テスト技法の基礎知識やプロダクトへの理解が前提として求められることが多い
月の残業は目安15〜25時間程度。リリース直前はテストが集中し、忙しさが波打ちやすい
求人の中心的なレンジ。テスト自動化・仕様レビュー等の上流スキルで上振れしやすい
- 業務内容
- 仕様書・要件定義書のレビューによる不具合の早期発見
- テスト計画・テストケース(『どんな操作をして何が起きれば正しいか』をまとめた確認項目リスト)の設計
- 手動テストの実施、E2Eテスト(実際のユーザー操作を再現するテスト)の自動化推進
- バグ管理・優先度の判断、開発チームへのフィードバック
- リリース判定に関わる品質指標のモニタリング
- 具体的な業務イメージ
新機能のテストケース(確認項目)は1機能あたり数十〜100項目規模になることもあり、テストケースの管理にはExcelや専用のテスト管理ツールが使われます。見つけたバグはバグ管理ツール(JIRA等)に起票し、再現手順・重要度を整理した上で開発チームに報告します。E2Eテスト(実際のユーザー操作を再現するテスト)の自動化にはコードを書く必要があり、手動テストと自動化コードの作成を並行して進めるのが一般的です。リリース直前は、限られた時間で優先度の高い項目からテストを終わらせる判断力が求められます。
- この仕事のやりがい
- リリース前に重大な不具合を発見し、ユーザーへの影響を未然に防げたときの達成感
- 開発の初期段階から品質を作り込む文化をチームに根付かせられる
- テスト自動化によって、手動作業を減らしながら品質を高められる
- 向いている人
- 仕様の抜け漏れや矛盾に気づく観察力・注意力がある人
- 「壊すつもりでシステムを見る」視点を楽しめる人
- 開発者と対等に議論しながら品質を作り込みたい人
- 向いていない人
- 新機能を作る側に回りたい気持ちが強い人
- 細かい確認作業の繰り返しにモチベーションを保ちにくい人
- 不具合の指摘で開発者との摩擦が生じることにストレスを感じやすい人
- つまずきやすいポイント
- リリーススケジュールが優先され、テスト工程が圧縮されやすい
- 不具合の指摘が開発者との関係にストレスを生むことがある
- テスト自動化の整備に時間がかかり、当初の期待値とのギャップが生まれることがある
- 必要スキル
- テスト設計・テスト技法の知識 テスト自動化ツールの実装力 仕様理解・レビュー力 バグ管理・優先度判断力 開発チームとの折衝力
- その後のキャリアパス例
- QAのテックリード・品質保証責任者へ
- SET(Software Engineer in Test、テスト基盤を開発するエンジニア)へ
掲載の年収は各パターンの求人情報から算出した中央値の参考レンジです(quickfactsを参照)。経験・スキル・企業規模により変動します。
この職種で転職を考えたら
相性の良い転職エージェントは人によって違います。求人の量や、担当者との相性を見るためにも、2〜3社まとめて登録しておくのがおすすめです。
求人数が多く、まず1社目に登録しておきたいタイプ
求人を見る(準備中)エンジニア求人・選考ノウハウに強いタイプ
求人を見る(準備中)自分のペースで求人を探したい人向け
求人を見る(準備中)※求人リンクは現在準備中です。ASPとの提携が完了し次第、実際の求人ページへのリンクに差し替えます。