ハクソク

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

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

2026年1月17日原文(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ツールはこれからも存在し続け、今後数ヶ月や数年で加速するだろう。進展もあるだろうけど、コスト削減は主にオンショア/オフショアの置き換えによって実現されている。残ったオンショアのチームは、もっと多くの余裕や修正を吸収し、結果的により生産的になる。

Hacker Newsで議論の続きを見る