AIは「なんでも叶えてくれるもの」ではない。揺らぐエンジニア像と直面する現実

みなさんは、開発にAIを利用していますか？利用している方は、はじめて使用した時にどのように感じたでしょうか。「期待通りじゃなかったな」「アウトプットのスピードに感動した」…さまざまな感想があると思います。 

最近、私は自律型AIエージェント「Devin」を使い、フロントエンドのフレームワーク移行を検証しました。

その圧倒的なスピードと自然言語の理解力には目を見張るものがあり、20代後半でエンジニアに転身した私にとって「これでキャリアの短さを気にしなくてよくなるかもしれない」と一瞬期待しました。

関連リンク：Devin活用の現場。既存アプリのフロントエンドフレームワーク移行、その検証で学んだこと

しかし、現実はそう甘くありません。AIは決して、何でも叶えてくれるものではないのです。AIへの指示を出すのも、そのアウトプットを評価するのも、結局は人間です。 

指示が抽象的すぎると結果は安定しませんし、レビューのために設計やアーキテクチャに関する専門性は引きつづき求められます。

つまり、AIという強力な武器を使いこなせるかどうかは、使う側の「地力」にかかっており、その実力以上の成果は出せないのです。

失われる「試行錯誤」と、エンジニアの危機

AIを活用することで、コーディングやテストといった実装フェーズのスピードは劇的に向上します。しかし、これは裏を返せば「エンジニア自身が手を動かして試行錯誤する時間」が減少することを意味します。

特に、若手エンジニアや経験の浅いエンジニアにとって、「手を動かす機会の減少」は深刻な問題です。

かつては時間をかけてコードを書くことで養われた「技術的な直感」や「基礎体力」を、今後はどのように身につければよいのでしょうか。 

私自身、この変化には強い危機感を抱いています。

異業種からの転身。私の「キャリア」とコンプレックス

冒頭に少し触れたとおり、私は、20代後半で包装資材メーカーの営業職からIT業界へ転身した経歴をもちます。「キャリアの短さ」や「それによる信頼の壁」はずっとコンプレックスでした。 

「もっと手を動かして経験を積みたい」と願う一方で、前職の経験からコミュニケーション能力ばかりが評価され、現場では調整役を任されてしまう。

「口で仕事をして、手が動いていないのではないか」というジレンマや、自分の技術力不足にずっと苦しんできました。

私が抱えていた悩みと、AI時代のエンジニアが直面する課題はリンクしており、大きく3つに整理できます。

これらを解決するカギは、AIに頼る部分と、人間が磨くべき「地力」を明確に分けることにあります。

AI時代こそ、エンジニアリングの「原体験」に立ち返ろう

AIが得意とするのは「How（どうつくるか）」の実装部分です。対して、人間が担うべき領域は「Why（なぜつくるか）」と「What（何をつくるか）」の定義にシフトしています。 

これから、エンジニアの仕事は「コードを書くこと」から「課題解決を設計すること」へと重心が移るでしょう。問いを深く理解していなければ、AIに適切な指示を出すことはできません。

上流工程への理解と、課題の本質を見抜く力が、これまで以上に重要になります。

多くのエンジニアがこの道を選んだきっかけは、「自分の書いたコードで何かが動く楽しさ」や「誰かの役に立つ喜び」だったはずです。

AI時代だからこそ、この原体験に立ち返りましょう。「誰のために、なぜつくるのか」をつねに自分ごととして捉えること。その情熱と目的意識が、AIという強力なツールを使いこなすうえで必要になります。

AI時代を生き抜く「地力」の鍛え方1：実践機会の創出

では、どうすれば「地力」を鍛えられるのでしょうか。

私は「実践機会の創出」を意識的に行ってきましたが、もっとも効果的なのは、業務外で「自分自身でアプリケーションをつくり、公開してみる」ことです。 

最初はローカル環境で作成して、「つくって壊す」を繰り返しましょう。その後、誰かに使ってもらうことを前提としたアプリを作成し、公開してみるとよいと思います。

コスト意識を醸成できますし、上流から開発工程をすべて経験できます。

何より、ユーザーからフィードバックをもらえたら、モチベーションが高まります。

AI時代を生き抜く「地力」の鍛え方2：効率的なインプット

エンジニアは学ぶべき技術領域が広いため、効率的なインプットも欠かせません。そこでおすすめなのが「アクティブリコール」です。これは、「学習した内容を、何も見ずに思い出す」勉強法です。

1.　技術書を1章読んだら本を閉じる。 

2.　白紙やテキストエディタに、覚えている内容をすべて書き出す。 

3.　わからなかった部分だけを後で確認する。 

脳に「思い出そうとする負荷」をかけることで、記憶の定着率は飛躍的に向上します。ただ読むだけの受動的な学習よりも、はるかに効率的です。 

アクティブリコールに、生成AIを活用した「分散学習」を組みあわせることで、学習効果を最大化できます。分散学習とは、一度にまとめて学ぶのではなく、時間をおいて繰り返し学ぶ学習法です。 

私のおすすめの学習法は、以下の通りです。 

1.　参考書を読む。 

2.　本を閉じ、Claudeのチャット欄に学んだ内容をアクティブリコールで書き出す。 

3.　プロンプトで「上記の内容に間違いや不足があれば指摘して」と指示し、添削してもらう。 

4.　同じ内容を「翌日」「5日後」「10日後」と間隔を空けて再度テストする。 

このサイクルの利点は、AIが客観的なフィードバックをくれることです。「毎回この部分の説明が抜けています」といった指摘を受けることで、自分の知識の「穴」や苦手分野が明確になります。 

AIを「答えを教えてくれる先生」としてだけでなく、「自分の理解度をチェックしてくれる壁打ち相手」として活用することで、地力を効率的に高めることができます。

アナログな「つながり」こそが最強の武器になる

最後に、技術力と同じくらい大切なのが「人との出会い」です。エンジニアはつい技術的な会話ができる同業者とばかり交流しがちですが、本当に価値ある情報は、お客様にもっとも近い場所にあります。 

営業、マーケティング、カスタマーサクセス（CS）といった職種の人々は、「お客様の困りごと」「意外な使い方」という、一次情報を大量に持っています。

彼らと仲良くなることは、システム開発のヒント（Why/What）を得るための最短ルートです。 

私も、人との出会いに救われたことがあります。ある案件でクライアント側のデプロイ体制に問題があることが発覚した際、偶然社内イベントで知りあっていたアジャイル部門のメンバーに相談しました。

そのつながりがあったおかげで、適切な開発体制診断サービスを提案でき、クライアントの課題解決に貢献できました。もし彼らと面識がなければ、自分一人で抱え込み、解決策を見出せなかったかもしれません。 

このとき、新卒時代の上司からもらった言葉を思い出しました。 

「源泉という観点では、モノを売るのは製造や開発だ。しかし、モノをつくるのはお客様を知る営業やマーケだ」 

よりよいプロダクトをつくるためには、インサイトをもつお客様自身やマーケティング部署の人々との連携が不可欠です。

「自分たちはつくる人、彼らは売る人」という壁を取り払い、ともに価値を創造するパートナーとしての関係を築く必要がある、そういったことを教えてくれる言葉としていまも大事にしています。 

「エンジニアは忙しそうで話しかけにくい」と思われがちですが、こちらから自己開示し、顔の見えるコミュニケーションをとることで、心理的安全性が生まれます。

些細な雑談から、次の開発のヒントが生まれることは往々にしてあるのです。 

最後に、私が一番お伝えしたいこと。それは、「エンジニアをエンジニアたらしめる価値」は、これまでも、これからも変わらないということです。 

私自身、キャリアの短さをずっとコンプレックスに感じてきました。しかし、今回の登壇にあたって自分の人生を振り返ってみて、気づいたことがあります。 

エンジニア以外の仕事をしてきた時間、遠回りをした経験。それらすべてがあったからこそ、いまの私の視点があり、今日こうしてみなさんにお話しする機会をいただけたのだと。

最初からエンジニアとして最短距離を歩んでいたら、いまの自分はいなかったかもしれません。 

みなさんがこれまで出会ってきた人々、積み重ねてきた仕事、そして葛藤。そのすべてが、AIには代替できない、あなただけの「武器」になります。

エンジニアリングの本質は、単なるコード書きではありません。自分の経験を総動員して、誰かの課題を解決することです。 

みなさんのエンジニアリングが、システムを利用する方々を幸せにし、そして何より、みなさん自身の人生を豊かにしてくれることを心から願っています。 

技術の力で、私たちはよりよい未来を創造しつづけましょう。 ご清聴ありがとうございました。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）