AIが猛威を振るう時代にエンジニアがこの先生きのこるには

何なのだ，これは！どうすればいいのだ？！

ちょうど業務の一環で評価や採用に関して考えていたら「そもそも今後エンジニアどうすればいいのか問題」になったのでまとめてみた．

今後，開発に AI を用いる比率が高まることは疑いない．これまでの人力型から AI 協働型に移行するにあたり，事業を展開するために求められるエンジニアの能力はどのように変化するのか考えた．また，組織においては評価・採用に際して着目すべき能力についても変えていく必要がある．

エンジニアどうなるのか問題

AI 協働型開発におけるエンジニアの役割変化

「AI を用いた開発の比率が高まる」という前提に立ったとき，エンジニアに求められる能力や役割は大きく変化する．単なる自動化の置き換えではなく，人と AI の協働を前提とした「新しいスキルセット」や「視点」が必要になる．

従来型との比較

項目	従来型	AI 協働型
主な価値	コーディングスキル，実装力	モデリング力，構造設計力，AI 活用の判断力
ワークフロー	要件 → 設計 → 実装 → テスト	要件 → 設計・プロンプト設計 → AI 活用 → 検証・補正
主体性	実装を自力で遂行	AI の出力を主導・評価・修正し，全体を制御
工数の使い方	コーディングに多くを割く	思考・検証・設計に多くを割く

求められるエンジニアの能力の変化

1. AI リテラシー・活用スキル

• AI（LLM・画像・音声など）の特性と限界を理解し，適切に使いこなす力
• プロンプト設計，ベンチマーク・検証スキル
• 単なる「ツールユーザー」ではなく，「AI との役割分担を設計できる人材」

2. 抽象化・構造化の力

• 手戻りの少ない「要件・設計」に落とし込める力
• 実装よりも「構成」「プロトコル」「フロー」設計が重要に
• ノーコード / AI 生成コードの整合性を担保できる設計思考

3. AI 生成物の「検証者・批評者」としての力

• 出力されたコード / UI / 提案の妥当性を見抜き，再設計する能力
• 実行時の挙動から問題点を逆算するデバッグ力

4. 継続的学習・変化適応力

• AI 技術の進化に追従し，自らのワークフローをアップデートできる
• フレームワーク依存ではなく，原理や背景を理解する力

5. チーム内 AI 利用の標準化・伝播スキル

• AI を用いた開発の「型化（テンプレート化）」「教育」など
• チームや非エンジニアとの協働において AI の適用範囲を広げる

採用時・評価時に着目すべき能力の変化

旧来中心だった項目（今後も必要だが相対的に比重が下がる）

• 純粋なコーディングスピード
• 特定技術スタックの深い知識のみ
• 完全なウォーターフォール型経験

今後重視すべき項目

能力・素養	着目ポイント（採用面接例）
抽象化力・構造化力	「複雑な仕様をどうシンプルに設計したか？」 「他人が読める設計ドキュメントをどう書くか？」
AI 活用経験・思考	「どんな場面で AI を使ったか？どう評価したか？」 「人力の方が早いと判断した事例は？」
学習力・変化耐性	技術選定の変化にどう対応してきたか 新しいツールやライブラリのキャッチアップ手法
プロンプト設計・評価	GitHub Copilot / ChatGPT などの活用経験と具体事例
自律性・探究心	趣味開発・検証用プロジェクトの有無（例：LangChain でツール作った 等）

今後のチーム設計への影響

項目	変化
採用の多様化	AI 活用・分析に長けた人材を採用（文系出身者も視野に）
評価制度	「AI を使ってどれだけ価値を出せたか」の評価軸追加
育成方針	AI 活用スキルや構造設計を中心とした社内教育体制の整備
技術選定	コーディング効率よりも「AI 連携しやすいアーキテクチャ」が重要に

AI 協働時代のエンジニア像

「コードを書く人」から「価値を構造化し，AI を含む手段で実現する人」へ．

エンジニアの本質が「作業者」から「設計者・統括者・検証者」へシフトしていく未来を見据え，採用基準・育成設計・評価制度を再設計していく必要がある．

ジュニア詰んでる説ある？ → そこまで詰んでない

一方で AI を有効活用するには開発の全体像の理解やある程度の技術的な知見・経験も必要になる．AI 登場以前からエンジニアで元々このような能力を持った人については問題となるケースは少ないが，未経験者やジュニアクラスの人が上記のような知見・経験を積むにはどのようなアプローチが有効なのだろうか？

AI が登場してもなお，「開発の全体像の理解」や「技術的知見の蓄積」は，AI 活用の前提条件であり，特に未経験者やジュニアクラスにとっては，そこを飛ばすことはできない．

つまり：

AI によってスキルの「底上げ」は可能でも，「土台づくり（基礎の理解）」は依然として本人の学習・経験に依存する．
（= 戦のやり方を理解していないと最新兵器を用いても勝てない）

未経験〜ジュニア層が AI 時代のエンジニアとして成長するためのアプローチ

1. 「手を動かす」ことから始める：AI なしでの基本理解

• フレームワークやツールを使う前に，HTML / CSS / JavaScript や基本的な CRUD 実装を通して「なぜそうなるか」を理解する
• Git・ターミナル操作・デプロイの基礎も実体験として習得
• 最初から AI に頼りすぎると，構造や意味を把握できず「ブラックボックス依存」になるリスクがある

2. 小規模なプロジェクトベース学習（AI 活用併用）

• 小さなアプリをゼロから作る経験（例：ToDo アプリ，ブログ，API 連携など）
• この過程で，エラー解消・リファクタ・設計見直しなどを AI とやり取りして学ぶ
• 自分の考えを言語化しながら AI に伝える＝構造理解のトレーニング

3. 開発の「全体像」を意識した学び方

フェーズ	意識すべき観点
要件定義	ユーザー目線，ユースケースの洗い出し
設計	モデル，API，UI の役割分担とデータの流れ
実装	フレームワークの使い方ではなく「処理の責務と流れ」
テスト・デバッグ	予期せぬ動作がなぜ起きたかを「構造的に説明する」力
デプロイ・運用	アプリが公開されるまでの道筋とインフラの役割

4. 実際のコードを読む＆レビューを受ける習慣

• GitHub 上の他人のコードを読む（設計意図や共通パターンの理解）
• チームでコードレビューを受ける・する文化に早く入る（→「なぜそう書くか」が分かる）

5. AI 活用のスキルも「文脈の理解」から育てる

• ChatGPT や GitHub Copilot に投げる前に，「自分の意図や課題を整理して明文化する・伝える」習慣
• 「なぜそのコードが出てきたか」「改善点は何か」を自分で評価・修正する習慣

補足：育成支援におけるポイント（企業・教育側の視点）

項目	内容
プロジェクト型 OJT	小さなタスクを任せ，要件〜デプロイまでを実体験させる
ペアプロ・メンタリング	経験者との協働で「考え方」「技術判断の根拠」に触れさせる
AI 活用トレーニング	AI 活用の「型」を教える（例：問題分解 → 要素化 → プロンプト化）
リフレクション機会	開発の振り返り・ドキュメント化を通じてメタ認知を促す

成長を加速させる環境の要素

• 「質問してもいい」文化
• 失敗を許容し，学びに変える空気
• 成長過程を評価する評価制度（完成物だけでなく，思考・工夫・調査力を評価）

ジュニア層は学びの姿勢を変える必要がある

AI 時代のジュニアに必要なのは「AI に頼って楽をする」のではなく，

「AI を相棒として使いながら，自分の理解を深める姿勢」

この姿勢を持ち，試行錯誤できる環境があれば，未経験でも確実に土台を築ける．

ベースのあるシニアはどうする？

プロダクト単位だけでなく，開発フロー全体や事業全体を見たときにシニアやリードポジションのエンジニアとして求められる能力はどのように変わっていくだろうか？

AI の活用が進む中で，プロダクト単位だけでなく「開発フロー全体」や「事業視点」からエンジニアに求められる役割や能力も大きくシフトしている．単なる実装力では不十分で，より戦略的・構造的な能力が求められる．

シニア以上のエンジニアに求められる能力の変化

領域	これまで	これから（AI 活用・事業連動）
プロダクト開発	実装・技術選定・運用の最適化	事業課題の言語化・価値設計・ユーザー体験の統合設計
開発フロー	CI/CD・コード品質・レビュー設計	AI を含む開発プロセス全体の再設計（ツール連携・自動化の設計）
チーム設計	担当分け・レビュー体制	AI 活用を前提にした「人と AI の協働体制」の構築と教育設計
事業との連携	プロダクト要件に従う	事業企画・営業・データ分析との協業を通じて「開発で価値を出す」立ち位置へ
戦略的視点	技術スタックの選定・拡張性確保	競争優位を生む技術活用戦略・技術ブランディング・知財戦略の意識

領域別に見る「これから求められるシニア以上の能力」

1. 技術と AI の戦略的活用力

• どの領域に AI を導入すべきか（効率性 vs 品質 vs コスト）
• 社内 AI 基盤の構築，セキュリティ・ガバナンス対応
• ベンダー依存からの脱却／自社に合った LLM 活用設計

2. 開発フロー設計・再構築能力

• GitHub Copilot や CI ツール，ChatOps 等を活用した新しい開発生産性モデルの設計
• コードレビューの再定義（AI レビューと人間レビューの棲み分け）
• 技術資産（ナレッジ・プロンプト・テンプレート）の組織内共有・体系化

3. プロダクトと事業をつなぐ設計力

• KPI／KGI やユーザーデータを踏まえた技術による課題解決の提案
• ビジネス側と開発側の思考を橋渡しする言語化・図解力
• 例：プロンプト設計や AI 処理の可視化が UX・価値にどうつながるかを示せる

4. エンジニア組織・カルチャーの育成能力

• 「AI 活用が前提の開発文化」をチームに定着させるファシリテーター
• 組織の成熟度に応じた育成・コード品質・設計粒度の調整力
• シニア層自身が「学び続ける姿勢」を見せ，ジュニアを牽引

5. 倫理・セキュリティ・透明性に対する判断力

• AI 導入に関する社内倫理基準の検討，ガイドライン整備
• データガバナンス（社内情報の取り扱い，ログ活用，誤出力対応など）
• 「なぜこの出力になったのか」を説明する責任＝説明可能性

今後のシニア以上エンジニア

「事業構造とユーザー価値を理解した上で，技術と AI を活用し，チームに伝播・拡張できるエンジニア」

• コードを書く時間は減るが，「技術で事業を動かす」影響力は増す
• 「答えを知っている人」ではなく，「チームが答えを出せる場を作る人」
• 「実装を任せる人」から「問題解決と構造設計を任せる人」へ

採用・評価に活かすには？

今後，シニアやリード層を採用・評価する際には以下のような観点が重要になる：

評価観点	例
技術視点の多角性	実装だけでなく設計・AI 活用・セキュリティなど含めて語れるか
事業・プロダクト視点	自分が関わった機能がユーザー／KPI にどう影響したか説明できるか
再現性・育成視点	自分だけでなく，チームで成果を出せる仕組みを作ったか
プロンプトや AI ツールの活用例	実務での応用範囲・工夫・ナレッジ共有の経験など

今後における専門性 is 何？

特定の技術に関する深い理解・経験による価値は大きいものの，大規模でない・複雑な処理が必要でないプロジェクトでは真価を発揮しないこともある（=そこまで必要でない場面もあるよねという話）．

「特定技術に対する深い理解・経験（＝専門性）」は本質的に価値ある資産であるが，その価値が最大限に発揮されるかどうかはプロジェクトの規模・複雑性・構造に大きく依存し「専門性をどのように発揮するか」が重要になる．

技術的専門性の価値はどうなる？

本質的な価値

• 構造的課題への最短解を見つける力（経験知から来る打ち手の早さと的確さ）
• 再現性・拡張性・保守性を持った設計を初期段階で実現できる
• 技術選定・アーキテクチャ設計において、判断を語れること自体が価値
• 若手の育成・レビュー・ナレッジ展開において圧倒的な差を生む

限界や誤解されやすい点

課題	説明
スコープに対して過剰になりがち	小規模・短期間のプロジェクトでは設計過剰・重厚すぎる技術選定になることも
汎用性を伝えるのが難しい	専門性は評価されにくい（特に非エンジニアやビジネスサイドには伝わりづらい）
AI や既成ソリューションとの役割かぶり	AI・SaaS で代替できる範囲が拡大している（特にインフラ・セキュリティ・LLM 活用領域など）
組織内で活用しきれない	組織の文化や設計自由度が制限されていると専門性が活きない

専門性の発揮の仕方

「使う場面が限られる」→「適切に使える組織設計が必要」

特定技術の専門性を活かすには，以下のような設計が重要である：

項目	内容
技術選定プロセスの明文化	専門家が判断し，技術スタックに説得力を持たせる場
アーキテクトロールの明確化	プロジェクト横断で技術判断に関わる仕組み
ナレッジの型化・伝播	実装だけでなく「考え方」「判断基準」を展開できる余地
専門性を評価する文化	定量評価が難しい専門性に対して，ピアレビューやドキュメントなどで価値を可視化する

1. 引き算の技術

• 「やらない」「軽く済ませる」判断ができる
• 専門性があるからこそ必要最低限で組める（簡素で壊れにくい設計）

2. 標準化・型化してチームに展開する

• 自身の専門性をチームの技術基盤に落とし込む（設計テンプレート／ライブラリ／Lint・CI ルールなど）
• これにより，ジュニアも安心して早く動ける＝「見えない加速」を実現

3. 抽象的スキルへの昇華

• 深い技術理解を「他の技術にも適用できる形」で説明する

  • 例：通信のレイテンシに関する知見 → フロントエンド SPA の UX 改善に応用
  • 特定フレームワークの内部理解 → フレームワーク選定時の比較軸に昇華

専門性の価値は「状況に応じて翻訳できるか」（=資産を様々な状況に適応させる）

価値がないのではなく，使い方と伝え方次第で活きる・埋もれるが決まる．

• 深い技術を「引き算して使える」
• 他者にわかる言葉で「再構造化して共有できる」
• 小さな案件でも「チーム全体をレベルアップさせる」貢献ができる

そうした能力のある専門家は，どんな規模の組織・プロジェクトでも確実に価値を出せると考えられる．

まとめ

• AI 協働型開発の進展に伴い，エンジニアの役割は大きく変化している．単なるコーディングから，AI を活用した価値創造へとシフトし，評価・採用基準もそれに応じて見直す必要がある．
• ジュニア層は AI を活用する前に，基礎的な技術理解と実装経験を積むことが重要である．AI はあくまで補助であり，土台となる知識が不可欠である．
• シニア層は，AI を含む開発フロー全体を設計し，事業価値を最大化する役割が求められる．専門性は依然として重要であるが，その活用方法や伝え方が変わってきている．
• 専門性は「状況に応じて翻訳できる」ことが重要であり，単なる技術力だけでなく，チーム全体をレベルアップさせる能力が求められる．

以上だ( `･ω･)b