ソフトウェア開発の未来はソフトウェア開発者にある

108日前原文(codemanship.wordpress.com)

概要

43年間のプログラマー経験から見た技術サイクルの繰り返し
**「プログラマー不要論」**の歴史的変遷とその誤り
AIやLLMの現状と限界についての批判的考察
プログラミングの本質的困難さと人間の役割の重要性
今後もプログラマー需要は続くとの予測と雇用への提言

プログラマー不要論の歴史と現実

43年以上のキャリアを通じて、何度も「プログラマー不要論」サイクルの経験
WYSIWYGやVisual Basic、Delphiなどの登場時も同様の主張
Microsoft Officeのウィザードやマクロ、Executable UML、No-Code/Low-Codeも同じ流れ
**LLM（大規模言語モデル）**も「プログラマー不要論」の最新例
1970年代・80年代の4GL/5GLやFortran、COBOL、A-0コンパイラでも同様の議論
COLOSSUSの再配線時代から続く技術進化と「真のプログラマー」論争
予測は毎回外れ、結果としてプログラマー人口とソフトウェアの増加
Jevons Paradoxの典型例としてのソフトウェア産業拡大

今回のサイクルの特徴とAIの限界

今回の「AIによる終焉」論は規模が異例
- Visual BasicやUML時代と比べ、社会的・経済的インパクトが大きい
過去の技術は本当に生産性向上を実現
- LLMは多くの現場で生産性低下や信頼性・保守性の悪化
本質的なボトルネックを解決しない限り「LOSE-LOSE」現象
プログラミングの難しさは「人間の曖昧な思考」を「論理的・形式的思考」へ変換する点
言語モデルによるプロンプト生成も本質的困難は変わらず
Edgar Dijkstraの指摘通り、自然言語による完全なプログラミングは非現実的

プログラマーの需要とAIの現状

論理的・明確な思考ができる人材の需要は常に供給を上回る
パンデミック期の過剰採用や資金流出が開発現場の混乱要因
AIがソフトウェア開発者を本格的に代替する証拠は皆無
AGI（汎用人工知能）は依然として遠い存在
AIコーディングアシスタントは過去のコンパイラやコードジェネレータとは根本的に異なる
- 同じプロンプトでも同じコードが生成されない
- 生成コードの品質問題やバグの発見・修正には依然として人間の力が不可欠
現場でのコード理解・実行はAIには困難
AI生成コードが原因の障害や事故が増加し、経営層もリスクを認識

プログラミングの未来と雇用への提言

「プロンプト＝ソースコード」論の誤りと現実の厳しさ
AIによるプログラマー終焉論は近い将来消滅する可能性大
巨大LLMの長期的な持続性や経済合理性への懐疑
- モデルの維持コストや技術的制約が大きな課題
今後は小規模なAIアシスタント（例：Java用の簡易モデル）が補助的に活躍
- プロトタイプ生成やインライン補完など限定的用途
本番環境では依然として人間のソフトウェア開発者が主導
Jevons Paradoxに従えば、今後もプログラマー需要は増加
企業への提言：今こそ優秀な人材の採用・育成が重要
- AIの有無に関わらず、納期短縮・信頼性向上・コスト削減に直結する技術習得の推進

まとめ

AI技術は過度な期待の割に、プログラマー不要論を裏付ける根拠は薄い
プログラミングの本質的困難は今後も人間の役割を保証
持続的な技術進化と人材育成がソフトウェア開発の未来を左右

Hackerたちの意見

本当にこれが真実であってほしい。自分が必要とされる存在でありたいんだ。もし予測が全部当たって、プログラマーがほとんど必要なくなったら、どうすればいいのかわからない。でも、「今回は違う」っていうのが本当に違うって感じるんだ。コーディングAIは、俺よりもソフトウェアを上手に設計して、コードをレビューして、見つけにくいバグを見つけて、長期プロジェクトを計画して、研究や文献、プロジェクトの状況に基づいて決定を下すのが得意なんだ。俺はそのプロセスの指揮者みたいなもんだよ。あ、コーディングについては聞かないで。AIを使って上記のタスクをやると、AIが得意な明確なコーディングタスクの定義が得られるよ。今はまだ雇われてるけど、まるで20人のエンジニアが必要だった仕事を一人でやってる気分だ。今の立場から見ると、ちょっと怖いよ。

└

これ、宣伝みたいに読めるね。コーディングAIは、少しでも複雑なことに苦労してるし、クソみたいなことを作って研究として提示してる。テストは「return true」みたいなもので、君が下した決定に疑問を持つこともない。あの20人のエンジニアはあまり成果を出してなかったんじゃないかな。

└

Michelin星付きレストランで11年間シェフをやってた。好きなポジションの一つは皿洗いだった。目標は常に5分サイクルで機械を動かし続けることだった。皿をラックに入れて、洗って、前のサイクルが終わるのを待ってすぐに機械に入れられるようにすることが大事だった。そして、サイクルが終わったら乾かして片付けて、品質を確認して、見逃した場所がないようにする。機械が止まったら、次のバッチを入れるために他のことを全部中断しないといけなかった。機械を動かし続けることが、皿が積み上がるのを防ぐ唯一の方法だったから、タワーが崩れて皿が割れることになる。これには素早く動く器用さが必要なんだ。AIコーディングエージェントはその機械に似てる。俺の仕事はプロンプトを書くことと、サイクルが終わった後の品質管理とハウスキーピングだよ。それでも、全自動化のように、今のところは人間がまだ必要なんだ。

└

俺のこのツールに対する経験は、全然そんなもんじゃない。もし本当に20人の組織の仕事を一人でできるなら、ビジネスを始めた方がいいよ。

└

確かに怖い部分もある。でも、俺の組織でもトレンドを見つけてるよ。優れた非AI開発者は、AIを使って開発するのが上手い傾向がある。AIはまだ要件を忘れちゃうし、今は企業向けの「SAAS置き換え」アプリケーションのデザインを試みて実験中なんだ。AIは完全に説得力のあるプロジェクト計画を出すことができるけど、誰かがその計画を実行しようとするとギャップが出てくる。ここで、適切で経験豊富な開発者が正しいタイミングで手助けできるんだ。これが新しい世界に踏み出す正しい方法かはわからないけど、少なくとも俺は自分の組織がこの技術をどう使っているかの最前線にいるように頑張ってるよ。これは、俺のスキルとAIの能力の限界を試す良いエクササイズだと思った。成功は期待してないけど。

└

AIの使い方、間違ってたかも。こういう証言、全然理解できない。AIを使おうとすると、ほとんどの場合、めちゃくちゃになって、結局全部書き直さなきゃいけないんだよね。

└

今日の時点で、知られているAIコードボットは、新卒や夏のインターンを面接するために使う50以上のプログラミング演習を正しく解くことができるものは一つもない。ゼロだよ！中学校の数学を使って20行未満で解けるレベル1の問題ですら、解けないんだから。

└

残念だけど、君はあまり良いプログラマーじゃないね。AIは、君が足し算や掛け算でコンピュータに勝てないのと同じように、何かをすぐに作り出すことができる。でもその後、間違いや誤検知、完全に動かないコードを見つけることになる。そして一番厄介なのは、完全に動かないだけじゃなくて、君がまだ理解していないコードもあるってこと。これが時間を奪うところだよ。今度はそれを見直さなきゃいけないからね。それに、彼らはシステムをより良く設計するわけじゃない。部分的なものは作れるかもしれないけど、複雑なものを与えると、君が10年以上その言語でプログラミングしてきたとしたら、もっとひどい解決策を妄想することになる。今、その「AI生成」したコードが増えるにつれて、この不安定さの問題が倍増するんだ。今、君は信頼できるかどうかも分からないシステムを持っていて、それを修正するために理解できない状態になってる。おめでとう…。私はAIを適度に使ってるけど、得意なタスクには良いからね。スクリプトを生成したり、ちょっとした関数をくれたりして、それを見直す。私のコードを見直してもらうと、私はその言語をよく知ってるから、君の間違いや妄想の一部を捨てて、いくつかの価値のあるものを見つけることができる。さらに、私のコードの問題を見直していると、LLMが存在しないエラーを妄想する必要があることに気づいた。これはLLMが正確でないように見えることの一つだね。それに、問題がちょっとでも典型的でなくなったり、難易度が上がったりすると、もっと不安定になる。結局のところ、人間が必要になるよ。どれくらい必要か、どれくらい改善されるかは分からない。ただ、彼らが信頼できないことと、この「速く生成する不安定さ vs 今はコードベースが分からない」というのが、根本的な障害だと思う。これは非常に難しいか、もしかしたら不可能なことだと思う。

└

> コーディングAIは、私よりもソフトウェアをデザインしたり、コードをレビューしたり、見つけにくいバグを見つけたり、長期プロジェクトを計画したり、研究や文献、私たちのプロジェクトの状況に基づいて意思決定をするのが上手だ。それは全然真実じゃないよ。ある程度の能力があれば（君がそうだと仮定するけど）、AIはこれらのタスクが苦手だし、経験の浅い人間にも及ばないよ。

└

>> コーディングAIは俺よりもソフトウェアをデザインできるなんて絶対にありえない。俺は超速キーボード派で、使えるときはほぼ毎回速いキーボードを使ってる。デバッグスキルには驚かされたこともあるけど（正直、何度もがっかりしたこともある）、速いキーボードでHTML UIをあっという間に作れるのには本当に感心してる。PRをレビューする時に、速いキーボードが欠陥を指摘する能力にも感心してるんだ。要するに、速いキーボードにはたくさんの価値があるけど、プロンプトやスキル、フックをいくら追加しても、モジュール化についていくら詳しく説明しても、「エージェント」は人間と同じようにはソフトウェアをデザインできない。LLMの根底にあるメカニズムが何であれ（次のトークン予測器と呼ぶのはその能力を過小評価してる）、問題を独立して解決できる部分に分解するメカニズムは持っていない。これが真実である限り、ここに変化の兆しは全く見えない。今の最先端の技術は、エージェントがTODOリストを使っているのと同じくらいのものだから、LLMは人間よりも良いデザインはできない。シンプルなCRUD系のビジネスアプリなら、十分にデザインできる場合もある（もっと正確に言うと、問題が小さくてシンプルだから）けど、だからといって一般的なケースでソフトウェアをデザインできるわけではない。

└

俺はそうは考えてない。コーディングアシスタントと一緒にいる方が、俺一人やコーディングアシスタントだけよりも良いんだ。俺にとっては、俺とコーディングアシスタントの関係が大事で、どちらか一方ではない。だけど、俺はプロのコーダーじゃないし、コーダーとして自分を位置づけてるわけじゃない。プログラミングにはずっと関わってきたけど、タイトルとしては持っていない。製品側やステークホルダー側で働いてきたけど、開発チームと話すことでより深く関わることができた。だから、純粋なコーダーと比べて、コーディングアシスタントと並んで働くのが自然なんだ。

航空安全には「スイスチーズ」モデルっていう概念があって、各安全層は100%完璧ではないけど、それぞれ異なる穴があって、重なり合うことで安全性が向上するんだ。今のLLMをソフトウェア開発やデプロイメントパイプラインの「チーズ」の層として扱うことができるから、追加する目的は測定可能な指標（コードの質、稼働時間、開発コスト、成功した取引など）を改善することになるべきだよ。もちろん、選んだLLMの挙動を特定のシナリオごとに理解する必要があるけどね。スイスチーズのように（大きな穴が少数）なのか、ハバティチーズのように（小さな穴が多数）なのか、それに応じて扱う必要がある。

└

面白い概念だけど、今のところこの技術を新しい複合層として適用してないんだ。初期のソリューションを構築した後に使ってるわけじゃないし、仕様と比較するためにコードを取り込んでるわけでもない。現在の手書きテストをキュレーションして分析するためにも使ってない（プロンプト: このテストは良いの？アシスタント: それはクソみたいなもので、期待される結果がモックされた結果と等しいと推測してる）。まだこの段階には達してない。一般的にも、賢くもない。でも、「安全で効果的」な人たちが技術から離れたら、良いユースケースが見つかると思うよ（UMLやVB、Delphiとは違って）。

└

LLMはクラフトシングルみたいなもんだ。見た目はチーズっぽいけど、実際はそうじゃない。中に入ってるってわかったら、誰かが全体を検査して、安全性の信頼性を確認しないといけない。

└

> 現在のLLMをソフトウェア開発やデプロイメントパイプラインの「チーズ」として扱うことができる。これはLLMのクソみたいな出力を正当化しようとする面白い試みだけど、NOだね。エンシティファイされたボーイングでさえ、航空業界の安全性と信頼性の記録は、決定論的ソフトウェア（自体も多くの不安定さで知られてる）よりも遥かに上なんだから。決定論的なB2Cソフトウェアは、ボーイングやエアバスのソフトウェアとハードウェアの信頼性にとって、B2Cソフトウェアにとっての基準なんだ。だから、航空業界のパラダイムをクソマシンに適用するなんて、そもそも無理だよ。

今回は本当に違うと思う。HNはそう思わないかもしれないけど、HNはもっとシニアな開発者に偏ってるから、新卒が何を経験してるのか、全然分かってないと思う。ひどい状況だよ。

└

新卒が何を経験しているのかって？もし仕事を見つけるのが難しいって言ってるなら、今は経済の低迷と業界の過剰採用の修正が同時に起こってることを忘れないで。AI業界が経営者の行動に影響を与えているのは確かだけど、AIが開発者の仕事を完全に置き換えるとはまだ思わないな。

> WYSIWYGやドラッグ＆ドロップエディタ、例えばVisual BasicやDelphiは、プログラマーの必要性を終わらせるはずだった。VB6やDelphiは、ドメインエキスパートが仕事をこなすためのものをサクッと作れる、最高の認知的インピーダンスマッチだった。あれ以降、普通の人がコンピュータで何かをやるための生産性の高いものは全然出てこなかったよ。結局、実際のプログラマーを雇って、コーナーケースを処理させたり、他の人が使えるように実際に信頼性のあるものを作らせたりすることになる。今、私たちは非常に似た状況に直面していて、AIは脆弱でほとんど機能しないプログラムを生成できるかもしれないけど、結局は本物のプログラマーがそれを安定させて使えるようにしなきゃいけない。

「機械の中の血」という本を読んだ。ラッダイトの歴史についての本だよ。今の状況を理解するのにすごく役立った。産業革命前は、町や家族全体が衣服を作っていて、質の高い服を作る技術を持ってた。機械が登場したとき、すぐには変わらなかったけど、ほぼすべてのコテージ産業が消えてしまった。機械が作る服は同じレベルの品質ではなかったけど、早くて安く作れるようになった。機械から服が出てくるという新しさもあって、後にそれが普通になった。今、開発者のコテージ産業の終わりの始まりにいるんだと思う。

└

でも、そのアナロジーは成り立つのかな？私たちは何年、何十年も「無料の服」を手に入れてきた。安いという意味じゃなくて、文字通り無料、つまり$0.0のソフトウェアのこと。安いソフトウェアは新しくないよ。それに、今でも服のデザイナーやファッションショー、高価なパタゴニアのベストは存在してる。衣服産業は当時とは全く違うけど、確実に消えてはいない。

└

ラッダイト運動は、衣服を作る機械ではなく、織機に反応して生まれたんだ。機械は布を織ることができるけど、その布はまだ手で切って縫わなきゃいけない。布を織るのが衣服を作る中で最も時間がかかる部分だった。コードを書くことは、ソフトウェア開発の中で最も時間がかかる部分ではないよ。

└

車の例えを使った方が、俺にはもっと分かりやすい。トヨタがほぼ完全に置き換えたヨーロッパの車職人たちがいたし、ソフトウェアは車と似ていて、メンテナンスが必要で、壊れたら大きな結果（死や破壊、あるいは金銭的損失）が伴う。もしLLMがトヨタが車を生産するようにソフトウェアを生産できて、さらにメンテナンスもできるなら、職人（今の開発者）は置き換えられることになる。

これはエリザ効果が大規模に広がったものだね。ウィーゼンバウムの話を今読むと、目から鱗だよ。

コンテンツ制作のような仕事をAIが代替できるのを見てきた者として、これは現実を見ていないね。確かにソフトウェア開発者はまだ必要だけど、数はかなり減るだろうね。完全自動化された工場も、最初に工場を作ったり管理したりするために少しは人間が必要なんだから。

私の見解では、LLMの問題は自動運転車と同じで、信頼性なんだ。LLMに機能を実装するよう頼むことはできるけど、自分がかなり技術的でない限り、実際に自分の望んだことをやってくれたかどうかどうやって知るの？自分の手動テストケースには合うけど、実際にやりたいことには一般化しないような、致命的な誤解をしていないかどうかもわからないよ。人々は15年間、「5年後には自動運転車が普及する」って言ってきた。今やっとそれが実現しそうに見えても、進展は非常に遅いし、もう一度赤ちゃんを轢くようなことがあれば、さらに10年遅れる可能性がある。

└

以前はこの議論を単純な統計で片付けていた人が多かった。死亡統計が平均的な人間よりも低ければ、リラックスしていいって言われてたけど、私はそれを信じなかった。LLMが平均的な人間よりも優れた文章を書くから使うべきだ、みたいなもんだよね。どれだけ自分が持っているかに関わらず。

問題解決の未来は、問題解決者にある。

織物の未来は自動織機だけど、羊は原材料を提供するためにまだ必要だ。

ハクソク