AI活用読了 約3分

プログラミングは死んでもエンジニアリングは死なない

最近、「もうプログラマーはいらなくなる」という話をよく聞きます。

実際、僕もいまコードの9割はAIに書かせています。開発環境もほとんど開かず、チャット画面で話しながらシステムを作っています。30年以上エンジニアをやってきましたが、2025年の冬に「これは行ける」と確信してから、開発のやり方はがらりと変わりました。

じゃあエンジニアの仕事はなくなるのか。僕はそうは思いません。

プログラミングは死ぬかもしれない。でも、エンジニアリングは死なない。今日はその話をします。

この記事は、動画でもお話ししています

プログラミングとエンジニアリングは違う

この2つは、よく同じ意味で使われます。でも僕の中でははっきり違います。

エンジニアリングとは、現場の課題を見つけて、何をどう作るかを決めて、作って、動かし続けること。プログラミングは、その中の「作る」の部分、コードを書く工程にすぎません。

AIが肩代わりしているのは、主にこの「コードを書く」ところです。

腕の見せ所は「何をどう作るか」

僕が一番大事だと思っているのは、「何をどう作るか」を決めるところです。

誤解のないように言うと、AIもここに答えは出してくれます。課題を伝えれば、それらしい設計を提案してくれる。ただ、出てくるのはたいてい標準的な答えです。

同じ課題でも、何をどう作るかは人によってかなり違います。そしてその差を生むのは、経験と発想力、想像力だと思っています。だから僕は今でも、AIの提案に突っ込むところがたくさんあります。

実例:AIの案と、僕の案

今年の春、通販システムのデータをAIで分析する仕組みを設計していたときのことです。

AIの提案は、売上集計や利益ランキングといった専用の機能を一つひとつ作り込み、「ダッシュボード」「解釈」「経営者向けレポート」の3層に分けるというものでした。整理されていて、教科書的にはよくできた案です。

でも僕はこう返しました。「データを取ってくる部分はデータ取得だけにして、集計や分析、改善提案はAIのスキル側にやらせたい」。

結果、データ取得の部分はほぼSQLを実行するだけの薄い作りになりました。新しい分析をしたくなったら、スキルを一つ書き足せば済む。お客様ごとに見たい数字が違っても、スキルを変えるだけで対応できます。

ほかにも、在庫連携の設計でAIが外部ツールの役割を誤解していたのを、「このツールの目的は売り越し防止だけ。逆方向の同期は要らない」と訂正したこともあります。

注文取り込みアプリの設計では、「アプリ自体が止まったら誰も気づかない」という穴をAIが指摘してくれました。ここまではAIは優秀です。でも塞ぎ方は、新しい監視の仕組みを足すのではなく、すでにある後工程のアプリに「最後に取り込んだ時刻」をチェックさせる形にしました。既存の仕組みを知っているから出せた答えです。

道具は変わっても、変わらなかったもの

僕はRPAが流行る何年も前から、VBでブラウザ操作の自動化をやっていました。それからいろいろなツールが出て、そのたびに試して、ようやくClaude Codeで「喋るだけでシステムが作れる」ところまで来ました。

道具はずっと変わり続けてきました。でも、現場の課題を見て、何をどう作るかを考える仕事は、30年間ずっと変わっていません。

AI時代にエンジニアが磨くべきもの

コードを書く力の価値は、これから確実に下がっていきます。

でも、何をどう作るかを決める力は、むしろ価値が上がると思っています。AIが誰にでも標準解を出してくれる時代だからこそ、その現場にとっての最適解を出せる人が必要になる。

プログラミングは死んでも、エンジニアリングは死なない。僕はそう考えています。


関連するコラム:

業務システムやAI活用でお悩みなら。SaaSに業務を合わせるのではなく、 その会社の業務そのものを設計し直します。

無料相談を申し込む

まず中身を知りたい方は現場開発プラン(FDE)現場アプリ内製化ブートキャンプ導入事例:システムパック株式会社・豊前市のパン屋「ぱんのこ」

Claude CodeAI活用エンジニアリングシステム設計生成AI
Author
遠藤 友治

フォワード フィールド テクノロジーズ株式会社 代表取締役。 1996年から業務システムの保守・開発に従事。官公庁・保険・製造業を経て、2007年からコンサルティング会社の開発部門を統括。2026年にFFTを創業。一般社団法人日本生成AI推進協会 技術部長。

著者の経歴・開発実績を見る
← コラム一覧へ
どちらのプランか
決めきれなくても大丈夫です
まず30分、話す