概要
AIがコードを書く時代、エンジニアの価値は「コードを書けること」から「課題を定義できること」へ移ります。GitHubが公表した調査では、Copilotを使う開発者のコード生成タスクは平均55%高速化したと報告されており、Gartnerは2027年までに新規コードの80%以上が生成AIの支援を受けると予測しています。コードを書く時間が圧縮される一方で、業務を読み解き、顧客の課題を定義する仕事は誰にも代替されません。本稿は、現場リーダーが自分とメンバーを点検するための「5つの違い」を、構造的に示します。
問題の構造——AIがコードを書く時代の事実認識
事実は2つあります。AIはコードを書きます。そして、AIは業務を読み解きません。
GitHubのCopilotは2024年時点で月間アクティブ開発者数が180万人を超え、Microsoftの決算開示では同製品の有料契約数は前年同期比180%超の伸びを示しました。Stack Overflowの2024年Developer Surveyでは、開発者の76%が「AIツールを使用中、または近く使用予定」と回答しています。コード補完、テスト生成、ドキュメンテーション、リファクタリング——いずれもAIが担える領域です。
一方で、Gartnerは2024年のレポートで「生成AIプロジェクトの30%は2025年末までにPoC段階で中止される」と予測しました。中止の主因は技術ではなく、ビジネス価値の定義不全です。McKinsey Global Instituteの推計でも、生成AIの経済価値の約75%は「マーケティング・営業」「ソフトウェア開発」「カスタマーオペレーション」「R&D」の4領域に集中し、いずれも「現場業務の文脈理解」が成果を左右します。
つまり、AIはコードを書きますが、「何を作るべきか」を決めません。「何を作るべきか」を定義する仕事は、業務を読み解く人間が担います。経済産業省が2022年に策定し2024年に改訂したデジタルスキル標準(DSS)も、ビジネスアーキテクト・データサイエンティスト・ソフトウェアエンジニアといった人材類型を定義し、共通基盤として「ビジネス変革」「データ活用」「テクノロジー」の3領域を置いています。技術一辺倒ではなく、業務と技術の橋渡しが標準として求められる時代に入っています。
現場リーダーが直視すべき構造はシンプルです。コードを書く時間は減ります。業務を読み解く時間は増えます。両者の比率が逆転する組織が勝ち、逆転できない組織が負けます。
真因の分析——消える／残るを分ける構造的要因
消えるか残るかを分けるのは、スキルの量ではなく、仕事の上流に立てるかです。
エンジニアの仕事には「上流」と「下流」があります。下流は実装・テスト・運用、上流は要件定義・業務分析・課題設定です。これまで両者は明確に分かれていました。上流はSEやコンサルタント、下流はプログラマーが担い、間に「仕様書」という伝言が介在しました。
この伝言ゲームを、AIが破壊しつつあります。仕様書が明確であれば、AIは下流をかなりの精度で再現できます。逆に言えば、仕様書を作る側——業務を読み解き、課題を構造化し、要件に落とし込む側——の価値は、相対的に上昇します。
Palantir Technologiesが提唱する「Forward Deployed Engineer(FDE)」という人材像が、この構造を端的に示しています。FDEは顧客のオフィスに常駐し、業務を観察し、課題を見つけ、その場でソフトウェアを書き、価値を実証する役割です。同社の2023年Investor Dayでは、FDEを「顧客の文脈に深く入り込み、技術と業務の境界を消す職種」と説明しています。コードを書く能力と、業務を読み解く能力と、顧客と対話する能力——この3つが分離されず、一人の人間に統合されている点が特徴です。
日本のIT産業構造に当てはめると、深刻な含意が見えます。情報処理推進機構(IPA)の「IT人材白書」では、日本のIT技術者の約7割がベンダー側に所属し、ユーザー企業側は約3割と報告されています。米国は逆で、ユーザー企業側に約65%が所属します。つまり日本のエンジニアは構造的に「業務から遠い」場所に置かれており、仕様書を受け取って実装する立場に固定されやすい環境にあります。
AI時代に残るエンジニアは、この構造を逆走します。仕様書を待つのではなく、業務を取りにいきます。技術だけで評価されるのではなく、課題解決の成果で評価されます。これを本稿では「業務×AI×実装の三位一体」と呼びます。3つのうちどれか1つだけが強いエンジニアは、AIに代替されるか、AIを使う上流人材に下請け化されるかのいずれかです。3つを統合した人材が、希少人材として残ります。
解決の方向——5つの違い
ここからは、消えるエンジニアと残るエンジニアを分ける5つの違いを、対比で示します。煽る意図はありません。現場リーダーが自分とメンバーを冷静に点検するための物差しとして読んでください。
違い1：仕様を待つか／業務を読み解きにいくか
消える側は仕様書を待ちます。残る側は業務を観察に行きます。
消える側の典型行動は、要件定義書を受け取り、不明点を質問票で返し、回答を待つことです。仕様が確定するまで手が動きません。仕様の質が低ければアウトプットの質も低くなりますが、その責任は要件定義者にあると整理します。
残る側の典型行動は、顧客の現場に出向き、業務フローを自分の目で見て、課題を構造化することです。仕様書はゴールではなく、議論の途中経過です。「この業務、本当にこの順番で必要ですか」と問い直し、業務そのものの再設計に踏み込みます。
この違いは技術力の差ではありません。仕事の起点をどこに置くかの差です。コードから起点を置けば、仕様待ちになります。業務から起点を置けば、業務理解が深まり、要件を自ら定義できるようになります。
違い2：AIを警戒するか／AIを使い倒すか
消える側はAIを警戒します。残る側はAIを使い倒します。
消える側の思考様式は、「AIが書いたコードは信用できない」「自分で書いたほうが速い」「セキュリティ的に使えない」というものです。結果として、AIを使わない時間が積み重なり、AIを使いこなす同僚との生産性差が拡大します。
残る側の思考様式は、「AIに何を任せ、自分が何をやるか」を常に分割し続けることです。コード補完、テスト生成、ドキュメント作成、データ前処理、API調査——任せられるものは任せ、自分は業務理解・課題定義・設計判断に集中します。GitHub Octoverse 2024では、Copilotユーザーは非ユーザー比で開発者満足度が高く、繰り返し作業の負担が減ったと回答しています。AIを使う側は、創造的な時間が増えます。
AIへの態度は、技術選好ではなく、戦略的選択です。AI時代に残るには、AIを敵ではなく拡張機能として扱う必要があります。
違い3：コードを書く時間／課題を定義する時間
消える側は、コードを書く時間が長いことを誇ります。残る側は、課題を定義する時間が長いことを誇ります。
McKinsey Digitalが2023年に実施した調査では、生成AIを活用するエンジニア組織で「コード生成」タスクの所要時間は35-45%短縮、一方で「要件理解・設計レビュー」の時間は20-30%増加したと報告されています。総作業時間は減っていますが、内訳が大きく変わっています。
消える側は、この変化に気づかず、コードを書く時間を確保しようとし続けます。残る側は、課題を定義する時間を意図的に増やします。顧客との対話、業務ヒアリング、上位ゴールの再確認、トレードオフの整理——これらに使う時間が、価値の源泉になります。
現場リーダーは、メンバーの稼働時間の内訳を点検してみてください。コードを書く時間と、課題を定義する時間の比率が、消える側か残る側かを示す明快な指標です。
違い4：顧客から離れて働くか／顧客の隣で考えるか
消える側は、顧客から離れた席で働きます。残る側は、顧客の隣で考えます。
日本のIT産業は多重下請構造を持ち、エンジニアが顧客と直接対話する機会が限定されてきました。情報サービス産業協会(JISA)の調査でも、SIerに所属するエンジニアの大半は、エンドユーザーとの直接接点を週1回未満と回答しています。仕様書とテスト要件だけが顧客との唯一の接点になりがちです。
残る側は、この距離を埋めます。Palantir型のFDEは、顧客のオフィスに常駐します。MicrosoftやGoogleの一部のソリューションエンジニアも、顧客現場に張り付いて課題を観察し、その場で実装まで担います。Andreessen Horowitzが2024年に発表したFDEに関する論考では、「FDEは販売チームではなく、顧客の問題を一緒に解く共同創業者のような存在」と位置付けられています。
顧客の隣で考えるエンジニアは、業務の機微を理解できます。業務の機微を理解できるエンジニアは、AIに代替されない希少人材になります。
違い5：単価で評価されるか／成果で評価されるか
消える側は単価で評価されます。残る側は成果で評価されます。これを「価値ベース取引」と呼びます。
人月単価モデルは、エンジニアの時間を商品として売る仕組みです。スキルレベル別の単価表が存在し、稼働時間×単価で価格が決まります。このモデルは、コードを書く時間が価値の源泉だった時代に合理的でした。
AIがコードを書く時代、このモデルは崩れます。コードを書く時間が圧縮されれば、人月単価モデルは売上を維持できなくなります。一方で、課題を解決した成果——コスト削減額、売上増加額、業務時間短縮——を価格にする「価値ベース取引」では、時間ではなく価値が報酬を決めます。
McKinseyやBain、BCGといった戦略コンサルティングファームの一部案件は、成果連動型のフィー設計を取り入れています。コンサル業界が培ってきた「価値ベース取引」のノウハウは、これからのエンジニア組織に転用されます。残るエンジニアは、自分の仕事を時間ではなく成果で説明できる人材です。
実行のポイント——現場リーダーが今週から始めること
5つの違いを並べると、現場リーダーは焦るかもしれません。ただし、変革は一度に起きません。今週から始められる3つの実行ポイントを示します。
第一に、メンバー一人ひとりの稼働時間の内訳を可視化してください。「コードを書いた時間」「課題を定義した時間」「顧客と直接対話した時間」「AIを使った時間」の4分類で、自己申告ベースで構いません。1週間集計するだけで、消える側と残る側の構造が見えます。可視化された数字は、本人の自覚を促します。
第二に、メンバーに「業務を見にいく」機会を意図的に作ってください。顧客現場への同行、業務ヒアリングへの陪席、上流会議への参加——どれでも構いません。仕様書を介さず、業務を直接観察する経験を、四半期に1回以上は確保してください。FDE型人材は、現場経験の積み重ねでしか育ちません。
第三に、AI活用の標準ルールを定めてください。禁止と推奨を曖昧にしたまま放置すると、消える側がAIを警戒し続け、残る側が独力でAIを使いこなす二極化が進みます。組織として「どのタスクにAIを使うか」「機密情報の扱い」「コードレビューの基準」をルール化し、AIを使う側が標準になる環境を整備してください。
これら3つは、コストをかけずに今週から実行できます。逆に言えば、これらを実行しない組織は、消える側のエンジニアを大量生産し続けます。
中長期では、人材育成の枠組みそのものを上流化する必要があります。コンサル業界が培ってきた業務分析・課題解決・クライアントワークの方法論を、エンジニア組織に転用する動きが広がっています。経産省のDSSも、ビジネス変革領域の人材類型を強化する方向に改訂されました。技術研修だけでは、AI時代の希少人材は育ちません。業務×AI×実装の三位一体を、育成体系の中心に置いてください。
まとめ
AI時代に消えるエンジニアと残るエンジニアの違いは、技術力ではありません。仕事の起点を、コードに置くか、業務に置くかの違いです。
5つの違いを再掲します。仕様を待つか業務を読み解くか。AIを警戒するか使い倒すか。コードを書く時間が長いか課題を定義する時間が長いか。顧客から離れて働くか顧客の隣で考えるか。単価で評価されるか成果で評価されるか。いずれも、エンジニアの仕事の上流化、コンサル化を示す指標です。
Palantirが示したFDE、経産省が示したDSS、McKinseyやGartnerが示した生成AIの経済価値——すべての先行指標が、同じ方向を指しています。コードを書くだけのエンジニアは希少性を失い、業務を読み解き、AIを使いこなし、課題を解決するエンジニアが希少人材になります。
現場リーダーの役割は、メンバーをこの方向に動かすことです。稼働時間の内訳を可視化し、業務観察の機会を作り、AI活用の標準を整える。今週から始められることがあります。そして、中長期的には、コンサル業界の上流スキル——業務分析・課題解決・クライアントワーク——を、エンジニア育成体系の中心に据える設計が必要です。AIがコードを書く時代に、人間が売るのは「業務を読み解く力」と「課題を解く力」です。
Ballistaに相談する
自チームの上流化プログラムの設計や自社への適用について、まずはお気軽にご相談ください。
