AI時代に、エンジニアを目指す意味はあるか

結論から言います。

意味はあります。しかも、AIがコードを書けば書くほど、その意味は増えていくと思っています。

理由は単純です。AIが書いたコードを検証できて、中身を説明できて、動かなかったときに責任を取れる人が、書かれるコードの量に対して足りていない。書ける人が増えるほど、検証できる人の希少価値が上がる。AIは増幅装置で、どちら側に増幅されるかは基礎で決まります。 この記事で言いたいことは、これで全部です。

この問いが出てくる理由は分かります。AIがコードを書く速さを一度でも見れば、自分がこれから何ヶ月もかけて学ぶ意味を疑うのは自然です。その速さは、私も現場で見ています。そのうえで、意味はあると言っています。

ただ、この結論だけ聞くと「AIがあっても大丈夫」にも「AIがあるから無理」にも読めてしまいます。どちらでもないと言うためには、何をAIがやって、何を人がやるのかを、分けて話す必要があります。

なので、3つの円で考えます。AIができること。AIと人が重なるところ。人がやること。目指す意味があるのは最後の円で、そこに立てるかどうかを決めるのが基礎です。順番に書きます。

AIができること

今年の第1四半期、App Storeの新規アプリは前年同期比で80%増えたそうです。Appfiguresの集計をTechCrunchが伝えていました。

AIがコードを書くようになって、アプリを「作れる人」は爆発的に増えました。

これは事実として認めたほうがいいと思っています。文法を知らなくても、画面を設計したことがなくても、「こういうものが欲しい」と日本語で伝えれば、動くものが出てくる。少し前なら、本を読んで、環境を作って、エラーと格闘して、ようやく画面に文字が出るところまでで何週間もかかっていました。それが、いまは一晩で形になります。

AIが得意なのは、すでに世の中に山ほどある書き方を、要望に合わせて組み立て直すことです。ログイン画面、一覧と詳細、フォームの保存。こういう「どこにでもある部品」は、AIが最も速く、最もそれらしく書きます。世の中のアプリの大半はこの部品の組み合わせなので、作れるものの範囲は、思っているより広いです。

作れる人が増えたこと自体は、いいことだと思っています。作りたいものがあるのに作れなかった人が、作れるようになった。使える道具が増えたと考えれば、歓迎する話です。

そのうえで、線を引いておきます。コードを書く速度と量で、人はもうAIに勝てません。 ここで勝負しようとするのは、やめたほうがいいです。タイピングの速さで競うようなもので、勝てないだけでなく、勝ったところで意味がありません。

で、うちに来る相談も増えました。

「AIで作ったんですが、直せますか」

この一言に、AIができることと、できないことの両方が入っています。作れた。でも直せない。作れたところまでがAIの円で、直せないところから先が、この記事の話です。

重なるところ

うちは受託開発の会社なので、AIが書いたコードのその後を見る側にいます。

動くんですよ、最初は。それっぽく。

画面はきれいで、ボタンを押せば反応して、データも保存される。作った本人は、自分でも驚くくらいのものができたと感じていると思います。実際、そこまでは本当にできています。嘘ではありません。

問題はその先です。仕様を少し変えたい。データが増えた。エラーが出た。そうなったとき、作った本人が中身を説明できない。

説明できないので、AIに聞きます。するとAIは、前回と違う答えを返す。前回のコードを踏まえて直しているのか、別の方針で書き直しているのか、本人には判断がつかない。判断がつかないまま貼り付けると、動いていた部分まで動かなくなる。何度か繰り返して、どこが正しかったのかも分からなくなったところで、「直せますか」になります。

答えが毎回変わるのは、AIの欠陥というより性質です。同じ質問をしても、少しずつ違う答えが返る。読める人にとっては選択肢が増えるだけですが、読めない人にとっては、どれを信じればいいかが分からなくなる。同じ性質が、片方には便利さとして、もう片方には迷いとして返ってきます。

この状態を、私は「重なるところ」だと思っています。

コードを書くという行為そのものは、AIと人の両方ができるようになりました。ここは完全に重なりました。重なった以上、この部分の値段は下がります。「書けます」だけでは、もう仕事になりません。数年前なら「書ける」は立派な差でしたが、いまは差ではなく前提です。

これは、書ける人にとって悪い話に聞こえるかもしれませんが、私はそう思っていません。書くところで消耗しなくてよくなったぶん、その先に時間を使えるようになったので。

ただし、重なっているのは「書く」までです。書いたものを読んで、なぜそう動くのかを説明して、変えたらどこに影響するかを見通す。ここは重なっていません。 AIもそれらしいことは言いますが、言われた側がそれを確かめられないなら、確かめていないのと同じです。

ソフトウェアの仕事は、書いて終わりではありません。書いたあとのほうが長い。仕様は変わるし、データは想定より増えるし、動いていたものは周りの環境が変わると止まる。他人が書いたコードを読んで、直して、また別の誰かに読まれる。現場で時間を使っているのは、実は最初に書く工程ではなく、この「書いたあと」の工程です。AIが書けるようになったのは、主に最初の工程のほうで、あとの工程は、いまも誰かが引き受けなければ進みません。

「直せますか」と持ってこられたコードは、まさにこの「あと」の工程に入った瞬間のものです。書く工程はAIが済ませて、あとの工程を引き受ける人がいなかった。それだけの話です。

人がやること

ある記事で、企業が「バイブコーディングで作ったツールは、使用前に情シスのチェックを申請すること」というルールを作った話を読みました。

これ、笑ってしまったんですが、笑いごとじゃないんですよね。

情シスが、素人がAIに書かせた謎のコードを、いくつも読んで直して回る。そんな時間、現実にあるでしょうか。ないです。情シスは元々、社内のパソコンからネットワークから権限の管理まで、全部の面倒を見ていて、それだけで手一杯です。そこに、誰が何の目的で書いたのかも分からないコードが、部署ごとに届く。

ルールを作った会社は、たぶん正しいことをしています。チェックしないまま社内で使われるほうが怖い。ただ、そのルールが機能するためには、チェックできる人が要ります。そして、その人は増えていません。

増えない理由も単純で、検証できる人を作るには時間がかかるからです。書ける人はAIの登場で一気に増えましたが、読める人は、以前と同じ速度でしか増えません。

つまりこうなります。書ける人が増えるほど、検証できる人の希少価値が上がる。

コードの総量が増えて、その品質を担保できる人の数は増えていないので。

人がやることを、もう少し具体的に言います。3つあります。

ひとつめは検証です。動いているように見えるものが、本当に要件どおりに動いているかを確かめる。エラーが出て止まるものは分かりやすい。厄介なのは、エラーが出ないまま違うことをしているコードです。数字がひとつずれている、ある条件のときだけ保存されない、見えてはいけない人に見えている。どれも画面は普通に開きます。これは、読める人にしか見つけられません。検証は、疑うところから始まります。動いているから正しい、ではなく、正しいから動いている、と言えるまで確かめる。この順番を知っているかどうかが、読める人と読めない人の差です。

ふたつめは説明です。「なぜこう書いたのか」「ここを変えると何が起きるのか」を、発注した人や、次に触る人に言葉で伝える。説明できないコードは、誰にも引き継げません。引き継げないコードは、作った人がいなくなった瞬間に、誰も触れない箱になります。発注した側は、たいていコードを読みません。読めないから頼んでいます。だから説明できる人がいないと、発注した側は、自分が何を持っているのかも分からないまま使い続けることになります。

みっつめは責任です。「これで大丈夫です」と言うこと。言った以上、動かなかったら直す。壊れたら対応する。仕事としてコードを納めるとき、お金が発生しているのは、実はコードそのものではなく、この一言に対してです。

この3つは、AIができることと重なっていません。AIは検証らしいことも説明らしいこともしますが、その結果を引き受けることはしない。引き受ける人がいて、初めて仕事として成立します。

そして、この3つは書く力の上に乗っています。書いたことがない人は、読めません。壊したことがない人は、どこが壊れやすいかを知りません。検証できる人が急に増えない理由はここにあって、近道がないからです。

エンジニアを目指す意味があるとすれば、ここです。AIの円に入ることではなく、この円に立つこと。ここが答えです。

脅しで終わらせたくないので

ここまで書くと「AI怖い」の記事になってしまうので、逆側も正直に。

AIのおかげで、学習は確実に速くなりました。昔なら書籍を3冊読んでいた内容が、対話で確かめながら進められる。分からない単語をその場で聞ける。書いたコードがなぜ動かないのかを、夜中でも聞ける。うちの受講生も普通にAIを使って学んでいます。禁止する理由がありません。

使い方には向きがあります。出てきたコードをそのまま写して先に進むと、AIの円に入っただけで終わります。なぜそう書くのか、ここを変えるとどうなるのかを聞きながら進めると、同じ道具が基礎を作る側に働きます。道具は同じで、聞き方が違うだけです。

これは学習だけの話ではありません。基礎がある人がAIを使うと、単純に速くなります。読めるので、出てきたコードのどこが怪しいかがすぐ分かる。説明できるので、AIに何を直させればいいかを的確に指示できる。責任を持てるので、AIの出力をそのまま納めるか、手を入れるかを自分で判断できる。

要は、AIは増幅装置なんです。基礎がある人の生産性を増幅するし、基礎がない人の「動くけど説明できないもの」も増幅する。

同じ道具です。差が出るのは道具の側ではなく、使う人の側にあるものです。

どちら側で増幅されるかは、基礎で決まります。

だから「AIがあるから基礎はいらない」は、順番が逆だと思っています。AIがあるからこそ、基礎の有無が、以前より大きな差になって返ってくる。基礎がない人は、以前なら「書けない」のところで止まっていました。いまは「書けるが説明できない」まで進んでしまう。止まらないぶん、あとで戻る距離が長くなります。

ここで言う基礎は、文法の暗記のことではありません。コードを読んで、なぜそう動くのかを追えること。データがどこから来てどこへ行くかを、頭の中で描けること。何が壊れやすくて、壊れたときにどこを見ればいいかを知っていること。この3つがあると、AIの出力に「違う」と言えるようになります。言えるようになった瞬間から、AIは増幅装置として、いい側に働き始めます。

だから、意味はあります

3つの円に戻ります。

AIができることは、これからも増え続けます。ここで人が競う必要はないし、競っても勝てません。

重なるところは、値段が下がります。「書けます」だけの人は、AIと同じ土俵で比べられます。

人がやることは、残ります。それどころか、AIが書く量が増えるほど、検証して、説明して、責任を取る仕事は増えます。書かれたコードの量に、その仕事の量は比例するので。

エンジニアを目指す意味は、この最後の円にあります。目指すべきなのは「AIより速く書ける人」ではなく、「AIが書いたものに、大丈夫ですと言える人」です。そこに立つには時間がかかります。文法を覚えるだけなら短くて済みますが、読んで、説明して、引き受ける力は、そこから先の話なので。

逆に言えば、時間をかける価値が、いまほどはっきりしている時期もないと思っています。書く工程はAIが引き受けてくれるので、学ぶ側は最初から「読む」「説明する」「引き受ける」に時間を使えます。AIが書けば書くほど、それを引き受けられる人の値段は上がります。 目指す意味は、減っていません。増えています。

これから学び始める人に言いたいのは、AIと競う準備はしなくていい、ということです。競う場所はそこではありません。AIが書いたものの隣に立って、読んで、大丈夫かどうかを言う。その場所は空いていて、これからもっと空きます。

AIはコードを書きます。責任は書きません。

責任を書ける人になるために、うちは18ヶ月使っています。

※この記事はゆめさくエンジニアの代表が書いています。