AIネイティブ時代に「仕事の勘所」がわかる人を採用する方法

仕事の勘所とは、曖昧な仕事を実行可能な作業に変え、結果まで責任を持つ能力です。

---

最近、同僚とバイブコーディング導入後の実務担当者の生産性に差を生む要因について話しました。同じAIツールを使っていても、なぜ人によって成果が違うのでしょうか。その違いを一つずつ考えていくうちに、韓国語の「일머리」、つまり「仕事の勘所」という言葉で説明できるという結論に至りました。

ところが、その意味を定義してみると、興味深いことに気づきました。仕事の目的と文脈を理解し、曖昧な問題を構造化し、優先順位を決めて実行し、結果を確認して改善する能力。開発者がソフトウェアを作るなかで行ってきたことと、ぴったり一致していたのです。

では、この能力を持つ人をどう見分ければよいのでしょうか。開発経験が長いという事実だけでは判断できません。今回は、経験年数にかかわらず、仕事の勘所がわかる人を採用する方法について考えます。

出発点は、会社全体が求める人物像と、チームが必要とする実務能力を分けることです。全社共通の人物像は面接で、チームの実務能力はAIを使う個別の課題で確認します。AIは応募者の働き方だけでなく、会社がその課題を作るコストも変えています。

TL;DR

• 仕事の勘所を、目的の把握、構造化、判断、実行、検証、適応という観察可能な行動に置き換えます。
• AIによって個別の採用課題を作るコストが下がった分、チームと役割の実務に近い課題を設計します。
• 全社共通の人物像は面接で、チームの実務能力はAIを使う課題で評価し、提出物に基づく面接で判断の根拠を確認します。
• 実務でAI活用を期待する職務では、課題と面接中の実務作業でもAI使用を必須にします。会社のサンドボックスで作業し、ログとコミット履歴を保存します。
• 評価項目、配点、合格基準は会社と役割に合わせて設計します。経験年数に頼るより、実際の判断と成果を確認します。

1. 採用したい能力を定義する

私が考える定義は、次のとおりです。

与えられた仕事の目的と文脈を素早く理解し、必要な作業を自ら構造化して、適切な優先順位と方法で成果までつなげる能力。

さらに、実行結果を確認して計画を修正する能力も含める必要があります。最初の計画がもっともらしくても、現実に合わなければ変更すべきだからです。

例えば「顧客からの苦情が増えたので調べてほしい」と頼まれたとします。勘所が表れるのは報告書の分量ではありません。本当に増えたのか、注文数の増加による変化なのか、特定の商品や時期に集中しているのかを区別する過程です。その後、最初に確認する仮説と行動を決め、結果を確認します。

報告書の下書きはAIに任せられます。しかし、どのデータを見るべきか、何を解決すべきか、行動に移るにはどの程度の根拠が必要かは、依然として判断を要します。採用では、その判断を観察すべきです。

2. 優れたエンジニアに以前から求めてきた能力

この定義から、ソフトウェアエンジニアになじみのある仕事の流れが浮かびます。要件の理由を確認し、曖昧な点を明確にし、問題を分け、技術的な選択の長所と短所を比較し、実装後に運用結果を見て改善する過程です。

特に、失敗を先に考える習慣があります。入力が間違っていたらどうするか。外部サービスが応答しなかったらどうするか。結果の誤りをどう検知するか。問題が起きたら元に戻せるか。

こうした問いは、ソフトウェア以外でも役立ちます。研修を企画する際は、参加者の習熟度が予想と違った場合を考えます。顧客対応の設計では、担当者が不在のときに誰が引き継ぐかを確認します。市場調査では、結論を変え得る反証を探します。

ここに機会があります。AIが調査、文書化、分析の一部を支援すれば、エンジニアは問題解決の能力を隣接する業務に応用できます。ソフトウェアエンジニアリングの経験を、一般的な問題解決の訓練として捉えられるという仮説です。

ただし、開発者という肩書がその能力を保証するわけではありません。他の職種にも同じ能力を持つ人はいます。採用で見るべきものは職業のイメージではなく、実際の行動です。

3. 職務の境界より役割と失敗のコストを見る

AIと開発の話では、非開発者がサービスを作る方向に関心が集まります。逆方向にも注目する価値があります。開発者がAIを使って顧客インタビューの質問を作り、データを分析し、技術研修を設計することです。

このとき「他の職務を代わりに担う」という表現は広すぎます。市場調査の下書きと、事業への投資判断の責任を負うことは違います。技術文書を書くことと、セキュリティ監査を最終承認することも違います。

役割を広げるかどうかは、三つの要素を合わせて判断すべきです。既存の能力がどれほど応用できるか、結果を検証する領域知識があるか、失敗した場合のコストはいくらか。

内部検討用の下書きなら、小さな実験から始められます。顧客への約束や大きな支出を伴う判断には、より深い専門性とレビューが必要です。開発者が別の領域に移れば常にリスクが低くなる、という一般化はできません。

そのため、求人でも責任を持つ成果と必要な専門性を具体的に書くべきです。「AIを使いこなす開発者」よりも、「顧客の問題を確認し、小さな解決策を実装し、効果を測定して改善する人」のほうが、評価する行動を明確にできます。

4. 会社が求める人物像とチームの実務能力を分ける

もう一つ注目している変化は、個別の採用課題を作るコストが大きく下がったことです。チームの業務を課題にするには、状況を説明し、サンプルデータを作り、作業を始められるプロジェクトと検証方法を準備する必要があります。今はこの準備にもAIエージェントの助けを借りられます。

例えば、チームが作る製品の目的と採用する人が担う仕事を整理してAIに伝え、課題のシナリオ、サンプル文書、テスト用ツール、評価項目のたたき台を一緒に作れます。担当者は実務を適切に反映しているかを確認し、自分で課題に取り組んで難度と所要時間を調整します。この過程で、チームごとに異なる問題を採用課題に盛り込む負担を減らせます。

そうすると、採用でも二つの問いを分けて考えられます。

確認すること	主な評価方法	観察する内容
会社全体が求める人物像	共通の面接	協働、責任、顧客への姿勢など、会社が重視する原則を実際にどう実践してきたか
チームが必要とする実務能力	チームと役割に合わせたAI活用課題	担う問題を理解し、AIと設計・実装・検証して成果を出せるか

全社共通の面接では、抽象的な価値観への賛同を聞くだけで終わらせてはいけません。意見が衝突したときにどう調整したか、自分のミスをいつ誰に伝えたか、フィードバックを受けて行動を変えた経験があるかを具体的に尋ねます。会社が重視する原則を、観察可能な行動として整理するのです。

チームは、入社後に任せる仕事を縮小した課題で実務能力を確認します。同じ開発者の採用でも、顧客向け製品を作るチームと社内業務を自動化するチームでは、異なる課題を作れます。課題を調整する単位はチームと役割とし、同じポジションの応募者には共通の要求水準と評価条件を適用します。

二つの評価結果は合わせて見つつ、何を根拠に判断したかは分けて残します。チームの実務評価は課題と作業記録を根拠に説明し、全社共通の人物像については面接で確認した事例を根拠に説明します。提出物についての追加面接は、課題で観察した判断をより深く確認する過程になります。

5. AIエージェントと課題を設計し、提出する

私は以前、実際の業務を縮小したプロジェクトを採用課題として提示したことがあります。応募者にはコーディングエージェントでプロジェクトを進めてもらい、コミット履歴とプロンプトを含む振り返りを残してもらいました。最終成果物とともに、そこに至った過程も評価材料にしました。

この経験をもとに、チームの実務能力を確認する過程を二段階でつなげたいと考えています。応募者がAIエージェントと課題を設計して提出する段階と、提出した課題をもとに面接する段階です。全社共通の人物像を確認する面接項目も用意します。

実務でAIを使う人を採用するなら、両段階の実務作業でAI使用を必須にします。何をAIに任せ、どの判断を自分で行い、結果をどう検証するかが評価対象だからです。

開発者の採用なら、次のような業務用エージェントシステムの開発課題が考えられます。

社員の業務依頼を受け、社内文書を検索し、根拠を示して回答するエージェントシステムを設計してください。処理が必要な依頼には実行計画を作り、必要な承認を得てから業務ツールを呼び出せるようにします。制限時間内に検証する中核の流れを決め、設計と実装結果を提出してください。

会社はサンプル文書、架空の業務データ、テスト用の業務ツールを提供します。応募者はAIエージェントと要件を解釈し、システムを設計し、実装と検証を進めます。ここでは課題に取り組むためのコーディングエージェントと、開発対象の業務用エージェントシステムを区別します。

応募者が最初からすべての機能を作る必要はありません。まず、どの社員のどの業務を解決するか、文書に答えがない場合はどうするか、ツール実行前にどの承認が必要かを整理します。文書検索と回答に集中するか、小さな業務を一つ最後まで処理する流れを作るかも選ぶ必要があります。

会社は、その職務で必ず確認する要件と提出範囲を事前に示します。応募者はその範囲で優先順位と方法を決めます。実装中心の役割なら実行可能な中核の流れとテストを、設計中心の役割なら構造、選択の根拠、検証方法をより重視できます。課題の背景情報と質問に回答する条件は、同じ採用選考の応募者に一貫して提供します。

提出物には設計とコードに加え、置いた仮定、実装済みの内容、残っていることを含めます。プロンプトと振り返りは、その選択を説明する資料になります。実際の職務に似た活動を行わせる方法は、ワークサンプル評価につながります。米国人事管理局（OPM）もこの方法を紹介し、入社時点で備えているべき能力を対象に使うと説明しています。¹

提出までの期間と、実際に期待する作業時間は分けるべきです。提出期限を1週間後にしても、すべての応募者が課題に使える時間が同じになるわけではありません。会社は想定作業時間、最低限の提出範囲、追加実装を評価に含めるかを事前に案内し、必要に応じて課題への報酬も設計すべきです。

6. 会社のサンドボックスで作業記録を保存する

過程を評価するなら、記録をどこまで信頼できるかも考える必要があります。提出直前にまとめた振り返りは、当時の判断をそのまま示しているとは限りません。プロンプトや説明もAIで書き直せます。

私が最もよいと考える方法は、会社が用意したサンドボックスでプロジェクトを進め、生成されたログとコミット履歴を応募者が後から変更できないように保存することです。作業環境、AIツールとアカウント、利用費用を会社が提供し、応募者はその中で課題に取り組みます。

作業領域と記録保管領域の権限は分けます。応募者はコードと設計文書を自由に修正し、新しいコミットを作れます。すでに収集されたログやコミット記録には、変更・削除権限を与えません。作業に使うAIエージェントにも同じ制限を適用します。誤った選択を修正する過程は、新しい記録として残ります。

例えば、次のように構成できます。

記録	収集・保存方法	面接で確認する内容
AIへの依頼と応答、ツール呼び出し	会社が管理する収集経路から作業領域の外に保存	どの文脈を伝え、結果をどう扱ったか
コミットとその時点のファイル状態	会社のリモートリポジトリに自動送信し、受信した履歴を別途保存	設計とコードがどの順序で変わったか
実行・テスト結果	会社の実行環境でログを収集し、コードのバージョンと関連付ける	確認したと説明する動作を実際に検証したか
振り返りと最終提出物	提出時点のバージョンを固定し、後からの説明は別に記録	説明が当時の作業と一致するか

応募者や作業エージェントが収集機能を止めたり保存設定を変更したりできないよう、管理権限も分けます。リモートリポジトリでは強制プッシュとブランチ削除を禁止し、応募者に保護ルールを回避する権限を与えません。GitHubの保護ブランチも、このような制限を提供しています。²

ただし、リモートブランチの保護だけで、サンドボックス内のすべての作業履歴が保存されるわけではありません。ローカルで履歴を書き換えてから初めて送信する場合もあるためです。作業中のログとコードの状態を継続的に収集し、会社側の受信時刻と関連付けて保管する必要があります。収集した記録には、保存期間中の上書きと削除を防ぐ保存方式を使えます。例えばS3 Object Lockは、指定したオブジェクトのバージョンにこの保護を提供します。³

何を収集し、いつまで保存するかは、課題開始前に案内します。収集範囲は課題用の環境に限定し、応募者にはツールに慣れる機会も提供します。記録が欠けている期間は、面接で確認すべき未確認の期間として扱います。

この構成が確保するのは、収集した記録を後から変えにくいという信頼性です。記録の量や保存自体が応募者の判断力を証明するわけではありません。続いて、説明、作業記録、実際の成果物、実行結果を相互に照合する面接が必要です。

7. 提出した課題をもとに面接する

実務に関する追加面接は、応募者が提出したプロジェクトから始めます。面接官は設計、コミット、AIの利用記録、テスト結果を事前に読み、確認する意思決定の場面を選びます。作ったものをもう一度発表してもらうだけで終わらず、選択の理由と、その選択が実際の結果につながったかを尋ねます。

業務用エージェントシステムなら、次のような質問が考えられます。

• AIは業務ツールを直接呼び出す設計を提案しましたが、最終実装では承認段階を追加しています。どのような問題を想定しましたか。
• 振り返りには、文書に根拠がない場合は回答を保留するよう変更したとあります。どのコミットとテストで、その変化を確認できますか。
• テスト失敗後にプロンプトを修正しています。原因がプロンプトにあると判断した根拠は何ですか。コードやデータの問題はどう確認しましたか。
• 提出物の中でまだ検証できていない部分は何ですか。実務で使うなら、何から確認しますか。

これらの質問は、説明と記録をつなぎます。振り返りをAIの助けで書いていても、実際の作業を正確に説明しているか、応募者が選択の理由を理解しているかを確認できます。

必要なら、提出物に小さな変更要求を加えます。

業務ツールが依頼を処理した後、応答を返せませんでした。エージェントが同じ依頼を再試行しても、業務が二重に処理されないように設計を変えてください。

応募者は既存のプロジェクトをもとに、AIエージェントと影響範囲を調べ、修正方法を決め、可能な範囲で変更と検証を進めます。面接官は、どの情報を先に確認するか、AIの提案をどう判断するか、残る問題をどれほど正確に説明するかを観察します。面接中の変更記録も、元の提出物と分けて保存します。

最後に、最初の仮定、途中で変わった判断、AIの提案を採用または却下した理由を振り返ります。課題の記録と面接中の行動を合わせて見ることで、未知の条件でも同じ問題解決の方法を続けられるかを確認できます。

こうして課題と面接がつながります。課題に残された判断の跡を面接で確認し、新たな条件によってその判断がどう変わるかを観察するのです。

同じ面接の場で、全社共通の人物像を確認することもできます。技術的な選択の理由を確認する質問と、協働や責任に関する経験を確認する質問をそれぞれ準備し、回答も該当する評価項目に記録します。面接を何回に分けるかは会社が決めますが、各質問で何を確認するかは明確であるべきです。

8. 評価基準は会社と役割に合わせて設計する

この提案を、すべての会社が同じ配点で使うことはできません。採用する人の業務と責任が違えば、重視する判断も変わります。評価項目、配点、合格基準は、会社が役割に合わせて設計すべきです。

全社共通の人物像は組織全体で共有する面接基準として整理し、実務能力については採用チームが課題と評価基準を一緒に設計します。採用担当者とチームは、それぞれの最低要件と最終判断の方法を事前に合意します。そうすることで、課題の点数や面接の印象だけで、ほかの根拠が見えなくなるのを防げます。

同じ業務用エージェントシステムの課題でも、プロダクトエンジニアならユーザーの問題を絞り込み、中核の流れを完結させる能力を重視できます。プラットフォームエンジニアならツール実行の安定性と障害復旧を、アーキテクトなら要件の衝突と設計上の選択の根拠をより深く見られます。各役割で何を最低要件にするかから決めるべきです。

そのうえで、目的の把握、構造化、優先順位、AIへの委任、検証、適応のうち、どの行動を観察するかを具体化します。例えばツール実行の安定性が重要な役割なら、「二重処理の可能性に気づいた」「防止方法を説明した」「修正後にテストで確認した」を異なる根拠として記録できます。各行動をどれほど重視するかは、その役割の責任に応じて決めます。

同じ役割の応募者には、共通の評価項目と水準ごとの基準を適用します。基本課題、提供情報、利用条件、追加変更の難度もそろえます。提出物によって追加質問は変わっても、何をよい判断と見るかが面接官ごとに変わってはいけません。OPMの構造化面接の案内も、事前に決めた質問と共通の評価尺度を重視しています。⁴ この原則を、提出物に基づく面接の共通質問と評価基準に適用できます。

経験年数にかかわらず評価するとは、年数だけで仕事の勘所を判断しないという意味です。経験は問題を認識する速さや領域に関する判断に役立ちます。会社は入社時点で必要な専門性と入社後に学べる内容を区別し、業界用語をよく知っていることと、問題をうまく解けることを混同しないようにすべきです。

採用後も基準を引き継ぎます。目的が明確な仕事を任せ、領域の専門家からフィードバックを受け、実際に解決した問題と成果の質を確認します。採用時の評価を入社後の成果と比較すれば、課題と面接で何を捉え、何を見落としたかも振り返れます。

---

結論

AI時代に採用したいのは、目的と文脈を理解し、問題を構造化し、AIに任せる仕事を決め、結果を検証して最後まで完遂する人です。これは優れたソフトウェアエンジニアに長く求めてきた能力でもあります。

AIによって個別の課題を作るコストが下がった今、会社はチームが実際に解いている問題を採用により近づけられます。応募者にはAIエージェントと課題を設計・遂行してもらい、会社はその過程を確認できる環境と記録を用意します。続く面接では提出したプロジェクトを中心に、選択の理由と新たな条件への対応を確認します。

会社全体が求める人物像は面接で、チームが必要とする実務能力はAIを使う課題で確認します。どの判断をより重視するかは会社と役割によって異なります。共通して必要なのは、応募者の言葉、行動、結果をつなげて見ることです。

「何を何年経験したか」に加えて、「この曖昧な問題を受け取ったら、何を最初に確認し、AIとどのような成果まで作れるか」を問うこと。 AI時代の採用戦略は、その問いから始められます。

---