AIで“できてしまう”時代に、エンジニアはどう学び、どう働くか

先日、ShiftBのオフ会の作業会で、ざっくばらんに話す機会がありました。現役で現場に立っている人、これから転職を目指して学習中の人、受講生をサポートしている人。立場はバラバラなのですが、話していくうちに「結局みんな同じところで悩んでるな」というテーマがいくつも浮かび上がってきました。

キーワードは、やっぱり AI です。AIで開発が爆速になった結果、現場で何が起きているのか。学習者は何にハマるのか。これから転職する人はどう動けばいいのか。少し長くなりますが、当日出てきた本音を、できるだけそのまままとめてみます。

AIで開発は速くなった。でも“タスクマシン”になっていく

まず現場の話。AIで実装が速くなったぶん、求められる生産性も上がりました。その結果みんなが口を揃えたのが——

という感覚です。一つのタスクが終わる前に次が降ってくる。常に2〜3個抱えている。「できてます」と言った瞬間に「じゃあ次これ」が来る。だから、できていてもあえて隠しておこうかな……なんて冗談まで出るくらい、追われている。

そして怖いのが、開発している時間の中で、自分が学べることが減ってきているということ。理解に時間をかけるより、とにかくタスクを終わらせてくれ、と言われる。動いてるならいいじゃん、で進んでいく。脳死でも開発できてしまう。長期的にはマズいと全員わかっているのに、時代がそうなってしまって後戻りできない。「なんでそんなに遅いんですか?」と言われる空気の中で、「いや、ちょっと理解したいんですけど……」とは言いづらいんです。

AIが発達してから、QiitaやStack Overflowもほとんど開かなくなりました。Stack Overflowに至っては「私も同じ問題を抱えています」というコメントしか残っていない——というくらい、Q&Aサイトの役割そのものが変わってしまった。だからこそ、本当に勉強になる記事や公式ドキュメントを自分でしっかり読むというアプローチが、逆に効いてくる時代になっています。

「AIで安くできるでしょ」の罠

タスクマシン化の延長で出てきたのが、安受けの話です。「AIでできるんだから、安くできるでしょ?」——こう言ってくる人は一定数いる。でも、ここで安く受けてしまうと、それが業界の基準になっていく。誰かが安く受けるほど「それが普通」になって、まわりまわって自分の首を絞めます。

似た構造で危ないのが、ヒーローパターン。無茶な要望を、誰かが自己犠牲で解決して「できた風」に見せてしまう。すると「できるやん」と要求がエスカレートしていく。組織的には絶対に良くない。

社員を減らしてもAIで回った、という実績を作ってしまうと、本当はギリギリだったのに「いける」と思われてしまう。個人でやるならAIは恐ろしく強い武器ですが、組織で“無理やり回す”ための言い訳にしてはいけない、という話でした。

個人開発では神。でも、組織ではまだ難しい

ここが面白かったところ。AIの評価が、個人開発と組織でくっきり分かれるんです。

• 個人開発:AIは圧倒的な武器。むしろこれがないとリリースまで持っていけない。一人で戦うための生命線。

• 組織:まだまだ“改善の余地”の段階。上手に使いこなせていない。

特に教育の観点で深刻なのが、「AIに頼らないと何もできない人」の存在です。指示を受けた新人が、その指示をそのままAIに投げて、返ってきたPRをそのまま出してくる。レビューする側からすると「それなら自分でAIに投げたほうが早い」となってしまう。

教育コストをかけられる大企業なら、新卒を採ってAIの扱い方からコントロールして育てられるかもしれない。でも、中小ではそこまで面倒を見きれない。「教える価値がない」とまで言われてしまう状況が、現実に起きています。

学習者がハマる最大の罠は「意図を語れない」こと

では、AIを使う学習者は何に気をつければいいのか。出てきた答えはシンプルでした。

「意図は?」と聞かれて「意図もクソもない、AIが出してきて、いいと思ったから」では、現場では通用しません。AIが書いたコードを“理解した気になる”のと、自分で書いて理解しているのとでは、アウトプットが全然違う。

難しいのは、ここにスピードとのジレンマがあること。「AIを使って早く実装しろ」と言われる一方で、「自分で完全に理解してやってくれ」とも言われる。でも、自分で全部書いて理解しようとすると、当然スピードは落ちる。両立は無理——という境界に、みんなぶつかっています。

これは指示する側の問題でもあります。じっくり育てる余裕のある会社なら、あえて自分で書かせて学ばせることもできる。でも今は、その「余裕」がある現場のほうが少ない。だからこそ、学習段階のうちに「自分で書いて理解する」筋肉を作っておくことの価値が、相対的にどんどん上がっています。

それでも勝つのは「分からないけど、進む」人

学習の話で、全員が強く同意したのがこれです。

分からないことを全部分かってから進もうとすると、いつまで経っても先に進めません。実際、つまずきやすい章(ShiftBで言うと6章あたり)で1ヶ月止まってしまう人もいる。

大事なのは、「分からないけど、とりあえずやる」。違っているところは、レビューで正せばいい。本当に分からないところだけ、TAやメンターに聞く。「これでいいか分からないけど、とりあえずレビューに投げる」——それでいいんです。レビューしてもらえる環境があること自体が、めちゃくちゃありがたいことなので。

完璧主義で半年間ずっと同じところをやっている人と、分からないなりに進んで自走している人。自走力という観点では、間違いなく後者が伸びます。どれだけ粘ったって、最初から完璧にはなれない。基礎の基礎なんだから、分からないものは分からないと割り切って、次に進む。

ただし——「分からないと割り切っていいもの」と「割り切っちゃいけないもの」の線引きが、初心者には難しい。ここの判断を支えるためにも、人に聞ける場やレビュー環境を使い倒すのが正解、という話でした。

実務課題とGitHub —「今のうちに失敗しておけ」

学習の話で、もう一つ強く出たのが 実務課題をちゃんとやろう ということ。実務課題をやらないと、提出できる成果物が手元に残らないし、何よりGitHubでのチーム開発を一度も経験しないままになってしまう。セキュリティやAI駆動開発の課題も増えている今、ここを飛ばすのは本当にもったいない。

GitHubは、最初はみんなつまずきます。実際にあった話として——

• mainブランチに直接pushしてしまう

• 何度かやり直しをお願いしても、また同じことをやってしまう

最初の数回はしょうがない。だから優しく、コマンドを示しながら「こうやればやり直せるよ」と伝える。でも、何度も続くなら、傷つけないように配慮しつつ、作り直してもらったほうが本人のため。今なら、いくらでも失敗できるからです。

今のうちに、安全に失敗しておきましょう。

進化が速すぎる —「1ヶ月前の情報はもう古い」

AIそのものの進化スピードについても盛り上がりました。ある時期は「Codexが最強」と言っていたのに、2ヶ月後には「Claudeが最強」、そして「Antigravityがすごい」……と、最強がコロコロ入れ替わる。AIがAIのモデルを改良していくので、人間が組んでいた頃とは比較にならない速さです。

象徴的なのが、Claude Codeの Skills の話。少し前はSkillsの解説記事がYouTubeにバーッと出ていたのに、今はほとんど出ない。もう「設定できて当たり前」になって、解説する間もなく次の機能、次の機能へ進んでいく。

CLAUDE.md や AGENTS.md の書き方のノウハウも、1年前と今では全然違います。昔は「こう細かく書いたほうがいい」と言われていたのに、今はモデルが賢くなったので、余計なことはあまり書かない方向になっている。

この速さに、人間が「調べて・実践して・記事にする」のはどうしても一歩遅れる。だから情報源としては、モデルを出している会社の公式サイトを見るのが一番早い。なんなら、その公式情報をAIに読ませて解説させるのが最速、という結論になりました。

そんな環境でも、判断力を持つために自分の手で書くことは、まだまだ必要。AIが何でも書いてくれる中で「あえて自分で書く」モチベーションを保つのは矛盾しているようで心がざわつくけれど、その地力こそが、AIの出力を正しく評価できる人とそうでない人を分ける、という話でした。

技術選定より「課題解決」— これがエンジニアの本質

転職や面接の文脈で出てきた、刺さる話。昔は、ライブラリ一つ使うにも「どんな選択肢があるか」を自分で必死に調べて、比較して、判断して取り入れていました。今はAIが「これがオススメ」と即提案してくれて、合わなければすぐ別のを試せる。試すハードルが劇的に下がった反面、自分の知識として落とし込む前に動いてしまうという難しさもあります。

そして面接でよく聞かれるのが「なぜこの技術を選んだんですか?」。これに対する、ちょっと逆説的な本音がこれ。

他がダメだった理由を完璧に語るのは難しい。だから、「他と比べて、これを選んだ理由」を、自分の作りたいものに引きつけて語れればいい。たとえば認証や面倒なインフラはSupabaseに任せて楽をする。なぜなら——

自分が価値を発揮したいのは、そこ(インフラ)じゃない。課題を解決することが、エンジニアの仕事だから。MVP(最小限の機能)で素早くサービスを届けたいなら、本質でないところ(どこにホスティングするか、細かいインフラ)に時間を割いている場合じゃない。自信を持って使えて、ある程度仕組みを理解しているフレームワークを選んで、最短距離で課題解決に向かう。これでいい。

だから面接でも、ちっちゃな技術の細部より、「どういう経緯でこのアプリを作って、どうなったのか」を、セールスマンみたいに熱量を持って語れるほうが強い。「技術なんてどうでもいい、このサービスを使いたいと思わせてくれ」——少し極端ですが、求められているのはそっちの方向だよね、と全員うなずいていました。

働き方の現在地 — 常駐かフルリモか、正社員かフリーランスか

最後に、働き方の話。これも面白い本音がたくさん出ました。

正社員 vs フリーランス。結論、フルリモ・フルフレックスの正社員と、フルコミットのフリーランスは、条件だけ見ればあまり変わらない。企業側からすると、正社員は切れなくなるので、業務委託のほうがコスト的に動きやすい面もある。

ただ、最初からフルリモを目指すのはおすすめしない、という声が多かったです。理由は、現場(出社・常駐)でしか学べないものがあるから。

• 自分に向けられた会話以外も見える。「AさんとBさんがこういうやり取りをしている」「ここで注意が入った」——そういう現場の空気や人間関係は、フルリモだと見えない。

• フルリモはテキストコミュニケーションが中心になる。主語が抜ける、文脈がずれる、捉えられ方が変わる……対面なら一瞬で済む確認に、めちゃくちゃ気を使う。

• フルリモで寂しくなって病む人も、実際にいる。共感できなくても現実としているので、自分がそのタイプかどうかは知っておいたほうがいい。

なので、最初の1年は常駐や出社で現場の空気と人となりを学んでから、フルリモにするか決める——というのが、概ねの共通見解でした。

そして、ちょっと毛色の違う選択肢として出たのが 株でもらう働き方。給料の代わりに(あるいは加えて)株やレベニューシェアで関わる形です。会社の価値が上がる=自分の持ち株の価値が上がる、という構造なので、思考回路が「課題解決」から「会社の価値を上げる」に変わる。スタートアップが数年でExit(売却)できれば、大きなリターンになる可能性もある。

ただし当然、株はただの紙切れになるリスクも背負っている。ストックオプションも、税制適格かどうかで手取りが大きく変わる(権利行使した時点と売却時点の二重で課税される非適格のケースなど)。日本の税制は、買った時点の差額で課税されるなど、なかなか厄介。「夢はあるけど、リスクも仕組みもちゃんと理解した上で乗る」もの、という温度感でした。

エンジニアとしてどう生きるかは、結局「技術を突き詰めるのが気持ちいい人」と「スピード感を持ってお客さんのニーズに応え、成長していくのが楽しい人」で、合う働き方が違う。どちらが正解ということではなく、自分がどっちなのかを知っておくのが大事だね、という話で締まりました。

まとめ — 変わったもの、変わらないもの

長くなりましたが、この日の話を一言でまとめると、こうなります。

変わったもの

• 開発スピードと、求められる生産性(タスクマシン化)

• 情報のキャッチアップの仕方(Qiita/SOより公式、1ヶ月前はもう古い)

• 技術選定や試行錯誤のハードル(AIで一瞬)

• 働き方の選択肢(フルリモ、業務委託、株という関わり方)

変わらないもの

• 「なぜそうしたか」を自分の言葉で説明できること

• 分からなくても進む自走力

• 痛い目を見て学ぶ(GitHub、チーム開発の失敗)

• そして、課題を解決することこそがエンジニアの仕事だということ

AIで“できてしまう”からこそ、何を自分の頭で考え、何を手で書いて身につけるか。その線引きが、これから一番効いてくる。

これから学ぶ人も、もう現場にいる人も、お互いに本音を言い合えるこういう場って、やっぱりいいですね。また集まって話しましょう。