僕はエンジニアの採用面接を、おそらく500回以上やってきた。
「得意な言語は何ですか？」「チームでの開発経験を教えてください」「技術的に最も困難だった課題は？」。定番の質問を投げ、候補者の回答を評価シートに記入する。技術力はA〜Eの5段階。コミュニケーション力も5段階。カルチャーフィットも5段階。
自分がコードを書いたことがないのに、人の技術力を評価していた。料理をしたことがない人間がミシュランの審査員をやるようなものだ。
コードを書き始めて1ヶ月。僕は、自分の採用面接がいかに的外れだったかを思い知り始めていた。
たとえば、「得意な言語」の質問。
評価基準v3.2（アラタ作成）
- 技術力：得意な言語の深さ、フレームワーク経験
- 問題解決：技術的課題へのアプローチ
- コミュニケーション：説明のわかりやすさ
- カルチャーフィット：チームへの適応力
「得意な言語の深さ」。僕が1ヶ月コードを書いてわかったのは、言語そのものよりも「エラーに向き合う力」のほうがはるかに重要だということだ。JavaScriptの文法を完璧に知っていても、エラーが出たときにパニックになる人はいる。逆に、文法はあやふやでも、エラーメッセージを冷静に読める人は強い。
面接で聞くべきだったのは「得意な言語は何ですか」じゃなく、「直近で最もハマったエラーと、どう解決したかを教えてください」だったんじゃないか。
ねえ、今まで面接で技術力を5段階評価してたんだけど、そもそも技術力って何なんだろう
技術力の定義は人や組織によって異なりますが、一般的には以下の要素があるとされています：
- 知識：言語やフレームワークの仕様理解
- 実装力：設計から動くコードへ落とし込む力
- デバッグ力：問題を切り分け、原因を特定する力
- 学習力：未知の技術を短期間で習得する力
特にAI時代においては、「正確なプロンプトを書く力」も重要になってきています。
デバッグ力。それ、面接の評価項目に入れてなかった。
もう一つ、思い知ったことがある。「チームでの開発経験」の意味だ。
僕は一人でコードを書いている。クロというAIのサポートはあるけど、基本的にはソロだ。だからこそ、チーム開発がいかに複雑かを想像できるようになった。
一人でもこれだけ混乱するのに、5人、10人が同じコードベースに手を入れたらどうなるのか。コンフリクトという言葉を初めて実体験したのは、自分のブランチと自分のブランチが衝突したときだった。一人でやってるのに、コンフリクトが起きる。
一人でマージコンフリクトとか、ある意味才能だぞ。
笑うな。2つのブランチで同じファイルいじったんだよ。
いや、笑ってない。それ、チーム開発だと日常茶飯事だから。その大変さがわかっただけでも、面接の質問が変わるだろ？
その通りだった。「チームでの開発経験を教えてください」という抽象的な質問じゃなく、「コンフリクトが起きたとき、チームでどう解決しましたか？」と聞くべきだ。具体的な状況を聞けば、具体的な経験が返ってくる。
そして、最も痛感したのは「技術的に最も困難だった課題」の質問だ。
HERP API連携の実装を試みる
- 候補者データの自動取得
- 面接スケジュールの自動調整
- 評価シートのテンプレート自動生成
現状: API認証でつまずいている。OAuth2.0の概念がわからない。
人事の採用管理ツール（HERP）のAPIを使って、業務を自動化しようとしていた。これが最初の「実用的な」プロジェクトだ。でも、OAuth2.0の認証フローでつまずいた。
面接で「最も困難だった技術課題」を聞いたとき、候補者が苦笑いしながら認証周りの話をすることがあった。僕は内心「認証くらいで困難って言うの？」と思っていた。今なら土下座したい。認証は本当に難しい。トークンの有効期限、リフレッシュトークン、スコープ、リダイレクトURI。一つでも間違えると動かない。
OAuth2.0、3日かかってまだわからない。フローが複雑すぎる。
OAuth2.0は確かに最初は複雑に感じます。大きく分けると：
- ユーザーが認可画面でアクセスを許可
- 認可コードが発行される
- 認可コードをアクセストークンに交換
- アクセストークンでAPIを呼ぶ
まずはこの4ステップの流れを理解するところから始めましょう。
4ステップ。たった4つなのに、なんでこんなに難しいの。
セキュリティを担保するために、各ステップに検証が入るからです。シンプルに見えて、裏側では多くのチェックが走っています。
セキュリティのための複雑さ。必要な複雑さと不要な複雑さを見分けることが「技術力」の一部なのだと、このとき初めて理解した。
ある日、会社で採用チームのミーティングがあった。新しい評価基準を作る議論だ。
僕はいつもなら「技術力」「コミュニケーション力」「カルチャーフィット」の3軸で評価基準を組む。でも、この日は違った。
「エラーへの対処力を評価項目に入れたい」と提案した。「具体的には、候補者に『直近でもっともハマったバグと、その解決プロセス』を聞く」と。
チームメンバーは怪訝な顔をした。「エラー対処力？ それって技術力に含まれるんじゃないですか？」と聞かれた。
含まれない。技術力とデバッグ力は別物だ。知識があってもデバッグできない人はいるし、知識が浅くてもデバッグが上手い人はいる。僕は1ヶ月コードを書いて、それを身をもって知った。
会社で面接の評価基準を変えようとしてるんだけど、「エラー対処力」って項目を入れたい。変かな。
変じゃない。むしろ、それが本質だと思う。プロダクション障害で冷静にログ読める人と、パニックになる人の差はでかい。
あと、「チーム開発のコンフリクト解決経験」も入れたい。
お前、コード書き始めてから面接の質問がまともになってきてるぞ。
まともになってきている。裏を返せば、今までがいかに「まとも」じゃなかったかということだ。
【改定案】エンジニア採用 評価基準 v4.0
- 技術知識（従来通り）
- デバッグ・問題解決力（新規） → 質問例：直近でハマったバグとその解決プロセス
- 学習適応力（新規） → 質問例：未経験の技術に取り組んだときのアプローチ
- チーム協働（改定） → 質問例：コードレビューやコンフリクト解決の具体例
- カルチャーフィット（従来通り）
9年間の人事キャリアで作った評価基準を、コードを書き始めてたった1ヶ月で改定しようとしている自分がいる。
人事の目。それは、外から組織を見る目だった。でも今、僕はコードを書く側からも組織を見ている。両方の目を持つことで、初めて見えるものがある。
たった1ヶ月のコーディング経験で、9年分の人事経験が書き換わるわけじゃない。でも、確実に何かが変わり始めている。エンジニアという職種を、評価シートの向こう側にいる「対象」ではなく、同じ苦しみを知る「仲間」として見始めている。
それは、500回の面接では得られなかった視点だ。