岩瀬義昌氏の議論が示すAI時代のエンジニア評価基準。コードより「問いの質」で部下を評価する3つの方法
岩瀬義昌氏らが指摘するように、AI時代のエンジニアに求められるスキルセットが根本から変わった。これは、もはや単なる技術トレンドの話ではない。McKinseyの調査によれば、生成AIはソフトウェア開発のタスクを最大2倍の速度で完了させる。この**「生産性の爆発」は、エンジニアを評価する側の管理職に、評価軸そのものの変更を突きつける最後通牒**だ。
📡 本日の観測ニュース
AI時代に磨くべきスキルの正体とは？ 再定義されるエンジニアの価値【岩瀬義昌、河野太郎、伊藤淳一、濱崎竜太】 - type転職サイト
この変化は、エンジニア本人だけの問題ではない。むしろ、彼らを評価し、導く立場の管理職にとって、自らの存在価値が根底から覆される事態を意味する。あなたの部下であるエンジニアの価値が「どれだけ速く、多くのコードを書けるか」から「どれだけ的確な『問い』をAIに投げかけ、ビジネス価値を生み出せるか」に移行したとき、あなたは彼らを正しく評価できるだろうか。
想像してほしい。月曜の朝の定例会議。2年目の若手エンジニアが、週末にAIを使って作ったという完璧なAPI仕様書とプロトタイプを画面に映し出す。「これで来週から実装に入れます」。一方、隣に座る15年目のベテランは、従来の手法で堅実に進めているが、進捗はまだ設計ドキュメントのレビュー段階だ。このとき、管理職であるあなたは、どちらの「生産性」を評価するのか。目に見えるアウトプットの速さだけで若手を称賛し、ベテランの慎重さを「時代遅れ」と断じてしまうのか。
この判断を誤る管理職は、確実に淘汰される。なぜなら、AI時代に価値が下がる管理職と上がる管理職の分岐点は、まさにここにあるからだ。
-
価値が下がる管理職（Before）: 部下のコミット数、消化したチケット数、書いたコードの行数といった**目に見える「作業量」**で評価を下す。AIが生成したコードと人間が書いたコードの区別もつかず、ただ「速い」ことだけを称賛する。
-
価値が上がる管理職（After）: 部下がAIに対して立てた「問い」の質、それによって解決されたビジネス課題の大きさ、生成されたアウトプットの裏にある思考の深さといった、**目に見えない「思考の質」**を評価する。
この変化の核心は、評価軸が「コードの生産性」から「問いの生産性」へ移行することにある。もはや管理職の仕事は、マイクロマネジメントで進捗を監視することではない。チームの知性を結集し、より質の高い「問い」を生み出すための環境を設計することだ。
そのための具体的なプロトコルを3つ提示する。だがその前に、一つだけ警告しておく。あなたが今、良かれと思って続けている「1on1での進捗確認」こそが、チームの創造性を殺し、あなた自身を「不要な調整役」へと追いやる最大の罠かもしれない。
ここからは、あなたの評価軸を21世紀型にアップデートし、「問いの生産性」でチームを率いるための3つの具体的な行動プロトコルを開示する。
1. 評価を「What」から「Why」へ
まず捨てるべきは「進捗どう？」という問いだ。この問いは、部下に「作業の完了」だけを意識させ、思考停止を招く。これからは、コードレビューや1on1の場で、徹底して「Why」を問うのだ。
- 「この機能、どの顧客のどのペインを解決するために作ろうと思ったんだっけ？」
- 「このAIが出したコード、たしかに動くけど、3ヶ月後の保守性は考えられている？」
- 「このプロンプトで、他にどんなビジネス課題が解決できそうか、3つアイデアを出してみて」
多くの上司が陥る罠は、部下のアウトプットに対して「良い/悪い」のジャッジをしてしまうことだ。そうではない。あなたの役割はジャッジではなく、部下の思考を深掘りする「触媒」になることだ。部下がAIの出力結果をそのまま持ってきたとき、「ありがとう。で、君はこの結果のどこが優れていて、どこにリスクがあると思う？」と問い返す。この一言が、部下を単なる「AIオペレーター」から「思考するエンジニア」へと変える。
この対話を実践するために、あなたのカレンダーに入っている「週次進捗確認MTG」の名称を、今日、「週次壁打ちMTG」に変更せよ。アジェンダも「各担当者の進捗報告」から「今週、最も悩んでいる課題1つ」に変える。これだけで、チームの会話の質は劇的に変わるだろう。
2.「AI試行回数」を評価する
次に、チームの評価指標（KPI）に「AI試行回数」を組み込む。これは、成功したアウトプットだけを評価する旧来の成果主義からの脱却を意味する。
多くのチームでは、失敗は評価を下げる要因となる。その結果、エンジニアはリスクを恐れ、使い慣れたツールや手法に固執する。これではAI活用の知見は一向に溜まらない。そこで、評価の概念を逆転させるのだ。「どれだけ賢い失敗をしたか」を称賛する。
- 具体的なアクション:
- チームの目標に「新しいAIツール/プロンプトを各自が週に3回以上試す」という行動目標を設定する。
- 週次定例で「今週のベスト失敗賞」を設け、最も学びの多い試行錯誤を共有したメンバーを表彰する。
- 共有される失敗は「コスト」ではなく、未来の成功確率を上げるための「投資」であると明言する。失敗ログは、チームにとっての「宝の地図」なのだ。どこに落とし穴があるかを示してくれる、極めて価値の高い情報資産なのである。
このアプローチは、心理的安全性を確保し、チーム全体でAIという未知の領域を探検する文化を醸成する。管理職であるあなたの仕事は、完璧な結果を求めることではなく、チームが安全に実験できる「実験場」を提供することに変わる。
3.「問いのライブラリ」を育てる
最後のプロトコルは、個人の閃きをチームの永続的な資産に変える仕組みの構築だ。それが「問いのライブラリ」である。優れたプロンプト、的確な課題設定は、一度使って終わりにするにはあまりに惜しい知的財産だ。
- 具体的な構築手順:
- 場所の確保: 今すぐ、チームで使っているNotionやConfluenceに「AI Prompt Library」という名のページを1つ作成する。（所要時間: 1分）
- フォーマットの定義: 以下のシンプルなテンプレートをページに貼り付ける。これを埋めることをチームのルールとする。
【課題】: (例: 既存のJavaコードをPythonにリファクタリングしたい)【試したプロンプト】: (例: #Role: ... #Instruction: ...)【得られた結果】: (例: ほぼ完璧なコードが出力されたが、特定のライブラリの互換性でエラーが出た)【考察・改善点】: (例: 事前に使用ライブラリのバージョンを明記すればエラーは防げたはず)
- 運用の定着: 週次定例で、このライブラリに新たに追加された「問い」を1つ取り上げ、貢献者を称賛する。ライブラリを引用・改善して新たな成果を出したメンバーは、さらに高く評価する。
- 評価への反映: 四半期ごとの評価面談で、このライブラリへの貢献度（量と質）を正式な評価項目の一つとして話し合う。
このライブラリは、単なるコピペ集ではない。チームの集合知が進化していく過程を可視化した「生きたドキュメント」だ。新メンバーはこれを見れば即座にチームのノウハウを吸収でき、ベテランは自らの知見を形式知化することで、新たな貢献ができる。あなたの仕事は、この「知の循環システム」を設計し、維持する庭師になることだ。
【AI-NATIVE CAREERからの実践課題】 次の1on1で、部下にこの質問を投げかけてみよ。「もしAIを、君専用の超優秀な新入社員として一人タダで雇えるとしたら、どんなビジネス課題を解決させたい？そのための最初の業務指示書（プロンプトの骨子）を、今ここで3行で書いてみてほしい。」この問いへの答えにこそ、そのエンジニアの未来の価値が凝縮されている。
コードの行数を数えるのをやめ、部下が立てる問いの鋭さを測れ。それができなければ、管理職であるあなた自身が、次に評価され、最適化される対象となる。—— AI-NATIVE CAREER
💭 あなたのチームでは、AIを使いこなす部下と、従来の手法にこだわる部下の間で、すでに生産性の差は生まれているだろうか。
AI時代の管理職向け 有料記事
AI-NATIVE CAREERでは、管理職がAI時代を生き残るための具体的な行動プロトコル・テンプレート・チェックリストを有料記事で公開しています。
本記事はAI-NATIVE CAREER編集部が最新ニュースを基に作成しました。掲載情報の正確性については各一次情報源をご確認ください。