コードが書けることは技術力なのか？ AI時代のエンジニア評価を研究から考える

はじめに

ある日のコードレビューで、ジュニアエンジニアが完璧なPRを出してきた。設計は適切で、エッジケースも網羅されていて、テストも充実している。

「すごく成長したな」と思いかけて、ふと気づく。これはこの人が書いたのか、AIが書いたのか、分からない。

そしてもっと厄介なことに気づく。仮にAIが書いたとして、このPRの品質が高いなら、それは問題なのか？

AI以前の世界では、コードの品質はエンジニアの技術力を映す鏡だった。良いコードを書ける人は技術力が高く、そうでない人は低い。シンプルな図式だ。しかしAIがコードを生成する時代に、この図式は崩れつつある。

本稿では、「技術力」とは何だったのかを改めて問い直し、AI時代に何を評価すべきかを考える。

1. これまでの「技術力」は何を測っていたのか

1.1 コーディング面接が測っていたもの

多くのテック企業が採用しているコーディング面接を例に考える。

ホワイトボードやオンラインエディタでアルゴリズムの問題を解く。制限時間内に正しい解を書けるか。計算量を最適化できるか。この形式が測っていたのは何だろう。

コーディング面接が測っていた（とされる）もの:
  - プログラミング言語の知識
  - アルゴリズムとデータ構造の理解
  - 制約下での問題解決能力
  - コードとして考えを表現する速度

しかしコーディング面接とストレスに関する研究は、ホワイトボード面接のパフォーマンスが問題解決能力よりもストレス耐性に左右されることを示した。面接で測っていたのは「面接問題を解く能力」であって、「ソフトウェアを作る能力」ではなかったのかもしれない。

AIの登場は、この曖昧さを一気に表面化させた。LeetCodeの問題はAIが瞬時に解ける。アルゴリズムの実装もAIがやる。すると、コーディング面接で測っていた能力の大部分が、AIで代替可能になった。

1.2 「書けること」が技術力だった時代

振り返ると、これまでの技術力評価は「コードを書く行為」に強く結びついていた。

評価の場面	測っていたもの
コーディング面接	制限時間内にコードを書けるか
コードレビュー	質の高いコードを書いているか
GitHub	どれだけコードを書いているか（コントリビューション）
技術ブログ	技術的な実装を言語化できるか
資格試験	技術知識を記憶しているか

これらの指標に共通するのは、「知識を持っていること」と「それを自力でコードにできること」を技術力と見なしている点だ。

AI以前は、これで概ねうまくいっていた。知識があり、それをコードに変換できる人は、実際に良いソフトウェアを作れる可能性が高かったからだ。しかし、AIがこの「知識→コード」の変換を高速に行えるようになった今、この等式は成り立たなくなっている。

2. AIが「技術力」の何を代替したのか

AIが代替した能力と、していない能力を整理する。

2.1 代替された領域

AIが得意なこと:
  - 定型的なコードの生成（CRUD、ボイラープレート）
  - 言語やフレームワークのAPI知識
  - アルゴリズムの実装
  - エラーメッセージからの原因特定
  - テストコードの生成
  - ドキュメント化

これらは従来「技術力が高い人」の特徴だった。API を暗記していて、パターンを知っていて、素早くコードに落とし込める。AI以前なら、これだけで十分に「できるエンジニア」だった。

2.2 代替されていない領域

一方で、AIが苦手とする領域がある。

AIが苦手なこと:
  - 曖昧なビジネス要件を技術要件に翻訳する
  - 複数の制約を同時に考慮したトレードオフ判断
  - 「何を作らないか」の決定
  - システム全体の整合性を保つアーキテクチャ設計
  - 組織のコンテキストを踏まえた技術選定
  - 障害発生時の優先順位判断
  - 技術的負債の「返済すべき順序」の判断

これらに共通するのは、正解が一つではない状況での判断だ。AIは「こう書けば動く」は得意だが、「この状況ではこう書くべきだ」の判断は、文脈依存の度合いが高すぎて難しい。

言い換えると、AIが代替したのは「実装力」（知識をコードに変換する能力）であり、代替していないのは「判断力」（曖昧な状況で何をすべきか決める能力）だ。しかし、従来の技術力評価はこの二つを区別してこなかった。

3. 「実装力」と「判断力」は別の能力である

3.1 専門技能の二層構造

認知科学では、専門家の能力は大きく二つの層に分けられることが知られている。

専門家のパフォーマンスに関する研究は、医師、チェスプレイヤー、プログラマーなどの専門家を分析し、専門技能が「ルーチン的専門性」と「適応的専門性」に分かれることを示した。

	ルーチン的専門性	適応的専門性
定義	既知の問題を効率的に解決する能力	未知の問題に既存知識を応用する能力
例	設計パターンの適用、API の使い方	新しいドメインの課題に適切なアーキテクチャを考える
学習方法	反復練習、暗記、パターンマッチング	多様な経験、失敗からの学び、異分野の知識の統合
AIによる代替	高い	低い

従来の技術力評価は、主にルーチン的専門性を測っていた。「このフレームワークを使えるか」「このアルゴリズムを知っているか」「このパターンで書けるか」。AIはまさにこのルーチン的専門性を代替した。

3.2 見えにくい「判断」の連続

コードを書く過程で、エンジニアは無数の判断を行っている。しかし、その判断はコードの成果物には表れにくい。

あるAPIエンドポイントの実装で起きている判断の連続:

1. エンドポイントのURL設計
   → RESTの慣例に従うか、フロントの使いやすさを優先するか

2. バリデーションの粒度
   → 厳密にやるか、MVP段階では緩くするか

3. エラーハンドリングの方針
   → 個別エラーを返すか、汎用エラーでまとめるか

4. パフォーマンスとリーダビリティのトレードオフ
   → N+1を今直すか、計測してから判断するか

5. テストの範囲
   → このケースはテストすべきか、過剰テストにならないか

これらの判断は最終的なコードからは見えない。完成したPRを見ても、「なぜこの設計にしたか」「何を検討して何を捨てたか」は分からない。

AIが出力するコードに欠けているのは、まさにこの「判断の履歴」だ。 AIは妥当なコードを出力するが、その背後にある「なぜそうしたか」の判断は持っていない。AIを使うエンジニアの技術力とは、AIの出力に対してこの判断を加える能力だとも言える。

4. 評価が難しくなった構造的な理由

なぜAI時代にエンジニアの評価が難しくなったのか。根本的な原因を整理する。

4.1 アウトプットから能力を推定できなくなった

従来の評価は、アウトプット（成果物）からインプット（能力）を逆算するという前提で成り立っていた。

AI以前:
  質の高いコード → この人は技術力が高い（妥当な推定）

AI以後:
  質の高いコード → この人が書いた？ AIが書いた？ AIに指示して書かせた？
                  → 技術力が高いのか分からない

業績評価に関する心理学研究では、人が他者を評価するとき、「プロセス（どうやったか）」ではなく「アウトカム（結果がどうだったか）」に偏る傾向があることが示されている。これを「アウトカムバイアス」と呼ぶ。

AIの登場は、このアウトカムバイアスの問題を深刻化させた。結果だけ見ても能力が分からないのに、人は結果で評価してしまう。

4.2 「速さ」が能力の指標にならなくなった

AI以前は、実装の速さは技術力の有力な代理指標だった。経験があり、パターンを知っていて、言語に精通しているエンジニアは速く書ける。

しかしAIを使えば、経験の浅いエンジニアでも高速に実装できる。速さという指標が、技術力と相関しなくなった。

AI以前:
  実装が速い ≒ 技術力が高い（概ね妥当）

AI以後:
  実装が速い = AIを上手く使っている？ 技術力が高い？ 判断を省いている？
             → 区別がつかない

4.3 「何を知っているか」より「何を判断できるか」

知識量による差別化も崩壊しつつある。

AI以前:
  「OAuth 2.0のPKCEフローの仕組みを説明できますか？」
  → 説明できる人 = 知識があり、技術力が高い

AI以後:
  → AIに聞けば3秒で説明が得られる
  → 知っているかどうかより、適切な場面で適用する判断ができるかが重要

知識経済と専門性に関する研究は、「何を知っているか（knowledge that）」と「何ができるか（knowledge how）」に加えて、「いつ・なぜそうすべきか（knowledge when/why）」という第三の知識層が専門家を特徴づけることを示している。

AIは「knowledge that」と「knowledge how」の大部分をカバーした。残されたのは「knowledge when/why」——いつ、なぜ、その判断をすべきかという文脈依存の知識だ。

「AIに聞けば分かること」は、もはや技術力の構成要素とは言いにくい。しかし、現在のほとんどの技術面接、評価制度、スキルマトリクスは、依然として「知っているか」「書けるか」を中心に設計されている。

5. AI時代に「技術力」として評価すべきもの

ここからは、何を技術力として評価すべきかを考える。

5.1 問題の発見と定義

AIは指示された問題を解くのは得意だが、何が問題かを見つけることはできない。

AIにできること:
  「このAPIのレスポンスを200ms以内にして」→ 最適化されたコードを生成

AIにできないこと:
  本番のメトリクスを見て「このエンドポイントだけ異常に遅い」と気づく
  → 原因がインデックスの欠如なのか、N+1なのか、外部API依存なのかを切り分ける
  → 今すぐ直すべきか、次のスプリントでいいか判断する

ソフトウェア開発において、問題を正しく定義することは、問題を解くことより難しい。デザイン思考の研究でも、多くのプロジェクトの失敗原因は「解き方が間違っていた」ではなく「問題の定義が間違っていた」ことだとされている。

5.2 トレードオフの判断と言語化

ソフトウェア設計は本質的にトレードオフの連続だ。そしてトレードオフには正解がない。

× 評価しにくい問いかけ:
  「マイクロサービスを設計できますか？」

○ 評価しやすい問いかけ:
  「現在の月間100万リクエストのモノリスを分割すべきか。
   チームは5人で、来年10人に増える予定。どう判断しますか？」

後者の問いに対する回答には、AIでは代替できない要素が含まれる。

• チーム規模と運用コストの考慮
• 現時点の複雑さと将来の複雑さのバランス
• 「今は分割しない」という判断も含めた選択肢の検討
• その判断の根拠の言語化

「なぜその判断をしたか」を説明できる能力は、AIが代替できない領域であり、かつチームへの知識共有に直結する。

5.3 AIの出力を評価・修正する能力

皮肉だが、AIの普及により「AIの出力を正しく評価する能力」が新しい技術力として浮上している。

AIが生成したコードに対して:

ジュニア:
  「動いたから大丈夫」→ そのままマージ

判断力のあるエンジニア:
  「動くけど、ここにレースコンディションがある」
  「このクエリ、データ量が増えたらフルスキャンになる」
  「エラーハンドリングが楽観的すぎる。本番のエッジケースを考慮していない」

これは「AIを使う能力」ではない。ソフトウェアが本番環境でどう振る舞うかを想像する能力だ。この想像力は、実際に本番障害を経験し、エッジケースに苦しみ、パフォーマンス問題をデバッグした経験の蓄積から生まれる。

AI時代の技術力とは、「AIなしでコードを書ける能力」ではなく、「AIの出力に対して正しいNoを言える能力」かもしれない。

5.4 システム全体を俯瞰する視点

AIは個々のファイルや関数のレベルでは優れたコードを生成する。しかし、システム全体の一貫性を保つのは苦手だ。

AIが見ている範囲:
  この関数、このファイル、このPR

エンジニアが見るべき範囲:
  この変更が他のサービスに与える影響
  デプロイ順序の依存関係
  既存のデータとの互換性
  障害時の影響範囲とフォールバック
  6ヶ月後にこのコードをメンテナンスする人の負担

ソフトウェアアーキテクチャの意思決定に関する研究は、経験豊富なアーキテクトの判断を分析し、彼らの能力の核心が「個々の技術要素の知識」ではなく「要素間の相互作用を予測する能力」であることを示した。

部分最適と全体最適の違いを理解し、システム全体の整合性を保てるかどうか。これはコードの表面からは見えないが、プロダクトの成否を分ける。

6. 評価制度をどう変えるか

6.1 プロセスを評価に組み込む

アウトプットだけでなく、判断のプロセスを評価対象にする。

従来の評価:
  「この四半期で何を作ったか」→ 機能リスト、PR数、コード量

AI時代の評価に加えるべき視点:
  「なぜその設計にしたか」→ ADR、設計ドキュメント、レビューコメント
  「何を作らない判断をしたか」→ スコープの交渉、技術的トレードオフの記録
  「チームの判断にどう貢献したか」→ 設計議論への参加、知識共有

ADR（Architecture Decision Record）をチームに導入している場合、その内容はエンジニアの判断力を評価する優れた材料になる。何を検討し、何を選び、なぜそうしたかが記録されているからだ。

6.2 「問い」で評価する

コーディング面接の代わりに、判断を問うシステムデザイン面接の比重を上げる。

従来のコーディング面接:
  「二分木を反転させてください」→ AIで瞬殺

判断を問う面接:
  「あなたのチームが運用している決済システムで、
   レスポンスタイムが徐々に悪化しています。
   どのようにアプローチしますか？」

  評価ポイント:
  - 何を最初に調べるか（問題の切り分け）
  - 仮説をいくつ立てられるか（経験に基づく想像力）
  - 短期的な対策と根本的な対策を区別しているか（判断の階層）
  - 「分からない」と言えるか（メタ認知、誠実さ）

この種の問いにはAIが直接答えることが難しい。なぜなら「正解」がなく、回答者のこれまでの経験と判断のフレームワークが問われるからだ。

6.3 チームへの影響を可視化する

個人の成果だけでなく、その人がいることでチーム全体がどう変わったかを評価する。

個人の成果（従来の評価）:
  - 実装した機能数
  - マージしたPR数
  - 解決したバグ数

チームへの影響（追加すべき評価）:
  - レビューで他のメンバーの設計判断を改善した回数
  - 障害対応でチームの学びにつながる振り返りをリードした回数
  - 新メンバーのオンボーディングに貢献した度合い
  - 技術的な意思決定でチームの合意形成をリードした回数

チームの知的資本に関する研究は、チームの成果を最も強く予測するのが「個人の能力の合計」ではなく「メンバー間の知識の流れの質」であることを示している。つまり、チーム全体の能力を底上げできる人は、個人として優れたコードを書く人以上に価値がある。

AI時代のエンジニアの価値は、「自分が何を作ったか」だけでなく、「自分がいることでチームが何を作れるようになったか」に移行していく。

7. 評価する側にも知識の呪いがかかっている

最後に、評価者自身の問題にも触れたい。

エンジニアリングマネージャーやテックリードの多くは、AI以前の時代にキャリアを積んできた。自分自身が「コードを書く能力」で評価され、それを磨いてきた。

このキャリア経験が、知識の呪いとして作用する。自分が「技術力」だと感じるものの基準が、AI以前の世界に固定されている。

評価者の無意識のバイアス:
  「あの人はAIに頼りすぎている」
  →「自力で書けないのは技術力が低い」という暗黙の前提
  → しかし、AIを使って高品質なアウトプットを出せるなら、
    それは新しい形の技術力ではないか？

  「この人は手が遅い」
  → コードの出力量が少ない = 生産性が低いという暗黙の前提
  → しかし、設計判断に時間をかけて手戻りを防いでいるなら、
    チーム全体の生産性には貢献しているのではないか？

評価基準を変えるには、まず評価する側が自分の「技術力」の定義を問い直すことから始めるしかない。

8. おわりに ― 技術力の定義が変わるとき

AIはエンジニアの仕事を奪ったのではない。「技術力」の定義を変えたのだ。

「知識をコードに変換する能力」は、長い間技術力の中核だった。しかしAIがその変換を高速に行えるようになった今、技術力の重心は移動している。

• 何が問題かを見つける力
• 正解がない状況でトレードオフを判断する力
• AIの出力に対して正しいNoを言える力
• システム全体を俯瞰して整合性を保つ力
• チームの判断の質を底上げする力

これらはいずれも、コードの表面からは見えにくい。だからこそ評価が難しい。しかし、見えにくいからこそ、意識的に評価の仕組みを設計する必要がある。

「AIを使えるか」を技術力として加えるのではない。AIが当たり前に使える時代に、AIにはできない判断をどれだけ質高くできるか。それが、これからの技術力の核になっていくのだと思う。

参考文献

• Behroozi, M., et al. (2020). "Does Stress Impact Technical Interview Performance?" ESEC/FSE 2020. ホワイトボード面接のパフォーマンスが問題解決能力よりストレス耐性に左右されることを示した研究。
• Hatano, G., & Inagaki, K. (1986). "Two Courses of Expertise." Child Development and Education in Japan, 262-272.
• Baron, J., & Hershey, J. C. (1988). "Outcome Bias in Decision Evaluation." Journal of Personality and Social Psychology, 54(4), 569-579.
• Mylopoulos, M., & Regehr, G. (2007). "Cognitive Metaphors of Expertise and Knowledge." Medical Education, 41(12), 1159-1165.
• Spear, S. J. (2012). "Are You Solving the Right Problem?" Harvard Business Review.
• Kruchten, P., Lago, P., & van Vliet, H. (2009). "Building Up and Reasoning About Architectural Knowledge." Proceedings of the Second International Conference on Quality of Software Architectures (QoSA).
• Reagans, R., & Zuckerman, E. W. (2001). "Networks, Diversity, and Productivity: The Social Capital of Corporate R&D Teams." Organization Science, 12(4), 502-517.
• Camerer, C., Loewenstein, G., & Weber, M. (1989). "The Curse of Knowledge in Economic Settings." Journal of Political Economy, 97(5), 1232-1254.
• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.