AI時代に残るエンジニア・消えていくエンジニア｜コードを書く、その先へ

西澤です。

AIにアプリづくりを任せられるようになったら、エンジニアの仕事はなくなるのでしょうか。

僕は、パソコンの前で作る時間を減らして、お客さんの現場で話を聞き、一緒に困りごとを解決する時間を増やせると考えています。「言われたものを作る」から、「何を変えれば仕事がよくなるかを考え、そこまで持っていく」へ。仕事の重心が変わる、という話です。

その変化について、動画で話しました。

動画：AI時代に残るエンジニア・消えていくエンジニア｜コードを書く、その先へ

作る時間が減った先に、どんな仕事が待っているか

たとえば、こんな仕事の進め方です。

午前中はお客さんの会社を訪ねて、担当者がどこで手を止めるのかを見る。持ち帰った困りごとをもとに、AIを使って試作品を作る。次に会うときは、長い説明書を渡す代わりに、その試作品を触ってもらう。

「この操作だと現場では使いにくい」「実は、先にこっちを直してほしい」。そういう反応を聞いて、また直す。

これは特定のお客さんへの納品実績ではなく、AIを使った仕事の進め方のイメージです。作る負担が下がれば、こうした対話と改善に時間を回せます。

お客さんにとっては、「頼んだものはできたけれど、仕事は楽にならない」を減らせる。エンジニアにとっては、完成した画面だけでなく、相手の仕事が変わったところまで見届ける仕事になります。

「この仕様どおりに作ってください」だけでは厳しくなる

動画のきっかけは、IT事業をしているメンターとの会話でした。AIの変化が速い中で、これからエンジニアはどう働くのか、という話です。

今の開発では、発注元から元請け、下請け、さらに孫請けへと仕事が渡ることがあります。上流で「何を作るか」を決め、下流でその指示に沿ってプログラムを書く形です。

僕は、このうち「決まった指示を受け取り、そのとおりに作ること」だけを価値にする仕事は、AIの進歩によって厳しくなると見ています。

これは、下請けの会社や、そこで働く人を否定する話ではありません。複数の会社で責任を分担する理由もあります。ただ、指示どおりに作る作業をAIが担える範囲が広がるなら、人が提供する価値も見直す必要があります。

新しいツールを覚えることは、もちろん続ける。そのうえで、「自分は何を解決するために、その技術を使うのか」まで考えたいんです。

お客さんの要望と、本当の困りごとは同じとは限らない

「こういうアプリを作ってください」と言われたら、そのアプリを作る。分かりやすい仕事の進め方ですが、それで相手の問題が解決するとは限りません。

お客さん自身も、毎日の仕事を当たり前だと思っていて、不便さに気づいていなかったり、原因を別のところに見ていたりします。相手の説明が下手なのではなく、仕事の中にいるからこそ見えにくいことがあるんです。

たとえば「入力を速くしたい」と相談されたら

ここからは、考え方を伝えるための仮の例です。

「注文を入力するのが大変なので、入力画面を使いやすくしたい」という相談があったとします。

その場で画面の改修を決める前に、注文を受けてから処理するまでを見てみる。すると、同じ内容を紙に書き、表計算ソフトに写し、別のシステムにも入力していたとしたら、どうでしょうか。

本当に減らしたいのは、キーを打つ時間ではなく、同じ内容を何度も入力する仕事そのものかもしれません。

もちろん、原因が本当に画面の使いにくさにあることもあります。最初から「あなたの考えは違う」と決めつけるのではなく、一緒に確かめる。その結果、「Aを直すつもりでしたが、先にBを変えると楽になりますね」と言える人が、これから頼られると思っています。

AIに作業を任せても、問題選びと確認は人が引き受ける

動画では、AIが作ったものを目標と照らし合わせ、自分で改善を進める未来にも触れています。そうした変化が進めば、人が作り方を一つずつ指示する場面は減っていく、というのが僕の見立てです。

ただし、いつ、どの仕事まで任せられるかは、まだ確定していません。動画の「来年には」という話も予測であって、すべての開発がその時期に置き換わるという事実ではありません。

補足すると、Anthropicの公式解説「When AI builds itself」が扱う「再帰的自己改善」は、AIが次のAIそのものを開発する話です。アプリの修正を繰り返すこととは区別が必要で、同社も完全な実現には至っていないとしています。

だから、AIに全部任せて技術の勉強をやめる、ではありません。作ったものが正しいか、安全に扱えるかを判断する基礎は必要です。お客さんの情報をどこまでAIへ渡してよいか、誰が使える仕組みにするか、公開前に何を確かめるかも、人が決めます。

そのうえで、プログラムを書く作業はAIに任せられる範囲を増やす。人は「この会社がよくなるには何を変えるか」と、「実際によくなったか」に向き合う。その分担に価値があると考えています。

雑談や現場を見る時間が、仕事の中心になる

動画で話した「残るエンジニア」は、お客さんの問題をかみ砕き、解決に必要なことを整理して、ゴールまで持っていける人です。

そのためには、会議で要望を聞くだけでは足りません。従業員さんの働き方を見る。普段の会話の中で、面倒に感じている作業を聞く。「なぜ、この順番なんですか」と尋ねる。

一見、開発とは関係なさそうな時間です。でも、そういうやり取りがないと、画面の向こう側で何が起きているのか分かりません。

僕が動画で「お金だけを追っていたら難しい」と話したのも、ここです。対価をもらうのは当然ですし、何でも無料で引き受けるという意味でもありません。目の前の発注だけを早く処理する姿勢では、相手の本当の困りごとまでたどり着きにくい、ということです。

どこまで調べるか、何を直すかは合意したうえで、相手の仕事を理解しようとする。その積み重ねが、「次もこの人に相談したい」につながると思っています。

次の案件で、最初に聞くことを変える

エンジニアなら、次の打ち合わせで「どんな機能が必要ですか」の前に、こう聞いてみてください。

「それができたら、誰の、どの仕事が楽になりますか？」

続けて、今のやり方を見せてもらう。そこで見つけた困りごとを一つ選び、AIで小さく試し、担当者と確かめる。新しいツールを追うことと、この動き方を身につけることは、並行して進められます。

開発を頼む側も、最初から正確な仕様書を用意しなくて大丈夫です。「同じ内容を何度も入力している」「担当者が休むと仕事が止まる」。まず、その場面を共有してください。

Galewestへの相談は、IT・AIシステム構築から確認できます。具体的な困りごとはお問い合わせへ。アプリの機能一覧より先に、「今、誰がどこで困っているか」を一つ書いてお送りください。