QA・テストの継続案件にする｜単発で終わらせない

QA・テストの仕事を業務委託で受けたものの、リリースが終わった時点で「ありがとうございました」で関係が切れてしまう。次の月にはまた案件を探し直している。QA・テストの継続案件という言葉で検索する人の多くが、この状態にいます。結論から書きます。QA・テストが単発で終わるのは、スキルが足りないからではなく、発注側が「テストを実施する工程」として切り出して発注しているからです。継続案件にするには、実施の担い手ではなく品質の状態を管理する担い手に、契約と成果物の形を移す必要があります。この記事では、その移し方を工程ごとに分解します。

QA・テストの案件が単発で終わる構造

継続にならない案件には、共通した形があります。個人の頑張りの問題ではなく、発注のされ方の問題です。まずここを正確に理解しないと、努力の向きがずれます。

発注書に書かれているのが「工程」だから切れる

単発で終わる案件の発注書には、たいてい「結合テストの実施」「受け入れテストの支援」といった工程名が書かれています。工程は必ず終わります。終わった時点で契約の目的物が納品済みになり、更新する理由がなくなります。ここが最も重要な分岐点です。

一方で継続している人の契約書を見ると、目的物の書き方が違います。「対象プロダクトの品質管理業務」「テストケース資産の保守および回帰テストの実施」のように、終わりのない対象が書かれています。プロダクトが動き続ける限り対象がなくならないので、契約を切る理由が発生しません。同じ作業をしていても、契約の書き方ひとつで単発と継続に分かれます。

初回の契約でいきなりこの書き方に持ち込むのは難しい場合もあります。その場合でも、工程名の後ろに「および同工程で作成したテスト資産の保守」の一文を足せるかどうかを交渉する価値があります。この一文があるだけで、リリース後に不具合が出たときの相談先が自動的にこちらになります。

検収の完了と同時に接点が消える

多くのQA・テスト案件では、テスト完了報告書を提出して検収が下りた瞬間に、チャットツールのゲストアカウントが停止されます。プロジェクト管理ツールの権限も外れます。この状態になると、次の開発が始まったときに発注側が思い出すきっかけがありません。

発注側の担当者に悪意はありません。単純に、権限管理のルールとして契約終了時にアカウントを閉じているだけです。だからこそ、契約が切れる前に「次に相談してもらう窓口」を人間関係の側に作っておく必要があります。具体的には、報告書の提出時に担当者へ直接メールで連絡先を渡し、リリース後に不具合が出た場合の一次相談を無償で受ける旨を伝えておく形です。これは値引きではなく、接点を残すための投資です。

「テスターは代替可能」と見られている

発注側の視点に立つと、テストの実施だけを切り出した業務は代替可能に見えます。手順書があれば誰でも同じ結果を出せるはずだ、という前提があるからです。この前提が正しいうちは、契約更新のたびに他の候補と比較されます。

代替可能性を下げる唯一の方法は、そのプロダクト固有の知識を自分の中に蓄積し、それを可視化することです。過去にどのモジュールで不具合が多かったか、どの機能が仕様変更に弱いか、どのテストケースが形骸化しているか。この情報は手順書に書かれていません。書かれていない知識を持っている人を外すと、発注側のコストが上がります。継続はここで決まります。

継続案件になりやすい仕事の型

QA・テストの領域で継続契約になりやすい仕事には、はっきりした型があります。自分がどの型に近いかを把握して、足りない部分を埋めていくのが最短です。

リリース周期に張り付く型

SaaSやモバイルアプリのように、リリースが定期的に発生するプロダクトでは、リリースのたびに回帰テストが必要になります。この回帰テストを担当する形は、最も継続になりやすい型です。開発が続く限り仕事がなくならないからです。

この型に入るための条件は、リリース判定の会議に呼ばれる立場になることです。テストの結果を提出するだけの立場だと、判定は開発側が行います。判定の場にいると、品質に関する意見を求められる立場になります。求められる立場になった時点で、契約の性質が実施から判断に変わります。

実務的には、テスト完了報告に必ず「リリース可否に関する所見」を1段落つけることから始まります。合否の一覧表だけを出すのではなく、残存する不具合のうちどれが利用者に影響し、どれが影響しないかを自分の言葉で書きます。この所見が意思決定に使われるようになれば、次のリリースでも呼ばれます。

テスト資産を預かる型

テストケース、テストデータ、自動化スクリプト。これらはプロダクトと同じく資産です。資産には保守が必要で、保守には担当者が必要です。テスト資産の保守を契約の対象に含める形は、稼働が薄い月でも契約が残りやすい型です。

保守の中身は、仕様変更に合わせたテストケースの更新、実行されなくなったケースの棚卸し、重複ケースの統合などです。3年ほど運用されたプロダクトのテストケースを見ると、実際には誰も実行していないケースが半分近く残っていることが珍しくありません。この棚卸しを引き受けると、発注側にとって手放しにくい存在になります。

自動化スクリプトを預かる場合は、実行環境の維持まで含めるかどうかを契約で明確にしてください。ブラウザのバージョンアップでスクリプトが落ちたとき、それを直すのが誰の仕事なのかを決めていないと、無償対応の温床になります。

品質の状態を定期報告する型

週次または隔週で、プロダクトの品質状態をレポートする形です。不具合の発生件数の推移、未修正の残存状況、テスト実行の進捗、リスクが高いと判断している領域。これらを定期的に出す立場になると、発注側の会議資料に自分の成果物が組み込まれます。

会議資料に組み込まれた成果物は、止めるとその会議が回らなくなります。継続の理由が組織の側に生まれるという点で、この型は強いです。レポートの作成に時間をかけすぎないよう、テンプレートを作って30分で仕上げられる形に落とし込んでおくと、稼働の割に効果が大きくなります。

契約の段階で決めておくこと

継続の可否は、実は稼働が始まる前の契約段階でかなりの部分が決まっています。あとから変えるのは難しいので、初回に押さえます。

作業範囲を工程ではなく対象で書く

前述の通り、工程名で契約すると工程の終わりが契約の終わりになります。交渉の場では「この工程だけを切り出すより、対象プロダクト単位で見たほうが引き継ぎのコストが下がります」という説明が通りやすいです。発注側にとっても、担当が入れ替わるたびに仕様説明をやり直すのは負担だからです。

範囲を対象で書く場合、逆に範囲が無限に広がる危険もあります。そこで「対象プロダクト」の定義と、そこに含まれない周辺システムを列挙しておきます。含まれないものを書いておくと、後から範囲外の依頼が来たときに追加契約の相談に持ち込めます。

検収の条件を文章にしておく

QA・テストの案件で最ももめるのが検収です。「テストが終わった」の定義が発注側と受注側でずれていると、いつまでも検収が下りません。検収条件は次の3点を文章にしておきます。テストケースの実行完了率をどこに置くか、未修正の不具合が残っている状態で完了とするか、報告書の様式は何か。

支払いの期日についても確認しておいてください。フリーランス保護新法では、発注事業者が給付を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定めることが求められています。制度の詳細は厚生労働省や公正取引委員会の案内で確認できます。検収の条件が曖昧なままだと、この期日の起算点そのものが定まりません。

更新の相談時期をあらかじめ入れる

契約書に「契約満了の1か月前までに更新の意思を相互に確認する」という条項を入れておくと、更新の話を切り出す口実が自動的に生まれます。自分から値上げや継続を切り出すのが苦手な人ほど、この条項が効きます。決められたスケジュールとして話し合いの場が発生するので、交渉という空気になりません。

稼働中に継続を決めている成果物

契約と同じくらい効くのが、日々出している成果物の質です。発注側は、更新を判断するときに成果物を見ます。以下の3つは、QA・テストの継続可否に直接効きます。

テスト観点表

テストケースの一覧ではなく、どういう観点でそのプロダクトを見ているかを整理した表です。機能単位ではなく、利用者の行動単位、データの状態単位、異常系の種類単位で観点を並べます。この表を持っている人は、仕様変更が来たときに「この変更はどの観点に影響するか」を即答できます。

観点表があると、発注側は「この人はプロダクトを構造で理解している」と判断します。実行を代行しているだけの人との差が、最もはっきり出るのがこの成果物です。作るのに時間はかかりますが、一度作れば同じプロダクトで使い続けられます。

不具合票の質

不具合票は、開発者が最も頻繁に読むこちらの成果物です。ここの質が低いと、開発者から「あの人の不具合票は再現できない」という評価が回ります。逆にここが良いと、開発チームの側から継続を求める声が上がります。

良い不具合票の条件ははっきりしています。再現手順が第三者の環境で再現できること、期待結果と実際の結果が分けて書かれていること、影響範囲の推定が書かれていること、そして再現に必要な前提データが添付されていること。特に前提データの添付は、開発者の調査時間を大きく縮めます。

もうひとつ、修正済みの不具合を再確認したときに、確認した環境とバージョンを必ず書き添えてください。ここが書かれていない不具合票は、後から誰も追跡できません。

品質レポートの粒度

レポートは詳しければ良いというものではありません。読む相手が誰かで粒度を変えます。開発リーダーが読むレポートには不具合の内訳と技術的なリスクを、事業側の担当者が読むレポートにはリリース可否と利用者への影響を書きます。同じ数字を、相手に合わせて2種類の言い方で出せる人は重宝されます。

この使い分けは、QA・テストの領域に限った話ではありません。QA・テスト・コードレビューのお仕事では、テスト実施だけでなく仕様レビューや品質改善の提案まで含めた業務内容が整理されています。募集の段階でどこまでを求められているのかを読み取る目を持つと、契約前に継続の見込みが判断できるようになります。

継続の相談を切り出す手順

更新の相談は、切り出し方より切り出す時期で結果が変わります。手順を分解します。

時期は「発注側の予算検討」に合わせる

契約更新の相談は、発注側が次期の予算を検討している時期に持ち込むのが基本です。予算が固まった後に相談しても、枠がない以上どうにもなりません。多くの企業では、期の変わり目の2か月ほど前から次期の体制検討が始まります。担当者との雑談の中で、次の期の開発計画がいつ決まるのかを聞いておくと、この時期を外しません。

伝えるのは実績ではなく「継続した場合の差」

更新の相談で自分の実績を並べるのは、あまり効きません。実績は発注側もすでに知っています。効くのは、継続した場合と交代した場合の差を具体的に示すことです。

たとえば「現在のテストケースは私が更新しているため、担当が変わる場合は仕様のキャッチアップに数週間かかります」「過去の不具合傾向を把握しているので、リスクの高い箇所に工数を寄せられています」といった説明です。これは脅しではなく、引き継ぎコストという実在するコストの提示です。発注側は継続と交代を比較して判断しているので、比較の材料を渡す形になります。

断られたときは理由を分解する

更新されなかった場合、理由は大きく3つに分かれます。予算がない、プロジェクト自体が終わった、こちらの評価が低かった。この3つは対応がまったく違うので、混ぜて落ち込まないことです。

予算とプロジェクト終了は自分の力の外側にあります。この場合は関係を維持して次の機会を待つのが正解で、終了時にきちんと引き継ぎ資料を残しておくと、次に別のプロダクトが立ち上がったときに声がかかります。評価が低かった場合だけ、成果物を見直す必要があります。どれに該当するかは、率直に聞けば教えてもらえることが多いです。

継続を支えるスキル、資格、ツール

継続案件を持つフリーランスが実際に何を持っているかを整理します。

実務スキルは設計と自動化の2軸

テスト実施のスキルだけでは、代替可能性から抜け出せません。抜け出す軸は2つです。ひとつはテスト設計、つまり仕様書から観点を導き出し、限られた工数の中でどこを厚く見るかを決める力。もうひとつはテスト自動化、つまり回帰テストを機械に任せて人間の工数を削る力です。

このうち、継続案件に直結しやすいのは設計側です。自動化はツールの知識で追いつける部分がありますが、設計は対象プロダクトへの理解が前提になるため、外部から短期間で置き換えにくいからです。自動化に手を出す場合も、まず自分が設計した観点のうち反復するものから自動化するという順番を守ると、無駄なスクリプトを作らずに済みます。

隣接する領域として、セキュリティやAI活用のテストに範囲を広げる道もあります。AI・マーケティング・セキュリティのお仕事では、AIを組み込んだプロダクトの検証やセキュリティ観点のチェックを含む案件の傾向が確認できます。生成AIを使った機能が増えたことで、出力の妥当性をどう検証するかという新しい観点が現場で求められ始めています。

資格は入口の説得材料として使う

JSTQB認定テスト技術者資格は、QA・テストの領域で最も広く知られた資格です。ただし資格を持っているから継続になるわけではありません。資格が効くのは、まだ実績を見せられない段階で「テストの共通言語を理解している」ことを示す場面です。

インフラやネットワークの知識を求められる案件では、ネットワークの基礎を体系的に学んだ証明としてCCNA（シスコ技術者認定）が評価されることもあります。テスト環境の構築やネットワーク起因の不具合切り分けを任される場面では、この知識の有無が作業速度に直結します。資格は継続の理由にはなりませんが、最初の1本を取る確率は上げます。

ツールは発注側の環境に合わせる

テスト管理ツールや不具合管理ツールは、発注側がすでに使っているものに合わせるのが原則です。自分の使い慣れたツールを持ち込もうとすると、それだけで導入の手間という抵抗が生まれます。

現場で使われているものは、不具合管理であればJiraやRedmine、テスト管理であればスプレッドシートを含む各種のテスト管理ツール、自動化であればブラウザ自動操作系のフレームワークが中心です。重要なのは、どれか1つを深く使えることよりも、新しいツールに1週間程度で慣れられる学習の速さです。継続案件を複数持つと、クライアントごとにツールが違う状況が普通に発生します。

継続案件と、フリーランスとしての足元

継続案件は収入の安定につながりますが、同時にリスクも生みます。ここを整理しておかないと、別の意味で身動きが取れなくなります。

1社に偏りすぎる状態を避ける

継続案件が1社だけになると、その1社の都合で収入がゼロになります。プロジェクトの中止、担当者の異動、方針転換。どれも自分では防げません。継続を増やす努力と並行して、複数のクライアントを持つ設計にしておく必要があります。

現実的には、稼働の中心になる継続案件を1つか2つ持ちつつ、稼働の軽いスポット案件を並行させる形が扱いやすいです。スポット案件は収入としては小さくても、別の業界のプロダクトに触れる機会になり、観点の引き出しが増えます。

保険と社会保険の整理

会社員からフリーランスになると、健康保険と年金の扱いが変わります。国民健康保険と国民年金が基本で、業種によっては国民健康保険組合という選択肢もあります。労災については、特別加入の制度が段階的に対象を広げてきました。制度の内容は日本年金機構や厚生労働省の案内で確認できます。

QA・テストの仕事は在宅で完結する場面も多い一方、現場常駐を求められる案件も残っています。次に示すのは、実際に募集されている案件条件の一例です。

職種：QAエンジニア、テストエンジニア・テスター 稼働日数：週1〜5日本郷三丁目 or 湯島 or 御茶ノ水 出典: flxy.jp

注目したいのは稼働日数の書き方です。週1日から相談できる案件は、複数のクライアントを並行させる働き方と相性が良く、1社依存を避けたい人にとって現実的な選択肢になります。逆に週5日の常駐案件は収入が安定する代わりに、他の案件を持つ余地がなくなります。継続を狙う際も、この稼働日数の設計を先に決めておくと迷いません。

将来性をどう見るか

QA・テストという職種そのものは、当面なくなりません。むしろ、AIによるコード生成が広がったことで、生成されたものが仕様通り動くかを検証する工程の重要性は上がっています。生成の速度が上がるほど、検証がボトルネックになるからです。

ただし、仕事の中身は変わります。手順書通りにテストを実行する作業は、自動化とAIの支援で減っていきます。残るのは、何をテストすべきかを決める仕事、リスクを見積もる仕事、品質の状態を関係者に説明する仕事です。継続案件を狙うということは、この残る側の仕事に自分を寄せていくということでもあります。

継続が生まれやすい発注元を見分ける

同じ努力をしても、継続にならない発注元があります。応募や商談の段階で見分けられると、無駄な消耗を減らせます。

プロダクトが動き続けているか

最も単純で確実な判定基準です。開発が終わって保守運用だけになったシステムでは、テストの需要が構造的に細ります。逆に、機能追加が続いているプロダクトでは回帰テストの必要が繰り返し発生します。募集要項を読むときは、開発体制の人数と、直近のリリース頻度を確認してください。面談の場で「直近半年のリリースは何回くらいですか」と聞けば、たいてい答えてもらえます。

受託開発のプロジェクトに入る場合は、そのプロジェクトの終了予定日が契約の実質的な上限になります。この場合、継続を狙うなら「同じ発注元の別プロジェクト」に横展開する設計が必要です。プロジェクト内で成果を出すだけでなく、発注元の社内で自分の名前が共有される状態を作るのが目標になります。

品質に対する困りごとが言語化されているか

商談の場で「品質を上げたい」としか言われない案件は、継続になりにくい傾向があります。困りごとが曖昧なままだと、何をもって成果とするかが決まらず、評価が担当者の気分に左右されるからです。

逆に「リリース後の障害が月に何件か出ていて、その多くが特定のモジュールに集中している」のように具体的に語られる案件は、解決すべき対象がはっきりしています。対象がはっきりしていれば、改善したかどうかが数字で示せます。示せれば、次も任せる理由になります。初回の商談で困りごとを掘り下げる質問をいくつか用意しておくと、この見極めができます。

過去に業務委託を継続させた経験があるか

その会社が過去にフリーランスや業務委託の担当者と長く付き合った経験があるかどうかは、かなり効く指標です。経験がある会社は、外部の人にどこまで権限を渡せばうまく回るかを知っています。経験がない会社では、権限が渡されないまま責任だけを求められる状況が起きがちです。

面談の場で「現在、業務委託の方は何名くらい関わっていますか」「一番長い方でどのくらい継続されていますか」と聞くのは、失礼な質問ではありません。むしろ長く関わる前提で考えている姿勢として受け取られます。答えづらそうな反応が返ってきた場合は、その理由を含めて判断材料になります。

運営者として見てきた「継続する人」の共通点

在宅ワークと業務委託の市場を20年運営してきた立場から言えば、長く続いている人ほど、作業そのものより「この人に任せると楽だ」という状態を作ることに時間を使っています。返信が早い、報告の様式が毎回同じ、聞かなくても状況がわかる。派手さはありませんが、発注側が担当を変えたくない理由になるのはこの部分です。

もうひとつ、運営者として見てきた限りでは、中間マージンが乗らない直接取引の関係のほうが継続しやすい傾向があります。理由は単純で、同じ予算で発注側はより多くの作業を頼めるからです。手数料0%で取引できる関係では、受け手の手取りが厚くなる一方、発注側から見ると同じ支出でより長い期間の伴走を依頼できます。この構造があると、予算が厳しくなった局面でも「まずこの契約から切る」という判断になりにくい。金額の大小より、双方が得をしている実感があるかどうかが、更新の場面で効いてきます。

職種ごとの収入の全体像を把握しておくことも、継続の判断材料になります。ソフトウェア作成者の年収・単価相場では、開発職の収入水準が公的統計をもとに整理されています。QA・テストは開発職と隣接した位置にあるため、自分の立ち位置を測る参考になります。また、長期的なキャリアの設計という点では定年後のフリーランス独立｜退職金を活かした起業プランと注意点のように、年齢を重ねてからの働き方を扱った記事も参考になります。QA・テストは体力よりも経験の蓄積が効く職種なので、長く続ける前提で設計する価値があります。

継続案件は、運が良い人に降ってくるものではありません。契約の書き方、成果物の形、相談を切り出す時期。この3つを意図的に設計した人のところに集まります。今の案件が単発で終わりそうだと感じているなら、次の契約更新までに、契約書の目的物の一文とテスト観点表の2つだけでも整えてみてください。この2つは、稼働を増やさずに継続の確率を変えられる、数少ないレバーです。

よくある質問

Q. QA・テストの経験が浅くても継続案件は狙えますか？

狙えます。継続の可否を分けているのは経験年数より、プロダクトの知識を蓄積して可視化しているかどうかです。テスト観点表を作る、不具合の傾向をまとめる、仕様変更の影響範囲を整理する。この作業は経験が浅くても始められます。実施だけを代行している状態から抜け出すことが先で、年数はその後についてきます。

Q. 契約書に「テスト資産の保守」を入れてもらえない場合はどうすべきですか？

契約本文が変えられないなら、作業計画書や見積書の備考に「テスト資産の更新を含む」と書いて合意を取る方法があります。書面のどこかに残っていれば、更新時の交渉材料になります。それも難しければ、報告書の中で保守した内容を毎回明記してください。実績として蓄積すれば、次の契約で範囲に含める根拠になります。

Q. 継続案件は何社くらい持つのが現実的ですか？

稼働の中心になる案件を1社から2社、稼働の軽い案件を並行させる形が扱いやすいです。1社に絞ると、そのプロジェクトが終わった時点で収入が途切れます。逆に多すぎると、クライアントごとに違うツールや報告様式への切り替えコストが膨らみます。週の稼働日数を先に決めて、その枠に収まる件数から逆算するのが安全です。

Q. テスト自動化ができないと継続は難しいですか？

難しくありません。継続に直結しやすいのは自動化よりテスト設計の力です。どこを厚く見るかを決められる人は、対象プロダクトへの理解が前提になるため外部から置き換えにくい存在になります。自動化は、自分が設計した観点のうち反復するものから着手すると無駄がありません。順番を逆にすると、使われないスクリプトが増えます。

Q. 更新の相談はいつ切り出すのが適切ですか？

発注側が次期の予算や体制を検討している時期です。多くの企業では期の変わり目の2か月ほど前から検討が始まるため、そこに合わせます。予算が固まった後では枠がなく、内容の良し悪しに関係なく通りません。契約書に「満了の1か月前までに更新意思を確認する」条項を入れておくと、切り出す口実が自動的に生まれます。