ITエンジニアの技術課題（宿題）対策ガイド

Webエンジニアの選考では、ライブコーディングや設計面接に加え、数日〜1週間程度の持ち帰り技術課題が課されることがあります。このページはその宿題課題に限定し、面接官との会話術や選考全体の流れは面接対策の領域と切り分けます。課題への取り組み方、提出物の形式、現職・個人プロジェクトのコード持ち込み可否、READMEに書くべき範囲を中心に整理します。合格率や内定の保証は一切しません。

持ち帰り課題

選考過程で自宅等で実装し、リポジトリまたはアーカイブで提出する形式の技術試験。

スコープ確認

必須機能と任意機能、評価対象外の範囲を採用側と事前にすり合わせること。

機密境界

現職のコード、顧客名、未公開APIを課題に持ち込まない線引き。

提出README

設計判断、トレードオフ、未実装理由、実行手順を書く文書。履歴書とは別用途。

技術課題・設計面接・ライブコーディングは、それぞれ評価したい能力が異なります。宿題は設計の深掘りや実装の完成度を見る場合が多く、当日のコーディング力だけを測るライブ形式とは目的がずれます。

技術課題の役割比較では、「観点」は「対象」、「技術課題（このページ）」は「宿題形式の実装・設計」、「面接準備全般」は「面接種別全体の準備」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の役割比較では、「観点」は「期間」、「技術課題（このページ）」は「数日〜1週間」、「面接準備全般」は「選考期間全体」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の役割比較では、「観点」は「評価焦点」、「技術課題（このページ）」は「完成度・README・設計」、「面接準備全般」は「コミュニケーション・当日対応」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の役割比較では、「観点」は「リスク」、「技術課題（このページ）」は「機密持ち込み・過剰実装」、「面接準備全般」は「想定外質問・緊張」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の役割比較では、「観点」は「関連記事」、「技術課題（このページ）」は「システム設計面接の進め方（Webエンジニア向け）等」、「面接準備全般」は「面接対策」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

課題文面に書かれていないことが多いのが、工数の上限と、既存OSSの利用範囲です。求人票の職種名だけでは課題の難易度は分からないため、課題受領時点で確認質問を送る習慣をつけてください。

技術課題の求人票の読み替えでは、「書いてあること」は「必須機能一覧」、「確認したい実態」は「優先順位」、「面談での質問例」は「MustとNiceの境界はどこですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「提出形式」、「確認したい実態」は「Private repo可否」、「面談での質問例」は「レビュー後にrepoは削除されますか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「使用技術」、「確認したい実態」は「バージョン指定」、「面談での質問例」は「フレームワーク未指定時の推奨は」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「評価基準」、「確認したい実態」は「テストの要否」、「面談での質問例」は「カバレッジは見ますか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「工数目安」、「確認したい実態」は「上限時間」、「面談での質問例」は「8時間超える場合はどうすべきですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「公開可否」、「確認したい実態」は「ポートフォolio掲載」、「面談での質問例」は「会社名をREADMEに書いてよいですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

技術課題の求人票の読み替えでは、「書いてあること」は「知的財産」、「確認したい実態」は「成果物の帰属」、「面談での質問例」は「提出コードの二次利用は」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

• 課題のMust/Niceをメールで確認した
• 現職コードを参照していないことを自己確認した
• 提出リポジトリにSecretsが含まれていない
• READMEに実行手順と設計判断を書いた
• 期限24時間前に提出し、問い合わせ余地を残した

確認ポイントは「課題のMust/Niceをメールで確認した」です。技術課題の求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「現職コードを参照していないことを自己確認した」です。技術課題の求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「提出リポジトリにSecretsが含まれていない」です。技術課題の求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「READMEに実行手順と設計判断を書いた」です。技術課題の求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「期限24時間前に提出し、問い合わせ余地を残した」です。技術課題の求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

技術課題では、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   確認質問を送る

   工数上限、Private repo、テスト要否、公開可否を箇条書きで送付。返答を課題フォルダに保存します。

2. 02
   スコープを固定

   Mustだけを満たす最小構成を先に設計。Niceは時間が余った場合のみ。

3. 03
   機密チェック

   コピペ元、環境変数、ドメイン名、社内ライブラリが混ざっていないかgrepします。

4. 04
   READMEを先に骨組み

   設計理由、未実装、既知の制約を先に見出しだけ書き、実装と並行で埋めます。

技術課題そのものの公式制度はありませんが、労働条件や選考プロセスの説明責任は企業側にあります。個人情報や現職の機密を課題に含めないことは、IPAの情報セキュリティガイドの一般論とも整合します。

ITエンジニアの技術課題（宿題）対策ガイドの判断材料は、出典が公開されている情報に限ります。媒体ごとの求人数や平均年収は集計定義が違うため、求人票や公式サイトの最新情報で確認してください。内定や年収アップは保証できません。提示された労働条件は書面で確認し、口頭の話だけを契約内容にしないでください。

Geeklyやレバテックキャリアの担当者は、同社の過去課題例や提出形式の傾向を共有できる場合があります。ただし課題の答えを代行することは倫理上避け、範囲確認のアドバイスに留めます。

• Geekly

  Web系の課題傾向に詳しい担当者が、確認質問の例文を共有してくれる場合があります。

• レバテックキャリア

  エンジニア経験者向け。課題と年収提示のタイミング関係も相談可。

• 明光キャリア

  課題の工数感と転職タイミングの両面から、無理のないスケジュール調整を支援。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• Niceまで完璧にしようとする

  工数上限を超えると、逆に優先順位の判断力を疑われることがあります。Must完了を最優先に。

• 現職コードを流用

  著作権・NDA違反のリスク。ゼロから書くか、自前OSSのみ参照。

• READMEを空で提出

  動いても判断理由が伝わりません。トレードオフと未実装理由は必須級です。

課題期限が1週間の場合の、確認→設計→実装→README→提出の配分例です。期限前日に初めて動き出すと、機密確認やテストが抜け落ちやすくなります。

1. 01
   月：要件確認

   質問送信とMustの洗い出し。返答待ちの間に開発環境だけ整える。

2. 02
   火：設計と骨格

   ディレクトリ構成、API契約、テスト方針をREADMEに書く。

3. 03
   水〜木：Must実装

   動く最小版を優先。リファクタはMust完了後。

4. 04
   金：テストと提出

   Secretsスキャン、README仕上げ、Private repo共有またはZIP提出。

ITエンジニアの技術課題（宿題）対策ガイドの応募準備では、「知っている」「使った」で止めず、どの入力を受け、何を判断し、どの成果物を残し、障害時にどこまで対応したかを分けます。対象領域は技術課題・選考・ポートフォリオです。公開できない固有名詞や数値は一般化し、公式資料（厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事、IPA 情報セキュリティ関連ガイド、厚生労働省 労働条件に関する総合情報）で確認した定義と、自分の担当実績を混同しないでください。

1. 01
   公式定義を一つ選ぶ

   厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事、IPA 情報セキュリティ関連ガイド、厚生労働省 労働条件に関する総合情報を開き、技術課題・選考・ポートフォリオに関係する用語を一つ選びます。版や更新日が分かる場合はメモし、求人票独自の表現と分けます。

2. 02
   担当箇所を図にする

   入力、処理、出力、依存先を四角で描き、自分が変更・レビュー・運用した場所だけに印を付けます。触れていない箇所は実績に含めません。

3. 03
   失敗例を一つ添える

   正常系だけでなく、失敗の検知、切り分け、復旧、再発防止の順に一例を整理します。秘密情報と確認できない改善率は書きません。

4. 04
   求人ごとに質問へ変える

   必須条件と歓迎条件を分け、主担当・補助利用・学習予定のどれに当たるかを記録します。回答が曖昧な項目は応募理由の主軸にしません。

• ITエンジニアの技術課題（宿題）対策ガイドで自分が決めたことを一文で説明できる
• 技術課題・選考・ポートフォリオの利用経験と設計・運用経験を分けた
• 成果物、レビュー責任、障害時の担当を確認した
• 出典のない求人数、年収、改善率を書いていない
• 求人IDと応募経路を管理し、重複応募を防いだ