1954年、IBMのチームがある報告書にこう書きました。
この仕組みを使えば、コーディングとデバッグは事実上なくなる。
その仕組みの名前は、FORTRANです。
同じ話は、形を変えて70年繰り返されてきました。今は「AIでエンジニアの仕事がなくなる」「プログラミングを学ぶ意味はあるのか」という形です。
ただ、この手の話はいつも、何がなくなるのかがはっきりしません。コードを書く作業なのか、エンジニアという役割なのか。
そこで、エンジニアを1つの関数として捉えてみることにしました。
output = engineer(input)
この関数は何を受け取り、何を返すのか。AIに任せられるのは、その中のどの部分なのか。関数として書き出してみると、漠然とした不安の正体が見えてきました。
エンジニアは何をインプットとし、何をアウトプットすることを期待されているのか
まずインプットです。
僕がエンジニアとしてこれまで受け取ってきた要望には、大きく2種類ありました。
「こういう課題を解決したい」と課題で来るものと、「こういう機能が欲しい」とHowで来るものです。
Howで来たときに言われた通りに作るのは、個人的には二流だと思っています。その機能で何を解決したいのかまで立ち返らないと、正しいものは作れません。つまりこの関数の最初の仕事は、インプットを課題の形に戻すことです。
ではアウトプットは何か。コードではありません。課題が解決された状態と、それを維持できる構造です。
「維持できる」を入れたのには理由があります。エンジニアの判断には、要件のどこにも書かれていないものが多いからです。
- メンテナンスが止まったライブラリは、いずれセキュリティ上のリスクになる。だから選ばない
- 採用や技術の流れを見て、あえて新しい技術に賭ける
- コストとセキュリティが釣り合う構成を選ぶ
機能要件にも非機能要件にも書かれていないのに、これらはアウトプットの良し悪しを決めます。効いてくるのは納品した瞬間ではなく、半年後や1年後です。
AIに任せられること、人に残ること
関数の中身をもう少し分解してみます。
def engineer(input):
problem = clarify(input) # Howを課題に戻す ← AIは壁打ち相手
spec = specify(problem) # 要件に落とす ← AIが手伝う
options = design(spec) # 設計案・技術の候補を出す ← AIが大きく担う
decision = decide(options) # 正解のない中で選ぶ ← 人
code = implement(decision) # 実装する ← AIが大きく担う
result = verify(code, problem) # 課題が解けたか確かめる ← AIが手伝う
return own(result) # 結果を引き受け続ける ← 人
AIが大きく担うのは、design と implement の2行です。設計案を並べる、ライブラリを比較する、コードを書く。ここはもう、人より速くて、精度も高い。
では decide もAIに任せられるのか。ここは「選択」と「意思決定」を分けて考えています。
基準が決まっていて、その中で一番良いものを選ぶのが選択です。これはAIの得意分野です。一方で、正解がない中で何を優先して何を捨てるかを決めるのが意思決定です。枯れた技術で安定を取るか、採用を見据えて新しい技術に賭けるか。AIは両案の長所と短所を僕より上手に並べてくれます。でも「こっちに賭ける」と決めて、外れたときに矢面に立つことは、AIにはできません。
最後の own には知識が要ります。評価できないものに責任は持てないからです。AIの出力を読めない人が「責任を持ちます」と言っても、それは署名しているだけで、検証はしていません。技術の知識は、責任を負うための資格だと思っています。
よく「PMが直接AIに頼めば、エンジニアはいらなくなる」と言われます。この関数で考えると、そのときAIの出力を検証して引き受けるのはPMです。エンジニアが消えたのではなく、PMがこの関数の役割を担っただけ、ということになります。
冒頭のIBMの報告書は、工程を「分析とプログラミング」「コーディング」「デバッグ」「実行」の4つに分け、なくなるのはコーディングとデバッグだけだと書いていました。今の関数で言えば implement の行です。
同じように今の関数を見ると、AIによってなくなるのは、design で候補を洗い出す手間と、implement で手を動かす作業です。それ以外は、人の側に残ります。
コードを書くだけの仕事が減っているのは事実
ここで終えると「だから安心」と言いたくなります。でも、数字はそう言っていません。
米国労働統計局は、ソフトウェアに関わる仕事を2つの職種に分けて集計しています。
| 職種 | 仕事の中身 | 人数の推移 |
|---|---|---|
| computer programmers | 開発者が作った設計をコードにする | 2010年 約36万人 → 2025年 約11万人（約7割減） |
| software developers | ソフトウェアそのものを設計する | 2010年 約91万人 → 2025年 約172万人（約1.9倍） |
computer programmers は、この関数で言えばほぼ implement の行だけを担う職種です。どちらの数字にも職業分類の改定による影響が含まれているので、差の全部が仕事そのものの変化とは言えません。それでも、コードを書くだけの仕事が減っている傾向ははっきりしています。
若手にも影が差しています。米国の給与データを使ったStanfordの研究では、AIの影響を受けやすい職種の22〜25歳の雇用が、影響を受けにくい職種の同世代と同じペースで推移していた場合より19%低くなっていました。エンジニアに限った数字ではありませんが、ソフトウェア開発者は最も影響を受けやすい層に入っています。主な原因は採用の減少です。ただし著者自身が、これは因果関係を示すものではないと明記しています。
エンジニアという仕事そのものは、なくなっていません。ソフトウェアを設計する側の人数は、むしろ増えています。狭まっているのは、implement の行だけを自分の仕事にしている人の居場所です。漠然とした不安の正体は、ここにあるのだと思います。
この整理には、成り立たなくなる条件もあります。decide と own までが、人を介さずにAIと依頼者の間だけで完結するようになれば、この話は崩れます。単に、今の社会の仕組みがそうなっていないというだけの話でもあります。
プログラミングを学ぶ意味はあるか
僕の答えは「ある」です。ただし、学ぶ目的が変わります。書けるようになることではなく、AIの出力を読んで判断し、引き受けられるようになることがゴールです。
AIの出力は、たいていもっともらしく見えます。それを疑えるかどうかは、自分の中にある知識と経験で決まります。批判的に考える力は、何もないところからは生まれません。プログラミングを学ぶのは、責任を負うための資格と、AIを疑うための土台を手に入れるためです。
具体的には、AIに任せきれない行を鍛えるために、次の3つを意識しています。
-
clarify：Howで来た依頼を、一度課題に戻してから作る -
decide：AIの提案を採用するとき、その理由を自分の言葉で言えるか確かめる -
own：作って終わりにせず、運用まで面倒を見る経験を取りに行く
ただし、上の関数に付けた「← AI」「← 人」の印は、今の時点のものです。コーディングエージェントの進化は速く、何をAIに任せて何を人が担うかの境目は動き続けます。少し前のAIの印象のまま考えていると、本来はAIに任せるべきことまで自分で抱えてしまい、かえって速さも精度も落ちます。だから、最新のAIに何ができるのか、いつもアンテナを張っておく必要があると思っています。新しいモデルが出たら、前は任せきれなかった作業をもう一度任せてみる。それだけでも、境目がどこまで動いたかは分かります。
気がかりなこともあります。判断力は実装の経験で育つのに、AIが実装を担うほど、その経験を積む機会は減っていきます。若手の入口が狭まっているのも、同じ問題の表れだと思います。この問題への答えは、正直まだ持っていません。
冒頭の報告書から70年以上経った今、機械語を手で書いているエンジニアはほとんどいません。コーディングの手間は大きく減りました。それでもエンジニアはいなくならず、空いた手で、もっと大きなものを作るようになりました。
AIでも同じことが起きると、僕は考えています。手を動かす作業はAIに任せて、インプットを問い直し、決めて、引き受ける。そこに使える時間が増えることが、AIによる進化なのだと思います。
参考
- J.W. Backus, H. Herrick, I. Ziller（IBM Programming Research Group）, Preliminary Report: Specifications for the IBM Mathematical FORmula TRANslating System, FORTRAN（1954年11月10日）
- U.S. Bureau of Labor Statistics, Computer Programmers / Software Developers（Occupational Outlook Handbook）
- Brynjolfsson, Chandar, Chen, Canaries in the Coal Mine?（Stanford Digital Economy Lab, 2025, 2026年8月改訂）