「エンジニアはでかいモニターとにらめっこする仕事」？？
こんな固定観念を持っていないだろうか？
コロナ禍を経て 「エンジニアはリモートで完結出来る(すべき)職業」という幻想 が、いつの間にか常識として定着した気がする。
しかし、もしそう思っているなら、 AIエージェントの潮流に飲み込まれる側 となるだろう。
TL;DR
『AIが実装を自動化する時代、エンジニアの競争力は「現場で顧客/ドメイン解像度を握る力」で決まる』
「顧客の問題をエンジニア視点で見たときに、どのような課題に置き直せるか」が、AIに代替されない最後の価値だと考える。
（筆者がAI受託をメインとしているため、AI受託を例に上げるが、社内システムだろうと、toB事業だろうと、toC事業だろうと、この価値は共通していると考える）
特にAI受託のPoC案件に限ると、言語化時に情報が削ぎ落ちてしまった要件定義やzoom会議だけでは見えない「現場の解像度」こそが、PJの成否を分ける。
補足: AI受託とは?
AI受託開発は、通常のシステム開発よりも 高い不確実性 を前提としている。
「生成AIを使えばこんなことができないか?」という期待から始まるプロジェクトは多いが、実際にやってみないと精度や実現性が分からないケースがほとんどだ。
だからこそ、AI受託は下記の2段階で動くことが多い。
PoCフェーズ（数百万円以内かつ短期間でAIの実現性を測る）
↓
本開発フェーズ（PoCで効果が検証されれば本格的なシステムの開発をする）
多くの場合、IT分野に詳しい営業やPMが顧客と会話し、要件を整理してプロジェクトをスタートさせる。しかし、いざ開発が始まると、見えていなかった情報が次々と出てくる ことは往々にある。（これは、どのようなNDAをどの段階で結べるのかというビジネス的な都合もあるため仕方がない）
つまり、会議室やZoomでの打ち合わせでは拾いきれない 現場の文脈 が存在し、これを掴めるかどうかが、PoCの成否を分ける。
だからこそ、エンジニア自身が現場に出ていくことが重要になる という話をしていく。
cf. AI受託開発 という起業が流行っている - AI受託開発の実態 (ちぇんさん)
AIエージェントは何を奪い、何を残すのか
Claude、Codex、GitHub Copilot、Cursor。これらのツールを使えば、明確な仕様から実装までの時間は劇的に短縮される。
「この画面設計書をもとにReactでダッシュボードを作って」
「このデータモデルのAPIのCRUD処理を実装して」
「テストコードも含めて生成して」
こんな指示で、及第点の実装が数分で出来上がる時代だ。
では、人間エンジニアに残される領域は何か？それは「何を作るべきか」を定義する力だ。
その答えは現場にしかない
一部のAI受託は失敗（≒本開発まで踏み切れない）してしまうことがある。
━━ 技術力不足？ 予算不足？ 違う。
「顧客の問題を、解くべき課題に落とし込めていない」からだ。
顧客は自分たちの課題を正確に言語化できない事が多い。そもそも、AIとは？プログラムとは？の違いや、何が出来るかが漠然としているため仕方がない。
そこで、クライアントのPJ担当の方に、ゆっくりと適切に説明し、一緒に考える回数を重なることは当然重要だ。
しかし、どれだけ重ねたとしても、会議室/Zoomだけで見えてくる情報には限度がある。
そのため、現場で実際の作業を観察して初めて見える景色 を自ら取りに行くのだ。
「エンジニアだから」という免罪符
ここで耳が痛い話をしよう。
「自分はエンジニアだから、現場のことは営業やPMに任せておけばいい」そう思っていないか？
残念ながら、その思考こそがAIに代替される第一歩のように思う。
なぜなら、仕様書をコードに変換する作業は、AIが最も得意とする領域だからだ。これはエンジニアである我々自身が痛いほど理解しているはずだ。誰かが定義した要件を実装するだけなら、もはや人間である必要はない。
一方で、現場の「違和感」を掴み、それを技術的な解決策に昇華させる力。これはAIには真似できない。
生成AI時代において「コンテキストが大事大事」と巷で叫ばれるが、それでいて現場に出ないのは、真にコンテキストの重要性を理解していないのではなかろうか？？
かくいう私も、つい最近まではリモート/オフィスにてウルトラワイドモニターとにらめっこする毎日だった。この働き方に体が慣れてしまっていたし、これで仕事ができているように思い込んでいた。現場を見ることの重要性を、薄々頭で理解しつつも、体が拒否反応を示し殻に閉じこもっていた。
現場に出るようになって分かったこと（実エピソード）
オンライン会議での対話、頂いたデータ/ファイルなどの情報だけでは、 「顧客の期待を超える」ことに限界 が来た。そこで意を決して現場訪問、現場同乗などをさせてもらった。
弊社は産廃業界を中心に顧客を抱えているため、産廃回収のダンプカーへの同乗、処分場の見学、見積営業への同行などをせてもらった。
複数のエンジニアで現場へ赴き、顧客のリアルを知る。issueの情報では掴めていなかったことや、どのような方々が働いているのかが見えてくる。また、我々の開発したシステムがどのように使われていくかのイメージも想起しやすくなった。
ときには、朝5時に起きて始発で郊外の車庫へ赴き、ヘルメットを被り、どでかい10tトラックに乗った。
正直、最初は気が進まなかった。しかし、その日の経験が、その後のシステム設計を根本から変えた。何より、 当事者意識 が芽生えるようになった。
一見長いように思う5時間の現場体験は、50時間の会議を超える価値があった。
10Tトラックからの眺め
「現場」に出る価値
AIが進化し続ける今、単なる仕様通りの開発は容易に置き換えらる。しかし、現場に足を運び、自分の目で業務や課題を理解し、顧客と同じ目線で本質を捉えることは人間にしかできない。
まずは、「実際の業務を現場で見させていただけませんか？」 と一言発してみよう。その一歩が、エンジニアとしての価値を大きく広げてくれる。AIにはできないこの経験と共感こそが強みとなるだろう。
Discussion