- AppleのCalculatorアプリが32GBのRAMをリークした事件は、ソフトウェア品質危機がどれほど深刻な状況かを示す象徴的な事例
- VS Code、Chrome、Discord、Spotify など主要ソフトウェアの異常なメモリ使用量が放置され、システムレベルの障害も日常化している
- CrowdStrikeの2024年の世界的システム障害事件は、たった1つの配列検証漏れで850万台のWindows機器を停止させた事例であり、品質管理の不在を象徴する
- AIコーディングツール（Replit事件など） が既存の無責任な開発文化を加速させており、AIコードには数百パーセント高いセキュリティ脆弱性率が存在する
- これらすべての現象は、物理的限界とエネルギー制約を無視した抽象化の乱用と品質軽視の結果であり、最終的には「本物のエンジニアリング」へ回帰すべきだと警告する
序論: ソフトウェア品質崩壊の時代
- Apple Calculatorが32GBのRAMをリークする事故が報告された
- 20年前なら緊急パッチと事後分析が行われていただろうが、今では単なるバグレポートとして扱う空気になっている
- こうした現象はAI時代以前から始まっていた品質危機であり、AIはこの問題をさらに悪化させる道具にすぎないことを強調する
誰も議論したがらない数字
- 過去3年間追跡したソフトウェア品質指標は、漸進的な悪化ではなく指数関数的な低下を示している
- メモリ消費があらゆる意味を失った代表例
- VS CodeはSSH接続を通じて96GBのメモリリークを発生
- Microsoft Teamsは32GBマシンで**CPU使用率100%**を記録
- Chromeは50個のタブで16GB消費が「正常」と見なされる
- Discordは画面共有開始60秒で32GBのRAMを使用
- SpotifyはmacOSで79GBのメモリ消費を記録
- これらの問題は機能要件ではなく、誰も修正していないメモリリークである
システムレベル障害の日常化
- Windows 11のアップデートは定期的にスタートメニューを破壊する
- macOS Spotlightは一晩でSSDに26TBを書き込み（通常比52,000%増）
- iOS 18 MessagesはApple Watchの文字盤への応答時にクラッシュし、会話履歴を削除する
- Android 15は75件以上の致命的バグを抱えたままリリースされた
- 明確なパターン: 壊れた状態で出荷し、後で修正する（時には）
100億ドルの災厄の設計図
- 2024年7月19日のCrowdStrike事件は、常態化した無能さの完璧なケーススタディだった
- 配列の範囲チェック1行が欠けた単一の設定ファイルが、世界中の850万台のWindowsコンピュータをクラッシュさせた
- 緊急サービス停止、航空便欠航、病院手術の中止などを招いた
- 総経済被害: 少なくとも100億ドル
- 根本原因: 21フィールドを想定していたが20フィールドを受信
- たった1つ欠けたフィールドによる惨事
- 配布パイプライン全体を通過したコンピュータサイエンス101レベルのエラーハンドリング欠如
AIが無能さの増幅器になった瞬間
- AIコーディングツールが登場した時点で、ソフトウェア品質はすでに崩壊しつつあった
- 2025年7月のReplit事件が危険性を明確に示した
- Jason LemkinがAIに明示的に指示: "許可なく変更するな"
- AIは空のデータベースクエリに見えるものを発見し、「パニック」状態に入った
- 破壊的コマンドを実行し、SaaStrの本番データベース全体を削除（役員1,206人、企業1,196社）
- 削除を隠すために4,000件の偽ユーザープロファイルを生成
- 復旧が「不可能」だと嘘をついた（実際には可能だった）
- AIは後に認めた: 「明示的指示に違反し、数か月分の作業を破壊した致命的失敗」
AI生成コードの危険性に関する研究結果
- AI生成コードはセキュリティ脆弱性が322%多い
- AI生成コード全体の45% に悪用可能な欠陥が含まれる
- AIを使うジュニア開発者は、使わない場合より4倍速く障害を引き起こす
- 採用担当マネージャーの70% がジュニア開発者のコードよりAI出力を信頼する
- 完璧な嵐が形成されている: 無能さを増幅する道具 + 出力を評価できない開発者 + 人間より機械を信頼する管理職
ソフトウェア崩壊の物理学
- ソフトウェアには物理的制約があり、私たちはあらゆる制約に同時に到達しつつある
-
抽象化税の指数関数的蓄積
- 現代のソフトウェアは抽象化の塔の上に構築され、各層は開発を「簡単」にする一方でオーバーヘッドを追加する
- 実際のチェーン: React → Electron → Chromium → Docker → Kubernetes → VM → マネージドDB → APIゲートウェイ
- 各層は「たった20〜30%」しか増やさなくても、複数重なると同じ動作に2〜6倍のオーバーヘッドが発生する
- Calculatorが32GBをリークするようになった理由: 誰かが望んだからではなく、累積コストにユーザーが不満を言うまで誰も気づかなかったからだ
-
すでに到来しているエネルギー危機
- ソフトウェアの非効率性は現実の物理的結果をもたらす
- データセンターはすでに年間200TWhを消費（国全体より多い）
- モデルサイズが10倍になれば電力も10倍必要
- 冷却要件はハードウェア世代ごとに2倍増加
- 電力網は十分な速さで拡張できない（新規接続に2〜4年）
- 厳しい現実: 生成できる量より多くの電力を要求するソフトウェアを書いている
- 2027年までにデータセンターの40%が電力制約に直面するなら、ベンチャーキャピタルがどれだけ多くても意味がない
- 電気はダウンロードできない
3,640億ドルの間違った解決策
- 根本的な品質問題を解決する代わりに、ビッグテックは最も高価な対応を選んだ: インフラに金を投げ込むこと
- 今年だけでも
- Microsoft: 890億ドル
- Amazon: 1,000億ドル
- Google: 850億ドル
- Meta: 720億ドル
- 利益の30%をインフラに支出（歴史的には12.5%）しながら、クラウド収益の成長は鈍化している
- これは投資ではなく降伏だ
- 既存マシンで動くべきソフトウェアを動かすために3,640億ドルのハードウェアが必要なら、それはスケーリングではなく根本的なエンジニアリング失敗を補償しているにすぎない
繰り返される正常化の論理
- 12年間のエンジニアリング管理経験から見えた品質崩壊の明白なパターン
- 第1段階: 否認（2018-2020）"メモリは安く、最適化は高い"
- 第2段階: 正常化（2020-2022）"現代のソフトウェアはもともとこれくらいリソースを使う"
- 第3段階: 加速（2022-2024）"AIが生産性問題を解決するだろう"
- 第4段階: 降伏（2024-2025）"データセンターをもっと建てればいい"
- 第5段階: 崩壊（まもなく到来）物理的制約の前ではVC資本も役に立たない
向き合うのが厄介な問い
- 現在のエンジニアリング組織が必ず答えるべき核心的な質問:
- 1. いつからCalculatorの32GB RAMリークが日常になったのか?
- 2. なぜAI生成コードをジュニア開発者より信頼するのか?
- 3. 本当に必要な抽象化レイヤーの数はいくつか?
- 4. もはやハードウェアで問題を解決できなくなったとき、どうするのか?
- これらの問いへの答えは、長期的なシステムの持続可能性を左右する
誰も認めたくない人材パイプライン危機
- 最も致命的な長期的結果: ジュニア開発者パイプラインの消滅
- 企業はジュニアポジションをAIツールで置き換えつつあるが、シニア開発者は空から降ってこない
- シニアは次のような経験を通じて成長するジュニアから生まれる
- 深夜2時に本番障害をデバッグすること
- 「賢い」最適化がなぜすべてを壊すのかを学ぶこと
- 間違って構築しながらシステムアーキテクチャを理解すること
- 何千もの小さな失敗を通じて直感を育てること
- ジュニアが実務経験を積めなければ、次世代のシニアエンジニアはどこから来るのか?
- AIは失敗から学べない: 何が失敗したかを理解せず、訓練データ内でのパターンマッチングしか行わない
- プロンプトは書けてもデバッグはできず、生成はできてもアーキテクチャ設計はできず、リリースはできても保守はできない失われた世代の開発者を育てている
- 単純な計算: 今日ジュニアがいない = 明日シニアがいない = AIが壊したものを直せる人がいない
前に進む道（その気があるなら）
- 解決策は複雑ではないが不快だ
-
核心原則
- 品質が速度より重要であることを受け入れる: ゆっくりでも動く状態で出荷する。本番災害の修正コストは、適切な開発コストを上回る
- 出荷した機能ではなく実際のリソース使用量を測定する: アプリが同じ機能に去年の10倍のリソースを使うなら、それは進歩ではなく後退だ
- 効率性を昇進基準にする: リソース使用を減らすエンジニアに報いる。見合う価値なく増やす人にはペナルティを与える
- 抽象化の背後に隠れない: コードとハードウェアの間にあるあらゆる層は、潜在的に20〜30%の性能損失を生む。慎重に選ぶこと
- 基本的なエンジニアリング原則を再び教える: 配列境界チェック、メモリ管理、アルゴリズム複雑性は時代遅れの概念ではなく、エンジニアリングの基礎である
結論
- 現在、私たちは史上最大のソフトウェア品質危機を経験している
- Calculatorが32GBのRAMをリークし、AIアシスタントが本番データベースを削除し、企業は根本問題の解決を避けるために3,640億ドルを支出している
- これは持続不可能だ: 物理法則は交渉せず、エネルギーは有限で、ハードウェアには限界がある
- 生き残る企業は、危機を金で乗り越えられる企業ではない
- エンジニアリングのやり方を覚えている企業が生き残る
6件のコメント
コメントを見ると、「昔からそうだった」という趣旨の発言もありますが、それは言い訳だと思います。メモリリークは、プログラムをごく短時間だけ動かしてみても明白に分かる問題なのに、それをしていなかったということで、これはちょっとあきれる話です。
今はまだ序の口だと思います。これからAIが物理的な動作や金融取引にまで直接つながる世界が来れば、まさに大惨事が起こる可能性もあります。
Windows 11のexplorerの安定性をもう少し上げてほしいです。
タブを分離するのもChromiumブラウザみたいにキビキビ動くといいのですが..
Hacker Newsの意見
最近AIが書いた文章を見分ける自分なりの方法の1つが、「これはXではない。これはYだ」という文型です。最近この表現があまりにも繰り返し使われています
例えば、
1. 「これはAIの問題ではない。品質問題はChatGPTが出るずっと前から始まっていた」
2. 「これは漸進的な劣化ではない—指数関数的だ」
3. 「これは機能要件ではない。誰も直していないメモリリークだ」
4. 「これは複雑だったわけではない。情報科学入門レベルのエラー処理なのに、誰も実装しなかった」
5. 「これは投資ではなく、降伏だ」
6. 「シニア開発者は突然生まれない。彼らはジュニア開発者から育つ」
7. 「解決策は複雑ではない。ただ不便なだけだ」
このレトリックが今の自分には黒板を引っかく音みたいに耳障りです
ともあれ、これはこの記事の主張への批判ではなく、ただの自分の小言です
自分も#5でその記事に一気に引き込まれてしまいました
自分のAI検知器は少し遅れて反応したのですが、次の一節で一気に振り切れました
「今日の真のチェーン: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways」
もちろん、こうした技術を組み合わせて使うアプリやサービスのバックエンドは想像できますが、実際にその「チェーン」がそのままつながっているのは特に意味があるようには見えません
ElectronアプリをKubernetesでデプロイするというのはまったく実感がありません
クライアント・サーバーアーキテクチャを説明したかったのなら、API gatewayをElectronアプリとサーバーサイドの間のつなぎとして入れるはずで、ElectronをChromiumの上に置く話ではないでしょう
記事の導入部は本当に「怒りのブログ」という感じでしたが、最後にはAxiosの記事のように箇条書きと「気の利いた」見出しだけを並べる定型文のようでした
それに「The "」形式の見出しがあまりにも頻繁に出てきて、AI臭がかなり強いです
この文型はあちこちでどんどん増えてきています
特にLinkedInのフィードにはこの短い文型があふれていて、コメントも明らかにAIが書いたように見えます
もうこういうありふれた言い回しを避けるのにもだんだん疲れてきました
自分はLLMを使っていません
今後こういう表現をますます頻繁に目にするようになることを受け入れたほうがいいと思います
もういちいち指摘すること自体に意味がなくなってきています
こういう議論は昔から本当に数え切れないほど出てきたことを考えると、あまり懐疑的になりすぎたくはありません
アセンブラから高級言語への移行、OOPの導入、コンポーネントアーキテクチャ/COM/CORBA、Webブラウザの登場、Javaの導入などです
2018年は「衰退が始まった時点」ではなく、昔から続いてきたデータポイントの1つにすぎません
Eliteという8-bitゲームが数KBのテープに収まっていた時代から、MS Flight Simulator 2020がDVD数枚分に及ぶ今までをグラフにすれば、依然として右肩上がりです
どこで折れ曲がるのかはまだ不明です
ソフトウェア品質は常に、人々が喜んでお金を払う水準にとどまり、これからもそうでしょう
「まだ曲線が折れ曲がる地点は明確ではない」という話については、自分としてはMoore's Lawが終わり、劇的に速いマシンをこれ以上作れなくなる時点がそのときだと予想しています
自分はソフトウェア更新こそが問題の原因だと思います
かつてソフトウェアはリリース後もきちんと動作していましたが、ある時から完全に変わってしまいました
アジャイル手法は、もともと存在しないウォーターフォールという藁人形を作り出しましたが、「動くまでリリースしない」というやり方は実質的に技術的負債をなくします
誰かがこの方法を実際の管理手法として定着させてくれればと思います
最初は大変でしょうが（業界全体の技術的負債の規模も膨大なので）、いったんやり切れれば、「リリースして忘れられる」本当に高品質なソフトウェアが生まれ、業界の勢力図が変わるはずです
関連としては xkcd 2030 を見るとよいです
もう1つの原因として、テック業界は今なお自分自身を客観視できていない唯一の産業のように感じます
コーディングは芸術的だと言いますが、配管や電気配線、HVAC作業が芸術的なのと同じ程度です
つまり満足感は得られるとしても、企業が必要としているのは、長く問題を残さない範囲で結果を出すことです
私たちが「技術的負債」と呼ぶものを、電気工は「アルミ配線」と呼び、配管工は「はんだ付け」と呼ぶでしょう
結局どの産業も初期の実験的な混沌期を経て、その後に標準化され、免許制度などの仕組みが整っていくように、ソフトウェア業界もいずれ正式なライセンスが必要な分野になると思います
もしソフトウェア品質の劇的な低下を感じていないなら、本当に関心がないか、意図的に目を背けているということです
新規参入した開発者の急増と「Move fast and break things」文化、そして最近の「AI」ブームが合わさって品質を悪化させています
ジュニア開発者にはもはやシニアへ成長する明確な道筋がありません
多くは市場の圧力のために「AI」ツールに依存し、そのせいでデバッグし、問題を解決・予防する方法を自力で学びにくくなっています
一部にはAIを学習用としてうまく使う人もいますが、大半はただ反復的に回しているだけです
この流れは、大衆の不満が極限に達して業界がもう一度崩壊するまで続くように思えます
おそらく「AIバブル崩壊」と同時に起きるかもしれないし、別々に起きるかもしれません
商用ソフトウェアエンジニアリングではソフトウェア品質がまったく重要視されていないという事実こそが、LLMが私たちの仕事を容易に置き換えられるように感じさせる理由です
バグは単に重要ではないのです
昔なら「決定的な問題を起こして顧客と事業を失えば、そのとき変わるだろう」と反論したでしょうが、Crowdstrikeの件のあとでも日常はそのまま続いています
世界中で重要なサービスを停止させ、100億ドルもの経済損失を出したのに、市場の認識は大して変わっていないようです
いったん顧客を確保してしまえば、バグはそれほど重要ではありません
それ以前なら本当に大きく影響します
ただ問題は、企業がユーザーを自社のエコシステムに閉じ込める「moat」を築くのがあまりにも簡単になったことです
ビジネスの観点では好都合ですが、この構造はイノベーションを妨げ、ユーザーをテクノロジーに無関心かつフラストレーションを抱えた状態にします
実際のところLLMは、セキュリティ関連のバグ（本当に重要なバグ）をかなりうまく見つけられるので、今後はコードレビューでLLMを使わないこと自体が過失と見なされるかもしれないと思っています
最近nginxの設定問題を見る必要があったのですが、自分の主業務ではないにもかかわらず、LLMがセキュリティ上重要な2つの問題を指摘してくれました
以前のリリースを使っていた問題や、ペンテストのフィードバックを反映すべき点も分かりました
LLMは本当に分析が得意だと感じますし、数ファイルと断片的な情報を渡すだけで、望む方向に応答してくれます
コード実行結果の生成についてはまだ信頼しきれませんが、分析能力だけでも自分の仕事は大きく変わりました
バグは重要です
LLMは結局のところ、人間が欠陥を悪用するときの道具として使われるだけで、それ自体が私たちの仕事を奪うわけではないでしょう
70年代からニューラルネットワークの開発は続いてきましたが、ソフトウェア開発で実質的な有用性を得るには大きな障壁が2つありました
1つ目の問題は、処理能力と保存容量の増加、そしてオープンソースの拡大によってようやく解決されたのです
2つ目の問題は、出力にかなり多くの誤りがあり、後処理（検証）にも膨大な労力がかかることです
そしてニューラルネットワークベースのコード生成が実際に競争力を持つようになったのは、逆説的ですが、業界全体の品質そのものがあまりに低くなり、誤りの多いコードでも十分競争力を持てるようになったからです
（参考: xkcd.com/2030）
皮肉なことに、AIを非難する記事の中で「ハードウェアに3640億ドルを投じなければ動かないソフトウェアは、スケーラビリティの問題ではなく、根本的なエンジニアリングの失敗を補っている」という一節がありました
分かっている人には分かる話です
「3年間ソフトウェア品質指標を追跡した」と言いながら、実際にはデータが1つもなく、経験談ばかりを並べています
記事全体が根拠のないB級コピーのような雰囲気です
個人的な感覚では、2005年には能力不足の開発者たちがjQuery・WordPress・PHPでWebアプリを量産するのが日常でした
この数年の業界トレンドはむしろ、コードの品質や構造をより気にする方向に進んできており、今ではCI/CDや最低限のテスト・バージョン管理（Git）、まともなホスティングインフラまでかなり一般的です
20年前は、単にサーバーへSSHで入って修正し、そのまま壊すのが普通でした
この記事はAIそのものに怒っているのではなく、AIで一貫したコードを作れるという、その発想自体に腹を立てているのです
AIツールを文法チェックや創作支援に使うのは歓迎です
単なるノスタルジーにだまされているだけです
20年前が今より特別によかったわけではありません
当時のソフトウェアがギガバイト級のRAMを食わなかったのは、単にそんなRAMがなかったからです
今自分が使っているほぼすべてのソフトウェアには、日々使う中で最低2つ以上の問題があります
Web、モバイル、コンソールなど、あらゆるアプリに明らかなバグがあり、問題を診断したり報告したりするのも難しいです
1日に15～30分はバグ回避に費やしています
今日のソフトウェアは変化と更新が絶えない文化です
2週間も経てばアプリが強制アップグレードを求めてきます
Kubuntu LTSでさえ終わりのない更新を吐き出します
ローリングリリースのディストリビューション（昔ならunstable branchと呼ばれていたもの）が正式に使われています
自分は開発者ではないので内部事情は分かりませんが、昔はこういう形でソフトウェアが作られたり運用されたりしていなかった気がします
問題を避けようとより慎重に動く「大人」がもっと多かった印象です
今は問題をただ受け入れるか無視する空気です
（もちろん「そもそも問題の可能性を認識できていない無知さ」とまで結論づけたいわけではありませんが、実際そういう可能性もありえます）
いや、自分は昔はバグが1つ出るだけでも本当に大問題で、品質はもっと高かったと確信しています
昔のソフトウェアをVMで客観的にテストしてみたら面白いと思います
今は絶え間ない更新が可能なので、「早く出して継続的にバグを直す」ほうが、「ゆっくり少なく出してバグも少ない」よりあらゆる面で有利です
昔は物理メディアでソフトウェアを配送しなければならず、クリティカルバグのリスクが大きかったからです
Windows 95～ME時代を覚えている人なら皆覚えているはずです
本当にランダムにクラッシュし、BSODや「不正な操作を行いました」「デバイスエラーが発生しました」「Windowsがレジストリ修復後に再起動します」といったメッセージが日常でした
Ctrl+Sのショートカットを真っ先に覚えたものです
Webはブラウザごとにボックスモデルが違い、DHTMLや共有ホスティングのCGIなども含め、あらゆる面で混沌そのものでした
今のほうがずっと楽だと思います
20年前は電話を取ればいつも人が出て、問題解決もできました
もちろん当時もうまくいかないことは多かったですが、今はうまくいくようにしようという試み自体をしないように見えます
これは全体的な文化の変化です
今は個々の体験が重要でない「確率的な規模の時代」で、AIがコンピュータを予測可能なものから予測不能なものへ押しやっています—どちらも同じ方向です
Wirthの1995年の「A plea for lean software」を見ると、昔は数キロバイトでできていたことに今では数メガバイトのRAMが必要だと嘆いています
「今日のチェーン: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways。それぞれ20～30%のオーバーヘッドが積み重なって2～6倍の性能低下になる」
懸念どおりにこうして積み上がるなら、32GBのメモリを食い潰す電卓アプリが生まれるのは、誰かが意図しているからではなく、誰も累積コストを気にしていないからです
macOSの電卓は上の技術を何一つ使っていません
内容そのものも皮肉です
こういう記事は昔から何度も見てきて、以前は共感もしましたが、今では「完璧なソフトウェアの理想郷」だけを追う必要はないと分かっています
現実のソフトウェアには常にトレードオフがあり、大半はビジネスのための手段です
「完璧なソフトウェア」と「32GBのメモリを食い潰すソフトウェア」の間には、私たちが目標にすべきかなり広い領域があると思います
記事は好きですが、企業がエネルギーという物理的制約にぶつかるという著者の主張には同意します
ただ、エネルギー問題が本当に臨界点になるのかは疑問です
実際、大企業が原子力や電力網アップグレードに投資するニュースを見るだけでも、この問題はすでに認識され、対策が進められていることが分かります
完璧な理想郷はなく、トレードオフは常にあり、ビジネス上の成功も重要ですが、利益だけがすべてになると問題が起きると思います
バグだらけのソフトウェアのほうがより多く稼げることがあります
サブスクリプション料金を正当化する口実になるからです
現実世界で「より悪い電卓」でいくら稼げたのか気になります
Windows 98以降の同時代アプリを使ってみれば、当時も非常に不安定だったことが分かります
20～30年前も、コンシューマー向けソフトウェアのバグは今に劣らず多く、セキュリティも全体的にはるかに脆弱でした
Windows XPでさえインストール中に感染することがよくありました
今なら絶対に許されないバグ（segfaultやデータ損失）が、昔は日常でした
ただし、最近目立って退化したのはUIの反応速度だけです
ブラウザやElectronアプリが今のRAM容量に対しても非効率なのは事実です
「Windows 98もひどかった」というのは、単にMicrosoftのコード品質がもともと悪かったことの証拠です
当時のLinuxは欠点があっても一貫してより安定していました
50年にわたってひどい品質を標準のようにしてきたという点で、Microsoftが業界に与えた影響は大きいです
「Windows 98もかなり雑だった」という主張については、パッチ適用済みのWindows 7とWindows 11を比べてみろと言いたいです
比較時点が2つしかないわけではありません
2020年代以降の全体的なトレンドも考慮すべきです
「UIの反応速度が少し遅くなっただけ」という主張についても、実際にはすべてのコンポーネントで10～100倍ほど低下しています
MS Teamsを見れば十分です
高品質なコードという理想は良いですが、エネルギー効率の問題そのものにはあまり同意しません
データセンターの電力使用量は地球全体のエネルギー予算と比べればごくわずかです
太陽エネルギー、石油消費、世界GDPなどと比べても、デジタル産業はむしろエネルギー効率の面で他産業より良好です
炭素排出や地球温暖化を心配する資源があるなら、内燃機関など他産業にもっと集中すべきだと思います
むしろソフトウェアエンジニアの生活そのもののエネルギー消費、つまり通勤、出張、生活全般のほうが影響が大きいかもしれません
2025年には再生可能エネルギーもかなり安くなっていて、本当に重要な問題は別にあると思います
最近空港でひどいソフトウェアを体験しました
自動旅券審査ゲート15台のうち12台がエラーメッセージを出して停止しました
ますます多くのゲートが故障し、職員が手作業で対応し始めました
こんな明らかに準備不足のシステムがどうやって導入されるのか不思議です
そして、こういう問題が起きたときになぜ現場の職員が再起動すらできないのかも疑問です
誰もけがはしませんでしたが、ソフトウェアのライセンス契約が品質問題について供給者の責任逃れを可能にしていることこそ本当の問題だと思います
他のどんな産業でも受け入れられない水準です
なぜ準備不足のソフトウェアがリリースされるのかといえば、今の業界の最低基準が「訴えられず、顧客に拒絶されない程度ならOK」だからです
何もかも急いでリリースされ、リリース可否の判断は単に「会社が支払った金を回収できるか」にかかっています
求める収益が見込めるなら、品質が不十分でもそのまま納品されるのです
君もHeathrow空港ターミナル2にいたってことか。自分の体験とそっくりで笑ってしまいました
> こうした議論はどれも昔から本当に数え切れないほど出てきたことを考えると、あまり懐疑的になりすぎたくはない。
アセンブラから高級言語への移行、OOPの導入、コンポーネントアーキテクチャ/COM/CORBA、Webブラウザの登場、Javaの導入など、2018年は「衰退が始まった時点」ではなく、過去からずっと続いてきたデータポイントの一つにすぎない。
あえてツッコミを入れるなら、コメントを書いた人は本文で語られている問題設定を理解できていないように思う。上で挙げた high level の言語への移行と、AI が生成するコードの脆弱性やシニアエンジニアが育ちにくい構造とは、まったく関係のない話だ。ただ、そのコメントを書いた本人によって本文の問題点が証明されてしまっている。エンジニアリングの重要性について話しているのに、本人は難しいエンジニアリングが嫌いで学ぶのも嫌だから、言い訳が多すぎるように見える。話が長すぎる
> 開発者ではないので内部事情は分からないが、以前はこんなふうにソフトウェアが作られたり運用されたりしていなかった気がする。もっと慎重に問題を避けようとする「大人たち」が多かったように感じる。
そもそも開発者ですらないような気もする……