- NoCodeからAIまで、開発者を代替すると称する技術は繰り返し登場するが、実際には技術変化に応じて役割が変形してきた
- NoCodeは開発者を消し去るのではなく、NoCode専門家と統合技術者を生み出し、クラウドはDevOpsエンジニアという高度な職種を作り出した
- 現在のAI開発ツールも同じ道をたどっており、AIがコードを書く時代でもシステムアーキテクチャ設計能力は依然として中核である
- AIはローカル最適化は得意だが全体システム設計には弱く、高速な生成速度によって構造的なミスを素早く固定化してしまう危険がある
- 開発者の代替とは結局、技術スタックの変化に伴う進化と高度化にすぎず、本質的な役割は引き続き必要である
From NoCode to AI-Assisted
- 数年おきに、ソフトウェア開発者を代替すると主張する新しい技術が登場する
- 「コーディングの終焉」「これからは誰でもアプリを作れる」「子どもでもコーディングする」といった誇張された期待を含む似た見出しが繰り返し生み出される
- 経営陣やコンサルタントはこの流れに注目し、予算が移動する様子が見られる
- しかし現実は、常に「代替」ではなく「変形」だった
- 複雑化した技術を扱う新しい役割と高度化した専門職が生まれ、賃金水準も上昇する傾向が繰り返し現れてきた
- NoCodeは専門技術者なしでアプリを作れるという期待を生んだが、結局はデータモデリング、統合、保守などの複雑な問題が存在し、それを解決する新しい職種が生まれた
- クラウドはシステム管理者なしで運用できるという信念を与えたが、実際にはDevOpsエンジニアという高度な専門性を求めるようになり、賃金も上昇した
- AIも同様に、「AIがコードを代わりに書く」ように見えるが、実際にはAIを管理・オーケストレーションできる熟練開発者の重要性がさらに高まっている
繰り返される代替の約束の回転木馬(The Endless Carousel of Replacement Promises)
NoCode/LowCode革命
- 直感的なインターフェースで誰もがアプリを作れるというNoCode/LowCode革命が登場した
- しかし実際の現場では、データモデル設計、既存システムやデータベースとの統合、例外処理、保守管理など新たな問題が発生した
- その結果、単なる開発者ではなく、ドメイン知識と技術的な限界を同時に理解するNoCode専門家が必要になった
- 彼らは既存の開発者より高い年収を受け取っている
クラウド革命
- クラウドに移行すればシステム管理者は不要になるという期待が大きかった
- しかしクラウド管理の専門性と複雑性はむしろ増大した
- 従来のシステム管理者はDevOpsエンジニアへと変身し、より高い給与を得ながら、インフラ自動化、デプロイパイプライン、分散システム管理などへと業務水準が高度化した
- 仕事が消えたのではなく、新しい仕事の形へ進化しただけだった
- マイクロサービス移行でも複雑性は増し、結局は根本的にシステムを管理する専門家の役割が重要であることが明らかになった
オフショア(Offshore)開発ブーム
- 海外アウトソーシングでコストを削減できるという信念が広がったが、コミュニケーション問題、品質低下、ドメイン知識不足によって困難が生じた
- 結局、分散チーム構造の再編、明確なオーナーシップ、強固なアーキテクチャへと戦略が変化し、当初期待されたよりも総コストが増える結果になった
AIコーディングアシスタント革命
- 今やAIがコードを自動生成するという約束が話題の中心になっている
- 初期の現実では、AIが作るコードにはしばしば微妙なエラーや一貫性の問題が含まれる
- シニアエンジニアはAIの結果をレビュー・修正するために多くの時間を費やし、経験ある開発者ほどはるかに大きな価値を生み出している
- AI補助だけで構築されたシステムは、体系的なアーキテクチャが欠如している場合が多い
- つまり、技術が技術者を代替するのではなく、より高い抽象化レイヤーへと技術者の専門性を引き上げているのである
今回のサイクルが特別な理由
- 人々が見落としている核心: コードは資産ではなく負債
- コードを速く簡単に作れるほど、保守・セキュリティ・リファクタリングの負担も大きくなる
- AIは関数単位の最適化は可能だが、システム全体の設計能力は不足している
- 実装速度が速くなるほど、構造的なミスを素早く固定化してしまう危険がある
- 結局、AI時代にも真の資産はシステムアーキテクチャ設計能力であり、それは代替ではなく強化の対象である
- 「AIが開発者を代替する」という主張は、次のような根本的誤解に由来する
- コードは資産ではなく負債だという事実
- コードには継続的な保守・検証・セキュリティ管理・置き換えが必要であり、その行数の分だけ負債が増えていく
- AIがコードを素早く作ってくれるということは、その分だけ負債を素早く発生させるにすぎない
- つまりAIはローカル最適化（関数、部分機能）は得意でも、グローバルな設計・アーキテクチャの意思決定は不得意である
- 実装速度が上がるほど、誤った設計がシステム全体に“固着する”危険性が高まる
- 一度きりの短期サイト制作では問題がなくても、長期的に発展するシステムには致命的である
- 技術革新のパターンは変わらず続いている
- システム管理者はDevOpsエンジニアになり、バックエンド開発者はクラウドアーキテクトになる
- しかしAIはすべてを加速させる。生き残り、発展するスキルはコードを書くことではない
- それはまさにシステムを設計すること(Architecting systems)。AIにできない唯一のことがそれである
19件のコメント
私はやや保守的に仕事をするタイプなので、AIツールを重要な業務に導入したことはなく、Google や Stack Overflow で検索していたものを Gemini や ChatGPT に聞く形に変えたくらいです。使ってはいるのですが……
AIに何か作ってもらうときは、関数単位で、こういう入力をしたらこういう出力が返る関数を作ってもらって受け取り、AIが作った関数から返ってきた戻り値が正しいかを検査するロジックくらいは自分で書く、という使い方なら悪くないのではないかと思っています。
すべてのコンテキストをAIがうまく理解できる形式に整理できるのか、という問いに対して、私は懐疑的です。人は、今まさに行っている開発に表面的に必要なコンテキストだけでなく、潜在的なコンテキストも持っていて、そうした部分も考慮しながら開発しています。しかし、そのコンテキストを人が十分に洗練された表現として書き起こせるとは、まだ思えません。これはAIの問題というより、人間の限界なのだと思います。特に、現代の人々の文章力はそれほど高くないと私は思っていますし。
怖いのは今この瞬間ではなく、むしろ流れそのもののように感じます..
今はまったく違います。
すべての職業が代替される未来が目の前にあり、開発者はそのうちの一つにすぎません。
こういうものが流行したことは一度もありません。
まったく同じ変化ではなかったでしょう。
しかし、ずっと前の近代にすでに多くの職業が通ってきた変化です。たとえば、写真の登場によって芸術家が、自動化された工場によって職人が経験した変化です。コーディングもそれと変わらないように見えます。
私は、イノベーションが日常化すれば、結果的に今より多くのエンジニアが必要になると予想しています。ユーザーの期待水準はさらに高くなるでしょうし、より大きく複雑なものを作らなければならなくなるからです。まるで赤の女王仮説が言うように。
もちろん、仕事の種類が変わったり、特定の業務が消えたりする可能性は高いです。いつの間にか植字工がいなくなったように。その文脈で、システムを設計するということは、おそらくさらに高まった抽象化の比喩や例になるのでしょう。
みんな開発者を何か別のもので置き換えたがっているからだと思います。
たいした仕事もしていないのに給料は多くもらっている、と考えている人がかなり多いようです。
実際に代替されるかどうかとは別に、そうした内容が繰り返し話題になる理由は、刺激的だからだと思います。
たいてい、そういう見出しをセンセーショナルに打ち出す場合、そもそも現実がどうなっているのか、あるいは「代替」とは何をもって定義できるのかについて、深く考えた結果であることはほとんどないんですよね。
きちんと考えた内容であれば、むしろAIやほかのツールが現在どこまでできて、どこへ向かって発展しているのかを扱うことになります。そういう地味なタイトルを、一般の人がクリックすることはないでしょう。
刺激的な見出しが多いですね..
"毎年10%を解雇するザッカーバーグ『来年はAIが開発者の半分を代替する』 [ユン・ミンヒョクのシリコンバレーView]"
https://m.sedaily.com/NewsView/2GRQ1RKIYC
"『AIが最も得意なのはコーディング』…MSの構造調整で真っ先に対象になるのは『開発者』"
https://n.news.naver.com/mnews/article/009/0005494133
"『このままでは仕事まで失うのでは』という懸念が『現実』になる？…不安に震える業界"
https://econmingle.com/economy/…
"[ユミ's ピック] 『新人SW開発者は採用しません』…『AIコーディング』を味わった企業が組織効率化を『スタート』"
https://v.daum.net/v/20250522162617091
"『AIが分析・設計・コーディングをすべて行う』…LG CNS、開発者の代わりに『AIプログラマー』を使う"
https://zdnet.co.kr/view/?no=20250528092405
段階的に代替されつつあると見るべきだと思います。
同じ作業結果を得るために投入しなければならない人数が減っているのは事実です。
「システムを設計すること」についても、10人でやっていたことが8人+AIサポートで解決できるなら、
すでに2人は代替された状況ですよね。
システム設計の側面も
プロンプティングでは普通は考慮せずに入れてしまうからではないだろうか
バイブコーディングの後始末がうまくできないのが問題っぽい
個人的な経験から、この意見に同意します。AIも結局はツールなので、1から99までは本当に速くて優れているのですが、いつも残りの1が欠けているように感じます。
概ね同意しますが、核心は「システム設計」そのものよりも、「システム設計を通じた複雑な問題解決」にあるのではないかと思います。
簡単な仕事はさらに簡単になり、難しい仕事は今後もさらに難しくなっていくと私は考えています。
笑
Hacker Newsの意見
最近、「使い捨てのマーケティング用ランディングページ」のような仕事をフリーランスで修正した経験では、支配欲の強い顧客はいつもAIではまともに処理できない妙な要求事項を追加してきて、結局自分が問題を収拾することになるという話。AIがどれだけ賢くなっても、ソフトウェアの問題は技術的なものというより、人間自身が「不要な複雑さ」を作り続けることにあるという見方。結局、開発者の最大の武器は「ノー」と言うことだが、AI同士が競争するようになると、人間と違って誰かが必ずイエスと言ってしまうのではないか、という懸念も含まれている
ソフトウェアは完全に実装できても、要求事項そのものが技術的現実を反映していなければ、結局は混乱しか生まれないという古典的な「要求仕様バグ」の概念。AIもフォーマットや対応可否（例: gif は透明度をサポートしない）といった現実的な制約には今や対処できるが、「ロゴを、各点が中心から同じ距離にある正方形にしてほしい」のような突飛な要求は人間がこれからも書き続けるだろうという考え。jpg の誤記もユーモアとして言及
「いいえ」と「はい」の間には「それで本当に合ってるのか」という50段階のグレースケールがある、という経験談。ある人は「データベースをダウンロードできる」Webページを欲しいと言ったが、実際には単純な csv エクスポートを意味していたように、文脈解釈の重要性を指摘。こうしたニュアンスを chatgpt がきちんと把握できるのか気になるという見方
「断ること」こそが本当に開発者の仕事で最も難しく大変な部分だという意見。多くの開発者は実際にはこうした役割自体を楽しんでいないか、自分の仕事ではないと考えている現実もある。結局、プロジェクトの実際の成功は技術ではなく、利害関係者との「人間対人間」のコミュニケーションに左右されるという点で、「実質的にPM役も兼ねる開発者」が常に必要だという信念
こうした話は、いわゆる『Peopleware』という本によく書かれている内容だという指摘。「あなたの問題がすべて技術的なものでありますように」という挨拶が好きな理由として、実際にコードで解く問題は、ごく一部のエッジケースを除けば、いつもそれほど難しくなかったという現実がある
良い指摘だという意見と、AIは潜在的に複雑さを見積もって警告することにますます長けていく可能性があるという見方。チェスでAIがすでに人間よりはるかに優れた評価・判断能力を見せている事例になぞらえたもの。ここでのAIはLLMに限らないが、その範囲内での進歩も認めている
記事で述べられている「AIはシステムを設計（architecting）できない」という主張には同意しない立場。実際にはAIはすでにこの領域でも徐々に実力を伸ばしており、必要条件の定義を次々と変えて論点をずらしている現象があると指摘。ただし、AIが自分で何を望むべきか、あるいはユーザーの動機まで代わりに決めることはできない（もちろんアイデア出しは可能）。今後も誰かが実際に動いて問題を解決したいと思わなければ社会は回らず、開発者の役割は変わっても問題解決は依然として人間の役目だという考え
「開発者」の意味が変わると言われるが、実際には本質は最初から同じだったという見方。プログラミングとは本質的に、曖昧な要求を明確なコードに変換する仕事だということ。昔はマシンコードやパンチカード、今はフレームワークやGUIなどのビジュアルツールへと手法は変わってきたが、結局コードを書くのが最も効果的なのは、明確さと伝達力があるからだと強調。LLMは既存パターンの踏襲には強いが、完全に斬新な作業や説明を自然言語で試みると、もどかしさが大きいという率直な感想。市場はハイプが極大化しているが、結局は新技術が出るたびに部分的に変わるというパターンの繰り返し
すでに企業がAIの影響でジュニア採用を減らすなど、変化が観測されているという意見。AIがアーキテクティング以外をすべてこなすなら、結果として必要なエンジニアの数は少なくなる構造になるのではないかという懸念
AIはまだアーキテクチャ設計はできないと断言する意見。アーキテクチャ設計とプランニング（計画立案）は違うとし、プランニングとは制約・解決策・リソースを配分し予測する能力だが、AIがそれを効果的に遂行できる水準にはまだ遠いと述べる。真のアーキテクチャ設計とは、多層の協調的かつ競合的な設計であり、AIが一つのレイヤーで誤ると全体が崩れる可能性があり、こうしたシステムを安全に設計し監理できるのは人間だけだと強調
十分な文脈情報さえあれば、AIも望まれていることをかなりうまく把握できるという意見。これは実はプライバシー侵害への警告にもつながる。組織が強力なシステムや文脈認識技術を握れば、AIがあなたの欲求や次の行動までも「十分に」予測できるようになる点のほうが、むしろ恐ろしいという話
AIはアーキテクチャ設計ではなくシミュレーションをしているだけで、しかもコーディングですらまともにできない場合が多いという率直な指摘
ビジネスが品質を重視するという前提自体が誤っているという主張。企業が考えるのは利益だけであり、顧客が望む場合にだけ高品質を提供する構造だという見方。正直、顧客も実際には品質よりコストパフォーマンスに優れた「最高」の商品を好み、Amazonで最も安いツールを買って、似たような雑な（vibe code）コードを何度も量産するのではないかという意見。結局、品質を本当に重視しているのはエンジニアだけであり、エンジニア視点で品質が重要な未来予測は大胆に無視してよいという立場
品質は差別化要因になり得るという反論。iPhone登場当時、機能だけなら多い競合製品がいくらでもあったが、実際にはより滑らかで洗練されたUIを備えたことで市場を圧倒したのだと強調
自分が最も好きな品質重視企業として Fractal Audio を紹介。ギター向けのハードウェアベースのモデラー（アンプおよびペダルボードのシミュレーター）を作る小規模企業で、連続的な革新的アップデートとCEOのアナログモデリング性能への執着により、大企業よりはるかに卓越した品質を実現しているという話。コミッション、サブスクリプション、有名人マーケティングなしに、直販と無料のアルゴリズム更新だけでポジショニングしており、品質で市場シェアを取った生きた例であり、すべてのビジネスが必ずしも「最安値・低品質競争」だけをしているわけではないという主張
顧客は品質を重視しないという見方に反発し、もし品質が無意味なら、すべてのスタートアップは未完成で安いだけの製品を作るだけで莫大な売上と成功を得ていたはずだ、という反論
実際に成功したソフトウェア製品の多くは非常に高品質だったと列挙。Google、iPhone、Stripe、Notion など、市場で長く生き残っている製品は決して遅くもバグだらけでもなく、むしろ品質が成功要因として機能したと見る。逆の例を聞いたことがないという疑問も提示
品質はある程度までは部品化、サブスク化、インターネット接続前提などによって曖昧になるかもしれないが、すべてが急速に崩壊する未来が来る可能性もあるという懸念。機器が文鎮化したり、簡単なサイトですら読み込みに12秒かかったり、社会インフラや政府システムが何十億も投じてなお不安定になったり、日常会話の相手がLLMになる世界のリスクを想起させる
過去のUMLベースの「アーキテクトが仕様を作り、開発者は空欄を埋める」式の組織改革は、むしろ過度に複雑なシステムを生み、俊敏性を失わせたという回顧。その後に現れた「アジャイル」も誤って理解され、開発者のマイクロマネジメント、不信、非創造的な組織文化の拡大につながったというパターンの振り返り。結局、成功したチームの特徴は、ツールやプロセスに関係なく、非開発者が開発者の仕事に本気で関心を持ち、一緒に問題を解いていたことにあり、逆に複雑性を下げようとする試みはいつも失敗してきたという評価
「アーキテクチャ設計が最も価値ある技術だが、AIには代替できない部分だ」という主張に対し、実際にAIへ明示的にシステムアーキテクチャ設計を依頼すると、現実に出会った設計者の少なくとも30%よりむしろ良い結果を返すことが多い、という意見。AI利用者がそうした依頼をあまりしていないだけだという立場
現在のLLMは主に中程度の水準（best practice）の回答が訓練データに多いため、自然と下位1/3程度の人間の設計者よりは良い結果、つまりコモンセンス中心の「無難な」設計を出しやすい一方、訓練データにない完全に新しい分野や高性能が要求される産業では、人間の「第一原理に基づく思考」がより必要になり、LLMが設計するDBカーネルも革新的というより基本レベルにとどまるだろうという予測
記事自体が ChatGPT で書いたような独特のスタイル（短文、反復句、「XではなくX+1」、「Xではなく反対のX」といった表現装置の多用）を持っていることへの批判と、HNでこうした文章が多くのアップボートを得る現実への驚き
著者は実のところ、自分自身の技術（アーキテクティング）が不変で代替不可能だと思い込みたい、あるいはそううぬぼれていることから来る「希望的観測」なのではないか、という解釈。もし別の能力に秀でていたなら、それを代替不可能だと考えていただろうという寸評
アーキテクトの本質とは、要求と制約を正確に理解し、それをシステムに反映できる能力、つまり良いプロンプトを書けて、回答を正しく読み、必要なら強く反論できる力にある、という要約
現実で出会った「アーキテクト」の多くは、実際のITインフラの専門性がなく、作図ツールや Excel さえ扱えればよいと思っているなど、実質的な能力が不足しており、マネージャーのように見えても実際に本質的な仕事をできる人は少数にすぎないという現実
AIに「過度に」依存する企業ほど、むしろイノベーションの波にさらされるリスクを高めているという意見。AI時代はコード生産性よりコード品質管理が核心なのに、市場は自動コード生成に過剰に集中しているという指摘。Satya Nadella の「MSコードの30%はAIで書かれている」という発言や、実際にGithubで月平均20件以上の障害・事故が発生している傾向（根拠リンク: githubstatus.com/history）に触れ、効率だけを追って品質低下のツケを払う企業が出てくると予想。特にMS級の巨大企業ではない中小企業は崩れる危険があるという話
AIを無視する企業のほうが、むしろ苦戦するだろうと見る反論
「AIを使いすぎる企業は、むしろ長期的に大きなコストを抱える」という主張と関連記事の紹介（AI: Accelerated Incompetence）
「コードは資産ではなく負債だ」という主張に100%共感するという意見。目標は最小限のコードで目的を達成することだが、AIはむしろコードを簡単に量産できるため、コード負債をはるかに大きくしてしまうという懸念
技術進歩の生産性パラドックス（生産性が上がったのに、実際にはシステムの複雑化によって効率向上が相殺される現象）に関するWikiリンクを共有（Productivity paradox）
現代のAIによるコード生成の時代は、昔 MS FrontPage でWebサイトを作っていた頃、html の90%が不要なコードで埋め尽くされていた「クラフトの時代」に似ている、という比喩
いまやコードが簡単に置き換えられるなら、むしろ負債という見方自体が無意味になるのではないか、今後はエラーが出たらプログラマーがAIにコードを書き直させるだけなので、負担は軽くなるかもしれないという逆張りの発想
自分はコードを創造的で芸術的な表現として見る側面もあるという意見。読みやすく洗練されたコードを見ると、すぐに美しさを感じられた経験を共有
FORTRAN の初期リリース（1954年）の時点から、「フォートランはコーディングとデバッグそのものをなくしてくれる」というスローガンがあったことを思い出させるリンクを共有（BackusEtAl-Preliminary Report）
こうした議論の底にある前提は、技術的進歩が近いうちに限界へ達するという期待だが、もしそれが間違っているなら、いつかAIがインフラ全体、ログ、財務、文書まで把握し、ビジネスそのものまで包括的に理解・設計する日が来ないとは言えない、という足場になる意見。AIモデルはなお増え続け、機能はより良く、より安くなっており、結局いつかは代替の本質にまで到達する側に重みを置く考え
開発者の解雇は技術進歩のせいではなく、不確実性に対する事後対応であり、技術やAIを言い訳にしているだけだという見方。5年前までは、コストを負担してでもSWエンジニアを増やして生産性向上を図っていたことを例に挙げ、したがってコストが根本原因ではないという主張
AIバイブコーディングをレビューしてくださる方を探しています。すでに全部作ってあるのですが、エラーが出るので少しだけ直してください――そんな外注依頼がすでに出てきていますが、新しく作るほうが早いでしょう。
これ、私もやられたことがありますが、本当に凄惨でした…
知らない人たちなのか、気にしていない人たちなのか、とにかく多いんですよね...
翻訳も同じで... AIは使い物になる？とはいえ、多くの人を苦しめている気がします...
ぱっと見はもっともらしいですが、直す側の立場だと仕事はさらに増えるんですよね……
鳥肌立つｗｗｗｗ