技術面接の評価シートは、候補者に点数を付けるためだけの書類ではありません。採用後の実務に必要な能力を、面接でのどの発言や過去の実績から判断したかを記録するためのものです。面接官が「良かった」「弱かった」とだけ記してしまうと、評価が割れた理由も、次の面接で何を確かめるべきかも曖昧になってしまいます。

項目は職務で実際に使う能力へ絞る

まず任せる仕事を書きます。たとえば「既存のデータ連携を保守しながら新しいデータ源を追加する」なら、データの欠損への対処、設計変更の影響、運用時の調査力が評価対象です。あらゆる開発技術を一枚に載せる必要はありません。

IPAは、デジタルスキル標準の項目を事業特性に応じて選び、企業ごとの評価指標を作ることを勧めています。評価シートも同じ考え方で、職務要件に結び付かない項目を削ります。特定のツール名に詳しくても、必要な設計や運用を担えるとは限らないためです。

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

評価欄は「基準・根拠・判定」に分ける

「根拠メモ」には印象ではなく、候補者が説明した具体的な仕事や面接中の回答を短く書きます。必要なら発言を要約し、事実と面接官の解釈を別にします。話せなかった項目は低評価に直結させず、「時間不足で未確認」と残してください。

記入例では、評価語より発言を残す

「設計力が高い」とだけ書いても、採用会議では根拠を確認できません。たとえば「既存のバッチ処理の失敗を調べ、再実行時に二重登録しない構造へ変更した。候補者本人が仕様確認とテストを担当した」と書けば、何を判断したかが分かります。結果が数値で示されたなら、その測り方も併記します。

一方で「マネジメント経験あり」は、何人をどの期間率い、採用、設計、評価のどこまで決めたかが不明です。人数だけで判断せず、本人の担当と権限を書きます。面接で確認できなかった場合は「未確認」とし、次回は「設計レビューで判断が割れたときにどう決めたか」を聞く、と質問まで残します。

点数を使うなら、各段階の意味を先に決める

5段階評価を使う場合でも、「3は普通」のような曖昧な定義では面接官によって基準がぶれてしまいます。「職務に近い経験を自身の判断と結果まで説明できる」「経験はあるが担当範囲が確認できない」など、客観的に観察できる基準を段階ごとに定めます。複数職種で同じシートを使う場合は、共通項目と職種固有項目を分けて整理します。

単純な合計点で採否を決める前に、必須項目を確認します。設計責任者を採用するのに設計判断が未確認であれば、他の項目の高得点で埋め合わせるべきかを採用会議で慎重に検討する必要があります。採用する役割と評価項目の重み付けを事前に決めておくことで、面接後の恣意的な判断を防げます。

評価が割れたら、発言と解釈を分けて比べる

候補者の発言に戻って評価の差を見る

一人の面接官が「主体的に設計した」と評価し、別の面接官が「指示通りの実装担当だった」と受け取った場合、候補者の同じ発言をどう解釈したかを確認します。本人が決定した範囲、レビューを受けた範囲、成果を測定した方法へ立ち戻ります。それでも判断がつかなければ、次回の面接や課題選考で追加確認すべき質問を決めます。

記録の閲覧範囲と保持期間を決める

評価シートは選考に関係するメンバーだけが閲覧できる安全な場所へ保存し、候補者の個人情報を共有する範囲と保持期間も定めます。後から基準を再確認できる記録とし、面接官の主観的な感想を漫然と残すだけの書類にしてはいけません。

外部の一次評価を自社の判断につなぐ

ZenNxt Labsのスクリーニング工程では、技術評価を複数の段階へ分けています。支援側の一次評価と自社の最終判断をつなぐ際も、「合格」という結果だけでなく、何をどのような方法で確認したかを共有することで、同一の質問を繰り返す無駄を省けます。

最後の欄は、採否より「次に確かめること」

評価シートの末尾には、採用する場合の配属条件と、選考内でまだ確認しきれていない能力を記入する欄を設けます。これにより、採用後の期待と選考時点の不確実さを混同せずに済みます。面接の精度を高めるのは細かな点数ではなく、職務に直結する客観的な根拠と、残された確認事項が見える記録です。

候補者の一次評価を外部と分担する場合は、自社の必須要件と評価シートの基準を事前に共有してください。ZenNxt Labsの技術評価支援と自社の最終判断を、同じ根拠でつなげられます。

お問い合わせはこちら