ハクソク

世界を動かす技術を、日本語で。

開発者を置き換えるという繰り返される夢

91日前原文(www.caimito.net)

概要

  • ソフトウェア開発を簡素化し「開発者不要」にする夢は、50年以上繰り返し現れている現象
  • COBOLからAIまで、技術進歩はあったが根本的な課題は解決されていない現実
  • 問題の本質は「複雑さの思考」にあり、ツールや言語の進化では解消できない知的作業
  • 新しいツールは価値をもたらすが、開発者の役割や専門性は依然として不可欠
  • 今後も夢は続くが、「人間の思考力」こそが最大の制約であり続ける

みんなを悩ませるパターン

  • 10年ごとに「ソフトウェア開発が簡単になり、開発者が減る」という新たな約束が現れる現象
  • COBOLからAIまで、技術が進化しても「開発の遅さとコスト」に対する経営層の不満と開発者の不遇感が繰り返される歴史
  • このサイクルが50年続く理由は、ソフトウェア開発の本質的な性質に起因

人類の偉業とソフトウェア開発の夢

  • 1969年のアポロ計画で、Margaret Hamilton率いるチームが手作業でソフトウェアを開発
  • ソフトウェアが「ミッションクリティカル」な存在であることを証明
  • しかし、専門知識・集中力・時間が不可欠なため、開発の簡素化という夢が生まれるきっかけに

COBOL：ビジネス担当者が自分でプログラムを書く夢

  • 1960年代後半から1970年代に登場したCOBOLは「ビジネス担当者が自分で書ける言語」を目指した
  • 英語風の構文で「誰でも書ける」とされたが、論理やデータ構造の複雑さは消えず
  • 結果として新たなCOBOL専門家が生まれ、夢は実現せず次の技術へ

1980年代：CASEツールの約束

  • CASE（Computer-Aided Software Engineering）ツールが「図を描けばコードが生成される」と宣伝
  • ビジネス側が視覚的に設計できると期待されたが、論理的な複雑さの理解は依然必要
  • 実際には手作業の修正や保守の困難、パフォーマンス問題が多発し、ほとんどが失敗に終わる

Visual Basic・Delphi：ドラッグ＆ドロップの普及

  • 1990年代、Visual BasicやDelphiでUI作成が容易に
  • 「パワーユーザー」や「市民開発者」が増えたが、本格的なシステムは依然として専門開発者の知識が不可欠
  • 簡単なアプリは作れても、複雑な要件や保守には限界

2000年代以降：Webフレームワーク、ローコード、ノーコード

  • Ruby on Railsやローコード／ノーコードが「誰でも開発」を再び目指す
  • 一部のシナリオでは開発効率向上や参加者拡大を実現
  • しかしプロの開発者需要はむしろ増加し、根本的な課題は解決せず

なぜこの夢は繰り返されるのか

  • ソフトウェア開発は**「自然言語で説明できる＝簡単」**と誤解されやすい
  • 実際には細かな例外処理や複雑な分岐が本質的な難しさ
  • どんなツールでも複雑さの思考作業は省略できず、「考えること」自体が開発そのもの

AI：最新の章

  • AIコーディングアシスタントは自然言語からコード生成や解説が可能
  • 開発者の生産性向上や学習支援に実際に役立っている
  • しかし「AIが開発者を不要にする」幻想はすでに現実的な理解へ移行
  • ビジネス要件の把握・安全性の検証・保守など、判断力と知識は依然不可欠

機会が増えても苦戦は続く

  • ツールやフレームワークの進化で多くの作業は楽になった
  • しかしソフトウェア需要は常に供給を上回り、「やりたいことリスト」は増加し続ける
  • 根本的な制約は「思考の複雑さ」であり、タイピングや構文ではない

リーダーが知るべきこと

  • 新ツールが登場しても「開発者不要」にはならない現実
  • 本質的な問いは「開発者がより複雑な問題に集中できるか」「単純作業を減らせるか」
  • 新たなスキル習得や業務効率化への期待を持ちつつ、現実的な評価が重要

パターンが示す本質

  • 50年繰り返されるパターンは「開発作業の本質は知的作業」であることを示す
  • COBOLやCASEツール、AIなど、各時代の進歩は「摩擦点の解消」には役立った
  • しかし「考える力」自体は省略不可であり、建築設計や医療診断と同様の知的活動

これからの進み方

  • 新しいツールやAIを積極的に試す姿勢は重要
  • しかし最も投資すべきは「複雑さを考え抜く人材」の育成
  • どんな時代でも「思考力」が最大の制約であり続ける

「夢」が果たす役割

  • 「開発者不要」の夢は技術革新の原動力として意味がある
  • 各時代の挑戦が現実的なツール進化を生み出してきた
  • 夢は完全には実現しないが、挑戦の積み重ねが価値を生む

Hackerたちの意見

> そのパターンが繰り返される理由は何か？市場がそれを促進しているからだ。企業は株主価値が多くの人に信じられることに依存しているから、AIを全能で無敵な仕事の殺し屋として押し出している。実際にツールが機能するかどうかは関係ない。ジェンセン・ファンのような人が、AIに対する人々のネガティブな反応が進展の最大の障害の一つだと言っているのは興味深い。まるで彼らが批判から免れるべきだと言っているかのようだ。彼らは実際に製品を宣伝通りに機能させるために努力するよりも、反対意見を貶めようとする。市場がこの現実に目覚めたら、本当に厄介なことになるだろう。
└
> パターンが繰り返されるのは、市場がそれを促進しているからだ。市場は普遍的な重力ではなく、社会政策のための店舗に過ぎない。政治的秩序がなければ、市場もなく、市場のインセンティブもない。
└
そうだね、もし彼らが自分たちの製品が主張することを実現できるなら、批判をやめろって言うよりも、そのことに集中するはずだよ。
逆に、開発者の夢は、ITに関係ない人たちを置き換えることだ。通常は100%オンラインの自動化された自己宣伝型SaaSでね。AIもその最新の形だ。
└
いつになったら「スタートレック」や「オービル」の夢、すべての仕事が良い仕事になるの？
開発者を置き換えるというより、開発者がより複雑な問題に取り組めるように、抽象度を上げることが大事なんだ。最初の電子コンピュータは、回路を手動で配線し直してプログラムされていた。それからパンチカードで機械命令をエンコードできるようになったからといって、開発者が置き換えられたわけじゃない。生の機械命令からアセンブリコードに移行したときも同じだし、手書きのアセンブリからCやFORTRANのようなコンパイルされた低レベル言語に移行したときもそうだ。低レベル言語からJava、C++、Pythonのような高レベル言語に移行したときも、機能を実装するためにライブラリやフレームワークに頼るようになったときも、開発者は低レベルの問題を心配する必要がなくなり、高レベルの問題に集中できるようになった。メルの知性は、メモリドラムの位置を最適化する必要がなくなったから、彼が解決しようとしている問題の高レベルの論理やアルゴリズムを最適化することに集中できる。結果として、ソフトウェアはより複雑になったけど、同時により能力が高まり、一般的になった。（生成AIがこれまでの抽象度の増加の例と異なるのは、それらが決定論的で、しばしば正式に検証可能な高い抽象から低い抽象へのマッピングであるのに対し、生成AIはそうではない。）
└
> 開発者を置き換えるというより、開発者がより複雑な問題に取り組めるように、抽象度を上げることが大事なんだ。でも、人々は開発者を置き換えることについて話すし、これからも話すだろう。
└
私にとって一番変なのは、トランジスタのスイッチングをコンピュータの基盤となる不変の根源として内面化しなければならないという考え方だ。だから、そこからあまりにも抽象的なものは本当のコンピューティングではないみたいなことを言う人がいる。真空管コンピュータをプログラムしていたときは、モスフェットとは全く異なるタイプの抽象だったことを完全に無視している。私は「正しい」方法があるとか、安定していなければならない儀式や思考パターンがあると思っている人とのエンジニアリングの会話を無視できる立場にいる。
└
AI企業の目標は、すべての知的労働を置き換えることだよね。失敗するかもしれないって議論もあるけど、実際の目標ははっきりしてる。
└
でも、議論で欠けてると思うのは、各抽象レベルが内省可能である必要があるってこと。LLMはコンパイラとよく比較されるけど、トークン、AST、SSA、IR、最適化パス、アセンブリをダンプするのに相当するものは何だろう？ ここがちょっと危ういアナロジーだと思う。誰かがそのレイヤーや変換を理解しなきゃいけないからね。
└
> 「開発者を置き換えるというよりも、開発者がより複雑な問題に取り組むための抽象度を上げることが重要なんだ。それが、AnthropicのCEOの目標ではないし、他のCEOもそうではない。」
中堅管理職やC-suiteの人たちから聞いた話だと、スタッフが最大のコストで、技術部門が最大のコストセンターだって。私はそれに反対だ。製品がなければ営業は成り立たないから。でも、それはどうでもいいポイントだ。だからこそ、同じ中堅管理職やC-suiteの人たちがAIに夢中になって、すべてのプレスリリースで言及しているんだ。実際には、コストが米国のチームをオフショアのチームに置き換えることで削減されている。そして、レイオフはAI導入の結果として捉えられている。ソフトウェア開発のためのAIツールはこれからも存在し続け、今後数ヶ月や数年で加速するだろう。進展もあるだろうけど、コスト削減は主にオンショア/オフショアの置き換えによって実現されている。残ったオンショアのチームは、もっと多くの余裕や修正を吸収し、結果的により生産的になる。
└
>私は反対だ。営業は製品なしでは存在できない。歴史の中にはたくさんの反例があるよ。
└
> 現実には、コストはアメリカのチームをオフショアのチームに置き換えることで削減されている。アウトソーシング先から来た俺としては、具体的にどこに行くのか聞きたい。俺たちも同じように解雇されたし。俺とチームは2025年の後半を半分の時間で働いてたけど、それが提示された条件だった。そんなにスキルの高い開発者が豊富にいる場所ってどこなんだ？ インド？ そっちの方がこっちよりも平均的に給料が低いわけじゃないし、いい人はもっと稼いでる。俺の考えでは、全体的にスタッフへの支出が減ったのは、どの会社も他の会社がレイオフしてるのに気づいたからで、ソフトウェアの競争圧が下がったからだと思う。あと、投資家のお金はデータセンターに使われたから、ある意味AIが仕事を奪ってるよね。
科学は、その習得には多くの努力が必要だから嫌われている。そして同じ理由で、その実践者である科学者たちも、その力から嫌われている。 - ダイクストラ '1989
この議論で見落とされがちなパターンは、「ノーコードが開発者を置き換える」波が実際には開発者の仕事を減らすどころか、増やすということ。COBOLはマネージャーがプログラムを書くためのものだったし、VBはビジネスユーザーがアプリを作れるようにした。Squarespaceはウェブ開発者の必要性を減らしたし、今はAIがある。実際に起こることは、ツールが参入障壁を下げることで、もっと多くの人が何かを作ろうとするようになり、その人たちがツールの限界にぶつかったときに、実際の開発者が必要になるってこと。つまり、「作る必要があるもの」の全体的な範囲はどんどん広がっていく。置き換えられるのは、すでに明確に定義された機械的な作業をしている開発者たち。でも、最初に何を作るべきかを理解する仕事や、自動化されたものが期待通りに動かない理由をデバッグする仕事はまだ残ってる。むしろ、その仕事は増えてる。
└
>「ノーコードが開発者を置き換える」波が実際には開発者の仕事を減らすどころか、増やすって言ってるけど、君が言いたいのは「作られた」って過去形だよね。君は基本的に、技術の進歩が世界のプログラマーの数を減らすことは不可能だって主張してるように見える。コードをデバッグしたり、非技術的なユーザーのニーズを解釈するのは人間だけだって考えは、ちょっと疑問だな。
└
クラシックなジェボンズの逆説 - 何かが安くなると、その市場は成長する。単位コストは縮小するけど、購入される単位数はその縮小以上に増える。
└
これは潜在的な需要がかなりあったことを示唆してるけど、それが無限であることを証明するわけじゃない。ある時点で、簡単に自動化できる部分は尽きてしまう。すでに存在しないものをオンラインにするには何ができる？どのビジネスプロセスが明らかに何倍も効率的になるの？さらに、これまで以上に多くの開発者がいて、異常に低い金利の時代を抜け出した。パーティーは終わるかもしれないね。
└
機械は農業を効率化したし、今では農家が過去最高に増えてる。
└
そうだね！システム管理者は職を失ったけど、多くは開発者になったよ。
└
> 「参入障壁が下がることで、もっと多くの人が何かを作ろうとする。そして、その人たちはツールの限界にぶつかったときに、実際の開発者が必要になる。」最初は企業が欲しい機能を拡張することを想像してたけど、それが十分だとは思えなかった。でも、今の話を聞くと、もっと理にかなってるね。
└
残った開発者たちも大幅に給料が上がったよ。
└
> 「この議論で見落とされがちなパターン: "ノーコードが開発者を置き換える"という波は、実際には開発者の仕事を減らすのではなく、増やす。」今回はそうなるとは限らない（つまり、AIが本当に約束されたものになるかどうか）し、実際にはそうなる可能性は低いけどね！
└
システム管理みたいなものがある平行宇宙があると思うんだ。ウィンドウズのシスアドはあんまり評価されてなかったのを覚えてるよ（ユニックスと比べてね）。だって、全部GUIベースだったから。笑。
このパターンをシステム管理の分野で20年間見てきた。いつも同じセールストーク：高い抽象化が専門的な仕事を民主化するって。SREは「根本的に異なる」って言われてるし、Kubernetesは「複雑さを抽象化する」って。でも実際には、高いコストでの再発明を見てる。開発者たちは、ファイルシステムのセマンティクスを理解せずにポッドの再起動後にデータベースの破損をデバッグしてる。彼らはCNIの上にモニタリング戦略やネットワーキングパターンを再構築してるけど、これらの抽象化が基づいている基本を学んでないから。彼らは早く学んでるわけじゃなくて、同じ運用の教訓を何倍ものコストで再学習してる。各「民主化」の波は専門家を排除するわけじゃなくて、新しい専門家を生み出して、彼らはその抽象化とそれが何を抽象化しているのかを学ばなきゃいけない。専門知識を得るのがもっと高くつくようになっただけで、不要になったわけじゃない。Excelがその例を証明してる。客観的に見てひどいもので、30%のゲノム論文にはオートコレクトによる遺伝子名のエラーが含まれてるし、JPモルガンは数十億ドルを数式エラーで失ったし、イギリスの公衆衛生はCOVIDのケースを16,000件もロウ制限で失った。それでも、適切なシステムが許容しないような壊滅的な失敗を受け入れることで民主化に成功した。このパターンは繰り返される。私たちはExcelのアクセスの良さをエンジニアリングの信頼性と両立させたいから。両方は無理だよ。民主化のために災害を受け入れるか、専門知識が必要だと認めるかのどちらか。
└
> 災害を受け入れて民主化を進める 非決定論的ソフトウェアを使うと、保険のカバレッジやプレミアムはどう変わるんだろう？
└
すべての抽象は漏れやすい抽象だよ。例えば、Cは漏れやすい抽象で、入力したものがそのまま出力されるわけじゃない（異なるコンパイラで同じコードを試すと、一方はループをベクトル化するかもしれないけど、もう一方はしないかもしれない）。
└
Kubernetesが労働を何も減らさなかったなら、導入した大企業の95%はみんなバカってことになる？ それはちょっと信じがたいな。Kubernetesはスケールが増す中で採用されてるように見えるし、システム管理者の仕事は新しい複雑さのレベルに移行しただけだと思う。2000年代初頭には、小さな会社でも物理ハードウェアやDB、カスタムデプロイスクリプトを管理するためにシステム管理者が必要だったけど、その仕事は今はもうなくなっちゃった。
半技術者が開発者を置き換えられるのは、彼らが開発者を避ける代わりに、システム全体の複雑さを最小限に抑えることを約束するならば？もちろん、半技術者はトラブルシューティングができる。それはほとんどの仕事の一部だからね。（中には得意な人もいるけど。）でも、トラブルシューティングを促進するシステムを設計できる半技術者はどれくらいいる？私のエンジニアの知り合いの中でも、できない人がたくさんいるよ。
└
生産環境でどうなるかはまだ分からないね。俺の予想では無理だと思う。自分のバイブコーディングセッションの出力を「オタクっぽい」とか言ってる人を見たことがあるけど、そういうのはちょっと上から目線だよね。AIの出力を拒否するのは、スピード感を失うことに繋がる。
会計士向けのツールを作っていて気づいたパターン: 自動化は仕事を奪うことは少ない、仕事の内容が変わるだけ。私が関わっている簿記の人たちは、以前は手動でデータ入力に何時間もかけてたけど、今はその時間をクライアントへのアドバイザリー業務に使ってる。全体の作業量は変わらないけど、より価値の高いタスクにシフトしてる。80年代のスプレッドシートでも同じことが起こった。会計士が消えたわけじゃなくて、新しい仕事のカテゴリーが生まれて、1人が扱える仕事の期待値が上がった。面白いのは、開発者が置き換えられるかどうかじゃなくて、新しいツールを使った開発者の役割が給料が下がるかどうかだよ。初期の兆候では、そうなるかもしれない。もしLLMがコーディング部分を商品化したら、プレミアムは問題理解やシステム思考に移るんじゃないかな。
└
機械学習は整数プログラミングとは全然違う。生物の学習を模倣したもので、人間の脳が得意とする問題に取り組むために明示的に設計されている。これは人間と直接競争する存在なんだ。これを軽視することほど危険なことはないよ。
雇用主がもっと選り好みして、トレーニングに投資してたら、たくさんの開発者を入れ替えられたのにね。今は、ほとんど役に立たない開発者がたくさんいる。記事に出てたウェブフレームワークがその例だよ。これらのフレームワークは、開発者や雇用主の生産性を上げるためにあるんじゃなくて、トレーニングを軽減して、雇用主が選べる候補者の幅を広げるために存在してるんだ。
└
それには同意できないな。良いフレームワークはコードをもっとメンテナンスしやすくして、製品にとって重要なことやユニークなことに集中できるようにしてくれるよ。確実に作業が速くなるしね。