AI時代のエンジニアに必要なパラダイムシフト－自己否定の先にあるもの

小西秀和です。
私はこれまで、設計に多くの時間をかけて熟考し、コードの品質にこだわり、それらを支える技術的な知識を深く積み上げることに情熱を燃やしてきました。そして、AWSの全認定資格を取得し、Japan AWS Top Engineerにも選出していただきました。知識と技術の蓄積こそが自分の価値だと信じていました。しかし、つい最近、その価値観を自己否定することにしました。

この記事では、AI時代にエンジニアが何に価値を置くべきか、何を手放し何を磨くべきかについて、私自身の経験と考察をまとめています。これは特定の誰かに向けた教訓めいた話ではなく、私自身が直面したパラダイムシフトの記録です。同じような葛藤を抱えているエンジニアの方にとって、何かしらの参考になれば幸いです。

1. 価値を失いつつあるもの－「知っている」ことの意味が変わる

「知っている」こと自体の価値が、急速に薄れてきていると感じています。

フレームワークの使い方を知っている
設計パターンを知っている
特定言語に精通している
ベストプラクティスをドキュメント化できる

これらはすべて、AIが即座に再現できるようになりました。知識の蓄積量で勝負する時代は、終わりに近づいているのではないでしょうか。

なぜそう考えるようになったのか

10年前、Stack Overflowの回答を暗記している人が重宝された時代がありました。5年前にはそれが「ググれば分かることを覚える意味はない」に変わりました。そして今、AIはググるどころか、質問の意図を理解し、コンテキストに合った回答をコードごと生成してくれます。

具体的に振り返ってみます。

設計・アーキテクチャの知識：「このAPIはRESTよりGraphQLで設計すべきです」「この処理はサーバーサイドに寄せるべきです」と判断できることに、かつては大きな価値がありました。しかし今では、AIに要件を伝えれば、適切なアーキテクチャを選択した上で実装まで完了してくれます。設計の引き出しを多く持っていること自体の価値は、以前とは比べものにならないほど小さくなっています。

言語・フレームワークへの精通 ：「Pythonのasyncioの挙動を深く理解している」「Reactのレンダリングサイクルを完全に把握している」。こうした知識はAIが広範に持っています。しかも、人間が一つずつドキュメントを読んで覚えるより遥かに速く、関連情報を横断的に引き出せます。

ビッグテックのCEOたちの発言

これは私個人の感想だけではありません。ビッグテックのCEOたちが次々と「AIがコードの大部分を書く時代が来ている」と公言しています。Google CEOのSundar Pichaiは2024年10月の決算報告で、Googleの新規コードの25%以上がAI生成であると発言しました(※1)。MetaのMark Zuckerbergは2025年1月、「2025年中にミッドレベルエンジニアの仕事をAIが代替し始める」と予測しました(※2)。Anthropic CEOのDario Amodeiは2025年3月に「3〜6ヶ月以内にAIがコードの90%を書くようになる」と予測し(※3)、同年10月にはAnthropic社内でそれが実現していると述べました(※4)。

これは未来の話ではなく、ここ数年の動きを踏まえれば、すでに現実として進んできたことだと受け止めています。

［出典］

私自身が陥った思考パターン

私自身が陥った思考パターンを正直に書きます。それは 「自分の方がうまく書ける、だから自分で書くべきだ」 という思考です。

AWSの全認定資格を取得し、6年連続でTop Engineerに選出されてきた自分にとって、「知識の蓄積量が自分の価値だ」という信念は非常に強固なものでした。「AIが書くコードは平凡だ。自分ならもっと洗練されたコードを書ける」。AIの登場初期に感じていたこの感覚は、おそらく間違っていなかったと思います。しかし、「自分の方がうまく書ける」という事実があっても、そのことがそのまま「だから自分で書くべきだ」という結論にはつながりません。

丁寧に磨き上げたコードを1時間かけて書く代わりに、AIに30秒で書かせてレビューと改善に集中する。浮いた時間で次の課題にも取り組める。結果として、同じ時間でのアウトプットの質も量も格段に高くなると実感しています。この気づきが、私にとっては大きな転換点でした。

2. 価値が残る、あるいは増していくもの

では、価値が薄れていくものがある中で、何が残るのか。私はこれを、単なるスキルの入れ替えではなく、エンジニアの価値の定義そのものが変わるパラダイムシフトだと考えています。

	従来のパラダイム	新しいパラダイム
価値の源泉	技術力（書く・知る・解く）	課題設定力・判断力・実行力（定義する・見抜く・届ける）
エンジニアの役割	手を動かす職人	AIを指揮して実現する人
評価の尺度	どれだけ良いコードを書けるか	どれだけ大きな課題を解決できるか

従来の延長線上にはこの転換はありません。だからこそ「自己否定」が必要になるのだと、私は感じています。

では、新しいパラダイムにおいて価値が増していくものは何か。私なりに整理すると、大きく3つの力に集約されます。

課題設定力 ：何を作るべきかを定義する力
判断力 ：AIの出力の良し悪しを見抜く力
実行力 ：実現してユーザーに届けきる力

それぞれ詳しく書いていきます。

2-1. 課題設定力－問いを立てる力

AIは「これを作って」と言えば作ってくれます。しかし 「何を作るべきか」は、AIには決められません。

この事業の本当の課題は何か
ユーザーが本当に困っていることは何か
技術的に可能なことのうち、今やる意味があるのはどれか

これは現場を知り、人と話し、判断する人間にしかできないことです。そしてこの問いの質が、AIの出力の質を決定します。

なぜ「問い」がこれほど重要なのか

AIの出力品質は、入力の品質に完全に依存します。同じ機能を作るにしても、以下の二つの指示では結果が全く異なります。

指示A ：「ユーザー管理画面を作って」

指示B ：「月間アクティブユーザー5000人規模のSaaSで、カスタマーサクセスチームが解約リスクの高いユーザーを素早く特定するためのダッシュボードを作って。直近30日のログイン頻度、主要機能の利用率、サポート問い合わせ回数をもとにヘルススコアを算出し、スコアが低い順にソートして表示する」

指示Bを出せる人は、事業を理解し、ユーザーの課題を把握し、何が本質的に必要かを判断しています。この「課題設定力」は、技術知識とは全く別の能力であり、AIには代替できないものだと感じています。

課題設定力を高めるために

私自身が意識していることを挙げてみます。

ドメイン知識の深さ ：事業領域を深く理解していなければ、本質的な問いは立てられません
ユーザーとの接点 ：実際のユーザーの声、行動、不満を知っていること
技術的な実現可能性の感覚 ：何ができて何ができないかを大まかに把握していること（詳細はAIが埋めてくれます）
課題の構造化能力 ：漠然とした問題を、解決可能な単位に分解する力

2-2. 判断力－ AIの出力の良し悪しを見抜く目

AIは100点の出力も出せば、一見もっともらしいが致命的に間違った出力も出します。その差を見抜く目は、むしろ従来のエンジニア経験があるからこそ持てるものだと思います。

人間が観察し、AIに問う

スケーラビリティやセキュリティの検証、エッジケースの洗い出し、パフォーマンス分析。これらはAIに聞けば高い精度で答えてくれます。しかし、何を確認すべきかに気づくのは人間の役割です。

本番環境で過去に起きた障害のパターンを知っているからこそ、「この設計で同じ問題が起きないか？」とAIに問える
ユーザーの実際の使い方を観察してきたからこそ、「この画面遷移は本当に自然か？」という違和感に気づける
ステークホルダーとの会話から感じた温度感があるからこそ、「この仕様で本当に合意が取れるか？」と立ち止まれる

過去のプロジェクトで痛い目に遭った経験、ユーザーの行動を観察してきた知見。こうした蓄積があるからこそ、AIに対して正しい問いを立てられるのではないでしょうか。

判断力の活かし方

ここで大切なのは、判断力の使いどころです。判断力はレビューと方向修正に使うものであって、自分の手を動かす理由にしてしまうと、かえって生産性が下がってしまいます。

映画監督は自ら演技をしません。しかしその判断力がなければ、映画は成り立ちません。エンジニアの判断力も同じだと思うのです。AIの出力に不満を感じたとき、自分で書き直すのではなく、方向修正のフィードバックとしてAIに返す。その繰り返しの中でこそ、判断力は最大限に活きるのではないでしょうか。

2-3. 実行力－実現してユーザーに届けきる力

コードが書けること自体の価値は変わりつつありますが、実際にサービスとして動かし、ユーザーの手に届けるところは依然として泥臭く、人間の仕事です。

インフラを構成し、運用する
ステークホルダーと合意を形成する
障害時に判断して対応する
ユーザーのフィードバックを受けて方向転換する

ここには人間の意思と感情が伴います。AIを最大限に活用する前提であっても、人間にしか担えない実行力があります。

実行力の具体的な中身

粘り強くやり抜く力

うまくいかない状況でも諦めず、AIを活用しながら試行錯誤を繰り返し、成果が出るまで挑戦し続ける
想定外の障害や仕様変更に直面しても、柔軟に方向転換しながら前に進み続ける
「もう少しで届く」という最後の一歩を、泥臭くやりきる

人の感情を汲み取る力

ステークホルダーの曖昧な不満や言語化されていない期待を読み取り、本当に求めているものを引き出す
ステークホルダー間の利害や温度差を察知し、合意形成を導く
チームメンバーのモチベーションや不安を感じ取り、適切に関わる

責任を引き受ける力

不確実な状況でも「これでいく」と決断し、その結果に責任を持つ
誰かが決めなければ進まない局面で、最終判断を引き受ける覚悟

AIはあらゆる技術的な作業を支援できますが、ステークホルダーの隠れた要求を察し、チームの士気を高めながら、成果が出るまで粘り強く走り続ける。こうしたことは人間にしかできません。

3. 自己否定について－なぜ私にはこれが必要だったのか

ここまで読んで、違和感や抵抗感を覚えた方もいらっしゃるかもしれません。私自身がまさにそうでした。第1章で書いた「自分の方がうまく書ける、だから自分で書くべきだ」という思考パターンは、まさに私が長年かけて積み上げてきたスキルへの執着から生まれたものです。そのため、「自分が何年もかけて積み上げてきたスキルの価値が変わる」ということを、素直に受け入れるのは簡単ではありませんでした。

だからこそ、私は自分に対して「自己否定」という強い言葉を使う必要がありました。

私が否定したもの

「自分の手で書いたコードに価値がある」という信念 ：コードの価値は、誰が書いたかではなく、何を解決するかで決まります。AIが書いても人間が書いても、ユーザーの課題を解決するなら同じ価値があるはずです。
「深い技術知識を持っていることが優秀さの証明」という評価軸 ：知識はAIが持っています。優秀さの新しい尺度は、AIを活用して成果を出せるかどうかに移りつつあるのではないでしょうか。
「AIより自分の方がうまく書ける」という判断で手を動かしてしまう習慣 ：これが最も手放しにくいものでした。判断力があるからこそAIの出力に不満を感じ、自分で書き直してしまう。しかしそれは、方向修正のフィードバックとしてAIに返すべきものを自分の手で処理していたのだと、今は思っています。

否定しなくてよかったもの

一方で、手放す必要がなかったものもあります。前章で述べた課題設定力・判断力・実行力は、むしろ価値が高まっています。

ただし、使い方は変わりました。AWSの全認定資格を取得する過程で培った幅広い技術知識は、自分でコードを書くためではなく、複数の領域を横断してAIの出力を統合的にレビューし方向修正するために使うものへと変化しています。知識そのものを否定したのではなく、知識の活かし方を再定義したということかもしれません。

自己否定は一度では終わらない

私が実感しているのは、自己否定は一回きりのイベントではないということです。AIの能力は日々進化しています。今日「これはまだ人間がやるべきだ」と思っていることが、半年後にはAIが完璧にこなせるようになっているかもしれません。

だからこそ、「自分にしかできない仕事は何か」を問い続けることが大切なのだと思います。自己否定とは、一度古い価値観を捨てることではなく、常に自分の価値を問い直し続ける姿勢そのものなのかもしれません。

4. どう働いていくか－私自身の行動変容

「手を動かす職人」から「AIを指揮して実現する人」へ。

抽象的な話で終わらせたくないので、私自身が実践している（あるいは実践しようとしている）ことを、具体的に書いてみます。

4-1. コードはAIに書かせて、自分は「定義」と「判断」に集中する

従来の私の働き方では、1日の大半を要件の理解や設計、コーディング、チームコミュニケーションに費やしていました。

今ではその時間の使い方が大きく変わっています。課題の定義や要件の構造化、AIへの指示と出力のレビュー、AI活用に関するチームでのコミュニケーションが中心になり、自分の手でコードを書く機会はほとんど無くなりました。かつてコーディングに充てていた時間の多くが課題の定義とAIの出力の判断に移ったことで、同じ時間でカバーできる範囲が大きく広がったと感じています。

4-2. T型ではなく面で動く

従来は「バックエンドに深い専門性を持ち、フロントエンドも少し分かる」といったT型のスキルセットが理想とされていました。しかし、AIが各領域の実装を担えるようになった今、一人のエンジニアがカバーできる範囲は面的に広がるのではないかと考えています。

フロントエンド、バックエンド、インフラ、データベース設計、セキュリティ。これらすべてを自分の手で実装する必要はありませんが、すべてに対して指示を出せるだけの理解と出力を判断できるだけの経験は必要になってきます。

私自身、AWSを軸としつつもマルチクラウド、オンプレミス環境を横断して設計・構築してきた経験がありますが、AIの登場によってこの「面で動く」ことのハードルが大きく下がったと感じています。以前は各プラットフォームの仕様を自分の頭に入れておく必要がありましたが、今はAIがその知識を補完してくれます。自分が持つべきなのは、全領域の詳細な仕様知識ではなく、本質を押さえた上でAIを適切に使いこなせるだけの経験値ではないでしょうか。

これは「浅く広く」とは少し違います。各領域の本質的なポイントを押さえた上で、AIに適切な指示を出し、出力の品質を判断できる深さが求められます。言わば「判断力の幅を広げる」ということではないでしょうか。

4-3. 考え込む前に作って検証する

私はキャリアの初期にシリコンバレーでR&Dに携わりましたが、そこでの経験から得た最も大きな学びは、素早い試行錯誤（rapid iteration）に主体性、創造的思考、粘り強さ、適応力を組み合わせることで、意味ある成果を生み出すスタイルでした。この考え方は、今まで一貫して重要だと体感してきた行動指針の根幹です。

この行動指針が活きる場面は、今回が初めてではありません。IT業界では、オンプレミスからクラウドへ、モノリスからマイクロサービスへと、「従来のやり方が通用しなくなる」局面が繰り返し訪れてきました。クラウド黎明期には「クラウドに本番環境は任せられない」という抵抗感がありました。私自身、生成AIが登場した当初は「自分の手で書いた方が品質が高い」と感じましたが、これもあの時と同じ構造の抵抗感ではないかと気づき、はっとしたことがあります。しかし私は、そのたびに素早く試して、失敗から学び、柔軟に方向転換することで、変化の波に乗り続けてきました。

そして今、生成AIの進化によって、この「素早く作って検証する」サイクルが劇的に加速しています。

従来: 2週間かけて設計を固め、2週間かけて実装し、合わなければ手戻り。

今後: 1時間で仮説を立て、AIに実装させ、動くものを見て検証し、方向転換する。これを1日に何度も回す。

「完璧な設計を最初に作る」という思考から、「素早く作って素早く学ぶ」という思考への転換です。失敗のコストが下がった以上、失敗を恐れて考え込む時間の方がもったいないのかもしれません。

今回のパラダイムシフトの規模はこれまで以上に大きいかもしれません。しかし、主体性を持って素早く動き、創造的に考え、困難に折れず、変化に適応するという姿勢そのものは、どの時代のシフトにおいても変わらず重要であり続ける普遍的なものだと考えています。

4-4. 「自分にしかできない仕事」を問い続ける

これが個人的には最も大切にしている行動指針です。日々の仕事の中で、常にこう自問するようにしています。

「今やっているこの作業は、AIにできないことだろうか？」

もしAIにできることを自分がやっているなら、その時間の使い方は見直した方がよいかもしれません。AIにできることを人間がやっている時間は、今後ますます「もったいない時間」になっていくように思います。

定型的なCRUDの実装 → AIに任せる
テストコードの作成 → AIに任せる
ドキュメントの作成 → AIに任せる
バグの調査と修正 → AIに第一報を任せ、自分は判断に集中する

では、自分は何に時間を使うべきか。

ユーザーと話して本質的な課題を見つける
事業戦略と技術戦略を接続する
チームの技術的な意思決定をリードする
AIの出力を統合し、プロダクトとして成立させる
障害時に最終判断を下す

5. チームとマネジメントに起きる変化－他者との関わり方も変わる

ここまでは主に「個人としてのエンジニア」の話をしてきましたが、エンジニアは一人で仕事をしているわけではありません。チーム、マネジメント、組織。他者との関わり方もまた、このパラダイムシフトによって大きく変わると考えています。

5-1. チーム構造の変化－少人数で大きな成果を出す時代へ

AIが実装を担えるようになることで、一人のエンジニアがカバーできる範囲が劇的に広がります。これは必然的にチーム構造に影響を与えます。

従来であれば、フロントエンド、バックエンド、インフラ、QA、PMとそれぞれ専門の担当者を揃えて10人のチームで開発していたプロダクトを、2〜3人のエンジニアがAIと協働してカバーできるようになりつつあります。

これは「人を減らす」という話ではなく、同じ人数でより大きなインパクトを出せるということです。ただし、そのためにはチームの一人ひとりが課題設定力・判断力・実行力を高いレベルで持っている必要があります。少数精鋭のチームでは、一人ひとりがより主体的に動くことが求められるようになるのではないでしょうか。

5-2. マネジメントの焦点が移る－「労働量」から「判断の質」へ

マネジメントの対象も変わります。

従来のマネジメント	今後のマネジメント
工数の見積もりと配分	課題の優先順位づけと方向性の判断
タスクの割り振り	「何をAIに任せ、何を人間がやるか」の設計
進捗の管理	アウトプットの品質レビュー
スキルセットに基づくアサイン	判断力・課題設定力に基づくアサイン

AIが実装速度のボトルネックを取り除く以上、マネージャーの仕事は「誰に何をやらせるか」ではなく、「チームとして何に取り組むべきか」「AIの出力の品質をチーム全体でどう担保するか」に移っていくのではないでしょうか。

5-3. 評価基準の再定義

これは組織にとって最も難しい変化かもしれません。

従来はコード量、コミット数、特定技術への専門性、資格の数といった「目に見える成果」で評価できました。しかしAIがコードを書く時代に、これらの指標だけでは十分な評価が難しくなっていくように感じています。これは資格を積み上げてきた私自身にとっても例外ではありません。

新しい評価基準として考えられるのは、以下のようなものです。

どれだけインパクトのある課題を定義できたか
AIの出力をどれだけ正確に判断し、品質を担保できたか
どれだけ素早く仮説検証を回して成果に繋げたか
チーム全体のAI活用レベルを引き上げる貢献をしたか

「何を知っているか」ではなく「何を実現したか」で評価する。言葉にすれば当たり前のことですが、実際に評価制度として設計するのは容易ではありません。しかし、ここに向き合わなければ、優秀な人材から離れていくのではないかと感じています。

5-4. ジュニアエンジニアの育成という課題

個人的に最も悩ましいと感じているのが、ジュニアエンジニアの育成です。

従来、ジュニアは比較的簡単なタスク（バグ修正、小さな機能追加など）を通じてコードベースを理解し、徐々に判断力を養ってきました。この「修行」の過程で失敗し、レビューを受け、少しずつ経験を積むことで、シニアエンジニアに成長していきます。

しかし、AIがジュニアレベルのタスクを高い品質でこなせるようになると、ジュニアが経験を積む機会そのものが減ってしまう可能性があります。かといって判断力は経験からしか育たない。ここに大きなジレンマがあります。

一つの可能性として、「AIが書いたコードをレビューすること自体を学習の場にする」というアプローチが考えられます。AIの出力に対して「なぜこの設計なのか」「他にどんな選択肢があるのか」「この実装のリスクは何か」を考える訓練は、従来の「自分で書いて覚える」とは異なりますが、判断力を鍛えるには有効かもしれません。

いずれにせよ、ジュニアからシニアへの成長パスは、各組織が意識的に再設計する必要がある課題だと思います。

また、一人ひとりがAIと組んで高速に動けるようになると、チーム内の情報共有が薄れるリスクもあります。「誰が何をどう判断してこの設計にしたのか」が見えにくくなるのです。ジュニアの育成に限らず、チーム全体として、コードそのものよりも判断の根拠を共有する文化が今まで以上に重要になるのではないでしょうか。

6. AIは「何を実現すべきか」を自分では決められない

最後に、私が最も大切だと考えていることを書きます。

AIは強力です。コードを書く速度も品質も、多くの場面で人間を上回ります。しかしAIには決定的にできないことがあります。「何を実現すべきか」を自分では決められないということです。

AIにとって、指示の質がすべてです。良い問いを立てられる人間がいなければ、AIはその力を発揮できません。逆に言えば、課題設定力で良い問いを立て、判断力で出力を正しく見極め、実行力で最後まで届けきる人間こそが、AI時代に最も価値を持つのではないでしょうか。

これは脅威ではなく、機会だと捉えています。AIが実装を担ってくれるからこそ、エンジニアは「何を作るべきか」「なぜ作るのか」「本当にユーザーの課題を解決できているか」という、より本質的な仕事に集中できるようになります。

手を動かす職人としてのプライドを手放すのは、正直に言って痛みを伴うものでした。しかし、自己否定の先には、課題設定力・判断力・実行力を軸に、より大きなインパクトを生み出せるエンジニアとしての新しい姿があると信じています。

この記事に書いたことは、あくまで私自身の経験と考察に基づくものです。異なる考えをお持ちの方もいらっしゃると思います。

この記事を読んで、「エンジニアの敗北宣言だ」と受け取る方もいるかもしれません。しかし、自己否定とは立ち止まることではありません。自分が積み上げてきたものを正面から見つめ直し、変化すべき部分を見極めて次に進む。むしろ、それはエンジニアが最も得意としてきたことではないでしょうか。私たちは昨日の自分のコードを今日リファクタリングしてきた人間です。今回は、その対象がコードではなく自分自身の価値観だったというだけのことです。

ただ、もしこの記事を読んで少しでも何かを感じていただけたなら、一つだけ自問自答してみてください。

自分が今日取り組んだ仕事のうち、AIには決してできないものはどれだけあったか？

その答えを考えることが、きっと次の一歩に繋がるのではないかと思っています。

参考：