エンジニア採用スコアカードの作り方｜一枚で技術要件を揃える

エンジニア採用のスコアカードに「技術力」「コミュニケーション能力」「カルチャーフィット」とだけ書いても、判断は揃いません。CTOは設計力、EMはチームとの協働、現場エンジニアは実装速度を思い浮かべ、同じ言葉へ別の意味を入れるからです。

僕なら、一枚の評価表を「期待成果」「必要な能力」「必須または加点」「観察する証拠」「判定尺度」「担当工程」の列で作ります。エンジニア採用スコアカードの役割は面接官の感想を点数へ変えることではありません。入社後に任せる仕事と、選考で確認する証拠を同じ行へ置くことです。

本記事では質問の進め方や合否会議の運営ではなく、評価表そのものの列、尺度、職種別項目、版管理に絞ります。

作成した評価表を技術面接で使う手順は、エンジニア採用の面接評価基準で、質問、記録、合否会議まで整理しています。

エンジニア採用スコアカードの列は期待成果から順に並べます

最初の列には、入社後の一定期間で実現してほしい状態を書きます。「バックエンドを担当する」では広すぎます。「決済処理の部分失敗を減らし、安全に変更できる境界を設計する」まで書けば、必要な能力を分解できます。採用時の期待成果を30日・60日・90日の確認材料へ移す手順は、エンジニアのオンボーディング90日計画で整理しています。

次の列には、期待成果へ必要な能力を書きます。決済処理の例なら、データ整合性、再実行、障害からの復旧、監視設計が候補です。Goやクラウド製品の利用年数は、能力を示す証拠になり得ますが、期待成果そのものではありません。技術名を必須にする場合は、入社直後から必要な理由も同じ行へ残します。

必須と加点は別の列にします。欠けると仕事を任せられない能力と、入社後に学べる知識を混ぜると、全項目が必須になりやすいからです。必須項目には採用しない判断へ直結する理由を書き、加点項目には担当範囲が広がる条件を書きます。

担当工程の列には、書類、技術課題、システム設計、マネジメント面談など、証拠を得る場所を一つ置きます。一つの項目を複数工程で確認する場合は、重複する理由を記録します。同じ能力を三回聞く表は候補者の負担を増やし、未確認の項目を残します。

一行へ複数の能力を詰め込みません。「設計力・実装力・協働力」のように中黒でつないだ項目は、どの能力を満たしたか判定できないからです。一つの行に一つの期待を置くと、後から不要な項目も削りやすくなります。

判定尺度と証拠欄を分けて定義します

判定尺度には、少なくとも「基準を満たさない」「基準を満たす」「基準を超える」「未確認」を置きます。数字だけの五段階評価では、三点の意味が人によって変わります。各尺度には、候補者の行動として観察できる状態を書きます。

たとえば「障害時の切り分け」なら、基準を満たす状態を「不足情報を挙げ、影響範囲を限定する仮説と確認順を説明できる」と定義できます。基準を超える状態は、難しい質問へ答えたことではなく、復旧、再発防止、開発速度の利害を整理して関係者へ説明できる状態です。

証拠欄は判定理由を自由記述するだけの欄にしません。「候補者が置いた前提」「比較した選択肢」「選んだ判断」「確認できなかった点」の小さな入力欄へ分けます。入力の観点が決まると、「優秀そう」「経験が浅そう」といった印象だけを残しにくくなります。

未確認は低評価と分けます。選考側が質問できなかった場合、候補者が経験していない場合、回答はあったが根拠が足りない場合も、理由を区別します。未確認が多い項目は候補者の問題ではなく、証拠を得る工程が表と合っていない可能性があります。

総合点の計算式も慎重に扱います。必須項目の不足を、別の加点項目で相殺してよいかを表の定義として決めます。単純平均だけを出すと、職務に欠かせない能力が不足していても高得点に見える場合があります。

共通の列を保ち職種別の項目だけを変えます

全職種で共通にするのは列の構造と尺度の言葉です。評価項目まで共通化すると、職種名だけ違う汎用表になります。バックエンド、SRE、EMでは、入社後に担う判断も必要な証拠も異なります。

バックエンドエンジニアの項目には、API境界、データ整合性、性能と保守性の判断を置けます。証拠欄には、仕様変更や部分失敗へどう対応したかを書けるようにします。利用言語の一致より、設計判断を再現できるかへ表を寄せます。

SREでは、検知、切り分け、復旧、再発防止を一つの「障害対応力」へまとめません。サービスレベルと開発速度をどう比較したか、オンコールの負担をどの仕組みで減らしたかなど、任せる責任に応じて行を分けます。

EMでは、メンバーとの関係づくりだけを置かず、開発計画の不確実性を説明する、育成へ時間を配分する、評価と役割を接続する、といった組織上の判断を書きます。実装力をどこまで必須にするかは、プレイングマネージャーか組織運営へ比重を置く役割かで変わります。

職種別の原本は複製元を一つにし、共通列の意味を変えません。追加したい項目が出た場合は、既存の行へ言葉を足す前に、期待成果との関係を確認します。候補者一人だけを説明するための項目を増やすと、選考途中で基準が動きます。

項目数には上限を置きます。全ての能力を評価表へ入れるのではなく、今回の役割で採用判断を変える項目を残します。使われない行を増やすより、重要な行の証拠欄を具体的にする方が判断しやすくなります。

更新履歴と適用日でスコアカードの版を守ります

原本には版番号、更新日、更新者、変更理由、適用日を置きます。プロダクト計画、チーム構成、入社後の責任が変わった場合は、期待成果から見直します。「最近の候補者は弱かった」という感想だけで尺度を動かしてはいけません。

変更時には、求人票、技術課題、面接資料とスコアカードの対応も確認します。評価表で障害対応を必須にしたのに、どの工程でも証拠を得られない状態では、列を追加しただけです。反対に、職務から外れた能力を慣習で聞き続けているなら、関連する行と課題を一緒に削ります。

選考中の候補者へ適用する版を途中で切り替えないことも重要です。やむを得ず役割自体が変わった場合は、旧版と新版の差、候補者への説明、再確認が必要な項目を記録します。過去の版は削除せず、どの候補者へ使ったか追える形で保管します。

スコアカードの項目は、職務上の適性と能力へ結びつけます。厚生労働省は、本人に責任のない事項や思想・信条に関わる事項を採用基準にしないよう案内しています。公正な採用選考の基本に照らし、家族構成、出生地、住宅状況、宗教、支持政党、愛読書などを評価項目へ入れません。

採用後の振り返りでは入社者を再採点せず、期待成果が実際の仕事と合っていたかを確認します。SREを採用したのに機能開発が大半だった場合、候補者の点数ではなく役割とスコアカードの前提を直します。

評価表の運用を職種別の選考件数や滞留日数と一緒に見る場合は、エンジニア採用KPIの設計へ尺度の変更理由と適用日も残します。

現在使っている評価表を開き、先頭から六列を確認してください。期待成果、必要能力、必須・加点、証拠、尺度、担当工程が並んでいなければ、まず一職種の最重要項目を一行だけ書き直します。一行を完成させる作業が、汎用的な点数表を職務に使えるスコアカードへ変える出発点です。

※制度に関する記載は2026年8月15日時点です。実際の募集・技術選考設計は、管轄の都道府県労働局または専門家へ確認してください。