副業テスターの始め方｜案件の条件・安全な実行・報告の準備

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

スマートフォンやパソコンを使う副業を探していると、アプリテスター、ゲームテスター、動作確認といった募集を見かけます。ただ、普段からアプリを使っていることと、仕事として検証結果を渡せることは同じではありません。応募する前に、自分が何を確認し、どこまで操作してよく、何を成果として提出するのかを見極める必要があります。

副業テスターを考えるときの軸は、案件の種類・受けられる条件・許可された環境・報告の品質です。高い端末をそろえたり、たくさんの不具合を見つけたりすることだけが準備ではありません。実施していない項目を合格にせず、分からない条件をそのまま相談できることも仕事の土台になります。

本記事は、許可された対象で一般的な機能確認を行う仕事の準備を扱います。脆弱性の探索、侵入試験、負荷試験などを無断で行うための案内ではありません。報酬相場や採用を保証するものでもなく、募集要項、契約、担当者の指示により条件は異なります。本文中の案件、報告例、数値は説明用の架空例です。

副業テスターの仕事は「操作すること」より先に種類を分ける

テスト実行と設計では求められる成果が違う

テスト実行の案件では、確認する手順や期待する動作があらかじめ用意されていることがあります。担当者は指定された環境で操作し、結果を記録します。一方、テスト設計は、何をどの条件で確認するかを考え、確認漏れを減らすために項目を組み立てる仕事です。募集に「テスト」とだけ書かれていても、前者なのか後者まで含むのかを確かめてください。

たとえば、会員登録画面の確認を頼まれたとします。「指定された十項目を実行する」と「登録画面で必要なテスト項目を作る」では、必要な知識も見積もる時間も異なります。実行だけのつもりで引き受け、後からケースの作成や仕様の判断まで当然のように求められると、準備とのずれが生じます。応募時点で担当範囲を一文にできると、そのずれを相談しやすくなります。

また、不具合を見つけた人が必ず修正するわけではありません。プログラムの修正、原因調査、修正後の再確認が別の担当に分かれる場合もあります。「直せないから応募できない」と決めつける必要はありませんが、修正や開発を含む募集に、実行経験だけで対応できると伝えるのも避けましょう。

モニターや相互協力は収入の仕事と同じではない

使用感を伝えるモニター、公開前のアプリを利用して意見を出す協力、開発者同士の相互テストもあります。それぞれ目的が異なり、謝礼の有無や提出内容も一定ではありません。「テスター」という名前から、有償の業務委託だと判断しないことが大切です。

操作の感想を尋ねられる仕事でも、個人的に使いにくかった点と、仕様どおりに動かなかった点は区別します。「この色は好きではない」は感想です。「説明にある保存操作を行ったのに、保存済みの表示も記録も確認できなかった」は観測した現象です。どちらが求められるかによって、提出する文章の組み立てが変わります。

※表は横にスクロールできます。

未経験可という言葉を自分の条件に翻訳する

未経験可は、すべての知識が不要という意味とは限りません。基本的なファイル操作、文章での報告、指定の時間に連絡できることなどが前提に含まれる場合があります。仕事の説明を読んで知らない用語があれば、知ったふりをするより、どの作業で使うのかを確認しましょう。

「テスト結果をチケットへ登録する」とあれば、使用するツール、入力項目、説明資料の有無を聞けます。道具を使ったことがなくても、練習環境や説明が提供されるなら準備できる場合があります。反対に、すぐに一人で運用することを求める案件なら、その条件と現状の差を率直に伝える必要があります。

ケース作成そのものを学びたい場合は、テストケースの作り方を送料判定の例で整理した記事も参考になります。本記事では、設計技法を網羅するのではなく、副業として受ける範囲と実行・報告の流れに焦点を当てます。

応募前に時間・端末・費用・報酬の条件を見積もる

在宅と自由な時間に働けることは別

在宅の仕事でも、平日の日中に確認や連絡が必要な場合があります。リリース前の短期間に作業が集中する案件と、一定期間に自分の都合で試す案件では、本業との組み合わせ方が変わります。「自宅でできるから夜だけで大丈夫」と考えず、実作業、打ち合わせ、問い合わせ対応、それぞれの時間条件を確認してください。

自分が平日夜に一時間使えるとしても、そのすべてを操作に充てられるわけではありません。対象の受け取り、環境の準備、結果表への入力、証拠の整理、質問への返信が必要です。作業量の目安が示されている場合は、その時間に報告や再確認まで含むのかを確かめます。

架空の例として、二時間の予定で引き受ける確認に、準備二十分、操作七十分、報告三十分が必要だと見積もったとします。ここに追加の再確認が入れば、二時間を超える可能性があります。この例は標準工数ではありません。自分の作業記録から、操作以外の時間がどこに発生するかを見つけるための分け方です。

端末を買う前に指定環境を確認する

スマートフォンの機種、OS、ブラウザ、画面サイズ、通信条件など、必要な環境は案件ごとに異なります。手持ち端末でよいのか、貸与があるのか、指定機種を用意する必要があるのかを先に確認しましょう。新しい高性能端末ならすべて対応できるとは限りません。

端末の設定変更や専用アプリの導入が求められる場合は、提供元と用途、作業後の扱いを確かめます。私用の端末に、意味が分からない設定や過剰な権限を入れることを急がないでください。業務に必要な権限であるという説明と、実際の要求が一致しているかを担当窓口へ確認し、不明なまま進めない姿勢が必要です。

費用は端末だけではありません。通信、指定ソフト、配送、貸与品の返却などに費用がかかる場合があります。誰が負担するか、立て替えの上限、精算方法を確認します。仕事を受けるために高額な教材や機材の購入を先に迫られる場合は、仕事内容と購入条件を切り離して考え、契約を急がないでください。

報酬の計算単位と追加作業の扱いをそろえる

時給、確認項目単位、成果物単位など、報酬の決まり方によって注意点が異なります。時給なら、準備や報告、待機時間の扱いを確認します。成果物単位なら、対象の数と範囲、提出形式、修正や再確認の回数・期限が重要です。「一件」という単位が、一画面なのか一つのテストセットなのかでも、作業量は変わります。

不具合が見つからなかった場合に報酬がどうなるかも確認しておきましょう。見つけた件数だけで支払われる条件なら、その仕組みとリスクを理解する必要があります。報酬を得るために、仕様どおりの動作を問題として報告したり、同じ現象を分けて水増ししたりすることは、仕事の品質を損ないます。

※表は横にスクロールできます。

確認事項は、相手を疑うための質問ではありません。できることとできないことを合意する準備です。案件探しの経路を比較するなら、フリーランス案件の探し方も参照し、募集の名称だけでなく条件の具体性を比べてください。

作業は許可された対象・環境・データの範囲で行う

開始前に対象と操作の上限をそろえる

同じサービス名でも、本番環境と検証用環境が分かれている場合があります。指定されたURLやアプリ、アカウント、版を確認し、自分の判断で別の環境に移らないことが基本です。アクセスできることと、その場所を検証してよいことは別です。

開始時には、対象の名前だけでなく、今回確認する機能、使うデータ、操作してよい範囲、困ったときの連絡先を整理します。購入、送信、削除、外部通知など、他の人や実際の取引に影響する操作が含まれていたら、テスト用の手順と許可を確認してください。練習のつもりで本番の問い合わせを大量に送ったり、実際の決済を繰り返したりするものではありません。

担当者から渡されたアカウントでも、他の案件へ流用しないでください。権限が足りない場合は、認証を回避しようとせず、どの画面で何ができなかったかを連絡します。必要な権限を担当者が整えるまで、その項目は実行できない状態として残します。

本物の個人情報を練習材料にしない

入力データは、指定されたテストデータを使います。手元の顧客名簿、家族の連絡先、勤務先の資料などを、便利だからという理由で持ち込まないでください。架空の入力値でも、偶然実在する宛先へ送信される可能性がある操作は注意が必要です。使用する値と、通知が実際に飛ぶかどうかを確認しましょう。

画面の記録には、名前、連絡先、注文内容、認証情報などが写り込む場合があります。証拠を残す際も、必要な範囲に絞り、許可された保存先と共有方法を使います。個人のSNS、公開ストレージ、承認されていない外部ツールへ持ち込まないでください。文章を整える目的でも、秘密情報をそのまま外部へ貼り付けてよいとは限りません。

画像を加工して情報を隠す場合は、報告に必要な現象が分からなくならないようにします。ただし、記録方法自体にルールがある案件では、そのルールに従います。加工前の原本を残すか、保管期間をどうするかも自分だけで決めず、取扱条件を確認してください。

予定外の挙動が出たら、試行を増やす前に止まる

想定していないデータが見えた、他人の情報にアクセスできた、課金や外部送信が起きそうになったといった場合は、確認のために操作を広げないことが重要です。発生した時点の対象と操作を、許可された範囲の記録に残し、指定の窓口へ知らせます。問題の深刻さを自分で証明しようとして、さらに情報を集める必要はありません。

また、アクセス制限やセキュリティ警告が出たときに、別アカウントや別経路で通るかを試すのは、通常の動作確認とは別の行為になり得ます。案件に含まれる作業か分からない場合は止めましょう。安全に進める担当者は、止まった理由を説明できる人です。全部進めたように見せる人ではありません。

ここで必要な条件がそろわなければ、着手できる項目と条件待ちの項目を分けて相談します。条件待ちがあることを隠すと、後から「どこまで確認したのか」が分からなくなります。最初の確認は遠回りではなく、結果を信用できる状態にするための作業です。

不具合報告は推測より「再確認できる観測」を残す

原因を当てるより起きたことを切り分ける

報告の目的は、驚いたことを伝えるだけではなく、担当者が状況を理解し、次の判断に進めるようにすることです。「壊れています」「たぶん通信が原因です」だけでは、何を見ればよいか分かりません。観測した動作と、自分の推測を別にして書きましょう。

JSTQBが公開するFoundation Levelシラバスの欠陥マネジメントでは、問題の処理に必要な情報を伝えることや、環境、手順、期待結果と実際の結果などを記録する考え方が説明されています。また、報告した事象が調査の結果、欠陥以外の扱いになる場合もあります。詳しくはISTQB Foundation Levelシラバス日本語版（JSTQB翻訳）、5.5節をご確認ください。

以下は本記事で作成した架空の報告例です。実在する製品の不具合ではありません。現場の指定書式がある場合は、それを優先し、不要な項目を増やすより、必要な情報を正確に埋めてください。

この報告では、「備考が保存されていない」とまでは断定していません。確認画面に表示されないことと、データが保存されないことは別だからです。まだ見ていない保存結果を推測で書かないことで、調査の方向を不必要に狭めずに済みます。

期待する動作の根拠を確認する

自分が期待した動作と、仕様上求められている動作が一致するとは限りません。手順書、仕様、依頼時の説明など、何を根拠に判定したかを示します。資料間に食い違いがあれば、どちらが正しいかを自分で決めず、該当箇所を示して確認しましょう。

「前のサービスではこう動いた」「自分ならこう作る」という感覚は、使いやすさの提案にはなりますが、そのまま不具合の根拠とは限りません。報告欄を分けられるなら、仕様との差、使いにくさの意見、仕様を確認したい点を分けます。分類が不明なときは、観測事実を残して判断を依頼してください。

再現しない事象も、起きなかったことにする必要はありません。最初に起きた時刻や前後の操作、再確認で使った条件を区別し、「初回一回、同条件の再確認では未再現」と書けます。ただし、再確認のために無制限に操作を繰り返すのではなく、許可された回数や時間の範囲で行います。

報告の粒度は読み手と運用に合わせる

一つの報告に無関係な現象を詰め込むと、対応状況を追いにくくなります。反対に、同じ原因かもしれない現象を細かく分けすぎると、重複の整理に時間がかかります。現場のルールを確認し、既存の報告を検索できるなら、同じ現象が登録されていないかを見ます。

重要度や優先度も、個人の驚きだけで決めないでください。「作業を先に進められない」「見た目のずれだが操作はできる」など、観測した影響を説明すると判断材料になります。最終的な対応順を決める人が別にいる場合は、その役割を尊重します。

記録を短くする工夫と、情報を省きすぎることは違います。タイトルに現象の要点、本文に条件と手順、添付に必要な証拠という役割を持たせると読みやすくなります。長文で熱意を示すより、次の担当者が同じ状況を確認できるかを基準に読み返してください。

未実行・保留・修正後の確認を分けて納品する

全項目の状態を空欄のままにしない

作業が終わったかどうかは、見つけた不具合の件数だけでは分かりません。予定した確認のうち何を実施し、何が止まっているかも必要です。空欄があると、未着手なのか、問題がなかったのか、条件がそろわなかったのかを読み手が判断できません。

状態の名前は現場の指定に合わせますが、少なくとも「実施して期待どおりだった」「実施して差があった」「まだ実施していない」「条件がなく実施できない」を区別すると、範囲が伝わります。実施できなかった項目を、期限に間に合わせるために合格へ置き換えることは避けてください。

※表は横にスクロールできます。

「全体として問題なし」という言い方にも注意が必要です。今回確認した条件で問題を観測しなかったことと、製品のすべてに問題がないことは同じではありません。対象、版、範囲、未確認を添えて報告すれば、確認の限界も含めて判断に使えます。

修正されたという連絡と再確認の完了を分ける

開発担当から「修正しました」と連絡が来ても、それだけで自分の確認が終わったことにはなりません。どの版で修正されたのか、何を再確認するのかを確かめ、合意した範囲で結果を記録します。古い版を再度見ていると、修正が反映されていないように見える場合もあります。

再確認で期待どおりになった場合も、いつ、どの環境で確認したかを残します。近くの機能まで追加確認する必要があるかは、指示や担当範囲に従います。元の不具合が直ったことと、関連するすべての機能を確認したことを混ぜないようにしましょう。

再確認の途中で別の問題を見つけたら、元の報告との関係を整理します。同じ問題が残っているのか、新しい現象なのか、判断に迷う場合は、その迷いを含めて相談します。報告を閉じることを急ぐより、次の人が状態を追えるようにするほうが重要です。

納品時には残っている仕事も伝える

納品物を送る際は、ファイルの場所だけでなく、対象の版、実施範囲、未実行・条件待ち、確認してほしい点を短く添えます。報告書の中に詳細があっても、受け取る人が最初に把握できる入口を用意すると、確認が進みやすくなります。

たとえば「指定二十項目のうち十八項目を実行し、二項目は必要な権限がないため保留。保留対象と依頼済み事項は一覧の末尾に記載」と伝えられます。これは架空の件数例です。実行数だけを大きく見せるのではなく、分母と状態を一緒に示す考え方が大切です。

提出後の質問対応や追加確認が契約に含まれる場合は、対応できる時間と窓口を確認しておきます。提出した時点、受領された時点、検収された時点が別になっている案件もあります。完了の扱いと支払い条件は、契約や事前の取り決めに沿って確かめてください。

未経験からは小さな練習と正直な見本で準備する

練習は自分が操作してよい対象で行う

最初から実案件の内部資料を使わなくても、手順を読んで結果を分ける練習はできます。自分で用意した小さな練習用画面や、利用条件が明確な学習用環境など、操作と記録が許可されている対象を選びます。他人のサイトやアプリを、無断の負荷試験や安全性の探索に使わないでください。

練習の題材は一つに絞りましょう。たとえば入力欄のある簡単な練習画面なら、「何を入力し、どのボタンを押し、何が表示されたか」を順番に書きます。動作の良し悪しを判断する前に、相手が同じ手順をたどれるかを確認すると、報告文の足りない部分に気づけます。

練習中に不具合が出ない場合でも、観測記録は作れます。実施条件と期待どおりだった結果を残し、未確認の範囲を明示する練習になるからです。見本を作るために不具合を捏造する必要はありません。架空の報告例を作る場合は、学習用に作成した例であり、実際の製品で観測した結果ではないと分かるようにしてください。

一回の練習を振り返るための点検方法

練習を終えたら、すぐに別の題材を増やす前に、自分の記録だけを見て操作を再現できるか確かめます。前回の記憶に頼らなければ進められない箇所は、文章に条件が不足している可能性があります。最初に開く画面、入力前の状態、操作の順番を読み直し、必要な情報を補ってください。

たとえば「ボタンを押す」という一文だけでは、同じ画面に複数のボタンがあると迷います。「入力欄の下にある確認ボタンを押す」のように、区別に必要な情報を加えます。ただし、画面上のすべての配置を長々と説明する必要はありません。対象を取り違えないために必要な範囲を見極めることが、読みやすい記録の練習になります。

次に、結果の文章が操作の文章になっていないかを点検します。「確認ボタンを押した」は操作した事実です。「入力内容を示す確認画面が表示された」が観測した結果です。この二つを混ぜると、操作後に何が起きたかが抜けやすくなります。結果欄だけを読んだ人にも、何を見て判定したかが伝わるか確認しましょう。

時間も、単純な速さの競争にしないでください。最初は記録の整理に時間がかかっても、どこで迷ったかが分かれば改善できます。用語の理解に時間がかかったのか、手順が不足していたのか、画像を整理する方法が決まっていなかったのかを分けます。次回はそのうち一つだけを変えてみると、自分に必要な準備が見えやすくなります。

最後に、第三者へ見せる前の点検を行います。個人情報や他者の資料が混ざっていないか、架空例と実際の観測が区別されているか、未実行を実行済みと書いていないかを確認します。見本の見栄えを整えることよりも、何をした記録なのかを正確に説明できることを優先してください。

見本と実務経験を分けて応募する

応募書類には、使える端末や基本操作、対応できる時間、報告見本の内容を具体的に書けます。ただし、自主練習を受託実績として記載しないでください。「自主練習で結果表と報告例を作成した」と書けば、実務経験を誤認させずに準備を示せます。

過去の仕事の成果を見せる場合は、公開や転用の許可を確認します。名称を消しただけでも、画面や仕様から案件が分かる可能性があります。守秘義務のある資料を使わずに説明できるよう、作業の進め方や担当範囲を一般化して伝える方法を考えてください。

応募文では「何でもできます」より、今できること、説明があれば対応できること、現時点では難しいことを分けるほうが、仕事との適合を確認できます。時間の条件も同じです。毎日いつでも対応できると書くより、本業と両立できる実際の時間帯を示しましょう。

高評価投稿や先払いを仕事の条件にしない

動作確認の仕事と、ストアで高評価を付ける行為は別です。Google Playのユーザーの評価、レビュー、インストールに関する公式ポリシーでは、報酬などで評価やレビューを不正に操作する行為を禁止しています。テスト報告の対価と、公開評価への見返りを混同せず、良い評価の投稿を条件とする募集には応じないようにしましょう。

仕事内容の説明がないまま登録料や高額教材の支払いを求められる場合も、いったん止まって確認してください。少額の報酬を受け取った経験だけで、後から求められる大きな支払いまで安全だと判断しないことが大切です。不安な勧誘への対処は、副業詐欺を見分けるための確認と相談先で整理しています。

副業テスターは、ただアプリを触る仕事として考えるより、決めた範囲を確かめて結果を渡す仕事として捉えると、準備すべきことが見えます。無理に多くの案件へ応募する前に、自分の環境と時間で、正確な記録を作れるかを試してみてください。

報告が短くても、対象と条件、実際にしたこと、見えた結果、まだ分からないことが区別されていれば、次の判断に使いやすくなります。できない操作を無理に通すのではなく、止まった理由を伝えることも含めて、自分が安心して続けられる仕事を選びましょう。

参照：ISTQB Foundation Levelシラバス日本語版（JSTQB翻訳）、Google Play公式ポリシー。確認日：2026年10月21日。案件ごとの契約、情報管理、操作許可、最新の公式ルールを優先してください。