前回書いた「エラーを3秒でAIに丸投げする若手を見て、AIから答えを取り上げることにした」が、思っていたよりずっと多くの人に読まれました。コメントもはてなブックマークのコメント（100件以上ありました）もひととおり読みました。ありがとうございます。（賛否両方あって、読んでいて結構しんどい日もありましたｗ）

前回はハッカソンで作ったSocraMetryの紹介記事でしたが、個人的に一番書きたかったのは、実は冒頭の「評価面談でメンバーの実力を語ろうとしたら、材料が印象しかなかった」という部分でした。SocraMetryはそれに対する「測る側」の道具として作ったものです。

ただ、コメントを読んでいるうちに、そもそも私の問いの立て方がちょっとズレていたんじゃないかと思うようになったので、今回はその続きを書きます。上長として、AI時代にエンジニアの何を評価すればいいのか、という話です。

コメントを読んで気づいたこと

前回いただいた反論を、ざっくりまとめると3つくらいに分かれていました。

ググってコピペしてたのと何が違うの？
抽象化の流れは止まらない。車の仕組みを知らなくても運転はできる
今はエージェントがエラーを検知して勝手に直すので、そもそも貼り付けすらしていない

3つ目は正直痛かったです。前回は「若手がエラーをAIに貼る」ところから話を始めたのですが、公開して3か月で、その場面自体がもう古くなりつつあります。エージェントが勝手に直す世界だと、「エラーを読めるか」の前に「エージェントが何をどう直したのか読めるか」の方が先に来そうです。

一方で、賛成とも反対とも言いにくいコメントがいくつかあって、こちらの方が考えさせられました。

AIはあくまでアドバイザーで、回答をそのままコピペするのは責任をAIに移しているだけじゃないか
エージェントに任せるほど、最後に判断する側の感覚をどう保つかが課題になる
AIにどこまで任せるか、リスクをどこまで許容するかは、個人じゃなくて会社が決めることでは
答えの代わりに問いが返ってくるなら、人間の仕事は何になるのか

並べてみると、どれも「AIが出したものに、誰が責任を持つのか」の話をしているように見えました。

車の例えは私も好きで、たしかに仕組みを知らなくても運転はできます。ただ、事故ったときの責任は運転した人にあるので、だから免許があって、何をどこまで引き受けているか分かった上で乗ることになっている。抽象化は止まらないと思いますが、責任の方は抽象化されないんじゃないかと思います。

前回の問いは「AI時代にもデバッグ力は要るのか」でした。要るとは今でも思っていますが、問いとしては狭かったです。今は「AIの出力に、誰が名前を書くのか」の方が、評価する側としてはしっくりきています。

上長側で何が起きていたか

評価する側の話を正直に書きます。成果物の大半がAI経由になって、今まで何となく使っていた評価の材料が、ほとんど使えなくなりました。

まずコード量やPR数。AIを使えば誰でも増えます。試しに自分のチームの変更行数を分解してみたら、ある月は変更行の大半が、テスト用に入れたサンプルデータと、ツールが自動生成する定義ファイルでした。これで人を測るのは、タイピング数で測るのとあまり変わらないと思います。はてブで「評価のための枷ならタイピング数でも同じ」と書かれていて、その通りだなと。

次に「難しい問題を解いた」という実績。解いたのがAIなのか本人なのか、PRを見ても分からないです。

本人の自己申告も怪しいです。METRが2025年にやった実験で、経験のあるOSS開発者にAIを使ってもらったら作業が19%遅くなったのに、本人たちは20%速くなったと感じていた、という結果がありました。体感と実測で40ポイントずれています。嘘をついているわけじゃなくて、人はAIの効果を自分では測れないっぽい、という話だと思っています。（METR自身がその後の追跡で「今はたぶん速くなっているけど、ちゃんと測れていない」と言っているので、19%という数字自体は古くなっているかもしれません）

これは自分のチームでも似たことを感じていて、開発プロセスの計測ツールで見るとPRの数もコードの量もはっきり増えているのに、それに見合うだけ生産性が上がったという実感は正直薄いです。数字は増えている、本人も速くなったと言っている、でもリリースされる価値がそれだけ増えたかというと、そこまでではない。

なので面談で「AIでだいぶ速くなりました」と言われても、額面通りには受け取れなくなりました。

で、残るのは印象だけ、というのが前回の冒頭です。

もうひとつ、重なってくる話があります。Stanfordの「Canaries in the Coal Mine?」という論文で、米国でAIの影響を受けやすい職種の22〜25歳の雇用が、同年代の他職種より19%くらい低い水準になっていて、原因は解雇より採用の減少だ、という結果が出ています。

つまり、若手を育てないことが合理的に見える状況になってきています。その中で評価軸を持っていない上長は、若手を「評価できない人」のまま置いておくことになる。これって育てていないのと一緒だよな、と思いました。

じゃあ何を見るのか

前回はAIから「答え」を取り上げました。今回は、評価から「コード」を取り上げてみようと思っています。

コードはAIが書くので、「何を書いたか」で人を見るのはやめます。じゃあ何を見るかというと、AIを使うのは前提で、しかもそのAIがまだまだ進化していく、という条件で考えると、端的には次の3つかなと思っています。

先に書いておくと、どれも今までエンジニアがやってきたことで、新しい能力ではないです。ただ、今まではコードを書くことが評価の主役で、この3つは付け足しのように見ていました。コードをAIが書くようになって、付け足しだったものが主役に回ってきた。新しい軸というより、見方が変わった、という話です。

変わっていく状況についていく力

AIのモデルもツールも数か月単位で変わるので、去年の正解が今年は違う、ということが普通に起きます。新しいやり方を試して、合わなければ捨てて、自分のやり方を更新し続けられるか。

それと、ついていくというのは鵜呑みにすることではないので、AIの出力のおかしいところに気づいて止められるか、もここに入ります。松尾研究所のテックブログに「AIコーディングではコードではなく検証プロセスをレビューする」という記事があって、AIだけで作った60時間動くバッチが後半でメモリ不足で落ちた話が出てくるのですが、それを見つけたのは人です。前回書いたデバッグ力の話は、この力の一部だったんだと思います。

DBスキーマ、認証、決済、インフラ定義のような「ここは人が必ず見る」と決めている領域を任せられるかどうかも、結局はここで決まります。

良かったことを他のメンバーに広める力

うまくいったプロンプト、エージェントの設定、レビューの観点、Issueの書き方。自分の中で良かったことを、他のメンバーが使える形にして広められるか。

一人で速くなるのはAIがやってくれるので、一人で10倍速く書く人より、チーム全員を1.5倍にした人を高く見たいと思っています。Zennの「生成AI時代にITエンジニアに求められているのはレビュー能力ではない」という記事が、本体はAIに正しい文脈を渡す能力だと書いていますが、その文脈を自分だけでなくチームに渡せるか、という話でもあります。

仕組みを作る力

個人の工夫で終わらせずに、テスト、手順、自動化、レビューのガードレールのように、自分がいなくても回る形にできるか。

「AIの間違いを止めた」みたいな実績は、エンジニアの仕事の中でかなり価値があるのに、止めたら何も起きないので一番記録に残らないんですよね。なのでレビューコメントの分類とか検証ログとか、止めた記録が残る仕組みを作ること自体も、この力に入ると思っています。

この3つに共通しているのは、AIの出力に自分の名前を書ける範囲をどれだけ広げたか、です。スキルの高さというより、引き受けている範囲の広さの話で、シニアとジュニアの差はここが一番素直に出る気がしています。

逆に、見ないと決めたもの

行数、PR数、AIツールの利用率、ツールの課金額。これはAI導入がどれくらい進んだかの指標で、人の評価ではないので、チームのKPIとしては見るけど、個人の面談には持ち込まないことにしました。

「感情的な誘因には勝てない」という指摘について

前回のコメントで一番重かったのがこれでした。要約すると、

AIへのコピペは「すぐ解決した」という快感に動かされている。将来の能力向上みたいな論理的なメリットは、感情的な誘因には勝てない。SocraMetryを入れても、禁止すれば私物のAIが使われるだけで、しかもそれは観測できない。

これはその通りだと思います。前回の仕組みは、最後のところで本人の意志に賭けていました。

なので今回の答えは、意志じゃなくて評価の向きを変える、です。評価が「速く解決した」に払っている限り、丸投げは合理的な行動です。「おかしいところに気づいて止めた」「チームに広めた」「仕組みにした」に払うようになれば、AIの出力を理解しておく方が合理的になる。人は論理より感情で動くと思いますが、感情は報酬の向きには結構従うと思っています。

ここで一つ分けておきたいのですが、「使い方は本人に任せる」のは、会社が許可したAIの範囲内での話です。業務のエラーやコードを私物のAIに貼るのは、評価以前にセキュリティとガバナンスの問題なので、そこは禁止でいいと思っています。（前回の記事でマスキングやログの話を長々と書いたのも、業務のテキストを預かる以上そこは外せないからでした）

「禁止すれば私物AIに流れる」という指摘は、禁止が悪いというより、許可されたツールが使いにくいか、許可されたツールを使っても評価上の得がない、という状態を指しているんだと思います。なので対策は、承認済みのツールを十分使いやすくしておくことと、その上でどう使ったか（任せたのか、理解しながら使ったのか）は本人に任せて、評価は引き受けた結果で見る、という組み合わせになります。

ここで、Anthropicが今年の1月に出した研究が参考になりました（How AI assistance impacts the formation of coding skills）。若手中心の開発者52名に未経験のライブラリで実装してもらって、AIあり／なしで比較した実験です。

事後クイズの得点はAIあり群が50%、なし群が67%
一番差がついたのはデバッグの設問
AIに全部任せた人は最速で終わったけど、エラーに一度も遭遇していないので学ぶ機会がなかった
逆に、概念的な質問だけしてコードは自分で書いた人は、エラーは多かったけど自力で解決していて、点数も高くて速かった

「AIを使うと学ばない」というより、「どういう使い方をしたかで学びが決まる」という結果だと読みました。委任モードと学習モードがあって、納期前は委任、余裕があるときは学習、と切り替えるのは健全だと思います。問題は本人が今どっちのモードにいるか自覚していないことと、上長がそれを区別せずに評価していることの方かなと。

前回のSocraMetryは学習モード用の道具で、今回の評価軸は委任モードの結果に責任を持ってもらう仕組み。両方要るんだと思います。

「会社によって違う。エンジニアで一括りにするな」という指摘について

前回の記事に最近付いたコメントが、こういう内容でした。

言語そのものを作るような業界なら、AIのコピペ実装は原理を理解していないことになる。でも配られたパッチを当てるだけの会社に、そこまで求める必要はない。AIの使い方とリスク許容は企業が決めること。「エンジニア」で一括りにするから議論が混乱する。

これも完全にその通りで、前回の記事への批判としては一番正確だったと思います。

上の3つは普遍的な指標ではなくて、会社がまず「AIに任せる範囲」と「人が責任を負う範囲」を決めた後じゃないと機能しません。言語を作る会社とパッチを当てる会社では、人に残す責任が違うので、「ついていく」「広める」「仕組みにする」の中身も変わります。

評価制度で最初にやることは、評価軸を作ることじゃなくて、上長が「うちは何を人に残すか」を文章にすることだったんだなと。これをしないまま「デバッグ力」を測ろうとしていたのが、前回の私の順番の間違いだったと思います。

前回の結論が「AIに何をさせないかを設計する」だったので、今回はその裏返しで「人に何を残すかを文章にする」になりました。

これからのエンジニアの価値について

「AIを使える」はもう価値にならないと思っています。GitHubのOctoverse 2025では、新規の開発者の8割近くが最初の週からCopilotを使っているそうです。米国のPythonコードのうちAIが書いた割合が2022年の5%から2025年初めには29%まで来た、というScience誌の研究もあります。全員が使っているものでは差がつかないので。

今のところの私の定義はこうです。

エンジニアの価値＝ AIの出力に自分の名前を書ける範囲 × それをチームに広げて仕組みにできる力

前者が責任で、後者がチームへの影響です。AIは責任を取れないですし、チームの中で何を広めて何を仕組みにするかを決めるのもAIではないので、どちらもAIに代わってもらえない部分だと思っています。

若手の人には、採用の門が狭くなっているのは事実として、「育てない会社」が増えるほど、自分で育つ経路を持っている人の希少性は上がる、とは言いたいです。Anthropicの研究を見る限り、ポイントはAIを使わないことじゃなくて、エラーに遭遇するのを避けないことっぽいので、委任モードで終わった仕事を1つでも学習モードで読み直してみるのがいいんじゃないかと思います。

シニアの人は、自分の体感をあまり信用しない方がよさそうです。METRの被験者も熟練者でしたが40ポイントずれていたので。あと「止めた」ものは記録に残しておいてほしいです。それが価値の証拠になるし、若手が学ぶ教材にもなるので。

上長（私も含めて）は、印象で評価していることをまず認めるところからかなと。3つのうち1つでいいので来期の目標に文章で入れる。その前に「うちは何を人に残すか」を書く。私もまだ途中です。

あとがき

前回は「AIに何をさせないか」を構造で実装した話でしたが、今回は同じ問いが組織側にもあった、という話でした。「AIに何をさせないか」と「人に何を残すか」は、同じ問いの裏表だったんだと思います。

ちなみに、私は専門学校で臨時講師もしているのですが、学生に関しては別の話だと思っています。ここまで書いたのは、すでに仕事としてエンジニアリングをしている人をどう評価するかの話で、「コードを書くことやエンジニアリングを学ばなくていい」という意味ではないです。むしろ逆で、AIの出力のおかしいところに気づくには、自分で書いて、エラーを出して、直した経験がないと無理だと思っています。Anthropicの研究でも、学んでいる途中の人がAIに全部任せると一番身につかない、という結果でした。学生のうちは全部学習モードでいいと思っていて、AIを使うのは働き始めてからいくらでもできるので、今は自分の手でエラーを出しておいてほしい、と授業では言っています。

もう一つ、今回は書ききれなかった話があります。AIで同じ人数でできることが増えるということは、エンジニアがより少ない人数で回せるようになる、ということでもあります。なので上長としては、浮いた時間をコードを書く量に戻すんじゃなくて、エンジニアリング以外のところに向けてもらうように、意識して誘導しています。業務の理解、企画の段階から入ること、お客さんと直接話すこと。AIに正しい文脈を渡すには結局そういう理解が要るので、3つの力の話ともつながっています。実際にどう振って、メンバーがどう変わったかは、まだ整理できていないので、次の記事で書きたいと思います。

評価のやり方はまだ試行中なので、うまくいかなかったらまた書きます。同じようにチームを見る立場の人は、自分のチームで誰が何を止めて、何を広めたかを語れるか、一度考えてみてもらえればと思います。同じことで悩んでいる人がいたら、コメントで教えてもらえると嬉しいです。