コーディングテストは、動くプログラムを提出できたかだけで評価してしまうと、入社後の実務とのつながりが薄くなります。既存コードを読み解いて改修する役割であれば、境界条件への対応、修正の影響範囲、テストの網羅性、設計変更の理由なども見極めたい重要な要素です。課題を出題する前に、「任せる職務で必要な判断を、どの部分から観察するか」を定めておく必要があります。

課題は実際の仕事を小さく切り出す

日々の業務がAPIの保守運用であれば、実務とかけ離れた競技プログラミング形式の問題だけで選考を行うのは避けるべきです。既存のシンプルなAPIに一つの仕様変更を加え、入力の例外処理、エラーハンドリング、ユニットテストを記述してもらう課題であれば、実務に即した判断力を確かめられます。データエンジニアであれば、欠損値を含むデータを変換し、再実行可能なパイプラインに整える課題などが有効です。

使用可能な言語、制限時間、公式ドキュメントや生成AIツールの利用可否は事前に明確に伝えます。実務で一般的に使うツールを禁止する場合は、採用側がその理由と、代わりに評価したい能力を候補者へ説明できるように準備しておきます。採点者が候補者ごとに異なる前提で評価してしまうと、結果の公平な比較が難しくなります。

評価を四つの観点へ分ける

未完成の提出物でも、どこまで動き、残った問題をどう捉えているかが分かる場合があります。逆に正答していても、仕様を変えたときの修正が難しい作りなら、その職務で必要な設計力は別に確認します。全員の提出物を同じ入力と基準で見てから、個別の工夫を読みます。

採点表は課題を配る前に試す

採点者2人が同じサンプル提出物を読み、観点ごとに評価理由を書き出してみます。「設計がよい」という言葉の定義にずれがあれば、実際の候補者が提出する前に評価基準を修正できます。たとえば、今回の職務が既存APIの保守であれば、構造を複雑に作り直すことよりも、変更の影響範囲を限定した実装とテストの充実度を重く見るという判断もあり得ます。

課題文には期待する振る舞いと制約条件を明記し、採点者だけが知っている暗黙の前提を排除します。ただし、実務でも仕様の曖昧さが生じる業務であれば、候補者が質問できる窓口を用意し、どのような点を確認してきたかも記録します。曖昧さを放置したまま進めた結果と、前提条件を適切に確認して進めた結果を、同じ点数で扱うべきではありません。

提出物について話す時間を残す

課題提出後の面接では、「実装にあたって最初に何を確認しましたか」「時間がさらにあればどの部分を改善しますか」「この実装をチームへ引き渡すならどのような点を共有しますか」といった質問を投げかけます。候補者の説明を聞くことで、コード単体からは見えない前提認識や、採用後のレビューで必要となる対話力を把握できます。設計判断の詳細は技術評価の工程と併せて整理しておくと、課題選考が担うべき役割をより明確に定められます。

IPAのデジタルスキル標準でも、組織の事業特性に合わせた評価指標の策定が推奨されています。課題の採点表においても、すべての職種に画一的な配点を用いるのではなく、採用する職務内容に合わせて重み付けを調整することが重要です。

参考：IPA「デジタルスキル標準（DSS）策定の背景・目的」

課題の負担と評価できる範囲を明示する

作業時間と評価する能力を絞る

拘束時間の長い課題ほど候補者を正確に評価できるとは限りません。事前に想定作業時間を示し、その範囲内で何を確認するのかを絞り込みます。既存プロダクトの実コードや機密情報を含むデータを渡さないよう、課題データは選考専用に準備します。複数名でのチーム開発成果を一人の作品として見誤らないよう、提出物の作成範囲も個別に確認してください。

候補者が取り組める代替課題を用意する

家庭環境や現職の繁忙度によって長時間の持ち帰り課題への対応が難しい候補者もいます。提出期限、作業時間の目安、あるいは面接時間内で完結する代替課題をあらかじめ用意しておくことで、実力以外の外的要因で評価が歪む事態を防げます。課題選考を設けない場合でも、過去の実務コードや設計資料を題材に設計判断を問うなど、評価する技術軸は一貫させておきます。

課題で測れない能力は面接で確認する

課題選考で測定できるのは、限定された条件下での実装力と説明力です。中長期的な運用保守、チーム協働、突発的な障害対応までを一度に実証できるわけではありません。課題で測りきれなかった問いを次の面接へ確実に引き継ぐことで、同じ能力を繰り返し測らずに済みます。

評価理由を観点ごとに記録する

不採用とする場合でも、候補者からフィードバックを求められた際に誠実に回答できるよう、評価理由は設定した観点に沿って客観的に残します。「コードの品質が不十分」といった抽象的な表現ではなく、指定したどの境界条件で正しく動作しなかったか、説明においてどの点が確認できなかったかを記録します。これは、以降の候補者に対して公平な基準を適用し続けるためにも有用です。

採用する職種、課題で確認したい判断力、社内で採点に充てられる時間を整理しておけば、ZenNxt Labsの技術評価支援に相談する際も、課題と面接それぞれの役割分担を決められます。

お問い合わせはこちら