作業の中身を書く在宅サイトやアプリの使い勝手テストの職務経歴書

結論から書きます。サイトやアプリの使い勝手テスト、いわゆるユーザビリティテストの在宅案件で職務経歴書が通らない最大の原因は、職種名と期間しか書いていないことです。「ユーザビリティテスト業務　2年」と書かれても、選考する側は何も判断できません。テスト設計をしたのか、被験者として参加しただけなのか、レポートを書いたのか、その粒度が分からないからです。

この領域は職種名が業界内でまだ揺れているという特徴があります。ユーザビリティテスト、UXリサーチ、ユーザーテスト、モデレーター、テストオペレーター。同じ作業に複数の呼び名が並立していて、しかも会社によって指す範囲が違う。だからこそ、職種名に頼った書き方が最も通用しない領域なんです。書くべきは肩書きではなく、作業の中身です。

この記事では、在宅で使い勝手テストの案件を取りにいくための職務経歴書を、構成単位で分解して解説します。未経験からどう書くか、経歴が短い場合にどう埋めるか、そして書類が通らない状態が続いたときに何を疑うべきかまで扱います。精神論は書きません。

職務経歴書が読まれる時間と、その中で何が見られるか

前提として、書類選考にかけられる時間は非常に短いという傾向が見られます。中途採用の書類選考で、1通あたり数十秒から1分程度で振り分けが行われるのは珍しくありません。業務委託の案件応募であればさらに短く、冒頭の職務要約3行で判断が終わることもあります。

この時間内で確認されているのは、次の点です。

中途採用では、募集要項に求める人物像や優遇条件などが記載されている場合があります。企業側がどのような人材を必要としているのかを知るための大事な情報源となるので、職務経歴書を作成する前に確認しておきましょう。技術職の中途採用では即戦力の需要が高いとされており、実務経験や知識、スキルが重視されやすくなっています。職務能力の高さをPRしてそれらの能力が採用担当者に正確に伝わるよう、職務経歴書には情報を漏れなく簡潔に記載しましょう。 出典: type.jp

要するに「募集要項を読んでから書け」ということです。当たり前に聞こえますが、正直なところ、これができていない書類が本当に多い。同じ職務経歴書を全案件に送っている応募者は、募集要項に書かれたキーワードが一つも入っていない書類を提出することになります。読み手はまず自分たちの要件に対応する記述を探すので、対応が見つからなければそこで終了です。

この領域特有の「実績が数字にならない」問題

営業なら売上、開発なら処理速度やリリース数といった形で成果を数値化できます。ところが使い勝手テストは、成果が「発見した課題の質」であり、数値化が難しい。30件の課題を発見しました、と書いても、それが重要な課題だったのかは伝わりません。

そこで代替として使えるのが、プロセスの数値です。実施したテストのセッション数、被験者の人数、担当した画面数や機能数、レポートのページ数、テスト設計から報告までの日数。これらは事実として書けます。「8名の被験者に対し60分のリモートテストを実施し、5営業日で報告書を提出」と書けば、稼働の規模とスピードが同時に伝わります。

もう一つ有効なのが、課題が反映されたかどうかです。「報告した課題のうち3件が次回リリースで改修対象になった」という記述は、質の証明として機能します。守秘義務の範囲で書けない場合は「改修方針の決定会議に資料提供者として同席」といった表現に置き換えます。

在宅・使い勝手テストの職務経歴書、5つの構成要素

構成は次の順で固定します。読み手が探す順番に合わせるのが目的で、独創性は不要です。

要素1: 職務要約（3行から5行）

ここだけで判断される可能性がある場所なので、最も時間をかけます。書くのは、担当した工程の範囲と対象サービスの種類と在宅での稼働実績の3点です。

悪い例。「Web業界にて3年間、ユーザビリティテスト業務に従事してまいりました。ユーザー視点を大切に、丁寧な業務遂行を心がけております。」

良い例。「EC及びスマートフォンアプリを対象に、リモートユーザビリティテストの実施とレポート作成を3年担当。テスト設計は指示書ベース、モデレーションと書き起こし、課題一覧の作成までを在宅で完結。累計60セッション以上、対象12サービス。」

違いは形容詞の有無です。前者は「丁寧」「大切に」という自己評価しか含んでおらず、情報量がありません。後者は全て検証可能な事実です。

要素2: 職務経歴（案件単位で並べる）

会社単位ではなく、案件単位で書きます。在宅の業務委託では複数の発注元と並行することが普通で、時系列の会社リストにすると実態が伝わらないためです。

1案件につき次の5項目を並べます。

期間（2025年4月から9月）、対象（アパレルEC、月間訪問者数規模は非公開）、役割（モデレーターと書き起こし担当）、体制（リサーチャー1名、デザイナー2名のチーム、全員リモート）、成果（6名分のセッションを実施し、購入導線の課題14件を一覧化。うち4件が改修対象に採用）。

この形式なら、案件が1件しかなくても様になります。逆に、案件を10件並べて全部が1行だと、経験の浅さが露呈します。数より深さです。

要素3: 作業の中身の分解

ここが本記事で最も伝えたい部分です。「ユーザビリティテスト」という言葉を、実際の作業に分解してリスト化します。分解すると、自分が何をやっていて何をやっていないかが明確になり、募集要項との照合が一目で済みます。

分解の例を挙げます。テスト計画書の作成、タスクシナリオの設計、被験者の要件定義、スクリーニング設問の作成、日程調整と事前連絡、テスト環境の準備と接続確認、当日のモデレーション、発話の記録、録画データの管理、書き起こし、発言の分類とタグ付け、課題の優先度付け、報告資料の作成、報告会での説明、改善案の提示、再テストの設計。

このうち自分が担当したものに印を付けて、担当範囲として明記します。「モデレーションは未経験だが書き起こしと分類は200時間以上」といった書き方は、正直で、かつ配置しやすい情報です。全部できると書いて実際にできないより、はるかに信頼されます。

要素4: 使用ツールと作業環境

在宅であることが前提なので、環境は業務要件です。ここは箇条書きで簡潔に書きます。

会議・録画ツール（Zoom、Google Meet、Microsoft Teams等の使用経験）、記録・分析ツール（スプレッドシート、Miro、Figma等）、書き起こしツール、通信環境（回線種別と実測速度）、検証端末（PCのOSとスペック、スマートフォンの機種とOSバージョン、タブレットの有無）、静穏な作業時間帯。

検証端末を複数持っていることは、この職種では明確な加点要素という特徴があります。特に2世代から3世代前の端末は、実ユーザーの環境に近く、動作の重さを再現できるため重宝されます。最新機種しか書いていない書類より、古い端末の型番が並んでいる書類のほうが実務的に見えます。

要素5: 自己PR（200字から300字）

長く書かない。ここで書くのは性格ではなく、再現性のある行動です。

「テスト中に被験者が黙り込んだ際、誘導にならない範囲で『今、何を探していますか』と問い直す運用を徹底しています。発話が途切れた区間は録画のタイムスタンプを記録し、書き起こし時に該当箇所を優先して確認しています。」

これは性格の話ではなく、手順の話です。手順として書かれていれば、入社後・契約後の動きが想像できます。「几帳面です」では何も想像できません。

未経験から書く場合の翻訳作業

未経験でこの領域に応募する人が最も詰まるのが、書くことがないという状態です。ですが、翻訳の余地はかなり広い。

前職から翻訳できる要素

事務職・経理職。定型手順の遵守、記録の書式統一、例外処理の報告。使い勝手テストは手順書からの逸脱を記録する仕事なので、この経験は直結します。「請求処理の手順書に沿った処理を月300件、イレギュラー発生時は所定様式で上長に報告」と書けば、そのまま業務適性の説明になります。書式に沿った文書作成の基礎を客観的に示すならビジネス文書検定が使えます。文書の構成や敬語の運用を体系的に問う検定で、報告書の品質を担保できることの根拠になります。

接客・販売職。相手が言葉にしない詰まりを観察する経験。「レジ前で商品を戻すお客様の動きから、価格表示の位置を変更する提案を店舗内で実施」といったエピソードは、観察と改善提案の経験として書けます。

カスタマーサポート。この職種は最も直結します。ユーザーがどこで詰まるかを毎日聞いている職種だからです。「問い合わせ内容を分類し、月次で上位5件の発生原因を報告」という業務は、課題の優先度付けそのものです。

育児・介護での中断期間。空白期間として隠すより、観察の経験として書くほうが有効な場合があります。ただし過剰に美化すると逆効果なので、事実ベースで1行から2行にとどめます。

開発・IT系の経験。テスト工程の理解があると、報告の解像度が上がります。開発現場でテストがどう位置づけられているかはアプリケーション開発のお仕事に工程と役割が整理されており、自分の経験がどの工程に対応するかの確認に使えます。ネットワーク周りの切り分けができると動作不良の報告精度が上がるため、CCNA（シスコ技術者認定）のような資格を持っている場合は明記する価値があります。

実績が本当にゼロの場合

作るしかありません。ただし、無理のない範囲で作れます。

自分でテストレポートを1本書きます。対象は公開されている任意のWebサービスかアプリ。タスクを3つ設定し（会員登録する、商品を探してカートに入れる、退会手続きの入口を見つける）、自分で操作して詰まった箇所を記録し、3ページから5ページのレポートにまとめる。所要時間は3時間程度です。

これを職務経歴書に「実務外での自主的な取り組み」として3行で記載し、提出可能な状態にしておく。応募時に添付できれば、経験の有無を議論する前に実力を見せられます。

私自身、編集の仕事に移った直後、実績がないことを埋めるために既存メディアの記事構成を分解した資料を作って持ち歩いていました。結果として、それが職務経歴書の内容より評価されたことが何度かあります。書類は自分を説明する道具ですが、成果物は説明を省略させる道具です。

対象サービスを勝手にテストするときの注意

自主レポートを作る際、利用規約でリバースエンジニアリングや自動アクセスが禁止されている場合があります。手動で通常利用する範囲であれば問題になることは少ないですが、レポートを公開する場合は、対象サービス名を伏せるか、事前に確認するのが安全です。応募時の添付資料として個別提出する分には、通常の利用の範囲に収まります。

案件記述のテンプレートと記入例

実際の記述例を示します。そのまま項目名を流用できます。

案件A 期間: 2025年4月から2025年9月（6か月、業務委託） 対象: 食品系ECサイトのスマートフォン版 役割: リモートテストのモデレーションと記録 体制: 発注元のリサーチ担当1名と2名体制、全工程リモート 作業内容: 事前アンケートの設問レビュー、被験者8名に対する60分セッションの実施、発話の書き起こし、課題の分類と一覧化 成果: 検索から購入完了までの導線で課題14件を抽出。うち4件が次期改修の対象として採用 環境: 光回線、Windows 11、iOS端末2台（最新機種と3年前の機種）、Android端末1台

この形式の利点は、担当していない工程が自然に省略されることです。テスト設計をしていないなら「作業内容」に書かなければいいだけで、嘘をつく必要がありません。募集要項が設計まで求めているなら、そもそもその案件は自分向きではないという判断ができます。

やりがちな失敗と、その修正

書類を見ていて頻出する問題を挙げます。

失敗1: 全案件に同じ書類を送る。最も多い。職務要約の1行目だけでも案件ごとに書き換えれば、通過率は変わります。募集要項が「BtoB SaaSの検証経験者」なら、その語をそのまま職務要約に入れる。キーワードの一致は最初の関門です。

失敗2: 分量が多すぎる。業務委託の応募で5ページの職務経歴書を送るのは、正直なところ、これはどうかと思います。2ページが上限だと考えてください。案件数が多い場合は、応募先に関連する案件だけを詳細に書き、残りは一覧表に落とします。

失敗3: 守秘義務の扱いが雑。サービス名やクライアント名を無断で書くのは契約違反になり得ます。「大手アパレルEC（社名非公開）」「従業員規模1000名以上の製造業向け業務システム」といった書き方に統一します。逆に、守秘義務を守れている書類は、それ自体が信用材料になります。

失敗4: 在宅を「希望」として書く。在宅は条件であって、経歴の説明の中では実績として書くべきものです。「在宅を希望します」ではなく「全工程を在宅で完結した実績が3案件」と書きます。

失敗5: ツールの列挙だけで終わる。ツール名を並べただけでは、使えるレベルが分かりません。「Miroで課題一覧のクラスタリングを実施」のように、何に使ったかまで書きます。

書類が通らないときの見直し順序

10件応募して0件通過という状態が続いたら、次の順で疑います。順番が重要です。

第一に、応募先の選定。要件を満たしていない案件に出していないか。実務経験3年以上と書かれた案件に未経験で出し続けても、書類の質は関係ありません。ここが原因のケースが最も多く、しかも本人が最も気づきにくい。

第二に、職務要約。3行目までに、募集要項のキーワードが1つ以上入っているか。入っていなければ、まずそこを直します。

第三に、作業の分解。「ユーザビリティテスト業務」という塊のままになっていないか。工程名まで下ろせているか。

第四に、数字。セッション数、被験者数、対象サービス数、日数。1ページあたり5個以上の数字が入っていれば、密度としては足りています。

第五に、書式。フォント、余白、見出しの階層。乱れていれば、レポートの品質もその程度だと判断されます。この職種は成果物が文書なので、書類の見た目がそのまま職能の証明になります。

記録は必ず残してください。応募日、案件名、送った書類のバージョン、結果。20件も溜まれば、どのバージョンが通っているかが見えます。感覚で直すと、通っていた書き方を自分で壊します。

続かなくなる地点と、切り替えの判断

在宅の使い勝手テスト案件を続けようとして行き詰まる典型は、単発案件の連続で消耗するパターンです。1件60分のセッションでも、応募、日程調整、事前確認、実施、書き起こし、提出まで含めれば実働は3倍以上になります。時間単価で計算すると想定より低く、そこで意欲が落ちる。

切り替えの判断基準を数字で持っておきます。3か月続けて、応募20件に対して受注が1件以下なら、応募先の層が合っていません。受注はできているのに時間単価が上がらないなら、工程を上流に移すか、隣接領域へ広げます。

隣接領域として現実的なのは、テスト報告書の作成代行、マニュアルやヘルプの制作、カスタマーサポートの改善提案、品質管理の記録業務です。文書を書く力が資産になる方向で、単価水準は著述家，記者，編集者の年収・単価相場が目安になります。技術側に寄せるならソフトウェア作成者の年収・単価相場が基準です。専門分野を持つと単価が安定する傾向があり、たとえば法務領域の在宅化がどこまで進んでいるかは法律事務所のパラリーガルの働き方｜在宅・時短勤務の現状【2026年版】が参考になります。

AI関連の検証案件は、この2年で明確に増えている領域です。生成AIを組み込んだ機能の使い勝手を評価する案件では、AIの出力が期待と食い違ったときにユーザーがどう振る舞うかが検証対象になります。企業側がAI導入で何につまずいているかはAIコンサル・業務活用支援のお仕事に整理されており、テスト対象の背景理解に使えます。マーケティングやセキュリティを含めた広がりはAI・マーケティング・セキュリティのお仕事で確認できます。

提出の形式で損をしないために

内容が整っていても、提出の作法で落ちることがあります。地味ですが、確実に差が出る部分なので押さえておきます。

ファイル形式とファイル名

原則としてPDFで提出します。Word形式で送ると、相手の環境によってレイアウトが崩れ、表が分断されたり、見出しの階層が潰れたりします。せっかく整えた書式が読み手の画面で崩れているという事態は、こちらからは確認できません。PDFにすれば、少なくとも見た目は固定されます。

ファイル名は「職務経歴書_氏名_年月日」の形式に統一します。応募先の担当者は複数の応募書類をフォルダにまとめて保存しているため、「shokumu.pdf」「職務経歴書（最新）.pdf」といった名前で送られてくると、開くまで誰のものか分かりません。名前で判別できる状態にしておくのは、細かいようで実務的な配慮です。こういう配慮ができる人だという情報は、それ自体が業務適性の証拠になります。

ファイルサイズにも注意します。スクリーンショットを大量に貼り込んで10メガバイトを超えると、メールの添付制限に引っかかることがあります。画像を入れる場合は解像度を落とし、全体で3メガバイト以内に収めるのが無難です。

応募フォームの自由記述欄への貼り付け方

求人サイトやマッチングサービスの応募フォームには、自由記述欄が用意されていることがあります。ここに職務経歴書の全文を貼り付ける人がいますが、これはやめたほうがいい。改行やインデントが失われ、文字の壁になって読まれません。

自由記述欄に書くのは、職務要約に相当する3行から5行と、募集要項に対する対応関係だけです。「貴社が求める要件のうち、リモートテストのモデレーション経験は3年、レポート作成は60本以上の実績があります。テスト設計は指示書に基づく実施経験のみで、ゼロからの設計は未経験です」という書き方です。できることとできないことを両方書くと、読み手は判断が早く済みます。

詳細は添付ファイルに逃がす。この役割分担ができていれば、フォームの文字数制限に悩む必要もなくなります。

面談で必ず聞かれることに、書類で先回りする

書類が通った後の面談で、在宅の使い勝手テスト案件では決まって同じことを聞かれます。それを書類の段階で潰しておくと、書類選考の通過率そのものが上がります。読み手は面談で確認する手間を減らせるからです。

稼働時間をどれだけ確保できるか

これが最も多い質問です。在宅の案件では、稼働の予測可能性が発注側の最大の関心事になります。テストのセッションは被験者との日程調整が絡むため、「いつなら確実に空いているか」が分からない相手には振りにくい。

書き方としては、曜日と時間帯を具体的に固定します。「平日の10時から15時は確実に対応可能。16時以降と土日は事前調整により対応可」といった粒度です。「柔軟に対応します」は情報量がゼロなので書きません。むしろ、対応できない時間帯を明記したほうが信用されます。

月あたりの稼働上限も書いておきます。「月40時間程度まで」と書いてあれば、発注側は自分たちの案件規模と照らして判断できます。上限を書かないと、想定より大きい案件を打診されて断ることになり、その一往復が無駄になります。

トラブル時にどう動くか

リモートのテストでは、機材や通信のトラブルが一定確率で発生します。被験者側の接続が切れる、録画が止まっている、音声が入っていない。こうしたときにどう対処したかを1行でも書いておくと、実務経験の裏付けとして強く働きます。

「セッション中に被験者側の回線が不安定になった際、録画を継続したまま電話に切り替えて画面共有のみ再接続し、中断時間を4分に収めた」という記述は、経験がなければ書けません。逆に言えば、この種のエピソードが1つも書けない書類は、実務を経ていないと判断されます。

未経験の場合は、代わりに準備の手順を書きます。「事前に接続確認を1回実施し、予備の通信手段を用意する運用を想定している」と書けば、リスクを理解していることは伝わります。

守秘義務の扱いをどう考えているか

使い勝手テストでは、リリース前の画面や未公開の機能に触れることが日常的にあります。したがって、秘密保持契約の締結が前提となる案件がほとんどです。

書類には、締結経験の有無を明記します。「NDA締結のうえで未公開機能の検証に従事した経験あり」という1行があるだけで、扱いに慣れていることが伝わります。あわせて、録画データの保管と削除の運用についても触れておくと丁寧です。「録画データは指定のクラウド領域にのみ保存し、ローカル環境からは納品確認後に削除する運用を徹底」といった記述です。

なお、この種の契約書に記名する前には、成果物の権利帰属と、契約終了後の秘密保持期間を必ず確認してください。期間の定めがない条項が入っていることがあります。※契約条件に不明点がある場合は、署名前に専門家へ相談することを検討してください。

経歴が細切れになっている場合の組み立て方

在宅で単発案件を積み上げてきた人は、経歴が短期の集合体になります。これをそのまま時系列で並べると、定着しない人に見えるという問題があります。

案件をまとめて「領域」で括る

1件2週間の案件が15件並んでいる状態は、読み手にとって処理しづらい。これを「EC系サービスの検証（2024年から2025年、7案件、累計30セッション）」のように領域で括ると、経験の厚みとして読めるようになります。

括ったうえで、その領域の中から代表的な1件か2件だけを詳細に展開します。全部を同じ粒度で書くと、どれが重要なのか分からなくなる。これは編集の基本と同じで、強弱をつけないと読まれません。

空白期間の扱い

半年以上の空白がある場合、理由に触れないと、読み手が勝手に最悪の想定をします。ただし長々と説明する必要はなく、1行で足ります。「家族の介護のため稼働を停止（現在は解消）」「体調回復のため休養（現在は通常稼働可）」といった書き方です。

重要なのは、現在の状態を明記することです。空白の理由だけ書いて現状に触れないと、「今も同じ状況なのか」という確認のために面談が必要になり、その手間を避けるために見送られます。

実績が浅い時期の見せ方

経験1年未満の段階では、案件数で勝負できません。この時期は、学習と自主的な取り組みの記録で埋めます。読んだ書籍、受講した講座、自主的に作成したテストレポートの本数。3行程度で構いません。

私が編集の仕事に移った直後、実務経験がほとんどない状態で書類を出し続けていた時期があります。結局そこで効いたのは経歴欄ではなく、自分で作った分析資料でした。書類の空白を文章で埋めようとするより、埋められる成果物を作るほうが早い。これはどの職種でも変わらないという特徴があります。

市場を長く見てきた立場からの観察

20年この市場を運営してきた立場から言えば、書類で選ばれ続ける人と、毎回ゼロから応募し直す人の差は、書類の巧拙よりも関係の残し方にあります。

長く続く人は、1件目の納品時に、成果物とは別に一言添えています。「今回の手順書で、タスク3の指示が二通りに読めました」といった、依頼側の運用そのものに対する指摘です。これをやる人は、次の募集で真っ先に声がかかります。使い勝手テストは対象サービスだけでなく、テストの運用自体にも改善余地があるからです。書類は入口に過ぎず、二回目以降は書類を見られません。

もう一点。運営者として見てきた限りでは、中間の手数料が乗らない直接の取引形態では、同じ予算でも依頼側はより多くの回数を頼めますし、受け手に残る額は厚くなります。手数料0%という条件の意味は、単価表の数字ではなく「同じ仕事をして手元に残る額が違う」という質の差です。単発を積み上げて生活を組む人ほど、この差は効いてきます。年間で50件受注するなら、1件あたりの差が小さくても結果は変わります。

そして、書類が通らない時期が続くと、応募そのものをやめてしまう人が一定数います。収入より先に気力が尽きる構造で、在宅は特にこれが起きやすい。対処の具体策は在宅ワーカーのメンタルヘルスケア｜孤独・燃え尽きを防ぐ5つの習慣【2026年版】にまとまっています。書類を直す前に、まず記録を取って冷静に原因を切り分けるほうが早い。文書作成そのものを収入源に広げたい場合はビジネス文書検定で文書作成の副業力アップ｜在宅ライティング案件に、資格を案件へ接続する流れが書かれています。

職務経歴書は自己紹介文ではありません。相手の募集要項に対する回答書です。要件が読めていれば書くことは決まりますし、要件と自分が合っていなければ、書き方をいくら磨いても通りません。この切り分けができるかどうかが、応募を続けられるかどうかの分かれ目になります。

よくある質問

Q. 使い勝手テストの実務経験がなくても職務経歴書は書けますか？

書けます。前職の経験を工程に翻訳するのが基本です。事務職なら手順書の遵守と例外報告、接客なら顧客の詰まりの観察、カスタマーサポートなら問い合わせの分類と原因報告が、そのままテスト業務の要素に対応します。加えて、公開サービスを自分でテストしたレポートを3ページ程度作り、提出可能な成果物として添えると説得力が上がります。

Q. 職務経歴書は何ページにまとめるべきですか？

業務委託の応募なら2ページが上限と考えてください。案件数が多い場合は、応募先に関連する案件だけを詳細に書き、それ以外は一覧表に落として圧縮します。分量を増やすより、職務要約の3行に募集要項のキーワードを入れるほうが通過率に効きます。読み手が判断にかける時間は数十秒です。

Q. クライアント名やサービス名は書いてよいですか？

契約に守秘義務がある場合、無断で記載すると違反になる可能性があります。「大手アパレルEC（社名非公開）」「従業員1000名以上の製造業向け業務システム」といった業種と規模で置き換えるのが安全です。守秘義務を守った書き方をしている書類は、それ自体が信用材料として評価されます。

Q. 在宅であることはどう書けばよいですか？

希望ではなく実績として書きます。「在宅を希望します」ではなく「全工程を在宅で完結した実績が3案件」という書き方です。あわせて回線種別、PCとスマートフォンの機種、静かに録画できる時間帯を明記します。特に2世代から3世代前の検証端末を持っていることは、実ユーザー環境の再現という観点で加点されやすい要素です。