QA・テストの実績の見せ方｜出せない仕事をどう伝えるか

2026年7月17日

長谷川奈津

この記事のポイント

✓QA・テストの実績の見せ方を
✓秘密保持契約の範囲の確認から具体的に整理します
✓固有名詞を出さずに担当範囲と再現性を伝える型

QA・テストの仕事は、実績が外に出しにくい職種の代表格です。関わった製品名を言えない、見つけた不具合の内容を書けない、作ったテストケースは納品物として相手の資産になっている。手元に残るのは記憶だけで、次の相談で「これまでどんな仕事をされてきましたか」と聞かれたときに、具体的な話が何ひとつできない。QA・テストの実績の見せ方を調べている人の多くは、この行き詰まりに直面しています。

結論を先に書きます。出せないのは固有名詞と成果物の中身であって、仕事の進め方と判断の根拠は出せます。実績として評価されるのは前者ではなく後者です。この記事では、契約上どこまでが縛られているのかを整理したうえで、固有名詞を使わずに再現性を伝える型、自分の手で用意できる成果物、書類と面談での説明の組み立て方を、順に具体化します。

出せない理由を、契約の側から正確に把握する

実績を語るときに最初に確認すべきは、自分が何によって縛られているのかです。「たぶん言えない」という曖昧な自己判断で情報を絞ると、出せるはずの内容まで削ってしまい、実績が空になります。

秘密保持契約が守っている対象

秘密保持の合意が守っているのは、原則として発注側が秘密として指定した情報です。多くの契約書では、開示された技術情報、営業情報、開発中の製品の仕様といった範囲が列挙されています。ここで重要なのは、列挙されているのは「開示された情報」であって、自分が仕事の過程で身につけた進め方や判断の型は、通常その対象になっていないという点です。

つまり、どのようなテスト設計の考え方で臨んだか、どういう順序で進めたか、どんな観点で不具合を切り分けたかは、多くの場合語れます。語れないのは、その対象が何であったか、どんな不具合が実際に存在したか、といった具体的な事実のほうです。

契約書に明記がなくても注意すべき範囲

契約書に秘密保持の条項が無い案件でも、常識的に語れない情報はあります。まだ公表されていない製品の存在、社内の体制の弱点、リリース前に発見された重大な問題。これらは契約の有無にかかわらず、口にした時点で相手からの信用を失います。契約書を根拠に「書いていないから話してよい」と判断するのは、法的には正しくても実務的には損です。

契約書のどこを見ればよいか

確認すべき条項は三つです。秘密情報の定義、有効期間、そして実績公開に関する定めです。有効期間は契約終了後も一定年数続く形が一般的で、期間が切れていれば話せる範囲が広がることもあります。実績公開について何も書かれていない場合は、禁止されていないのか、単に想定されていないのかを判断する必要があります。判断に迷う場合は、発注側に確認するのが確実です。制度や契約の一般的な考え方については、行政の情報源も参考になります（公正取引委員会）。

出せる情報と出せない情報の線引き

契約の確認が済んだら、情報を種類ごとに分けます。線引きが自分の中で決まっていると、面談中に迷って口ごもることがなくなります。

固有名詞は出さない

企業名、製品名、サービス名、担当者の名前。これらは原則として出しません。「誰もが知っている大手」といった表現も、業種と規模を組み合わせると特定できてしまうことがあるため注意が必要です。特定を避けるには、業種を一段階広く言い換えるのが有効です。

不具合の内容は出さない

見つけた問題の具体的な内容は、相手の製品の弱点そのものです。修正済みであっても、当時どんな問題があったかを語ることは避けます。ただし、「どういう観点で探したか」「どうやって再現条件を絞り込んだか」という手順は、対象を伏せれば語れます。実務では、この手順のほうが評価されます。

成果物そのものは持ち出さない

作成したテストケースの一覧や手順書は、多くの場合納品物として相手の資産になっています。ファイルを手元に残して面談で見せるのは、契約違反になり得ます。見せたい場合は、同じ形式で自分が作り直したサンプルを用意します。中身を実在の案件と無関係な題材に置き換えれば、形式だけを見せることができます。

進め方と判断の根拠は出せる

どういう順序で範囲を確定したか、どんな基準で優先順位を決めたか、報告をどんな形式でまとめたか。これらは自分の仕事のやり方であり、通常は秘密情報に当たりません。実績として語るべき中心は、ここに置きます。

固有名詞を使わずに伝える型

実際の説明の組み立て方を、要素ごとに見ていきます。この型に沿って書けば、契約を守りながら具体性のある実績になります。

業種と対象の性質に置き換える

「A社のB というサービス」ではなく、「利用者が自分で申し込みを行う形の、会員制のWebサービス」と言い換えます。業種は一段広く、対象の性質は具体的に。この組み合わせが、特定を避けながら仕事の難易度を伝える最良の方法です。

対象の性質を伝える要素としては、利用者の層、扱うデータの種類、外部との連携の有無、対応が必要な環境の幅などがあります。「複数の決済手段に対応し、スマートフォンとパソコンの両方で利用される」と言えば、確認すべき組み合わせの多さが伝わります。

期間と体制で規模を示す

どのくらいの期間、どういう体制の中で担当したかを示します。単独で受けたのか、チームの一員だったのか、外部の立場から関わったのか。体制の説明は、自分がどこまで裁量を持っていたかを伝える情報でもあります。

自分の担当範囲を動詞で書く

もっとも効く要素がこれです。「テストを担当しました」では何も伝わりません。「仕様書から確認の観点を洗い出し、手順書の形に落とし、実行して結果を記録し、発見した問題の再現条件を絞り込んで報告した」と書けば、担当した工程が明確になります。

工程を動詞で分解すると、自分がどこを強みにしているかも見えてきます。設計が得意なのか、実行の速度が武器なのか、切り分けの精度が高いのか。分解しない説明は、どの受け手からも同じに見えます。

制約と工夫をセットで語る

実績として印象に残るのは、うまくいった話ではなく、制約の中でどう動いたかの話です。「仕様書が断片的だったため、既存の挙動を確認して一覧に起こしてから設計に入った」「環境の提供が遅れたため、先に手順書の作成を進めて着手日を待った」。制約の説明には固有名詞が要らないため、契約を守ったまま具体性を出せます。

数字を使えない場面で成果を示す方法

実績の説明では数字が説得力を持ちますが、案件の数字は多くの場合出せません。代わりに使えるのは、自分の管理の仕方に関する指標です。

テスト設計の見積り含め、経験豊富なメンバーの協力により総テストケース数(予測値)は途中増減しつつも、最終的には誤差が5%前後に収まり改めて予実管理の必要性を感じました。出典: note.com

見積もりと実績のずれをどう管理したか、という話は、対象を伏せたまま語れます。しかも、この話ができる人は多くありません。実績として語るなら、絶対量よりも管理の精度に焦点を当てるほうが、契約上も安全で、評価も高くなります。

予実の管理をどう回したかを語る

計画した項目数に対して、どのくらいのずれが出たか。ずれた原因は何で、どう修正したか。この一連の説明は、案件の中身を明かさずに、自分の管理能力を示せます。記録を残していない人は語れないため、差別化の材料にもなります。

進捗を見える形にした工夫を語る

進捗の管理は、QAの実務で必ず発生する作業です。

QAのプロジェクトにおいて「今のテストがどれくらい進んでいるのか」または「どれくらい遅れているのか」といった進捗を測定して状況を把握することは、テストの実行を管理する際にとても重要なタスクとなります。出典: sqripts.com

進捗をどう可視化したかは、使った道具と一緒に語れます。表計算ソフトの関数で集計する仕組みを作った、スクリプトで自動集計した、結果を日次で共有する形式を整えた。道具と工夫の話は、案件の秘密に触れずに技術力を示せる領域です。

テスト項目書の形式を語れるようにしておく

実績の説明で意外と効くのが、項目書の形式についての具体的な話です。どの列を持ち、結果と実施日をどう記録し、そこから進捗をどう集計していたか。この部分は案件の秘密に触れないうえ、実務を経験していないと語れない領域です。

「テスト項目書」シートの「結果」列及び「実施日」列に対応するものが、上図赤枠の各結果行と各日付列となります。上節の「テスト項目書」シートを例に挙げると、F列：「2024/4/1」の8行目「OK」が3件、G列「2024/4/2」の8行目「OK」が1件…というように、各テスト項目に対して「いつ」「結果がどうなったか」をそれぞれ入力する必要があります。出典: sqripts.com

この水準の話ができると、実行の経験があるかどうかが即座に伝わります。逆に、形式について語れない人は、手順書を渡されて実行しただけの経験だと判断されます。実績の説明を準備する段階で、自分が使っていた項目書の列構成を一度書き出しておくと、面談で具体的に話せます。

報告の形式を語る

どんな項目を、どの頻度で、誰に向けて報告していたか。報告の形式は仕事の質を強く反映します。実施件数、未実施の残り、発見した問題、判断が必要な事項。この四点を整理して出していたと説明できれば、実務経験の質が伝わります。

見せられる成果物を自分で用意する

守秘義務の壁は、自分で作った成果物には及びません。実績として見せられる形を、手元に一式そろえておきます。

公開されているソフトウェアを題材にする

誰でも触れるアプリケーションやWebサービスを題材に、テストの観点を洗い出して手順書の形にまとめます。実在の案件と無関係なので、そのまま見せられます。題材の選び方は、自分が受けたい案件の性質に近いものにします。会員登録や決済を含むサービスを題材にすれば、そのまま実務の説明に接続できます。

テストケースの形式サンプルを作る

自分が普段使っている項目の並びを、架空の題材で再現します。前提条件、操作手順、期待結果、実施日、結果、備考。列の設計と粒度の取り方に、その人の実務経験がはっきり出ます。

手順書と報告書のひな型を用意する

報告書のひな型は、実績を示すと同時に、受注後の進め方の提案書にもなります。「報告はこの形式で行います」と最初に見せられる人は、相談の段階で信頼を得やすくなります。書類としての体裁を整える基本は、ビジネス文書検定の出題範囲が実務の型として参考になります。

学習と検証の記録を残す

新しい道具を試した記録、自動化の練習で作ったコード、読んだ技術資料の整理。これらは公開しても契約に触れません。継続的に記録が残っている人は、実案件の話ができなくても、学び続けている事実で信頼を得られます。

書類と面談での組み立て方

素材が揃ったら、伝える場面ごとに形を整えます。

職務経歴書の構成

案件ごとに、対象の性質、期間、体制、担当した工程、使った道具、工夫した点を並べます。固有名詞の欄は「非公開」と書くのではなく、業種と性質の説明に置き換えます。「非公開」と書くと、隠している印象だけが残ります。置き換えて書けば、契約を守りながら説明していることが伝わります。

書類の分量は、案件数を増やすより一件あたりの記述を厚くします。読む側が知りたいのは、何件経験したかではなく、一件をどう進めたかです。

面談で聞かれることに備える

よく聞かれるのは三つです。担当した工程の範囲、困難だった場面とその対処、そして今回の依頼にどう当てはまるか。三つ目に答えるには、相手の依頼内容を事前に読み込んでおく必要があります。自分の経験を並べるだけの説明は、当てはめの作業を相手にさせることになります。

踏み込まれたときの断り方

「具体的にはどこの案件ですか」と聞かれることがあります。断り方は短くします。「守秘義務があるため対象は申し上げられませんが、進め方は同じ形でご説明できます」。ここで曖昧に濁したり、遠回しに匂わせたりすると、この人は自分の情報も漏らすと判断されます。はっきり断ることが、そのまま信頼の材料になります。

契約が終わった後も残る義務を意識する

秘密保持の義務は、契約が終了しても一定期間続く形が一般的です。案件が終わった直後は話せなくても、期間が満了すれば範囲が変わることもあります。ただし、期間の満了だけを根拠に語り始めるのは慎重に判断すべきです。相手の製品が現役で使われている場合、期間が切れていても不利益を与える情報は出さないほうが賢明です。

判断の基準は単純です。その情報を出したときに、相手が困るかどうか。困る情報は、契約上の期間にかかわらず出さない。この基準を自分の中に持っている人は、契約書を細かく読み込まなくても大きく外しません。

語れる実績は、日々の記録から作られる

案件が終わってから思い出そうとしても、具体的な材料は出てきません。実績として語れる中身は、進行中に記録した内容の範囲に限られます。記録の取り方を決めておくことが、実績づくりの実体です。

案件ごとに残す項目を固定する

残す項目は毎回同じにします。対象の性質、期間、体制、担当した工程、使った道具、当初の計画と実績のずれ、困難だった場面とその対処。この七項目を案件ごとに埋めていけば、そのまま職務経歴書の素材になります。

注意点は、記録に固有名詞を書き残さないことです。手元のメモであっても、後で書類に転記するときに混ざる危険があります。最初から業種と性質の言い換えで書いておけば、転記の際に迷いません。この習慣は、契約を守る仕組みとしても働きます。

記録を取るタイミングを決める

記録は案件の終了時ではなく、区切りごとに取ります。設計が終わった時点、実行の一巡目が終わった時点、報告を出した時点。区切りで残すと、その時点で何を考えていたかが残ります。終了後にまとめて書くと、結果だけの記述になり、判断の過程が消えます。

判断の過程こそが、実績として価値のある部分です。なぜその観点を優先したのか、なぜその順序で進めたのか。結果だけの記録からは、この部分を後から再現できません。

記録が効く場面は書類だけではない

蓄積した記録は、書類や面談だけでなく、見積もりの根拠としても使えます。過去の類似案件でどのくらいの時間がかかったかを示せる人は、条件の相談を事実に基づいて進められます。実績の記録と見積もりの精度は、同じ材料から生まれます。

数字を出せない代わりに、比較を使う

実績の説明では、絶対的な数字を出せない場面が多くあります。その場合に有効なのが、比較の形で語る方法です。「着手した当初は確認に丸一日かかっていた作業を、手順を整理して半分程度の時間で回せるようにした」という言い方は、具体的な値を出さずに改善の度合いを伝えられます。

比較の軸には、時間、手戻りの回数、確認の抜けの発生、報告から修正着手までの間隔などが使えます。いずれも案件の秘密には触れず、自分の仕事の質を示せる指標です。

注意点は、比較の前提を明示することです。何と比べているのかが曖昧だと、誇張と受け取られます。「同じ範囲を、同じ体制で確認した場合の比較です」と一言添えるだけで、説明の信頼度が変わります。

案件の性質によって、見せ方の重心は変わる

同じ実績でも、相手が求めている経験によって強調すべき部分が変わります。翻訳の仕方を分野ごとに整理しておきます。

業務システムの案件を語る場合

業務システムでは、確認すべき条件の組み合わせが多く、業務の流れを理解しているかが問われます。強調するのは、業務の手順をどう把握したか、権限や役割による違いをどう洗い出したかです。対象の業種を伏せても、「複数の権限が存在し、承認の段階がある業務の流れ」と言えば性質は伝わります。

消費者向けサービスの案件を語る場合

不特定多数が使うサービスでは、環境の幅と使い勝手が論点になります。対応する機器やブラウザの組み合わせをどう決めたか、想定外の操作をどこまで試したか。この説明は、対象を伏せたまま具体的にできます。実際の利用場面を想定して観点を立てられるかどうかが、評価の分かれ目になります。

自動化を含む案件を語る場合

自動化の経験は、成果物を出せなくても語りやすい領域です。どの範囲を自動化の対象に選んだか、その選定の基準は何だったか、失敗したときの原因調査をどう運用したか。選定の基準は普遍的な判断なので、案件の中身に触れずに説明できます。作ったコードそのものは出せなくても、同等のものを自分の題材で作り直せば見せられます。

短期の単発案件を語る場合

短い案件は「大した経験ではない」と扱われがちですが、限られた時間で何を優先したかという判断が出るため、語り方次第で強い材料になります。時間が足りない前提で、どの機能から着手し、何を捨てたか。優先順位のつけ方は、どの現場でも求められる能力です。

実績を置く場所をどこにするか

素材が揃っても、置き場所が無ければ相手の目に触れません。置き場所ごとに向き不向きがあります。

応募のたびに提出する書類

もっとも確実な経路です。相手の募集内容に合わせて記述の順序を組み替えられるため、当てはめの精度が高くなります。手間はかかりますが、通過率に直結します。ひな型を一つ持っておき、案件ごとに強調点だけを入れ替える運用にすると、負担を抑えられます。

常時公開しておく紹介ページ

自分の進め方をまとめたページを一つ持っておくと、相談のたびに説明する手間が減ります。掲載するのは、担当できる工程の一覧、使える道具、報告の形式、受けられる案件の性質です。実案件の中身は載せず、形式と考え方だけを載せます。固有名詞が無いぶん、更新の際に確認が不要になるという利点もあります。

技術的な記録を公開する場所

学習の記録や、公開されているソフトウェアを題材にした検証の記事を残す方法です。継続して更新されている記録は、実案件を語れない期間の空白を埋めます。書く内容は難解である必要はなく、道具の使い方や観点の整理で十分です。読み手が「この人は考えて仕事をしている」と判断できれば目的を果たします。

評価が公開の形で残る場所

仕事の依頼と評価が同じ場所に記録される仕組みを使うと、第三者から見える実績が蓄積されます。守秘義務で中身を語れない場合でも、依頼が繰り返されている事実そのものが材料になります。ただし、評価は依頼を受けなければ増えないため、書類と紹介ページで最初の一件を取る作業が先に来ます。

更新されていない書類をそのまま使う

一度作った職務経歴書を、内容を見直さずに使い回すケースがあります。担当した工程が増えているのに記述が古いままだと、実際にできることより低い評価で判断されます。案件が終わるたびに一項目を書き足す運用にしておくと、更新の負担が分散します。

書類の更新は、実績が増えたときだけでなく、応募先の性質が変わったときにも必要です。設計から任せたい相手と、実行を任せたい相手では、読みたい箇所が違います。順序を入れ替えるだけでも、伝わり方が変わります。

見せ方でよくある失敗

最後に、避けるべきパターンを挙げます。

工程を分解せずに「テストを担当」とだけ書く

もっとも多い失敗です。読む側は、設計から関われる人なのか、手順に沿って実行する人なのかを知りたがっています。分解しない記述は、判断材料を提供していないのと同じです。

発注側の内情を語ってしまう

「前の現場は仕様書が無くて大変だった」という話を、批判の形で語ってしまうケースです。制約の話は語ってよいのですが、相手の落ち度として語ると、この人は自分の現場のことも外で話すと受け取られます。制約は事実として述べ、自分がどう動いたかに話を寄せます。

実績の量で勝負しようとする

案件数を並べて厚みを出そうとすると、一件あたりの記述が薄くなります。読む側が知りたいのは総量ではなく、一件をどう進めたかです。書く件数を絞り、工程と判断を厚く書くほうが、結果として評価されます。

許諾を取れば話せる範囲は広がる

出せない前提で工夫するだけでなく、出せるようにする方法もあります。

終了時に確認しておく

案件が終わったタイミングで、「実績として、業種と担当工程の範囲で紹介させていただくことは可能でしょうか」と確認します。多くの発注側は、固有名詞を出さない範囲であれば問題にしません。確認した事実をメールなどの記録に残しておけば、後で説明する際の根拠になります。

契約の段階で条項を入れる

新しい契約を結ぶ際に、実績公開の可否をあらかじめ定めておく方法もあります。「業種と担当工程の範囲で実績として公開できる」という一文を入れられれば、以後の説明が楽になります。難しい場合でも、確認したという事実だけで、相手は情報の扱いに慎重な人だと受け取ります。

見せ方の丁寧さが、そのまま信用になる

検証や品質保証の仕事がどのような形で発注されているかは、QA・テスト・コードレビューのお仕事の募集内容から傾向が読み取れます。実行だけを求める依頼と、設計から任せる依頼では、示すべき実績の中身が変わります。募集の文面から、相手がどの工程の経験を見たいのかを読み取ってから書類を整えると、通り方が変わります。

隣接する領域の募集も見ておくと、実績の翻訳先が増えます。AI・マーケティング・セキュリティのお仕事のように、検証の観点が別の文脈で求められる分野もあり、同じ経験を違う言葉で説明できるようになります。技術的な裏付けを客観的に示したい場合、環境構築まで踏み込める説明材料としてCCNA（シスコ技術者認定）のような認定を持っておくと、実績が語れない領域を補えます。職種ごとの水準を把握しておきたい場合は、ソフトウェア作成者の年収・単価相場で開発職全体の位置づけを確認できます。

20年この市場を見てきた立場から言えば、実績を語れない状況で信用を得ている人には共通点があります。守秘義務の線を自分で引けていることです。話せない理由を明確に説明し、話せる範囲を具体的に語る。この二つが揃っている人は、発注側から「この人に頼んでも情報は漏れない」と判断されます。逆に、前の案件の内情を面白おかしく話す人は、その場では場が持っても、次の依頼は来ません。実績の見せ方は、営業の技術であると同時に、情報の扱い方を示す場でもあります。

もうひとつ、取引の形が実績の残り方に与える影響も見ておく価値があります。仲介を挟む取引では、受け手と発注側の間に事業者が入るため、誰の仕事だったのかが記録として残りにくくなります。手数料0%の直接の取引では、依頼者と直接やり取りした記録が手元に残り、実績公開の確認も本人に対して直接できます。運営者として見てきた限りでは、直接のやり取りを重ねている人ほど、次の相談で語れる材料を多く持っています。手取りが厚くなるという話と同じくらい、関係が記録として残ることの価値は大きいと考えています。

海外の案件を視野に入れる場合、実績の示し方の作法が国内と異なる点にも注意が必要です。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法では、プラットフォーム上で評価が蓄積される仕組みが説明されています。評価が公開の形で残る場所を一つ持っておくと、守秘義務で語れない国内案件を補う材料になります。