QAエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

QAエンジニアのスキルシートは、「テスト担当」とひとまとめにせず、計画・設計・実行・管理のどの工程を担ったかを書き分け、使ったテスト技法と、品質の状態を誰にどう伝えたかを添えるのが基本です。テストの案件は、同じ「総合テスト」でも、観点を考えて計画を立てる人と、決まった手順書に沿って実行する人とで、求められる経験が大きく違います。読み手はシートから、その違いを見分けたいと考えています。

工程ごとに求められるスキルはQAエンジニアのスキルの記事、全体の構成はスキルシートの基本で扱っています。この記事では、QAならではの書き方に絞って説明します。

工程は「テストの段階」と「担った作業」の二軸で書く

QAの経歴は、テストの段階（単体・結合・総合・受け入れなど）と、その中で担った作業（計画・設計・実行・管理）の二つが混ざりやすい分野です。片方だけを書くと、担った範囲が伝わりません。

プロジェクト欄の「担当工程」は、次のように二つを組み合わせて書きます。

実行が中心の経歴でも、そのまま書いてかまいません。そのうえで、実行の中で自分の判断で行ったこと（追加の観点の提案、手順書の誤りの指摘など）を担当内容に書くと、設計に広げられる人として読まれます。

使ったテスト技法を名前で書く

テスト設計を担った方は、使った技法を名前で書くと、設計の深さが伝わります。

• 同値分割と境界値分析で入力の組み合わせを絞った
• 状態遷移図を作り、画面と処理の状態の抜けを確かめた
• デシジョンテーブルで条件の組み合わせを整理した
• 探索的テストの時間を区切って行い、記録を残した

技法の名前は、JSTQBの用語にそろえると、発注元と言葉が合いやすくなります。技法を使い分ける考え方はQAエンジニアのスキルの記事にまとめているので、スキルシートでは「どの対象に、どの技法を使ったか」を1行で書くことに集中しましょう。

件数の数字は「規模」として添える

QAのスキルシートでよく見るのが、「テストケース○千件を作成」「不具合○百件を検出」という書き方です。これらの数字は、扱った規模の目安にはなりますが、そのまま成果として読まれるわけではありません。

• テストケースの件数は、粒度の決め方で大きく変わる
• 不具合の件数が多いことは、開発の品質の問題でもあり、テストの成果とは限らない
• 件数を競うように書くと、「数をこなす人」と受け取られることがある

件数は、案件の規模を伝える材料として「数千件規模のテストケースを管理」のように桁でぼかして添え、成果の欄には判断と改善を書きます。

• 不具合の傾向を分析し、設計の段階で観点を追加した
• リリースの判断の材料として、残った不具合の影響を整理して報告した
• 手順書の書き方をそろえ、担当者が変わっても同じ結果になるようにした

品質の状態をどう伝えたかを書く

QAエンジニアの仕事は、不具合を見つけることだけではなく、品質の状態を関係者が判断できる形にすることです。スキルシートでは、報告の相手と方法を書くと、この力が伝わります。

• 報告の相手：開発チーム、プロジェクトの責任者、発注元の担当者
• 報告の方法：日次の進み具合の共有、不具合の傾向をまとめた週次の報告、リリース前の判定会議の資料
• 使った指標：消化の進み具合、不具合の発見と修正の推移、重大な不具合の残り

指標の数字そのものは書かなくてかまいません。「不具合の発見の推移を見て、収束の見込みを報告した」のように、何を見て何を判断したかを書きます。

対象の分野と環境を書く

テストの案件では、対象の分野の知識や、確かめる環境の経験が、技術と同じくらい読まれます。

分野の知識は、業種の名前より「何の機能を確かめたか」で書くと伝わります。たとえば「金融系」より「口座の振替と残高の計算の確認」のほうが、案件との結びつきが分かりやすくなります。

発売前の製品の情報は書かない

QAの仕事では、公開前の製品や機能に触れることが多くあります。スキルシートには、次のような情報を書かないでください。

• 公開前の製品名や、発表されていない機能の内容
• 見つけた不具合の具体的な中身（特に、利用者に影響したもの）
• テストの対象の画面や操作の手順を写したもの

公開済みの製品であっても、どの製品のテストを担当したかを書けるかは、契約の内容によって違います。迷ったら「スマートフォン向けのゲームアプリ」のように種類で書きましょう。線引きの考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

短い案件が多い経歴のまとめ方

テストの仕事では、数週間から数か月の案件を次々に担当してきた方も少なくありません。すべてを同じ分量で並べると、シートが長くなり、得意なことが見えなくなります。

• 同じ種類の対象が続いた期間は、「スマートフォンアプリのテスト（20XX年〜20XX年・十数件）」のようにまとめる
• まとめた中で、最も深く関わった1件だけをくわしく書く
• 担った工程が広がった時点（実行から設計へ、など）が分かるように並べる

工程が広がっていった流れが見えると、短い案件の多さは、むしろ経験の幅として読まれます。

プロジェクト欄の記入例

以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（10か月）
案件概要：サービス業向け 予約と決済のWebアプリの刷新
規模・立場：テストチーム6名（自分は総合テストのリーダー）
担当工程：総合テスト（計画・設計・実行の管理）、受け入れテストの支援
使った技法：予約の状態に状態遷移図、料金の計算にデシジョンテーブル、入力に同値分割と境界値分析
ツール：不具合の管理ツール、テストの管理ツール、実機の端末とブラウザの組み合わせ表
担当内容：リスクの高い決済まわりから優先順位をつけて計画を立てた。メンバーの設計をレビューした
報告：不具合の推移と重大な不具合の残りを週次でまとめ、リリース前の判定会議の資料を作成した
工夫・成果：前の段階の不具合の傾向から観点を追加し、手戻りの多かった機能の確認を前倒しした

件数は書いていませんが、工程・技法・報告の相手がそろっているため、担える範囲が伝わります。

資格の書き方

QAの分野には、JSTQBの認定テスト技術者資格があります。2026年10月時点の公式サイトでは、Foundation Levelのほか、Advanced Level（テストマネジメント、テストアナリスト、テクニカルテストアナリスト、テスト自動化エンジニアなど）や、分野別の資格が案内されています。スキルシートには、「JSTQB認定テスト技術者資格 Foundation Level」のように、区分まで含めた名称と取得年月を書きます。区分ごとの役立つ場面はQAエンジニアのスキルの記事で整理しています。

よくある質問

テストの実行だけの経験でも、スキルシートで評価されますか？

実行の中で自分の判断で行ったことを書けば、評価の材料になります。手順書の誤りの指摘、追加の観点の提案、再現の手順を整えた不具合の報告などです。設計に広げたい場合の準備はQAエンジニアがフリーランスになるにはも参考になります。

テスト自動化の経験は、どう書けばよいですか？

自動化の比重が小さければ、ツールの欄と担当内容に書き添える程度で十分です。自動化が仕事の中心になっている場合は、書く観点が変わるため、テスト自動化エンジニアのスキルシートの記事を参考に、プロジェクトを分けて書くことをおすすめします。

開発エンジニアからQAに移る場合、開発の経歴はどう書けばよいですか？

開発の中で担ったテストやレビューの経験を中心に書きます。単体テストの設計、不具合の原因の調査、コードのレビューなどは、QAの案件で技術的なテストを担える力として読まれます。開発の経歴そのものは短くまとめ、要約でQAに軸を移したいことを示しましょう。