プログラマーの仕事は、
AI でなくなるのでしょうか？

なぜ「プログラマーはなくなる」と言われるのか

そう言われる理由の一つは、以前なら人が何時間、何日もかけて書いていたコードを、生成AI が短時間で作れるようになってきたことです。条件が明確であれば、実用に近いコードが一発で出てくることもあります。既存コードの修正、エラー原因の調査、似た処理の展開なども、AI に任せられる場面が増えました。

ここだけを見ると、「それならコードを書く人はいらなくなるのではないか」と考えるのも自然です。ただ、業務システムを作る仕事は、もともとコードを書くことだけではありません。

生成AI を使っていて強く感じるのは、AI は「条件が明確な仕事」にはとても強いということです。反対に、何を作りたいのかが曖昧なまま「いい感じに作って」と頼めば、一見それらしいものはできても、こちらの意図とは違うものになることがあります。

つまり、AI を使いこなすためには、その前段階として「何をどのように作るのか」「どんなデータを扱うのか」「どんな操作なら利用者が使いやすいのか」を整理し、AI が理解できる条件に変えて伝える力が必要になります。コードを書く作業が減っても、この部分まで自動的になくなるわけではありません。

「上流へ行けばよい」だけではないと思う理由

AI の話になると、「これからはコードを書く仕事より、要件定義や設計などの上流工程へ行った方がよい」という意見をよく見かけます。利用者の要望を聞き、何を作るかを考える仕事が重要になる、という意味ではその通りだと思います。

ただ、「プログラマーは下流から上流へ移ればよい」と捉えるのは、少し違うのではないかとも感じています。なぜなら、AI によって変わるのはプログラミング工程だけではなく、要件定義や設計の進め方も含まれるからです。

従来は、利用者から要望を聞き、要件をまとめ、概要設計、詳細設計を行い、その後でプログラムを作る、という流れが一般的でした。そのため「上流」と「下流」を分けて考える意味がありました。

しかし AI が設計案を出し、データベース構成を考え、画面やプログラムまで短時間で作れるようになると、その境界はだんだん曖昧になります。概要設計をしている途中でプロトタイプを作り、それを見ながら要件を修正し、修正した内容をそのままプログラムへ反映する、といった進め方がしやすくなるからです。

そうなると、「設計する人」と「プログラムを書く人」をきれいに分けるより、利用者の話を聞き、AI を使ってすぐ形にし、それを見ながら一緒に考え、また直す人が必要になります。そこにこれからのプログラマーの仕事があるのではないかと思っています。

「考えてから作る」から「作りながら考える」へ

たとえば利用者から、「顧客ごとの売上を簡単に確認できるようにしたい」と相談されたとします。文章だけで要件を詰めようとすれば、「どの単位で集計するのか」「期間はどう指定するのか」「商品別にも見たいのか」「請求データと売上データは同じなのか」など、決めることが次々に出てきます。

もちろん、それらを事前に整理することは大切です。ただ、利用者自身も、実際の画面を見るまでは「自分が何を欲しいのか」をうまく説明できないことがあります。これは長く業務システムを作っていると、よく経験することです。

そこで AI を使い、まず大まかな要望からシステム概要、必要なプログラム、データベースの案を作り、簡単なプロトタイプまで形にする。それを利用者に見てもらうと、「ここは違う」「この項目も必要」「この集計はなくてもよい」といった具体的な意見が出てきます。その内容を AI に戻し、また修正する。この繰り返しなら、要件を文章だけで固めるより、利用者との認識を合わせやすくなると思います。

開発の流れは、たとえば次のように変わっていくかもしれません。

つまり、従来のように「十分に考えて、設計書を完成させてから作る」だけではなく、「まず見える形にして、作りながら考える」という開発が増えていくのではないでしょうか。

ここで大切なのは、AI が勝手に良いシステムを作ってくれる、ということではありません。むしろ逆で、AI を使って作る速度が上がるほど、「これは本当に利用者が必要としているものか」「業務の流れに合っているか」「データの持ち方に無理はないか」を人が短時間で判断する必要が出てきます。AI によって、プログラマーが考えなくてよくなるのではなく、考える箇所・ポイントが変わるのだと思います。

これからのプログラマーに求められる役割

では、そういう開発になったとき、プログラマーには何が必要になるのでしょうか。「AI に詳しいこと」だけでは足りないと思います。AI ができることは AI に任せ、その一方で、AI に任せるための条件を作り、出てきた結果を判断できることが必要です。

1. 利用者の要望を、システムの形に整理する

利用者は必ずしも「このテーブルが必要」「この画面が必要」と説明してくれるわけではありません。「二重入力をなくしたい」「毎月の集計が大変」「担当者によってやり方が違う」といった、業務上の困りごととして話すことの方が多いと思います。

そこから、システムの目的は何か、誰が使うのか、どの業務を対象にするのか、どんな機能が必要かを整理する。さらに、それを AI が理解できる形で伝える。これは、これからますます重要になると思います。

2. AI が作った設計を確認し、直す

AI にシステム概要を伝えれば、プログラム一覧、各プログラムの処理内容、必要なデータベーステーブル、項目構成などの案を出してもらうことができます。しかし、案が出たことと、その設計が正しいことは別です。

システムの目的に合っているか、必要なプログラムが漏れていないか、不要な機能が増えていないか、データの持ち方に無理がないか、後の処理に必要な項目が揃っているか。そうした点を確認し、問題があれば AI に修正を指示する必要があります。

3. コードではなく、システム全体を見る

一つ一つのコードを書く時間が短くなれば、その分、一人のプログラマーがより広い範囲を担当できるようになります。画面、データベース、帳票、集計、権限、運用までをつなげて考え、「一つのシステムとしてちゃんと動くか」を見ることが、これまで以上に大切になります。

ここでは、プログラミング技術だけでなく、業務を理解する力も重要です。たとえば同じ「顧客管理」でも、営業会社と製造業では、必要な情報も仕事の流れも違います。利用者の業務を知らなければ、AI に何を作らせるべきかを正しく判断できません。

4. 利用者と一緒に完成させる

AI で短時間にプロトタイプを作れるようになるほど、利用者との距離は近くなると思います。完成したものを最後に見せるのではなく、途中の段階から見てもらい、実際に使ってもらい、意見を聞いて直す。その繰り返しを進める役割です。

そう考えると、これからのプログラマーは、単に「プログラムを書く人」ではなく、利用者と AI の間に立ち、要望をシステムへ変換し、完成まで導く人に近づいていくのではないでしょうか。

今からプログラミングを学ぶ意味

ここまで書くと、「それなら、これからプログラミングを学んでも意味がないのでは」と思う人もいるかも知れませんが、それは違います。AI 時代こそ、少なくとも「プログラムが読める」ようになる必要があります。難しい漢字は書けなくても、読めれば仕事ができるのと同じです。また、プログラムの文法が読めるというより、処理の流れやデータの受け渡しを読み解くことができるようになることが大切です。

AI にコードを書かせるにしても、そのコードが何をしているのか、どこがおかしいのか、データがどのように流れているのかを理解できなければ、AI の出した結果を判断できません。基礎的なプログラミングやデータベースの知識は、AI を使う時代だからこそ「自分が書くため」ではなく、AI が作ったものを理解し、判断し、修正するための知識として意味を持つようになります。

初心者であればこそ、AI を積極的に使い、「なぜこの処理になるのか」「このテーブルはなぜ必要なのか」「別の書き方はないのか」と一つずつ確認していけば、従来より早く全体像を学べる可能性もあります。ただし、AI の答えをそのまま正解だと思わず、自分で動かして確かめることが重要です。

なくなるのではなく、役割が変わる

AI によって、プログラマーの仕事の一部は確実に減っていくと思います。以前は人が何時間もかけていたコード作成を、AI が数分で行う場面はこれからさらに増えるでしょう。その変化を見れば、不安になるのは当然です。

ただ、それは「プログラマーが不要になる」ということと同じではありません。コードを書く時間が減る一方で、利用者の要望を理解し、システム全体を考え、AI に適切な条件を与え、出てきたものを判断し、実際に使える形まで仕上げる仕事は残ります。そして、一人の人がそこまで広く担当できるようになることこそ、AI がもたらす大きな変化ではないかと思います。

これからのプログラマーは、「コードを書く人」から、「AI を使いながらシステムを作り上げる人」へ。

私は、プログラマーという仕事がなくなるというより、その役割がそこへ変わっていくのではないか、と考えています。