テスト課題は出来より返し方｜在宅ランディングページのコーディング

2026年1月27日

朝比奈蒼

この記事のポイント

✓ランディングページのコーディングのテスト課題を在宅で受けたのに落ちた
✓原因はコードの出来ではなく返し方です
✓発注側が見ている評価軸

ランディングページのコーディングの案件に応募したら、テスト課題を出された。在宅で作業して提出したのに、その後の連絡がない。あるいは、これから課題に取り組むところで不安がある。そういう方に、結論から書きます。テスト課題の合否を分けているのは、コードの出来ではなく返し方です。

正直なところ、これはかなり不本意な事実だと思います。夜中まで頑張って完璧なコードを書いた人が落ちて、実装が7割の人が通る。そういうことが実際に起きています。理由は単純で、発注側が課題で見ているのがコードの完成度ではないからです。

この記事では、発注側がテスト課題の何を見ているのか、提出時に何を添えれば評価が変わるのか、そして無償課題をどこで断るべきかまでを整理します。断る基準の話は特に重要です。テスト課題という名目で実務を無償で行わせるケースは、実際に存在します。

テスト課題で見られているのは完成度ではない

まず、この記事の核心から書きます。

在宅でのコーディング案件におけるテスト課題は、技能試験ではありません。試用です。つまり、この人と一緒に仕事をしたらどうなるかを、小さく試している。だから、評価軸は次の4つになります。

1つ目、期限を守るか。2つ目、不明点をどう扱うか。3つ目、自分の判断を説明できるか。4つ目、成果物の状態を自分で確認しているか。

コードの品質は、この4つに比べれば優先度が低いです。理由は、実務のコードは修正できるからです。修正すればいいコードと違って、期限を守らない性質や、質問しない性質は修正できません。だから前者を先に見ます。

ここを理解していないと、努力の方向が全部ずれます。実装を1%磨く時間があるなら、提出時のメールを書く時間に回したほうが、通過率は確実に上がります。

私も編集の現場でトライアル原稿を評価する側に回ったことがありますが、判断はほぼ同じ構造でした。原稿の巧拙より先に見ていたのは、指定した文字数を守っているか、指示のうち解釈が割れる部分をどう処理したか、そして提出メールに何が書いてあるかです。文章そのものは、一緒に仕事をすれば伸びる。伸びないのは、確認をしない性質のほうでした。

在宅コーディング案件でテスト課題が出される背景

なぜ課題が出されるのか。背景を知ると、対応の仕方が見えてきます。

在宅は着手後の軌道修正が難しい

オフィス勤務なら、最初の1週間は隣で様子を見ながら教えられます。在宅ではそれができません。発注してから「思っていたのと違った」と気づくと、そこまでの時間とコストが丸ごと損失になります。

だから、事前に小さく試したい。これがテスト課題の動機です。悪意ではなく、リスク管理です。

在宅前提の募集を見ると、業務範囲が明確に切られている案件ほど、事前確認が丁寧に設計されている傾向があります。

【完全在宅】対応マニュアル完備！≪業界経験・専門知識不要◎≫当社製品の運用保守をお願いできるスタッフ募集☆夜間業務を想定出典: mamaworks.jp

マニュアルを整備している企業は、業務を切り出す作業を既に済ませています。こういう案件のテスト課題は、範囲が明確で、評価基準も比較的はっきりしています。逆に、課題の内容が曖昧で「自由に作ってください」というだけの案件は、社内で業務が整理されていないサインでもあります。

課題の種類は3つに分かれる

出される課題は、おおむね次の3種類です。

第1に、模写課題。既存のLPや支給されたデザインカンプを、そのままコーディングする課題です。実装の正確さと、レスポンシブ対応の質を見ています。所要時間は3時間から8時間程度が一般的です。

第2に、部分実装課題。フォームだけ、ファーストビューだけ、といった一部分を作る課題です。所要時間は1時間から3時間程度で、こちらのほうが良心的な設計です。

第3に、改善提案課題。既存のLPを見て、改善点を挙げる課題です。実装よりも思考プロセスを見ています。これは実は最も差がつきやすく、通過率を上げやすい課題でもあります。

問題は第4の類型で、これは課題ではありません。実際のクライアント案件をそのまま「テスト課題」として無償でやらせるケースです。この見分け方は後述します。

提出物の出来より評価される4つのポイント

ここから具体的に、何をすれば評価が上がるかを書きます。

期限より早く出す

これが最も単純で、最も効きます。「1週間以内に提出してください」と言われたら、4日で出す。

早く出すことの効果は2つあります。第一に、実務での納期感覚が伝わります。第二に、他の応募者より先に評価されるので、印象が残ります。同じ品質なら、先に見たほうが記憶に残るのは避けられません。

ただし、期限を守れないことが分かった時点で連絡するのは、それ以上に重要です。「体調を崩したため、提出を2日遅らせていただけますか」と事前に連絡できる人は、無断で遅れる人より評価されます。実務でも、遅れそうなときに先に言える人が最も信頼されます。

判断した箇所を明記する

デザインカンプには、必ず解釈の余地がある箇所があります。ボタンのホバー時の挙動、テキストが長くなったときの折り返し、画像が用意されていない箇所の扱い。

多くの応募者は、ここを自分で判断して黙って実装します。そして、判断が発注側の想定と違っていると、実装ミスとして減点されます。

正解は、判断した箇所を明記することです。「カンプにホバー時の指定がなかったため、透過度を80%に落とす挙動で実装しました。指定があれば合わせます」と書く。これだけで、実務が分かっている人という評価に変わります。

なぜなら、実務では毎日この判断が発生するからです。いちいち全部確認していたら進まないので、判断して進めつつ報告する。この動きができるかどうかが、在宅で任せられるかどうかの分岐点です。

質問を事前にまとめて送る

課題を受け取ってすぐ、質問を送ってください。ただし、まとめて3つ程度に絞ります。

「対応ブラウザの下限バージョンをお教えください」「フォームの送信先は実装対象に含まれますか」「使用するフレームワークの指定はありますか」。この3つは、LPの課題でほぼ必ず論点になります。

質問を1つずつ小出しに送るのは避けてください。相手の時間を細切れに奪うことになります。まとめて送れるかどうかも、評価対象です。

そして、質問がゼロの提出物は、確認をしない人だと判断されるリスクがあります。要件が完璧に書かれた課題は存在しないので、質問がないということは読み込んでいないということだからです。

自己確認の結果を添える

提出時に、自分で確認した内容を書きます。

「確認環境: Chrome最新版、Safari最新版、iPhoneの実機。表示幅は375px、768px、1440pxで確認済みです。読み込み時間はモバイル回線想定で2.4秒でした。フォームのバリデーションは、未入力とメール形式不正の2パターンで動作を確認しています。」

この一文があるかないかで、評価はまったく変わります。理由は、実務で最も手間がかかるのが「確認していない成果物を確認する作業」だからです。自分で確認してから出す人は、発注側の手間を減らします。手間を減らす人が選ばれます。

逆に、確認していない成果物を出すと、その後の実務でも同じことをすると判断されます。実際、そうなります。

提出メールの書き方

課題そのものより、添えるメールが評価を決める。この話を具体的にします。

落ちるメール

「お世話になっております。課題を提出いたします。ご確認のほどよろしくお願いいたします。ファイルは添付しております。」

情報がゼロです。これでは、評価者は自分でコードを読み解くところから始めなければなりません。手間を増やしているので、印象が悪くなります。

通るメール

構成は4ブロックです。

第1に、実装した範囲。「指定いただいたセクション全6つを実装しました。フォームは送信先の指定がなかったため、フロント側のバリデーションまでを実装対象としています。」

第2に、判断した箇所。前述の通り、解釈が分かれた点を列挙します。2つから3つで十分です。

第3に、確認した内容。環境と数値を書きます。

第4に、今後の改善案。「実務でお任せいただく場合、画像の配信形式を見直すことでファーストビューの読み込みをさらに短縮できると考えています。」この一文を入れると、課題を課題としてではなく、実務の入口として扱っている姿勢が伝わります。

このメールは、書くのに20分もかかりません。それで評価が変わるなら、実装を磨くより効率がいい。ここが冒頭に書いた「出来より返し方」の意味です。

文書力そのものが見られている

在宅の仕事は、やり取りのほぼ全部が文章です。だから、提出メールの日本語そのものが評価対象になります。誤字、敬語の誤り、主語のない文、一文が長すぎる。これらは実務でのやり取りの品質を予測させます。

文書の基本を体系的に押さえるなら、ビジネス文書検定の出題範囲が役立ちます。報告、依頼、確認といった文書の型は、そのまま提出メールに使えます。文書作成の力を仕事に接続する方法については、ビジネス文書検定で文書作成の副業力アップ｜在宅ライティング案件に具体的な案件の形が整理されています。

無償のテスト課題をどこで断るか

ここは、正直に書きます。テスト課題という名目で、実務を無償でやらせるケースは実在します。

危険な課題の見分け方

次のいずれかに当てはまる場合、警戒してください。

第一に、実在する商材のLPを丸ごと作らせる課題。架空の商材ではなく、実際に販売されている商品のLPを作らせる場合、それは納品可能な成果物です。

第二に、所要時間が10時間を超える課題。試用の目的であれば、そこまでの時間は必要ありません。部分実装で十分に判断できます。

第三に、複数人に同じ課題を出し、良かったものだけを採用すると明言している場合。これは実質的にコンペです。コンペであれば、そう明示して報酬を設定すべきです。

第四に、成果物の権利について何も説明がない場合。課題の成果物を使用しないことが明示されていないなら、確認する必要があります。

断り方と交渉の仕方

危険だと感じたら、次のように聞いてください。

「課題の想定所要時間をお教えいただけますか。また、提出物の権利の取り扱いについて確認させてください。実案件に近い内容の場合は、有償のトライアルとしてご相談させていただければ幸いです。」

この確認は、失礼ではありません。むしろ、権利の扱いを確認できる人は実務が分かっていると評価されます。ここで態度を硬化させる発注元は、着手後も条件面で揉める可能性が高いので、早めに分かってよかったと考えるべきです。

なお、報酬が発生する取引においては、発注者が一定規模以上の事業者であれば、成果物の受領日から60日以内に報酬を支払う義務があります。取引の適正化に関する情報は公正取引委員会のサイトで確認できます。有償トライアルに切り替わった場合も、この考え方は同じです。

受けてよい課題の目安

逆に、次の条件を満たす課題は、積極的に受けて構いません。

架空の商材またはサンプルデザインを使っている。所要時間が5時間以内。評価の観点が事前に説明されている。成果物を実務で使用しない旨が明示されている。

こういう課題を出す企業は、社内で採用プロセスを整理できている企業です。着手後の進行も、たいてい整理されています。

課題の質を上げる実務的なポイント

返し方が重要とはいえ、実装の質が低くていいわけではありません。差がつきやすい箇所を挙げます。

表示速度は必ず測る

LPは広告の着地点なので、表示速度が成果に直結します。ここを意識しているかどうかは、実装を見ればすぐ分かります。

画像の書き出し形式、遅延読み込みの有無、フォントの読み込み方法、不要なライブラリの読み込み。この4点を押さえるだけで、モバイルでの読み込みが数秒単位で変わります。

そして重要なのが、測って数値で言えることです。「速くなるよう配慮しました」ではなく「モバイル回線想定で2.4秒です」と言えるかどうかです。

コードの読みやすさは評価される

自分だけが分かるコードは、実務では負債になります。クラス名の命名規則が統一されているか、コメントが必要な箇所に入っているか、インデントが揃っているか。

評価者は、そのコードを引き継ぐ立場で読みます。引き継ぎたくないコードは、そのまま不合格になります。

隣接領域の理解が差を生む

LPのコーディングだけで完結する仕事は、実は多くありません。フォームの裏側の処理、外部サービスとの連携、CMSへの組み込み。この周辺を理解していると、課題の提出時に書ける改善案の質が変わります。

開発案件の工程分担についてはアプリケーション開発のお仕事に整理されています。自分の担当範囲の前後に何があるかを把握しておくと、提案の説得力が増します。

表示速度やドメイン周りの問題は、コードだけでなくサーバーやネットワークに起因することが多いです。CCNA（シスコ技術者認定）の学習範囲には通信の基礎が含まれるので、原因の切り分けが速くなります。課題の提出時に「読み込みが遅い原因はサーバー側の設定にある可能性があります」と指摘できる人は、まず落ちません。

広告やメール施策との関係を理解しておくのも有効です。AI・マーケティング・セキュリティのお仕事には、Web施策の周辺職種がどう分業されているかがまとまっています。LPが誰から何を受け取り、次に何へつながるのかを知っていると、改善提案課題で圧倒的に有利になります。

近年は、実装工程にAIを組み込む前提の案件が増えています。

【完全在宅×生成AI構築】生成AI構築経験のある方、トップ層の知見をボット化するお手伝いをお願いします！出典: mamaworks.jp

この種の募集が増えている以上、課題の提出時に「生成AIを実装の下書きに使い、表示崩れの検証は手作業で行いました」と書くのは、隠すべきことではなく、むしろ品質管理の説明になります。導入設計側の仕事についてはAIコンサル・業務活用支援のお仕事に業務範囲が整理されています。

単価の目安を持っておく

課題に通った後、条件交渉が始まります。ここで根拠のない金額を言うと、以後の単価が固定されます。

開発系職種の報酬水準はソフトウェア作成者の年収・単価相場に公的統計ベースで整理されているので、自分の時間単価が市場のどこにあるかを確認できます。文章を書く仕事と組み合わせる場合は、著述家，記者，編集者の年収・単価相場も参照すると、兼業時の収入設計がしやすくなります。

落ちたときにどう受け止めるか

課題に落ちることは、当然あります。ここも実務的に書きます。

落ちた理由は教えてもらえない

ほとんどの場合、不合格の理由は開示されません。これは意地悪ではなく、理由を書く工数がないからです。応募が30件あれば、30件分の講評を書くのは現実的ではありません。

だから、自分で仮説を立てるしかありません。提出までにかかった日数、質問を送ったかどうか、判断箇所を明記したかどうか、確認結果を添えたかどうか。この4点を振り返って、次に変える点を1つ決めてください。

落ちた課題を作品として残す

課題の成果物を実績として公開してよいかは、必ず確認してください。使用しないと明示されている課題なら、内容を一部変更したうえでポートフォリオに載せられる場合があります。

ただし、支給されたデザインカンプの著作権はデザイナーまたは発注元にあるので、そのまま公開するのは避けてください。自分でデザインを作り直したうえで、実装部分だけを見せる形が安全です。

続けられる状態を保つ

課題に時間をかけて落ちるのは、精神的に堪えます。在宅だと、その落ち込みを共有する相手もいません。

消耗のパターンと対処法は在宅ワーカーのメンタルヘルスケア｜孤独・燃え尽きを防ぐ5つの習慣【2026年版】に整理されています。課題に取り組む時期は、結果ではなく行動を管理指標にするのが現実的です。専門職が在宅と時短をどう成立させているかは法律事務所のパラリーガルの働き方｜在宅・時短勤務の現状【2026年版】に実態がまとまっているので、働き方の設計として参考になります。

20年市場を見てきた運営者の視点

フリーランスと在宅ワークの市場を20年運営してきた立場から言えば、テスト課題で通る人には共通点があります。課題を「試験」ではなく「最初の仕事」として扱っていることです。

試験として扱う人は、満点を取ろうとします。だから実装を磨き、期限ぎりぎりまで粘り、メールには何も書かずに提出する。最初の仕事として扱う人は、相手の手間を減らそうとします。だから早めに出し、判断した箇所を書き、確認結果を添える。この差が、そのまま評価の差になります。

運営者として見てきた限りでは、長く残る人は課題の段階から相手の作業を想像しています。提出物を受け取った人が、次に何をするのか。ファイルを開いて、表示して、コードを読んで、社内で共有する。その一連の作業を楽にする形で渡す。これは技術ではなく、想像力の問題です。

もうひとつ、手取りの話をします。同じ収入を得るのに、中間マージンが乗る経路で件数を積むのと、マージンの乗らない直接取引で少ない件数を丁寧に回すのとでは、1件あたりに使える時間がまるで違います。手数料0%の直接取引が効いてくるのは、額面が増えるからというより、手取りが厚くなることで1件を丁寧にやれるようになるからです。丁寧にやれば継続が生まれ、継続が生まれれば課題を受ける回数そのものが減る。依頼する側から見ても、同じ予算でより多くを任せられます。この構造は、長く続いている方の稼働を見ると実際にそうなっています。

案件データから見えるテスト課題の位置づけ

在宅ワーク市場の案件分布を見ると、テスト課題を設ける案件は全体の一部です。単発のコーディング案件では、提案文とポートフォリオだけで決まることが多い。課題が出るのは、継続前提の案件か、業務範囲が広く社内の体制に組み込む必要がある案件です。

つまり、課題が出された時点で、その案件は長く続く可能性がある案件だということです。だからこそ、権利の扱いや所要時間の確認をきちんとする価値があります。ここを曖昧にしたまま始めた関係は、後の条件交渉でも曖昧なままになります。

《完全在宅》kintoneアドバイザーとして相談対応を中心に活躍！経験を活かして課題解決に貢献できる柔軟な働き方を実現◎ 出典: mamaworks.jp

この種の募集文に出てくる「経験を活かして」という表現が示しているのは、企業が求めているのが新品のスキルではなく、判断の履歴だということです。テスト課題で見られているのも、まさにそこです。何を作れるかではなく、どう判断して、どう伝えるか。

最後にもう一度書きます。実装を1%磨く時間があるなら、提出メールを書いてください。判断した箇所を3つ書き、確認した環境を書き、改善案を1つ添える。それだけで、同じコードでも評価は変わります。テスト課題は、技能ではなく仕事の仕方を見る場です。

課題に取り組む前後の実務的な段取り

評価軸が分かったところで、実際の進め方を時系列で整理します。ここを段取りとして固定してしまうと、案件ごとに迷わなくなります。

受け取った当日にやること

課題を受け取ったら、その日のうちに次の3つを済ませてください。

第一に、要件を箇条書きに書き出します。支給ファイルの一覧、実装対象の範囲、納期、提出形式、指定された技術。これを自分の言葉で書き直すと、抜けている情報が浮かび上がります。浮かび上がった穴が、そのまま質問の材料になります。

第二に、質問をまとめて送ります。前述の通り3つ程度に絞り、1通のメールにまとめます。ここで大事なのは、質問と一緒に自分の想定を書くことです。「対応ブラウザの下限をお教えください。指定がなければ、主要ブラウザの最新版と1つ前のバージョンを対象に実装します」と書けば、相手は返信しなくても進められます。返信の手間を減らす質問の書き方は、そのまま評価につながります。

第三に、作業のスケジュールを自分で切ります。いつ着手し、いつ提出するか。ここを決めずに始めると、期限ぎりぎりまで粘る癖が出ます。粘っても評価は上がりません。

作業中に記録しておくこと

作業しながら、次の2つをメモに残してください。

1つは、判断が分かれた箇所です。カンプに指定がなかった挙動、テキストが想定より長くなったときの処理、支給されていない画像の代替。気づいたその場でメモしないと、提出時に思い出せません。

もう1つは、実際にかかった時間です。工程ごとに測っておくと、条件交渉のときに根拠のある工数を提示できます。この記録は、その案件だけでなく、以後のすべての見積もりに効いてきます。実測データを持っている人と持っていない人では、単価の交渉力がまったく違います。

提出直前の最終確認

提出する前に、次の項目を確認してください。指定された表示幅すべてで崩れがないか。画像の代替テキストが入っているか。リンクが正しく動くか。フォームのバリデーションが動くか。読み込み時間を実測したか。不要なファイルやコメントアウトされた古いコードが残っていないか。

最後の項目は、意外と見落とされます。作業途中の残骸が入ったまま提出すると、それだけで雑な印象になります。実務でも同じことをすると判断されるので、必ず整理してから渡してください。

提出後に待つ期間の目安

提出から返信までは、1週間から2週間程度かかることが普通です。評価する側も本業の合間に見るので、すぐには返ってきません。

2週間経っても連絡がない場合、1度だけ確認の連絡を入れて構いません。「先日提出いたしました課題について、その後の進捗をご教示いただけますでしょうか」という短い文面で十分です。催促と受け取られることを心配する必要はありません。むしろ、期限管理ができる人だと伝わります。

ただし、確認は1度までにしてください。何度も送ると、実務でも過剰な連絡をする人だと判断されます。1度連絡して返信がなければ、その案件は縁がなかったと考えて次に進むほうが、時間の使い方として健全です。

複数社の課題を同時に抱えない

応募を並行して進めていると、課題が同時期に複数届くことがあります。これを全部受けると、どれも中途半端になります。

課題は1本ずつ、順番に処理してください。同時に2本抱えると、片方の判断をもう片方に流用してしまい、その案件に固有の配慮が抜けます。抜けた配慮は、評価者にはすぐ分かります。テンプレの提出物になるからです。

どうしても時期が重なる場合は、片方に事前に相談してください。「他案件の選考と重なっているため、提出を3日ほどいただけますでしょうか」と伝えるのは、まったく失礼ではありません。むしろ、状況を正直に共有できる人だと評価されます。黙って遅れるほうが、はるかに印象を損ねます。

そして、条件面で明らかに合わない案件の課題は、着手前に辞退して構いません。報酬レンジが自分の下限を大きく下回る、業務範囲が説明されない、権利の扱いが不明。こうした案件に時間を使うより、条件の合う1社に丁寧に向き合ったほうが、結果として早く仕事が決まります。数を打つ発想は、課題においては機能しません。