QAエンジニアのスキルシートの書き方｜品質実績の数値化と職種別テンプレ
最終更新日：2026/09/01
QAエンジニアのスキルシートは、テスト工程・自動化率・不具合検出数など品質の仕事を数値で表現できるかで、通過しやすさに差が出やすい書類です。マニュアルQAから自動化SET・SDETまで、フリーランスのQAエンジニア向けに、案件欄・実績欄の書き方をテンプレとNG/OK例で整理しました。
先に結論
品質実績は「担当テスト工程／不具合検出・再発防止／自動化カバレッジ／リリース判定への関与」の4軸で書くと評価されやすいです
テスト計画・設計・実行・報告のどこを担当したのかを工程名で明示し、「テスト全般」のようなぼかし表現は避けます
自動化・SET・SDETの経験は、対象レイヤ（UI／API／E2E）と使用ツール（Selenium／Playwright／Cypress など）をセットで書きます
マニュアルQAでも、テストケース件数・欠陥検出率・回帰テスト工数などの数値で語ると差別化しやすくなります
単価を上げたい場合は「品質判断を任された経験」（リリース可否判定、GateKeeper＝リリース可否の最終確認役、上流レビュー）を1〜2行足すと評価材料になりやすいです
スキルシートの全体書式はフリーランスエンジニアのスキルシートの書き方を徹底解説！記入例や今すぐ使えるフォーマットも紹介！に委ね、本記事はQA特有の「実績欄・案件欄」の書き方に絞ります
この記事でわかること
QAエンジニアのスキルシートで評価される観点と、通らない書類の共通点
品質実績を数値で表す4つの型と、そのままコピーできるフレーズ集
テスト工程別・自動化領域別・案件タイプ別の実績表現テンプレ
ケース別（駆け出しQA／リード経験／開発兼務／ドメイン特化）の書き方
面談で追加質問が出やすいポイントの先回り記述法
目次
QAエンジニアのスキルシートで評価される観点
品質実績を数値化する4つの指標
テスト工程別の実績表現
自動化・SET・SDETの実績表現
マニュアルQAでも数値で語る書き方
ケース別の書き方
案件タイプ別テンプレ
スキルシートでよくある失敗
まとめ
よくある質問
QAエンジニアのスキルシートで評価される観点
結論: 案件担当者が書類で確認しやすいのは、「どのテスト工程を、どのくらいの規模で、何の指標で回してきたか」の3点です。汎用スキルシート記事では「担当業務」「使用技術」の埋め方が中心ですが、QAエンジニアの場合はここに品質指標が加わります。用語定義に迷ったときはJSTQBソフトウェアテスト用語集で公式定義を確認できます。
QAエンジニアの職種そのものの解説はQAエンジニアとは｜仕事内容・年収・テストエンジニアとの違いをフリーランス視点で解説にまとめてあります。案件の単価感はQAエンジニアのフリーランス単価相場｜案件動向と単価アップの条件に切り出しました。本記事ではこれらの解説には踏み込まず、書類上の表現方法に絞って解説します。
評価者が見ている3層
書類選考の担当者が、案件アサイン判断のときに確認する項目は3層に分けられます。
層 | 見ている項目 | スキルシート上の記述位置 |
|---|---|---|
職種フィット | 担当してきたテスト工程・レベル | 案件詳細欄／スキル欄 |
実務規模 | 体制人数・テストケース件数・カバレッジ | 案件詳細欄（数値化した実績） |
判断力 | リリース可否判定・欠陥トリアージ・上流レビュー | 職務要約欄／案件詳細欄の役割記述 |
このうち「判断力」層は、書類で明示されにくいため差別化につながりやすい箇所です。担当者は「実行だけ回せる人」と「品質判断を持てる人」を区別してアサインします。
通らないQAスキルシートの共通点
書類選考で落ちやすい書き方には、いくつか共通点があります。
テストケース件数・体制規模などの規模感が書かれていない
「テスト全般を担当」のように工程が曖昧
使用ツール名だけ並んでいて、どの案件で何をやったかが紐づいていない
自動化経験の記述に対象レイヤ（UI／API／E2E）が書かれていない
リリース判定・トリアージ経験があっても書類に反映されていない
書類選考が通らない原因の一般的な整理はフリーランスのスキルシートが通らない7つの原因｜書類選考の改善策にありますが、QAは特に「規模と工程の具体性」でつまずきやすい職種です。
ミニFAQ
Q. スキルシートと職務経歴書のどちらを作ればいい？
A. フリーランスの案件応募では、面談前に共有するのがスキルシートで、参画確定後に契約書類として職務経歴書を求められることもあります。目的の違いは職務経歴書とスキルシートの違い｜フリーランスエンジニアの使い分けと書き方にまとめました。
品質実績を数値化する4つの指標
結論: QAエンジニアのスキルシートでは、①担当工程 ②規模 ③品質成果 ④自動化・判断経験 の4点が最低限伝われば、書類の骨格は作れます。すべての案件で全部書く必要はなく、案件ごとに書けるものを1〜2個ずつ入れると全体で骨太になります。
書類選考で評価されやすい定量表現の一般論はスキルシートで単価を上げる書き方｜評価される定量表現と実績の翻訳に整理しています。ここではQA固有の4指標に絞って書き方をまとめます。
指標1: 担当テスト工程と規模
もっとも基本になる指標です。テスト計画／設計／実装（テストケース作成）／実行／報告のどこを担当したかを、工程名で書きます。
NG: 「テスト全般を担当」
OK: 「テスト設計・実行・欠陥管理を担当。テストケース約1,200件を単体〜結合工程で運用」
規模感を出すためのフレーズ例です。
記述する規模 | フレーズ例 |
|---|---|
テストケース件数 | 「テストケース約◯◯件を管理」「回帰テストケース約◯◯件を運用」 |
体制人数 | 「QAチーム◯名／開発チーム◯名の体制」「マネジメント対象◯名」 |
対象システム規模 | 「機能数約◯◯／画面数約◯◯」「マイクロサービス◯◯個をカバー」 |
リリース頻度 | 「月次リリース／週次リリースを担当」「デイリーデプロイでの回帰運用」 |
指標2: 不具合検出・再発防止の実績
「見つけた欠陥」だけでなく「再発を防いだ」ところまで書くと単価に効きます。
NG: 「テストで多くのバグを検出」
OK: 「結合テスト工程で欠陥◯◯件を検出。上位10件は既知不具合として整理し、受け入れテスト範囲の見直しに反映」
再発防止の書き方例です。
「重大度Aランクの欠陥について、原因分類（要件／実装／テスト観点漏れ）をまとめ、翌スプリントの設計レビュー観点表に反映」
「リグレッション回避のためのチェックリストを整備し、以降のリリースで同種欠陥の再発を抑制」
数値化できない場合は「観点を追加した」「レビュー基準を更新した」など成果物レベルで書くと具体性が出ます。
指標3: 自動化カバレッジと対象レイヤ
自動化を扱った経験は、「範囲」と「効果」の2つを書きます。
NG: 「Seleniumを使用した自動化を担当」
OK: 「Playwrightを用いたE2E自動テスト約120シナリオを実装。主要回帰テストの手動実行工数を、1リリースあたり約4割削減（案件内実測ベース）」
対象レイヤを明示するフレーズ例です。
レイヤ | 記述例 |
|---|---|
UI自動化 | 「Playwright／Cypress／SeleniumでUI回帰テストを実装」 |
API自動化 | 「PostmanのCollection Runner／RestAssuredでAPI結合テストを実装」 |
E2E自動化 | 「主要ユーザーシナリオ◯本をE2E化。デプロイパイプラインに組込」 |
負荷・性能 | 「JMeter／k6で負荷試験を設計・実施。想定TPS◯◯までを検証」 |
「削減効果」の書き方は次のとおりです。
手動テスト工数削減率（例：4割減、月◯◯人日削減）
自動化率／自動化カバレッジ（例：主要回帰シナリオの◯％を自動化）
実行頻度（例：デプロイごとに自動実行、日次で全件実行）
指標4: リリース判定・トリアージ経験
品質判断を持てるかどうかは、単価が変わる分岐点です。
NG: 「開発チームと連携」
OK: 「PdM・開発リーダーと合同のリリース判定会議に参加し、既知欠陥のリリース可否判断を実施」
判断力を示すフレーズ例です。
「重大度・優先度に基づく欠陥トリアージ（優先度づけ）を主導」
「リリース前のGateKeeper（リリース可否の最終確認役）として、Go／No-Go判定に関与」
「受入テスト完了時の品質サマリを作成し、ステークホルダーへ報告」
指標を書く順番
案件詳細欄（1案件あたりの記述量が多い箇所）は、次の順で書くと読み手が把握しやすくなります。
プロジェクト概要（業界・規模）
体制と自分の役割（QAリード／担当QA／SET など）
担当したテスト工程と規模（指標1）
具体的な成果（指標2〜4のうち書けるもの）
使用ツール・自動化範囲（該当あれば）
案件詳細欄の粒度はスキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度にも整理しています。
ミニFAQ
Q. 業務でNDAがあり、案件名や具体的な数値を書けない場合はどうする？
A. 「大手金融機関向け業務システム」「toC向けECサイト」など業界＋システム種別で匿名化します。数値も「テストケース約◯◯件（概算）」と概算表記で構いません。逆に、案件名や画面キャプチャなど提示可能な資料は面談時に別途持参できる旨を職務要約欄に添えると評価されやすくなります。
テスト工程別の実績表現
結論: 工程ごとに書き分けると、担当者が「どの工程で戦力になるか」を判断しやすくなります。案件アサインは工程ベースで判断されることが多く、単体テスト経験と受入テスト経験では求められる書き方が変わります。
単体・結合テスト
開発チームに近い側のテストです。技術要素の記述を厚めにします。
「JUnit／Jestを用いたユニットテスト整備。カバレッジ計測ツールにJaCoCoを利用」
「結合テスト設計を担当。APIレスポンスの整合性、状態遷移、エラー系のパターンを網羅」
書き方のポイントは、担当したモジュール・機能名を1〜2個具体的に挙げることです。「決済モジュール」「ログイン認証周辺」など、粒度を落とすと現場感が出ます。
システムテスト
一般に「QAが主戦場になる」工程です。テスト観点・シナリオ設計の記述を厚くします。
「非機能要件（性能・可用性・セキュリティ）を含むシステムテストを設計」
「ユーザーシナリオ約◯◯本をベースにテストケースを起票」
観点を書き出すと具体性が出ます。
業務観点（正常系・異常系・境界値）
性能観点（レスポンス時間、スループット）
セキュリティ観点（認証・認可、入力検証）
互換性観点（ブラウザ・端末・OSバージョン）
受入テスト（UAT）
事業側と対話しながら回すことが多い工程です。業務理解と説明力を示すと単価に効きます。
「受入テストの前工程として業務フロー確認会を実施。事業部側の担当者と共同でテストシナリオを整備」
「UAT期間中の欠陥トリアージ・優先度合意・スケジュール調整を担当」
受入テスト経験は書類に反映していない人が多いため、書くだけで差がつきやすい工程です。
ミニFAQ
Q. 単体テストしか経験がない場合、システムテスト以降の経験は書かないほうがいい？
A. 経験がない工程を書かないのは正しい判断です。ただし「見ていたこと」「議事メモを取っていたこと」レベルの関与でも、「システムテスト計画レビューに参加」など関与の粒度で書くことは可能です。実行を担当していないなら「担当」ではなく「関与」「同席」「レビュー」に語を落とします。
自動化・SET・SDETの実績表現
結論: 自動化ができるQAは案件でも単価でも希少なため、書けるだけ全部書きます。ただしツール名の羅列にせず、どの範囲を、どの深さでやったかを明示します。
SET（Software Engineer in Test）・SDET経験の書き方
SET（テスト自動化を担う開発寄りQA）／SDET（テストコード実装まで担うソフトウェアテストエンジニア）は、テスト自動化の設計と実装を主業務にする役割です。開発寄りのスキルセットが問われます。
「テスト基盤の設計・実装を担当。CI（GitHub Actions／Jenkins）上での自動テスト実行環境を構築」
「Page Object Model（UIテストの保守性を高める設計パターン）を採用したUIテストフレームワークを設計。保守性の高いテストコード構造を実装」
言語・フレームワーク・実行環境をセットで書くフレーズ例です。
分類 | 記述例 |
|---|---|
言語 | Java／TypeScript／Python／Ruby |
E2Eフレームワーク | Playwright／Cypress／Selenium／Puppeteer |
API/ユニット | JUnit／PyTest／Jest／RSpec／RestAssured |
CI | GitHub Actions／Jenkins／CircleCI／GitLab CI |
レポーティング | Allure／ReportPortal／HTML Reporter |
自動化の「効果」の書き方
自動化は導入したこと自体より、効果の説明で評価が決まります。
NG: 「Playwrightを導入」
OK: 「Playwrightを導入し、毎リリース時に手動で実施していた回帰テスト約80シナリオを自動化。1回あたりの回帰テスト工数を約2人日から1時間に短縮」
書き方のポイントは、次の3つです。
導入前後の対比：手動での工数／頻度と、自動化後の工数／頻度
カバレッジ：どの範囲をカバーしているか（主要業務フロー、決済、認証、など）
運用体制：誰が回しているか（QAチーム／開発チーム／CIで自動）
「自動化しなかった判断」も書く
すべてを自動化するのが正解ではないため、「自動化しないと判断した領域」の説明も評価されます。
「UI変更頻度が高い管理画面については保守コストを考慮し、自動化対象から除外」
「E2E自動化はコア業務フローに限定し、細部の分岐は探索的テストに寄せる方針を採用」
判断の理由をセットで書くと、書類段階で技術判断力が伝わります。
マニュアルQAでも数値で語る書き方
結論: 自動化経験がなくても、マニュアルQAの実績は数値化できます。むしろマニュアル領域で数値を出せる人は市場では少数派で、書類の通過率を上げやすくなります。
数値化できる項目
項目 | 書き方の例 |
|---|---|
テストケース設計量 | 「新機能◯◯件に対しテストケース約◯◯件を設計」 |
実行工数 | 「1リリースあたりのテスト実行工数◯人日」 |
欠陥検出率 | 「テストケース◯◯件あたり欠陥◯◯件を検出」（欠陥密度は通常LOCや機能点など規模ベースの指標のため、テストケース基準の場合は「検出率」または「テストケースあたりの欠陥検出件数」と書き分けます） |
探索的テスト工数 | 「探索的テストセッションを週◯回、1回あたり2時間で実施」 |
ドキュメント整備 | 「テスト観点表・チェックリストをOO件整備しチームに共有」 |
プロセス改善の実績
マニュアルQAでもプロセス改善は数値化しやすい領域です。
「テスト設計テンプレートを整備し、新規メンバーのオンボード期間を◯週間短縮」
「探索的テスト用のチャーター（テスト観点メモ）フォーマットを標準化」
「欠陥報告テンプレートを見直し、開発チームからの差し戻し件数を減少」
ドメイン知識の書き方
QAはドメイン知識が武器になる職種です。ドメイン理解を書類に反映するフレーズ例を挙げます。
「金融ドメイン（証券／保険／決済）で◯年のテスト経験。約定処理・与信フローの観点表を整備」
「toB SaaSの権限管理・監査ログ機能のテスト設計に強み」
「ゲーム開発におけるレベルデザイン・キャラクター挙動のテスト経験」
ミニFAQ
Q. 自動化未経験だと単価は上がらない？
A. 単価には差が出やすい傾向がありますが、マニュアルQAでも上流工程・ドメイン特化・リリース判定関与があれば、評価対象になりやすい案件があります。QAリード寄りの案件では、むしろ数値で説明できるマニュアルQAのほうがフィットするケースもあります。自分の案件レンジがどのあたりかを確認したい場合は、無料のフリーランスエンジニア単価診断で目安を確認できます。
ケース別の書き方
結論: QAエンジニアのキャリアは幅が広く、書き方も画一化できません。ここではよく相談される4つのケースについて、書類上のアピールポイントを整理します。
ケース1: 実務経験1〜2年の駆け出しQA
経験年数が少ない場合は、関与範囲を落として書ける粒度を細かくするのが基本です。
「担当」ではなく「サブ担当」「一部を担当」など関与レベルを正確に書く
「実行フェーズを担当」「テストケース作成を担当」など工程を絞って書く
資格（JSTQB Foundation Level など）を持っていれば取得年とセットで記載
実績が薄いときの書き方は実績が少ないフリーランスエンジニアでも通るスキルシートの書き方にも整理しました。
ケース2: QAリード・マネジメント経験あり
QAチームのマネジメント経験がある場合は、規模と判断領域を明示します。
「QAチーム◯名のマネジメントを担当。月次計画・アサイン・成果レビューを実施」
「複数プロジェクトの品質責任者として、リリース判定・スコープ調整を主導」
「新規メンバーのオンボード資料を整備」
QAリードの案件は単価レンジが上振れしやすいため、判断領域の記述を厚めにするとフィットしやすくなります。
ケース3: 開発とQAを兼務してきた人
開発経験を持つQAは希少で、書き方次第で差別化しやすくなります。
「開発担当としてバックエンド実装を◯年経験後、品質改善プロジェクトを機にQAへ転向」
「開発チームとQAチームの橋渡し役として、コードレビューとテスト設計の双方に関与」
「SET／SDETロールとして、自動テスト実装・保守を担当」
「開発ができるQA」は自動化SET案件でも上流工程案件でも評価されるため、両方を意識した記述にします。
ケース4: 特定ドメインに強みを持つQA
金融・医療・ゲーム・EC・toB SaaSなど、業界を絞ってキャリアを重ねてきた人向けです。
ドメイン固有の観点（金融なら約定・与信、医療なら対象システム（医療機器・院内システム・ヘルスケアアプリ等）に応じた規制・品質文書対応、ECなら決済・在庫）を1〜2個具体的に書く
業界特有の規制（PCI-DSS、GxP、個人情報保護）にどう対応してきたかを1行で入れる
ドメイン理解を活かして書いたテスト観点表・チェックリストの名前を残す
職務要約欄への反映
各ケースの強みは、案件詳細欄だけでなく職務要約欄（冒頭3行）にも反映させると効きます。書き方の型はスキルシートの職務要約の書き方｜冒頭3行で読ませる型と職種別テンプレにまとめました。
案件タイプ別テンプレ
結論: 案件タイプによって、スキルシートで強調すべき箇所が変わります。応募先の案件が決まっている場合は、その案件タイプに合わせて記述順序を入れ替えます。
金融・決済ドメイン
品質要求が高く、監査観点・トレーサビリティが重視される案件タイプです。
強調する項目の例です。
業界経験年数と、扱ったサービス種別（銀行／証券／保険／決済ゲートウェイ）
テストエビデンスの整備（キャプチャ・ログ・実行結果の残し方）
監査対応・内部統制対応の経験
リスクベーステスト・要件トレーサビリティマトリクスの整備経験
EC・toC Web
リリース頻度が高く、自動化との相性がよい案件タイプです。
強調する項目の例です。
リリース頻度と自動化カバレッジ
クロスブラウザ・スマホ端末対応の経験
探索的テストの運用
パフォーマンステスト経験（セール前負荷試験など）
toB SaaS
権限管理・監査ログなど「地味だが漏らせない」観点が多い案件タイプです。
強調する項目の例です。
権限管理・ロール別テストの設計経験
API結合テストの範囲
顧客ごとのカスタマイズ機能のテスト方針
個人情報・監査ログ関連のテスト観点
ゲーム開発
デバッグ工程が独特で、他ドメインとは書き方の粒度が変わります。
強調する項目の例です。
担当したタイトル種別（コンシューマ／スマホ／PC／MMORPG／FPS など）
開発規模（総プレイ時間、キャラクター／マップ数）
障害切り分けの経験（サーバー／クライアント／通信）
端末カバレッジ（対応OS・端末数）
SES経由の案件が多い場合
SES契約で複数案件を経験してきた場合は、記述の集約が問題になります。案件数が多いときの書き方はSESスキルシートの書き方｜案件数が多い時の集約術と粒度にまとめました。
スキルシートでよくある失敗
結論: 書類選考でよく指摘されるのは、規模感の欠落と、工程・役割の曖昧さの2点に集約されます。ここではQAエンジニア固有の失敗パターンを整理します。
失敗1: 「テスト全般を担当」で終わる
一番よくあるのが、担当領域を「テスト全般」で片づけてしまうパターンです。
修正例: 「テスト全般」→「テスト計画レビュー／テスト設計／テスト実行／欠陥管理／テスト報告書作成を担当」
工程を列挙するだけで印象が変わります。
失敗2: ツール名の羅列で使い方が書かれていない
「使用ツール: Selenium, JMeter, Postman, JIRA」のように列挙だけになっているケースです。
修正例: ツール名の後に用途と規模を1行添える
- 「Selenium：UI回帰テスト自動化。約80シナリオを保守」
- 「JMeter：負荷試験の設計・実行。想定同時接続◯◯まで検証」
失敗3: 自動化の範囲・対象が不明
「自動化を推進」だけで、範囲・対象・効果が抜けているパターンです。
修正例: 「主要ユーザーシナリオのE2E自動化を推進。手動回帰工数を約4割削減」
前掲の「指標3」に沿って書き直します。
失敗4: 資格の年次が古いまま
QA関連資格（JSTQB Foundation Level、ISTQB Advanced Level など）を持っている場合、取得年を書き添えると信頼度が上がります。ただし取得年だけだと現在の実務との接続が見えにくい場合があるため、直近の学習・活動を1行添えると印象がよくなります。
失敗5: 空白期間の説明が抜けている
案件の切れ目や体調・家族事情での空白期間がある場合、書類の中で説明していないと不利になります。空白期間の書き方はスキルシートの空白期間の書き方｜フリーランスエンジニアの表現例と粒度にまとめました。
失敗6: 「テストリーダー」の中身が曖昧
「テストリーダーを担当」だけだと、実際に見ていた範囲が伝わりません。
修正例: 「QAチーム◯名のリーダーとして、テスト計画立案／進捗管理／ステークホルダー報告／欠陥トリアージを担当」
責任範囲を4つ程度に分解すると、判断力が伝わりやすくなります。
失敗7: AI・生成AIツールの利用経験を書いていない
近年、テスト観点抽出やテストデータ生成に生成AIを使うケースが増えています。書類上で言及している人はまだ少なく、案件によっては差別化要素になります。ただし利用可否は案件の情報管理ルールに従います。
記述例: 「テスト観点抽出の下書きにChatGPTを利用（機密情報はマスキング後に投入する運用）」
スキルシート自体をAIで整えたい場合の手順と機密情報の扱いはスキルシートをAIで作る手順｜下書き活用と情報漏えい対策にまとめました。
まとめ
QAエンジニアのスキルシートは、「テスト工程・規模・品質指標・判断領域」の4層を意識するだけで、書類での伝わり方が大きく変わります。全部の案件で完璧に書く必要はなく、案件ごとに書けるものを積み重ねる形で十分です。
要点をまとめます。
担当したテスト工程を工程名で明示する：「テスト全般」ではなく、計画／設計／実行／報告のどれかに落とす
規模を数値化する：テストケース件数、体制人数、リリース頻度のどれか1つは必ず入れる
自動化は範囲と効果をセットで書く：ツール名の羅列ではなく、対象レイヤと削減効果まで書く
品質判断の経験を書き漏らさない：リリース判定、トリアージ、上流レビューへの関与は単価に効く
案件タイプに合わせて記述順序を入れ替える：金融／EC／toB SaaS／ゲームで強調すべき項目が変わる
職種解説と単価相場の議論は別記事に委ねる：本記事は書類表現に絞り、QAエンジニアとはやQAエンジニアのフリーランス単価相場を組み合わせて読むと全体像が掴めます
書き上げたスキルシートで狙いたい案件レンジは、フリコンのテストエンジニアの案件一覧で公開案件の条件を確認できます。手戻りの少ないスキルシート整備には、他職種の書き方テンプレも参考になります。近い工程・体制の書き方としてインフラエンジニアのスキルシートの書き方｜構築・運用実績の数値化と職種別テンプレ、データ・AIエンジニアのスキルシートの書き方｜モデル精度と基盤規模の定量表現、PMOスキルシートの書き方｜PMとの違いと体制規模・予算・工数の定量化を並べて読むと、数値化の型の共通点と差分が見えます。
一次情報として、テスト工程・テスト種類の分類とテスト用語の定義はJSTQB（日本におけるソフトウェアテスト技術者資格認定の運営組織）のシラバス・用語集ページ、ソフトウェアテストの国際標準としてはISO/IEC/IEEE 29119 シリーズを参照できます。書類の表現に迷ったときは、これらの一次情報で用語を確認しつつ、案件ごとに書ける項目を積み上げる方針で組み立てるとぶれません。
よくある質問
スキルシートは何枚に収めるべき？
目安は2〜4枚です。案件数が多くて枚数が増える場合は、直近5年・主要案件を厚く、それ以前は要約に落とす整理が実務的です。QA領域は工程・規模・ツールで書く項目が多いため、汎用スキルシートより1枚多く（3〜5枚）になるケースもあります。
自動化ツールをまだ実務で使えていない。書類ではどう表現する？
「実務経験」と「学習中／個人開発で試した経験」は分けて書きます。「学習中」の項目に「Playwrightでの個人プロジェクトのUI自動化を試作中」など成果物レベルで書くと、書類上の印象が変わります。実務未経験の技術を「経験あり」と書くのは避けます。
資格（JSTQB）は書類に効くのか？
資格そのものより、取得後にどのような業務に活かしたかを1行添えるほうが評価されます。「Foundation Levelを取得。以降、テスト設計テンプレの整備とチームの観点抽出研修に活用」など、業務接続の記述をセットで書きます。試験の概要はJSTQBの試験実施案内ページで確認でき、資格全般の書き方はフリーランスエンジニアの資格は案件獲得に効くのか｜評価される場面とスキルシート・面談での使い方にまとめました。
面談で「テストケース件数」を突っ込まれるのが怖い
突っ込まれるのは「盛った可能性がある数字」に限られます。約◯◯件（概算）のように概算表記にしておけば、面談で「厳密には◯◯件〜◯◯件です」と補足するだけで問題になりません。逆に、丸めすぎて実態と乖離した数値を書くと突っ込まれます。
QAエンジニアの案件はどこで探せる？
フリーランスエージェント経由の場合、QAエンジニア（テストエンジニア）の案件一覧で公開されている案件を確認できます。案件検索で使うタグは「テストエンジニア」「QA」のほか、自動化なら「Selenium」「Playwright」「Cypress」など具体的なツール名で絞ると精度が上がります。
開発経験のあるQAは、開発職の案件にも応募できる？
応募自体は可能ですが、書類は応募案件ごとに軸を変えます。QA寄り案件では品質実績と自動化を前に、開発寄り案件では実装・言語・アーキテクチャを前にした職務要約に組み直します。同じスキルシートを使い回さず、応募先ごとにトップの見出し順を入れ替えるのが実務的です。
業務委託契約ではなく、SES契約でしか経験がない場合の書き方は？
契約形態は書類の評価にはほとんど影響しません。契約形態より「担当工程・規模・成果」の書き方のほうが重視されます。SES契約特有の複数案件経験の集約方法は前述のとおり、案件数が多いときの集約術で対応できます。
QAリード案件を狙うにはスキルシート上でどこを厚くする？
リード案件で見られるのは「品質判断」「体制設計」「ステークホルダー折衝」の3つです。案件詳細欄に「リリース可否判定」「QA計画立案」「開発・PdMとの合意形成」の記述を最低1つずつ入れると、書類段階でリード候補として扱われやすくなります。
自動化のカバレッジは何％あれば書類で通用する？
業界共通の基準はありません。書類では「全部の◯％」よりも「どの領域をカバーしているか」のほうが評価されます。主要業務フローの回帰テスト、決済・認証などのクリティカルパス、リリース前の受入テストなど、対象範囲を具体的に書けば、カバレッジ数値がなくても十分に伝わります。
単価を上げるための書き方のコツはある？
4つの品質指標のうち「リリース判定への関与」を書けているかで大きく変わります。実行だけの経験なら中位レンジ、判定・トリアージまで持てていれば上位レンジの案件にフィットしやすくなります。単価レンジ全体の考え方はQAエンジニアのフリーランス単価相場｜案件動向と単価アップの条件にまとめてあります。自分のレンジ感を数字で確認したいときはフリーランスエンジニア単価診断を利用できます。
関連するタグ：
