AI時代に生き残るエンジニアの「非技術スキル」

実装は速くなったのに、リリースは速くならない

生成 AI を使い始めて、コードを書く時間は明らかに短くなりました。前なら半日かかった処理が、一時間で形になる。それなのに、機能が世に出るまでの日数は前とほとんど変わっていない。心当たりのある人は多いはずです。

短くなったのは、工程全体のうちの一部だけだからです。何を作るかが決まらずに止まっている時間、関係者の合意が取れずに待っている時間、レビューの順番待ち。実装が十倍速くなると、これらが相対的に大きく見えてきます。AI が手を速くするほど、詰まる場所は人と人のあいだへ移っていきます。

だから今、価値が上がっているのは、書く速さではなく、その前後にある力です。

「これ作って」の、前を聞く

依頼をそのまま実装するのは、AI が最も得意とする仕事です。人がやるべきことは、その前に一つ挟まっています。

「このボタンを赤くして、押したときに派手な演出を入れてほしい」と頼まれたとします。そのまま作れば十五分で終わります。ただ、なぜ目立たせたいのかを聞くと、「申し込みが少ない」という話が出てくることがあります。それが本当の困りごとなら、色より先に、入力項目の多さや、ボタンに辿り着くまでの導線を見たほうが効くかもしれません。

聞くのは難しいことではなく、次の二つで足ります。それによって誰のどんな困りごとが減るのか。それを減らす方法として、作る以外の手はないか。この二つを確かめてから作ると、作ったのに使われなかった、という結末をかなり減らせます。

依頼を疑う姿勢と受け取られないよう、順番だけ気をつけてください。先に「やります」と伝えてから、目的を確認すると、話がこじれません。

AI の出力を、通す人になる

AI は、存在しないメソッドを自信たっぷりに提示することがあります。古い書き方をそのまま出してくることも、セキュリティ上まずい実装を混ぜてくることもあります。

問題は、出力が例外なく読みやすいことです。整った形で出てくるものは、正しく見えます。だからこそ、動いたかどうかではなく、なぜ動いたかを説明できるかで受け入れを決めてください。説明できない箇所が残っているなら、それはまだ自分のコードではありません。

ここには、技術以外の判断も含まれます。個人情報をどこまで外部のサービスに渡してよいか。生成された文章や画像の扱いに問題はないか。こうした線引きは、最後は人が引き、人が責任を負います。エンジニアの役割は「書く人」から「通す人」へ動いていて、通した以上は理由を説明できることが求められます。

一分で説明できないものは、通らない

もう一つ、価値が上がっているのが、技術の話を技術者以外に伝える力です。

「今の設計だと同時アクセスが増えたときに落ちるので、作り直したい」とだけ言っても、予算を決める側には判断ができません。「今の作りのままだと、利用者が三倍になった時点で表示が止まる可能性があります。作り直しに二週間かかりますが、後からだと停止中の対応も必要になるので、今のほうが安く済みます」と言えば、判断できます。専門用語を減らし、影響と時間と選択肢の三つに置き換えるだけです。

これは相手のための配慮であると同時に、自分の理解の確認でもあります。専門用語を使わずに説明できないなら、まだ自分がその技術を掴みきれていない、という合図として使えます。

技術力は土台として要ります。そのうえで、何を作るかを問い、出てきたものを通し、それを人に伝える。この三つを持っている人は、AI が速くなるほど手が足りなくなります。今関わっている開発の目的を、チームの誰かと言葉にしてみるところから始めてください。