10年ごとに繰り返される開発者代替の夢

• この50年以上、ソフトウェア開発を単純化して開発者への依存を減らそうとする試みが繰り返されてきた
• 1960年代の COBOL に始まり、CASEツール、Visual Basic、ローコード・ノーコード、そして最近の AIコード支援ツール まで、同じパターンが続いている
• それぞれの技術は生産性を高めたが、複雑性を扱う思考プロセスは依然として人間の役割として残っている
• AI は開発者の能力を増幅するが、ビジネス課題の理解と判断力を置き換えることはできない
• この繰り返される試みは、ツールの限界ではなく問題そのものの複雑さを示しており、結局のところ 人間の思考力への投資 が核心となる

---

繰り返されるパターンの始まり

• 10年ごとに「今度こそ開発は簡単になる」という約束が現れる
  • 1969年のアポロ計画以降、ソフトウェアは中核技術として台頭
  • しかし開発には 専門知識、集中力、時間の投入 が必要であることが明らかになった
• ここから「開発を単純化して人員を減らそう」という 持続的な夢 が始まった

COBOL: 業務担当者が自らコーディングできるという信念

• COBOL は Common Business-Oriented Language という名前のとおり、業務担当者が英語の文章のようにコードを書ける よう設計された
• しかし実際には ロジック・データ構造・システム設計の複雑さ が依然として残り、結局 専門のCOBOL開発者層 が新たに形成された
• 「誰でもコーディングできる」というビジョンは実現しなかった

1980年代: CASEツールの自動生成という約束

• CASE(Computer-Aided Software Engineering) ツールは、ダイアグラムからコードを自動生成 するという約束とともに登場した
• 企業は生産性が10倍向上することを期待して大規模な投資を行った
• しかし生成されたコードは 性能問題、保守の難しさ、モデルとの不一致 により失敗した
• 論理的複雑性の理解が依然として必要 だったため、問題は解決されなかった

1990年代: Visual Basic と Delphi のアプローチ

• ドラッグ＆ドロップ方式 でUIを簡単に作れるようにし、開発参入のハードルを下げた
• 単純なアプリケーションは作れたが、統合・セキュリティ・性能・保守性 が必要な複雑なシステムでは、なお熟練した開発者が必要だった
• 結果として 開発者需要は減るどころか、むしろ拡大 した

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

• Ruby on Rails は「設定より規約」を、ローコード・ノーコードプラットフォーム は「コードのない開発」を掲げた
• 特定領域ではスピード向上と参加者拡大を実現したが、専門開発者の必要性は継続的に増加 した
• 繰り返される問い: 「なぜこのパターンは続くのか?」

複雑性の本質

• ソフトウェアは一見すると単純に見えるが、実際には 細かな状況と例外処理 で複雑性が爆発する
  • 例: 在庫引当の競合、決済失敗、メールサービス停止など
• こうした細部の判断こそが 開発という行為の本質 であり、どんなツールもこれを取り除くことはできない

AI時代の新たな章

• AIコーディング支援ツール は自然言語でコードを生成し、説明・デバッグ・改善提案を行う
• これは 実質的な前進 ではあるが、それでも 問題定義・セキュリティ・統合・保守の判断 は人間の役割である
• AI は 開発者の生産性を増幅 するが、判断力と文脈理解 を置き換えることはできない

依然として不足する開発力

• 技術は飛躍的に進歩したが、ソフトウェア需要は供給を上回っている
• 企業は「より速く、より多く作る方法」を求めて 開発簡素化ツール に期待を寄せる
• しかしボトルネックは タイピング速度や文法ではなく、複雑性を考える能力 にある

リーダーが投げかけるべき問い

• 「このツールは開発者を置き換えるのか?」ではなく
  • 「複雑な問題解決に役立つのか?」
  • 「反復作業を減らし、創造的な問題に集中できるようにするのか?」
  • 「新しいスキル習得が必要なのか?」
• こうした問いは、ツールの限界と人間の思考の不可避性 を認識させる

50年の教訓: 問題は機械的ではなく知的である

• COBOL は構文を単純化し、CASE はタイピングをなくし、AI は関数全体を生成するが、本質的な難しさは依然として残る
• ソフトウェア開発は「思考を具体化する行為」 であり、これはツールで代替できない
• 建築設計や医療診断のように、思考プロセスそのものが中核的な価値 である

これからの方向性

• 新しいツールは今後も登場し続けるだろうが、人間の思考力への投資 が最も重要だ
• AI・ローコード・新しいフレームワーク を試しつつ、複雑性を理解する能力 を組織の中核的な能力に据えるべきだ
• アポロ計画のように、ツールよりも思考の精密さ が成功を左右する決定要因となる

夢が続く理由

• 「開発者を置き換えようとする夢」は失敗ではなく、ツール革新を促す楽観主義 である
• それぞれの試みは完全な代替には失敗したが、新しい世代の有用なツール を生み出してきた
  • COBOL は業務システム開発を普及させ
  • CASE は視覚的モデリングの発展を促し
  • Visual Basic は開発のアクセシビリティを広げ
  • AI は開発手法の変化を促進している
• 結局のところ制約は ツールではなく、私たちが解こうとしている問題の複雑さ にある
• 新しいツールを拒む必要はなく、現実的な期待と人間の判断の重要性 を認識すべきである

[GN⁺]

Hacker Newsの意見

• 今回のAI革新の波を見ると、コーディングの多くの部分は本質的な複雑さではなく、偶発的な複雑さだったのだと気づかされる
  人間にとっては概念的な作業が、AIにとっては手続き的な作業に変わる現象だ
  例えば、以前はJavaのpublic static void main(String[] args)を書くために複数の概念を学ぶ必要があったが、AIには「クラスのエントリーメソッドを書け」というプロンプトを与えるだけで、ほぼ確実にそのコードを生成する
  人間には難しい手続き的作業がAIには容易である一方、社会はこうした手続き的労働を中心に構造化されているため、革新が広がれば上に行く人もいれば苦しむ人も出る

  • 正しい質問を投げかけるのに必要な経験と専門性が過小評価されていると思う

• 「No-codeが開発者を置き換える」という主張は毎回繰り返されるが、実際には開発者の仕事をむしろ増やしてきた
  COBOL、VB、Squarespace、そして今のAIまで — ツールが参入障壁を下げると、より多くの人が何かを作ろうとし、結局限界にぶつかると本物の開発者が必要になる
  単純な反復作業は消えるが、何を作るかを定義し、デバッグする仕事は依然として残る

  • 私もその拡大が続いてほしいと思うが、結局は新しい需要が生まれるかどうかにかかっている
    AIが複雑なプロジェクトを自力でコーディングできるなら、人間は細部を気にしなくてよくなるので、開発者需要は減るかもしれない
    過去にはインターネット、クラウド、モバイル、機械学習のような大きなトレンドがあったが、今後もそうした**「大きな問題」**が生まれ続けるのかは確信がない
  • これはJevons Paradoxの典型例だ — 何かが安くなると、市場はむしろ大きくなる
  • もちろん今回は違うかもしれない。AIが本当に約束どおりなら、開発者の数が減る可能性もある
  • 農業機械は農家をより効率的にしたが、今ではむしろ農家の数の方が増えている
  • 「開発者の数は減らない」という主張は断定的すぎる。AIがデバッグや要件の解釈までできるようになれば、状況は変わりうる

• この20年間、システム管理の分野でも同じパターンを見てきた
  「より高い抽象化が専門家の仕事を民主化する」という約束は繰り返されるが、実際には高コストな再発明が起きる
  Kubernetesのようなツールは複雑性を包み隠したと言われるが、結局は開発者たちが基礎概念を知らないまま、同じ問題をより高いコストで学び直している
  Excelが代表例だ — ひどいエラーを量産したが、アクセスのしやすさのおかげで成功した
  結局のところ、私たちは「Excelのアクセスしやすさとエンジニアリングの信頼性」を同時に望むが、その両方は手に入らない

  • だとすると、非決定的なソフトウェアを使うとき、保険料や補償ポリシーは変わるのだろうか？
  • Kubernetesが労働を減らせなかったのなら、大企業の95%が愚かだという話になる
    実際には規模が大きくなるにつれて、業務の複雑さが上のレベルへ移動しただけだ
  • すべての抽象化は漏れる抽象化だ。Cでさえコンパイラごとに結果が異なる

• こうしたパターンが繰り返される理由は市場インセンティブにある
  企業はAIを万能の解決策として見せなければ株価が上がらないため、実際の性能よりも信念を売る構造になっている
  結局、現実が明らかになれば市場は混乱するだろう

  • 市場は万有引力ではない。政治秩序があって初めて市場は存在する
  • 本当に製品が約束どおりに動いていたなら、「懐疑派への反論」に集中せず、開発に没頭していただろう

• 実際、開発者の数を減らすこともできたはずだ
  企業がもっと選別的な採用と教育投資をしていれば、という話だ
  しかし現実は逆で、Webフレームワークは生産性向上よりも教育コスト削減と人材プール拡大のために作られてきた

  • 同意しない。良いフレームワークは保守性と生産性を高めてくれる

• 中間管理職と経営陣は技術部門をコストセンターとしてしか見ていない
  そのため、あらゆるプレスリリースでAIに言及し、人件費削減を叫ぶ
  実際にはAIのせいではなく、オフショア人材への置き換えでコストを削減している
  残ったオンショアのチームは、より多くの仕事を背負いながら生産性を上げている

  • しかしオフショア地域でも同じようにレイオフが起きている
    人件費削減ではなく、全体的な投資縮小が原因だ
    結局、AIがデータセンター投資に資本を吸い上げることで、雇用を減らしている形になる
  • 「営業は製品なしでは存在できない」という主張には、歴史的な反例が多い

• AIの目的は開発者の置き換えではなく、抽象化レベルを上げてより複雑な問題を扱えるようにすることだ
  初期コンピュータの配線プログラミングから始まり、アセンブリ、C、Python、フレームワークへと発展する中で、開発者はより高いレベルの問題を扱うようになってきた
  ただし、以前の段階はすべて決定的で検証可能な変換だったのに対し、生成AIは非決定的である点が違う
  関連する話として The Story of Mel は読む価値がある

  • だがAnthropicのCEOをはじめとする企業は、そうした哲学的目標よりもコスト削減と置き換えに強い関心を持っている
  • それでも人々は相変わらず「開発者の置き換え」を語り続けるだろう
  • 各抽象化レイヤーは内部をのぞけることが必要だ
    LLMはコンパイラのようにトークン、AST、IRなどを見られないため不透明だ
  • AI企業の本当の目標はあらゆる知的労働の自動化だ
  • 抽象化が高くなるほど正確性と制御力は下がる
    自然言語ベースの非決定的システムは、前世代の抽象化とは異なる
    だから「アセンブリからCへの移行」という比喩は適切ではない

• Dijkstraの言葉どおり、科学は難しいがゆえに嫌われ、その力を持つ科学者も嫌われる
  EWD1041 原文リンク

• 逆に、開発者たちは常に非開発職を自動化する夢を見てきた
  AIはその夢の最新バージョンだ

  • いつの日か、すべての仕事が良い仕事になるStar Trek的な世界は来るのだろうか？

• 2000年代初頭、大学ではRational Rose UMLが必修科目だった
  当時あるスタートアップのCEOが、「もうダイアグラムだけ描けばコードは自動生成されるので、開発者は不要だ」と語っていた
  だが結局、その予言は実現しなかった

[kayws426]

機械が機械のためのコードを作る。
機械語の上に人間が築いた砂上の楼閣は、結局は崩壊する運命だ。
...なんてことも言えるんですけどね（笑）