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

Sat, 03 Oct 2026 10:00:00 +0900

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

チョン・ドヒョン - ROBOCO首席コンサルタント

最近、同僚とバイブコーディング導入後の実務担当者の生産性に差を生む要因について話しました。同じ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エージェントにも同じ制限を適用します。誤った選択を修正する過程は、新しい記録として残ります。

Software-Engineering on ROBOCO