持ち帰り課題とは？エンジニア転職の対策と、課題の分量から企業を見極める方法

課題ページの一番上に書かれた「想定時間：4〜6時間」という一文を、提出直前にもう一度見返したエンジニアがいます。手元のタイマーはすでに18時間を超えていました。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、コーディングテストの中でも持ち帰り課題（テイクホーム課題）は、企業ごとの分量のばらつきが最も大きい形式です。対策の仕方以前に「この課題にどこまで時間をかけるべきか」で迷う相談が後を絶ちません。今回は、持ち帰り課題を出された時にまず確認すべきこと、限られた時間で評価を落とさない進め方、そして課題の分量そのものから企業の開発体制を読み取る視点まで、実例を交えてお伝えします。

目次

1. エンジニア転職の持ち帰り課題対策、まず整理しておきたい位置づけ
2. ライブコーディング・オンラインジャッジとの違い、評価軸はどこにあるか
3. 「何時間が目安か」に一般解はない、それでも判断する基準
4. 良い持ち帰り課題に共通する設計、Hollowayが指摘する条件
5. 分量から読み取る、開発体制のリアル
6. 限られた時間で評価を落とさない進め方
7. 面接官は提出物のどこを見ているか
8. 質問していい範囲、聞くこと自体を減点材料にされないか
9. 持ち帰り課題の有無・分量は、選考前に確認できるか
10. 提出後に音信不通、フィードバックがないときの受け止め方
11. 持ち帰り課題は辞退していいのか、判断基準
12. 成果物が実務に使われてしまわないか、無償労働の線引き
13. よくある質問
14. まとめ、持ち帰り課題は「対策」より先に「見立て」が要る

エンジニア転職の持ち帰り課題対策、まず整理しておきたい位置づけ

持ち帰り課題は、書類選考を通過した後、一次面接の前後に挟まれることが多い形式です。候補者が自分のペースで自宅からコードを書いて提出するため、面接官の目の前で手が止まっても評価されない分、業務に近い完成度まで求められやすいという特徴があります。

企業側がこの形式を選ぶ理由も、対策の的を絞るうえで知っておく価値があります。面接の日程調整が要らず候補者もリラックスして取り組めるという運用上の利点に加え、要件を整理して手を動かす一連の流れを、限られた面接時間だけでは測りにくいという狙いがあります。裏を返せば、企業が見たいのは「解けるか」ではなく「どう進めるか」です。

ライブコーディングやオンラインジャッジ形式の対策については以前の記事で詳しく扱いましたが、持ち帰り課題はそれらとは評価の重心がはっきり違います。制限時間内に解き切る瞬発力ではなく、設計判断を後から検証できる状態で残せているかが見られる形式だからです。

面接官の前で書くわけではないので緊張はしにくい一方、「どこまで作り込めば十分か」という終わりの見えなさが、持ち帰り課題特有のストレスになります。相談を受けていても、時間切れで焦った、というより、際限なく手を入れ続けて疲弊した、という声のほうが目立ちます。

ライブコーディング・オンラインジャッジとの違い、評価軸はどこにあるか

同じ「コーディングテスト」という括りでも、形式によって見られている点はまったく違います。表にすると次のようになります。

この違いを知らずに、オンラインジャッジの感覚で持ち帰り課題に臨むと、動くコードだけ提出して終わってしまいがちです。持ち帰り課題では、なぜその設計にしたかを説明できる材料まで含めて提出物として見られています。逆に言えば、機能を全部作り切れなくても、判断の理由が書かれていれば評価はそこまで落ちません。

「何時間が目安か」に一般解はない、それでも判断する基準

「持ち帰り課題は何時間が目安ですか」という質問をよく受けますが、業界横断の相場を裏付ける調査は見当たらず、私自身も一般化した数字で答えることはしていません。ただ、企業側が公開している時間設計の実例はいくつかあり、参考にはなります。

メルカリグループが公開している中途エンジニア採用の選考ガイドでは、コーディングテストは75分（アルゴリズム基礎の実施は1時間程度）、機械学習職の選考課題は4〜5時間程度で提出できる想定で作成されており時間制限なし、システム設計面接は1時間という設計が明記されています（メルカリ「guide_software_engineer.md」）。企業側がここまで具体的に想定時間を設計・開示しているのは、選考課題としてはむしろ丁寧な部類です。

海外の技術採用の実務書であるHollowayのガイドでも、持ち帰り課題の設計について踏み込んだ指摘があります。タイムボックス（制限時間）を設けない課題は、2時間しか投入しない候補者と40時間投入する候補者の間で提出物の差が開いてしまい、公平な比較にならないと述べられています（Holloway「Take-homes」）。

この2つの一次情報から言えることは、「良い持ち帰り課題は、想定時間を明示し、その時間内で終わる分量に設計されている」という点です。想定時間の記載がなく、かつ完成度をどこまで求めているのかも書かれていない課題は、企業側の設計そのものが甘い可能性を疑ってよいと私は考えています。

良い持ち帰り課題に共通する設計、Hollowayが指摘する条件

Hollowayのガイドでは、時間の設計だけでなく評価基準の明示も欠かせない要素として挙げられています。コードの正確さを見たいのか、設計の創造性を見たいのか、実装の速さを見たいのか。企業側が何を評価軸に置いているかを、あらかじめ課題の中で伝えるべきだという指摘です。

実際にはこの基準が書かれていない課題の方が多いというのが、私の実感です。評価軸が分からないまま提出物の完成度を際限なく上げようとして時間を溶かしてしまう人を、何人も見てきました。基準が書かれていない場合は、候補者側から評価軸を確認してよい場面だと考えています。「今回の課題では、実装の網羅性と設計判断の説明、どちらをより重視されますか」と聞くことは、的外れな箇所に時間を使わないための情報収集であり、評価を下げる質問ではありません。

もう一つHollowayが挙げているのが、候補者の経済的事情への配慮です。長時間の課題は、生活のために可処分時間が限られている候補者ほど不利に働き、選考としての公平性を損ないます。想定時間が明記され、かつその時間内に無理なく収まる分量になっているかどうかは、企業が候補者の事情にどれだけ配慮しているかを映す指標でもあります。

分量から読み取る、開発体制のリアル

ここからは実際にあった例です。26歳、経験3年のバックエンドエンジニアのNさんは、独立系SIerで小売業向けPOSシステムの保守を担当しながら、自社開発のフィンテック系企業に応募していました。書類選考を通過した後に届いた課題は、在庫管理APIの実装で、ページの冒頭には「想定時間：4〜6時間」とだけ書かれていました。

ところが要件を読み進めると、在庫の増減API、履歴の検索API、単体テスト一式、エラーハンドリングの網羅、さらに「本番運用を想定した設計判断をREADMEにまとめること」まで求められていました。Nさんが実際に手を動かしてみると、テストとREADMEまで含めて18時間近くかかり、想定時間の3倍以上に膨らんでいました。

私がこれまで見てきた中で、常識外れに重い持ち帰り課題を出す企業には共通するパターンがあります。課題の作成者が現場のエンジニアだけで、採用部門や人事がその分量を見積もり直していないケースです。現場の感覚では「このくらい普通」でも、候補者の可処分時間で見ると業務水準の丸ごとの成果物を無償で求めていることに、作った本人が気づいていません。

これは選考の話にとどまらず、入社後のレビュー体制の話でもあります。課題の分量を誰も見積もり直さないまま候補者に渡してしまう組織は、実際の開発でも見積もりの精度を上げる仕組みが弱く、評価基準が担当者の主観に寄りやすい傾向があると、私は現場で見てきた実感として捉えています。分量は、その会社の体制を映す簡易的な指標として使えます。

同じ時期に別の候補者が受けた、決済系スタートアップの持ち帰り課題は対照的でした。要件は最小限のAPI一本に絞られ、ページの末尾には「評価では機能の網羅性より設計判断の説明を重視します。時間が足りない場合は、その旨をREADMEに一言書いてください」と明記されていました。同じ持ち帰り課題という形式でも、設計の丁寧さでここまで差が出ます。

限られた時間で評価を落とさない進め方

Nさんはこの時、全部を作り切ろうとして深夜まで手を止めませんでした。ただ、途中で私に連絡をもらい、進め方を一度組み替えています。持ち帰り課題は、時間をかけた量ではなく、時間内で何を選び何を捨てたかの説明が評価される形式だからです。

Nさんは要件のうち在庫の増減APIとその単体テストに絞り、履歴検索APIは「時間内では設計方針のみ」としてREADMEに書き、エラーハンドリングは主要な異常系のみに留めました。提出時のREADMEには「想定時間4〜6時間に対し、テストとドキュメント込みで約6時間半で区切りました。優先順位は次の理由で決めました」という一文を添えています。

ポイント： 持ち帰り課題は「全部終わらせる」ことが評価対象ではありません。何を優先し、何を後回しにしたかを言葉にできているかどうかが、完成度そのものより重視されます。

コミットの粒度にもひと工夫しています。「在庫増減APIの実装」「単体テストの追加」「READMEに優先順位の説明を追記」という3つのコミットに分け、それぞれのメッセージに一言ずつ理由を添えました。実装の順番と判断の理由が、コミットログを見るだけで再現できる状態です。

一次面接では、実装しなかった範囲について面接官から質問が飛びましたが、Nさんは「時間内では設計方針の説明に留めた理由」をその場で答え、結果として内定を得ています。分量が多い課題ほど、この「区切り方の説明」が効いてきます。

面接官は提出物のどこを見ているか

持ち帰り課題を評価する面接官の視点も知っておくと、時間の使い方が変わります。採用担当者から聞く限り、真っ先に見られているのはREADMEで、次にコミット履歴、最後にコードの中身という順番になっていることが多いです。

READMEだけで設計判断のおおよそが伝われば、コードは細部まで読まれなくても好意的に評価されます。逆にコードが動いていてもREADMEが空欄のままだと、面接官は「なぜこの設計にしたのか」を推測するところから読み始めなければならず、心証としては不利に働きます。

コミット履歴についても、提出直前に一括コミットされた課題より、機能ごとに分けてコミットされた課題の方が、進め方の筋道が伝わりやすく評価されやすい傾向があります。作業の過程をそのまま残しておく方が、慌てて一つにまとめるより結果的に得策です。

テストコードの有無も評価に直結します。要件を全部実装できなくても、実装した範囲に対して最低限のテストが書かれていれば、動作確認の意識がある候補者として見られます。逆に全機能を実装していてもテストが一つもない提出物は、業務での品質意識を疑われる材料になり得ます。

質問していい範囲、聞くこと自体を減点材料にされないか

課題の要件に曖昧な点があった時、質問していいのか迷う人は多いですが、これは基本的に質問して問題ありません。曖昧な仕様を確認せずに自己流の解釈で作り込んでしまう方が、実務では危険な進め方だからです。

ただし聞き方には差が出ます。「仕様を教えてください」という丸投げの質問ではなく、「〇〇という解釈で進めようと思いますが、この認識で合っていますか」という、自分の仮説をセットにした質問にすると、評価側には前向きな確認として伝わります。質問を送った後の返信を待たずに手を止めてしまう人もいますが、期限が迫っている場合は自分の仮説を明記した上で進めておき、後から答えが変わればその部分だけ直す、という進め方が現実的です。

持ち帰り課題の有無・分量は、選考前に確認できるか

持ち帰り課題が選考に含まれるかどうかは、求人票だけでは分からないことがほとんどです。エージェント経由で応募する場合は、選考フローを確認してもらう段階で「コーディングテストの形式」を尋ねておくと、事前に心づもりができます。

直接応募の場合も、カジュアル面談や一次面接の場で「選考の中でコーディングテストはありますか。ある場合はどのような形式でしょうか」と尋ねて問題ありません。志望度を疑われる質問ではなく、準備の仕方を具体的に考えている印象につながります。

分量についても、面談の場で「過去の候補者は平均してどのくらいの時間をかけて提出されていますか」と聞いてみる価値があります。この質問に具体的な数字で答えられる企業は、課題の分量を継続的に見直している可能性が高く、答えに詰まる企業は出しっぱなしで検証していない可能性があります。

提出後に音信不通、フィードバックがないときの受け止め方

課題を提出した後、何週間も連絡が来ない、という相談も多く受けます。ここで知っておくといいのは、持ち帰り課題という形式自体が、企業側にとっても手間のかかる選考であるという事実です。

Hollowayのガイドでは、Dropboxの採用担当者の話として、持ち帰り課題を提出しても次の選考に進める候補者の割合（パススルー率）はおおむね10%程度にとどまっていたと紹介されています。候補者の2割ほどはそもそも提出まで到達せず離脱していたともあり、企業側が課題の作成・評価にかける労力に対して、選考として得られる歩留まりは高くありません。

だからこそ持ち帰り課題は選考の早い段階のスクリーニングには向かず、選考フローの後段に配置すべきだとガイドは述べています。この事情を踏まえると、企業側の評価プロセスが選考体験を優先するほど整っていない場合、提出された課題への反応が遅れること自体は珍しくありません。

とはいえ、2週間を超えても一切の連絡がない場合は、待つより動いた方がいい段階です。エージェント経由の応募であれば担当者経由で状況を確認できますし、直接応募の場合も「提出後のフィードバックの目安時期を伺えますか」と一度だけ問い合わせるのは失礼にあたりません。返信の速さそのものが、入社後の連絡の取りやすさを映す先行指標になることもあります。

持ち帰り課題は辞退していいのか、判断基準

分量を見た時点で「これは無理だ」と感じたら、辞退するという選択肢もあります。ただし辞退の判断は、分量の多さだけでなく次の2点を合わせて見ることを勧めています。

想定時間が明記されているか、そして明記された時間と実際の要件量が明らかに矛盾していないか。想定時間の記載がなく、要件だけが本番の機能一式レベルまで積み上がっている課題は、選考としての設計そのものに疑問符がつきます。一方で、時間の記載があり、要件も無理のない範囲に収まっている課題であれば、多少骨があっても受けてみる価値はあります。

現職の業務量との兼ね合いも判断材料です。平日の夜と週末をまるごと差し出さないと終わらない分量が続く企業は、入社後の働き方も同じ発想で設計されている可能性があります。私が担当した候補者の中にも、課題の分量を理由に選考の途中で辞退し、後になって「あのまま入っていたら苦しかったと思う」と振り返った人が複数います。

分量以外にも、辞退を検討していい兆候があります。想定時間を尋ねても曖昧にしか答えられない、評価基準を聞いても回答が返ってこない、といった反応は、選考を通じて見えてくる社内のコミュニケーションの粗さでもあります。持ち帰り課題は、成果物だけでなく課題を巡るやり取りそのものが、小さな体験版の職場環境だと捉えると判断しやすくなります。

成果物が実務に使われてしまわないか、無償労働の線引き

持ち帰り課題で作ったコードが、そのまま企業の実務に流用されるのではないか、という不安もよく聞きます。この懸念自体は正当なもので、課題の要件が自社サービスの機能そのものと酷似している場合は、特に注意が必要です。

現実的な対処として、著作権や利用範囲について選考ページやメールに明記がない場合は、提出前に「本課題の成果物の著作権・利用範囲について教えてください」と確認しておくことを勧めています。良心的な企業であれば、この質問自体を嫌がることはありません。むしろ何も規定していない企業の方が、選考課題の設計を軽く扱っている可能性があります。

よくある質問

持ち帰り課題の提出後、追加の質問メールを送ってもいいですか。 提出前の質問と違い、提出後の問い合わせは基本的に控えた方が無難です。ただし提出物の一部にアクセス制限がかかっていて動作確認ができない、といった技術的な不備の連絡は例外で、早めに伝えて構いません。

複数社から同時に持ち帰り課題が来た場合、優先順位はどうつければいいですか。 想定時間が明記されている課題を先に着手し、明記のない課題は後回しにするという順番を勧めています。時間の見通しが立つ課題から片付けた方が、全体の負荷を自分でコントロールしやすくなります。

課題の分量が明らかに多いと感じた時点で、面接官に直接伝えてもいいですか。 伝えて構いません。「想定時間内には収まらなかったため、優先順位をつけて提出しました」と提出物に添えるのが最も自然で、面接の場で改めて口頭説明するより先に、README上で伝えておく方が誤解を招きにくくなります。

まとめ、持ち帰り課題は「対策」より先に「見立て」が要る

持ち帰り課題の対策と聞くと、実装力を鍛える話だと思われがちですが、私が現場で見てきた限り、明暗を分けているのは実装力そのものより、限られた時間の中で何を優先したかを言語化できるかという一点です。分量が多い課題ほど、この言語化の差がそのまま評価の差になります。

同時に、課題の分量そのものが、応募先の開発体制を映す手がかりになるという視点も持っておいてほしいと思います。時間設計を丁寧にしている企業もあれば、現場の感覚だけで無限に膨らんだ要件を渡してくる企業もあります。対策を練る前に、まず目の前の課題がどちらのタイプかを見立てること。それが、持ち帰り課題で消耗しないための一番の近道だというのが、この記事で一番伝えたかったことです。