AI 時代のエンジニア採用

これまでの技術面接は、コーディング能力を中心にしてきました。候補者がどの言語やフレームワークに詳しいか、ホワイトボードでアルゴリズム問題の解法を書けるか、といった点です。

AI の時代には、これはもう有効な基準ではありません。ある言語に詳しくなくても、AI の力を借りて価値のあるプロダクトを届けることができます。

より注目すべきなのは、次の 2 つの能力です。

1 つ目はシステム全体の理解です。完成したシステムにはどんな部分が必要か、それぞれがどう連携するか、リリース後に正常に動いていることをどう確かめるか。この理解がなければ、AI が出す設計案を評価できません。

2 つ目は知的好奇心です。新しい知識、特に AI の分野を自分から追いかけること。ツールやモデルの変化は速く、今日のベストプラクティスが半年後には古くなっているかもしれません。新しい技術を学び、試し、振り返り続けるかどうかは、エンジニアとしての長期的な成長に直接影響します。

いま最も重要な 6 つの能力

1. AI に意図を正確に伝える。 AI は与えられた情報をもとにしか動けません。目標、制約、完了の基準、何が決まっていて何が決まっていないか。これらを明確に伝えるほど、成果物は期待に近づきます。伝え方があいまいだと、もっともらしく見えて実は要件から外れた結果になりがちです。

2. AI の意図を理解する。 AI が計画やコードを返してきたとき、エンジニアはその考え方を読み取れなければなりません。要件をどう理解したのか、どんな前提を置いたのか、どこが推測なのか。AI の誤解に気づけることは、同じコードを自分で書けることよりも重要です。

3. あいまいな目標から、システムの姿を見通す。 要件は初めのうちはたいていあいまいです。優れたエンジニアは手を動かす前に、システムについての初期の見立てを持ちます。おおよそどんな部分で構成され、どこが難しくなりそうか。そして新しい情報に応じて修正していきます。この見立てがあって初めて、AI の設計案が正しい方向に向かっているかを判断できます。（私のやり方は今のシステムの設計の仕方にまとめています。）

4. テストを設計する。 コードがどれだけ速く生成されても、検証は省けません。どこを必ずテストするか、どんな方法を使うか、テストが検証したい振る舞いを本当にカバーしているか。いずれもエンジニアの判断が必要です。

5. 監視を設計する。 リリース前はテストが主要な振る舞いを検証して不具合のリスクを下げ、リリース後は監視が稼働状況を見守って異常を早く見つけます。どちらもシステムが常に正しいことを保証するものではありませんが、どちらも欠かせません。どんなログやメトリクスが必要か、障害が起きたときに誰がどれくらいの時間で気づくか。これらは障害の後で付け足すのではなく、設計の段階で考えておくべきです。

6. AI のワークフローを管理する。 agent が 1 つでも複数でも、作業をどう分けるか、成果物をどうレビューするか、文脈をどう保つか、自分がボトルネックにならないためにどうするか。それ自体がエンジニアリングの能力です。（私のやり方は十数個の AI agent を同時に動かす方法にまとめています。）

面接でどう見極めるか

grill-me で判断力と伝える力を見る

grill-me は AI のスキルの 1 つです。計画を渡すと、AI は判断どうしの依存関係に沿って何回かに分けて質問し、それぞれに推奨の回答を添えます。すべての判断に結論が出るまで続きます。

面接では、候補者にあいまいな要件を渡し、grill-me を使って AI と対話しながら、明確な設計案にまとめてもらいます。対話を始める前に、システムの境界、主な前提、まだ検証が必要な点を簡単に説明してもらいます。対話が終わったら、どの判断が変わったか、それはなぜかを説明してもらいます。このステップで見るのは 3 つ目の能力、つまり AI が提案する前に、候補者自身がどう判断していたかです。

対話の間、面接官は次の 2 点に注目します。

• 自分で判断しているか。 基準は AI に反対するかどうかではありません。それぞれの提案を受け入れた理由、退けた理由を説明できるか、それをどう検証するつもりかです。AI に頼りきっている人は、AI が間違えたときにも気づきにくくなります。
• 正確に伝えているか。 回答は明確か、必要な文脈や理由を添えているか。AI が誤解したときに、それに気づいて正せるか。

ホワイトボード問題と比べて、こちらのほうが候補者の日々の仕事にずっと近いやり方です。

システム設計：テストと監視を自分から考えているか

システム設計の問題は今も有効ですが、見るべき点は変わりました。コンポーネントとデータの流れを図にすることは、AI にもできます。より注目すべきなのは、候補者が言われなくても、システムをどうテストするか、リリース後にどう監視するか、障害にどう気づくかに触れるかどうかです。触れたこと自体は手がかりにすぎません。具体的な障害のシナリオを 1 つ挙げて掘り下げましょう。テストはその問題をどう捉えるか、本番ではどのシグナルで気づくか、誰が対応するか。こうした回答は、候補者がシステム全体を理解しているかを判断する材料になります。ただし、1 つの場面への回答だけで結論は出せません。

日頃 AI agent をどう管理しているか

最後に、普段 AI をどう使って仕事をしているかを聞きます。同時にいくつの agent を使うか、どう分担させるか、成果物をどうレビューするか、どんな問題にぶつかったか、最近どんな新しいツールを試したか、なぜ使い続けているのか、あるいは使うのをやめたのか。

具体的な経験や教訓は、さらに質問を重ねるための材料です。ただし、話がなめらかかどうかだけで実力を判断することはできません。この質問は知的好奇心を見るものでもあります。その人が最近何を試しているかは、履歴書のスキル一覧よりも多くを語ります。

公平さを保つ

面接する側は、全員に同じ AI ツール、モデル、アカウントを用意し、必要なスキルをあらかじめ入れておき、環境に慣れる時間を設けたうえで、課題、制限時間、評価基準をそろえるべきです。agent の数や有料ツールの使用経験では加点しません。こうしたツールを使う機会がなかった候補者でも、その場の課題を通じて、仕事の組み立て方、結果の検証の仕方、新しいやり方の学び方を示すことができます。

おわりに

AI の時代に求められるのは、いちばん速くコードを書く人ではありません。AI と協力して、あいまいな目標をテストと監視のできる完全なシステムに仕上げ、学び続けるエンジニアです。