エンジニア採用のコーディング課題｜持ち帰り時間と評価基準を決める

エンジニア採用の技術課題は、候補者に長く作業してもらうほど見極め精度が上がる、という設計には向きません。僕なら、入社後に任せたい職務のうち、選考で確認すべき最小単位から逆算して、持ち帰り課題の所要時間に上限を設けます。評価基準は、提出物の完成度に加え、設計の意図、制約の扱い、テストや保守性への配慮を、採用要件と同じ言葉で採点できる状態にします。

迷いやすいのは、課題を難しくする方向です。実務に近づけようとすると、仕様は増え、例外も増え、候補者の生活時間に入り込みます。採用選考で確認する対象は、候補者が会社の課題をどこまで無償で解けるかではなく、求人職種の職務遂行に必要な適性と能力です。厚生労働省の公正な採用選考の基本でも、採用選考は応募者の基本的人権を尊重し、適性・能力に基づく基準で行うものと確認できます。

技術的に何を見るかが決まらなければ、抽象的な「実装力」を評価者ごとに違う基準で測ることになります。IPAのDX推進スキル標準（DSS-P）概要は、ソフトウェアエンジニアを「デジタル技術を活用した製品・サービスを提供するためのシステムやソフトウェアの設計・実装・運用を担う役割」と整理しています。採用課題も、この設計・実装・運用のどこを確認するのかを先に決めなければ、所要時間も評価基準も決まりません。

エンジニア採用の技術課題で見る範囲を絞る

持ち帰り課題は、面接で見えにくい実務能力を補うための選考手段です。職務と関係の薄いパズルや、社内固有の前提を大量に読ませる課題は、評価したい能力よりも余暇、学習環境、事前知識の差を見てしまいます。これは公正な選考の観点からも危うい設計です。

まず、募集ポジションの期待を三つに分けます。

• 入社直後から必要な能力
• 入社後に伸ばせる能力
• 今回の選考では見ない能力

この分類をしないまま課題を作ると、採用担当は候補者体験を気にし、EMは実装品質を気にし、CTOは将来の伸びしろを気にする、という別々のものさしになります。見る能力を絞るほど、採用後の業務と選考の問いは近づきます。候補者にも評価者にも説明できる状態になっているかが、課題の妥当性を左右します。

たとえばWebアプリケーション開発の職務なら、持ち帰り課題で見る範囲は「要件を読み、データ構造を選び、境界条件を扱い、変更しやすい形で実装する」程度までで十分なことがあります。運用設計やセキュリティ判断を重く見るポジションなら、実装量を減らし、設計メモやリスクの洗い出しを評価対象に含めます。UIの作り込みや業務ドメインの深い理解まで同時に求める設計は、選考というより小さな業務委託に近づいていきます。

持ち帰り課題の時間は上限から決める

所要時間は、候補者に「どれくらい使ってよいか」を伝える時間です。実際に早く終わる人も、調べながら進める人もいます。だからこそ、企業側が期待する作業の上限を明記し、その上限を超えない前提で評価できる課題にします。

時間設計では、次の順で決めます。

• 評価したい能力を一つから三つに絞る
• 各能力を確認する提出物を決める
• 評価に不要な実装、装飾、周辺設定を削る
• 課題文に想定作業時間と提出期限を明記する
• 評価では、時間をかけた作り込みを過剰に加点しない

ここで外せないのは、候補者が長時間かけた成果をそのまま高く評価しない姿勢です。上限を示しながら、実際には作り込み量で評価するなら、時間を守った候補者が不利になります。時間の上限は候補者への配慮であると同時に、評価者への制約でもあります。

所要時間を決める前に、社内の評価者が自分で課題を解くことも欠かせません。採用担当が文章の分かりにくさを確認し、EMが実装量を確認し、CTOまたは技術責任者が職務要件との対応を確認します。社内で試した時間をそのまま候補者に当てはめる必要はありませんが、少なくとも、課題が評価したい能力以上の作業を要求していないかは見えます。

評価基準は提出前に候補者へ開示する

評価基準は、社内の採点表である前に、候補者への約束です。何を見られるのか分からない課題では、候補者は不安を埋めるために作業範囲を広げます。設計メモを書けばよいのか、テストを優先すべきなのか、見た目まで整えるべきなのかが曖昧なほど、所要時間は膨らみます。

評価項目は、職務要件に対応する言葉で置きます。

• 要件理解: 課題の目的、制約、未確定部分を読み取れているか
• 設計判断: データ構造、責務分割、変更への備えに説明可能な理由があるか
• 実装品質: 読みやすく、必要な例外や境界条件を扱えているか
• 検証: テスト、動作確認、再現手順が提出物から追えるか
• コミュニケーション: READMEや補足説明が評価者の確認負荷を下げているか

この項目は汎用的ですが、すべてを同じ重みにする必要はありません。バックエンドの即戦力を採るなら設計判断と検証を厚くし、ジュニア寄りの採用なら要件理解と学習可能性を面接で補います。評価基準を開示すると、候補者は企業が何を職務上の能力と考えているかを理解できます。

点数化だけに寄せると、評価者は迷わないようで迷います。実装がきれいだが要件を一部落としている提出物と、要件は満たすが保守性に不安がある提出物をどう扱うのか。採点表には、合格ラインの文章も必要です。「すべて満点なら合格」よりも、「このポジションで入社後に任せる業務に照らして、必須項目を満たしているか」を明文化するほうが運用しやすくなります。

採用担当、EM、CTOの分担を決める

持ち帰り課題は、候補者連絡、課題文、採点、面接での深掘り、選考全体の整合までつながります。役割分担が曖昧だと、候補者には丁寧に見える一方で、社内では評価の責任が分散します。

採用担当は、候補者体験と運用の責任を持ちます。課題を出す目的、想定作業時間、提出期限、評価項目、提出後の流れを同じ粒度で伝えます。辞退や辞退理由、提出率、候補者からの質問も採用プロセスの改善材料として扱います。ただし、候補者の家庭状況や思想信条など、職務遂行に関係しない情報を拾いにいく設計は避けます。

EMは、課題の職務妥当性と評価の一貫性を持ちます。現場で本当に必要な能力に絞れているか、評価者間で判断が割れないか、面接で何を追加確認するかを決めます。提出物のレビューでは、好みの設計かどうかより、課題文で示した制約の中で妥当な判断ができているかを見ます。

CTOまたは技術責任者は、採用基準と事業・組織の方向性の接続を見ます。今の開発チームに足りない能力、これから増える技術負債、プロダクトの運用責任に照らして、課題が古い成功パターンの確認になっていないかを点検します。課題の難度を上げるより、選考全体で何を見て何を見ないかを決める役割です。

現場エンジニアを評価者に入れる場合は、レビュー負荷も設計に含めます。評価者が疲弊すると、採点は雑になります。評価コメントのテンプレートを用意し、合否理由が候補者の適性・能力に結びつく表現になっているかを確認します。

課題文には制約と採点しない範囲を書く

良い課題文は、候補者を迷わせません。実務に近い曖昧さを残す場合でも、曖昧さそのものを評価するのか、質問してよいのか、仮定を置いて進めてよいのかを明記します。

課題文に入れる要素は、次の程度で足ります。

• 課題の目的
• 想定する職務との関係
• 想定作業時間
• 提出物
• 使用してよい技術や制約
• 評価項目
• 採点しない範囲
• 質問方法と提出後の流れ

採点しない範囲を明記する効果は大きいです。デザイン、インフラ構築、過度な最適化を採点対象から外すと書けば、候補者は評価に必要な部分へ集中できます。採点しない範囲を書けない状態では、評価したい能力がまだ絞れていません。

評価後の面接では、提出物の欠点を責める時間にせず、判断の根拠を聞きます。時間上限の中で何を捨てたのか、別の制約ならどう変えるのか、運用に乗せるなら何を足すのか。持ち帰り課題は、候補者の技術判断を会話可能にするための材料です。

公正さは選考後に点検する

公正な設計は、課題を出す前だけでは終わりません。厚生労働省の情報では、公正な採用選考の基本として、応募者に広く門戸を開くこと、本人の適性・能力に基づいた採用基準とすることを確認できます。技術課題も同じです。課題が特定の経歴、特定の開発環境、長時間を取れる候補者に偏っていないかを、選考後に見直します。

点検する観点は、難しいものではありません。

• 提出前の辞退が増えていないか
• 質問が特定の箇所に集中していないか
• 評価者ごとの採点差が大きくないか
• 面接で課題と関係のない情報を聞いていないか
• 合否理由が職務要件に結びついているか

この点検は、採用担当、EM、CTOで持ち寄ると機能します。採用担当は候補者体験を見て、EMは職務妥当性を見て、CTOは組織の採用基準を見ます。採用全体の設計から見直す場合は、エンジニア採用の進め方と合わせて、課題がどの選考フェーズを補っているのかを確認すると整理しやすくなります。

Cotomuが支援するのは、エンジニア採用の戦略と実務の伴走です。人材紹介、候補者送信、採用成果の保証は提供範囲に含めず、採用要件、選考設計、評価基準、運用改善を一つのプロセスとして整えます。外部伴走へ任せる範囲を決める際は、採用コンサルティングの支援範囲と選び方も判断材料になります。2026年7月30日時点の公開LP上の目安は、初期診断15万円、Core 30万円/月とGrowth 50万円/月はいずれも最低3か月、4か月目以降のAlumni 10万円/月です。初回60分相談から、課題設計の詰まりを確認できます。

持ち帰り課題の所要時間は、候補者に長く働いてもらうための枠ではありません。評価したい能力を絞り、上限時間の中で確認できる提出物に変換し、開示した基準で採点するための枠です。設計・実装・運用のどこを今回の職務で必須とするかを決め、採用担当、EM、CTOが同じ基準で運用できるところまで落とします。そこまで決めて初めて、エンジニア採用の技術課題は、候補者の負担を増やす書類から、相互理解の材料に変わります。