コーディングは既に完成されたはずなのに、なぜソフトウェアは劣化し続けるのか？

プログラミングという技術そのものは成熟し、優れたツールやフレームワークも揃っているはずです。しかし、私たちが日常的に使うソフトウェアは、なぜか動作が重くなり、バグが増え、ユーザー体験が悪化の一途をたどっているのでしょうか？技術的負債や過剰な抽象化の罠、あるいは開発サイクルの変化など、この業界が抱える矛盾について議論しましょう。

ソフトウェアが（ある意味で）劣化しているという点には同意するけど、AIのせいだとは思わないな。ユーザーとしての経験は実際ほとんど変わってない。ストリーミング機器はテレビへのキャストに失敗するし、ブラウザは企業側が出す赤いコンソールエラーや500エラーを確実に、かつ効率よくユーザーに届ける装置になっている。公共のタッチパネルには今でもブルースクリーンが映っているしね。Uncle Bobが、業界が良くならない理由をうまく言い当てていたよ。プログラマーの数は指数関数的に増えていて、全プログラマーの半分は実務経験がn年（5年？）未満という状況なんだ。加えて、私は2つの理由を挙げるよ。第一に、プログラマーは個別のアルゴリズムをシングルスレッドで書く練習ばかりしてスキルを磨く。そこでは間違えても何度でも書き直せるから問題ないんだ。でも実際に仕事に就くと、自分が「分散システム」の中にいることにすら気づかず、練習で慣れ親しんだゲッター/セッターモデルが、外部システムとの連携、CQRS、イベントソーシング、監査可能性、冪等性といった、現実の開発で求められる要素に対してあまりにも無力だと思い知らされる。要するに、10年間forループやデータ構造の練習を積み重ねたところで、データベースのスキーマが更新されている最中に、スマホやブラウザの複数タブからユーザーがアクセスしてくるようなシステムを構築できる力にはならないんだ。第二に、アジャイル開発に代わる現実的な選択肢はないと思っているけど、非技術系のプロダクトオーナー（PO）がソフトウェアのライフサイクルを支配してしまっているように見える。「MVPのためにハッピーパスだけ考えておこう」という進め方がバグだらけのソフトウェアを生んでいる。優秀なエンジニアなら、そんなやり方は将来の書き直しを約束するようなものだと学べるけれど、POは決してそれを理解しない。言語はどんどん初心者向け（C++ -> Java -> JS -> Python）になっている一方で、タスクは複雑化（B2B分散システム、24時間365日の稼働、数百万人のユーザー、ハッカーへの耐性、機械学習など）し続けている。

「macOSでSlackを開いたら、アイコンがDockで数秒間跳ねていた。待ちきれなくてGhosttyに切り替えて入力を始めた途端、Slackのウィンドウが飛び出してきてGhosttyからフォーカスを奪い、git pullコマンドがそのままグループチャットに送信されてしまった。」フォーカスを奪う動作を完全に無効化する仕組みがどうして標準にならないのか、未だに理解できない。私が作業中だったり、何らかの方法でUIとやり取りしている最中なら、他のアプリがフォーカスを奪うべきじゃない。絶対に。文句があるなら鬱陶しいポップアップでも出すなり、不快な警告音でも鳴らすなり、アイコンを点滅させるなりすればいい。99.9%、いや100%の確率で、その通知は私の作業と何の関係もないし、絶対に待てるはずだから。一部のOSにはそれに近い機能があるけれど、結局バイパスするためのツールまで用意されている（Cisco AnyConnect、お前のことだよ！接続ボタンを押した後の接続完了通知なんて緊急事態じゃないんだから！）。ターミナルで作業している最中にアプリが勝手に標準入力を奪うなんて想像してみてよ。なぜGUIならそれが許されているんだ？

「macOSでSlackを開いたら、アイコンがDockで数秒間跳ねていた。待ちきれなくてGhosttyに切り替えて入力を始めた途端、Slackのウィンドウが飛び出してきてGhosttyからフォーカスを奪い、git pullコマンドがそのままグループチャットに送信されてしまった。」KDE Plasma（Wayland使用時）で一番気に入っている機能の一つに、フォーカスを奪えるアプリを制御するグローバル設定があるんだ。あれは最高にうまく機能していて、仕事でMacやWindowsを使わなきゃいけない時はいつも恋しくなるよ。詳細はここのドキュメントを参照して。"Focus stealing prevention"の項目にあるよ - https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehaviour/index.html#focus

HNの他のユーザーと比べて非技術者である私の意見だけど、これは非技術者向けのソフトウェアにおいて常に課題だったことだと思う。デザインはプログラマーの経験則やテクノロジーのトレンド（例：JSが流行っているから多くのJS開発者を雇える企業は、その問題にJSが最適かどうかに関わらずJSを選ぶ、といったこと）に左右されてきた。一時期、エンタープライズ分野でUXや人間工学、HMIが注目を浴びたこともあったし、私見では21世紀のコンシューマー向けソフトウェアにおける最大の技術的成果はUXの領域にあったと思う。でも、消費者から金を稼ぐために優れたソフトウェアを作る必要はなくなったからか、その重要性は失われてしまった。AIが開発速度などでエンジニアにもたらす恩恵が何であれ、根本的な行動原理は変わらない。商用ソフトウェアは人間を考慮して開発されるわけじゃない。投資家や市場のため、運用ニーズのため、CEOの気まぐれ、あるいは開発者の個人的な欲求のために作られるんだ。人間体験の近似値は、プロダクトマネージャーやUXリサーチ（そもそも存在する場合の話だが、彼らがボタン配置をいじるためだけに呼ばれる頃には、既存製品のGUIは完成していることが多い）の商用プロセスを通して再生産されるだけ。人間体験が考慮されるとしても、それは利益を最大化するために私たちの弱みを突くという目的がある場合だけだ。だからこそ、21世紀の技術はダークパターンやフィード、ソーシャルメディア、LLMチャットボットなどを私たちに提供することになった。優れた、健全な、誇りを持てるものを作ろうと真摯に取り組んでいるエンジニアと話すときでさえ、多くの人はマシンへの命令を設計するのと同じような感覚で人間体験を設計しようと推論している。私の考えでは、状況が良くなることは決してない。AIはすでに存在している事象を増幅させているに過ぎないんだ。

「もしコーディングが解決されたのなら、なぜソフトウェアは悪くなり続けているのか？」コーディングが解決されたという前提自体が間違っているからだよ。:-)

「macOSのアップデート、あるいは依存しているアプリのアップデートが、期待よりも恐怖の源になってしまった。今では新しいバージョンになれば悪くなるものだと予想している。」これ、本当に共感する。昔は、無料で新しい機能が追加されるのを見るのが楽しみでワクワクしたものだ。Fedora Workstation 45で何が追加されるのか調べていたところだよ。スマホ、テレビ、車、そしてPC/ラップトップ上のLinux以外のOSにおけるアップデートは、今や私にとっては純粋に怖い。望んでもいない機能を何追加してくるんだろうか？ 外部とどの程度勝手に接続させられるんだろうか？ macOSは体験を台無しにしてユーザーの信頼を失ったけれど、その前からウィンドウのサイズ変更をするだけで、まるで80歳の老人のような動きになる（見えない小さな境界線を探す作業）など、期待できるようなものは何もなかった。Windows 11から移行する前にMicrosoftがやっていたと思うのは（証明はできないけど）、すべての変更を「必須のセキュリティアップデート」に紛れ込ませることだ。だからアップデートを避ける選択肢はない（特殊な設定でオフにしない限り）。そしてマシンが再起動すると、何か邪悪なものへの新しい接続を促すWelcomeプロンプトが追加されている。頼んでもいないAI機能、最近のダークパターンの筆頭だね。

ソフトウェアを速く作ることはできるけど、時間をかけるほどその正しさに対する自信は持てるようになる。これはAIコード生成以前から変わらない真実だけど、AIの登場で「速い」の定義がめちゃくちゃに変化してしまった。熟練のエンジニアなら1週間かかっていたものを、今や1時間で構築できてしまう。でも現時点では、それが「正しい」という確信には何一つ寄与しない。望むレベルの精度でソフトウェアを正しく動作させるためには、結局それなりに時間をかける必要があるんだ。あいにく、ソフトウェアの正しさ（安定性、パフォーマンス、バグのなさなど）を求める人たちにとって、現状あまりにも多くの開発者が前者の利益を享受するだけで、後者のトレードオフを無視しているように見える。（同時に、投稿者が不満を言っているようなメインストリームの消費財における品質は、ずっと前から崩壊している。そして彼らが挙げている例の多くはAI以前からあるものだという点にも注意が必要だ）

ソフトウェアの品質は市場のインセンティブと結びついているし、それは常にそうだった。AIが登場したからといって、誰もが堅牢なソフトウェアを書こうとするわけじゃない。だから突然ソフトウェアが良くなるなんてことは起こらないんだ。市場は「アップデートのたびに壊れないアプリ」を評価しないし、「Microsoftをワンストップショップとして使う」のと対照的に、「独立した複数のソリューションを継ぎ接ぎすること」も評価しない。もしコンピューティング黎明期にそれができたなら皆やっていたはずだが、当時はコンピュータの性能が低すぎて、知識も希少だった。こういう格言がある。「どんな馬鹿でも持ちこたえる橋を建てることはできるが、ギリギリで持つ橋を建てるにはエンジニアが必要だ」。私たちはソフトウェアが持ちこたえるために何が必要で、人々がどの程度の「ソフトウェアの些細な傷」なら我慢してくれるのか、その限界を見つけてしまったんだ。

LLMはコードベース全体を一度に解析して、それを理解した上で決定を下すことはできない。プログラミングにおいて難しい部分は、一つの関数やクラスがどう動くかではなく、それらが巨大な全体像の中でどう相互作用するかという点にある。これを緩和しようとすることはできるけど、ソフトウェアが巨大すぎてLLMのコンテキストウィンドウには収まりきらないというのは根本的な概念だ。これが解決されるまでは、コーディングがAIによって「解決」されたとは言えない。グリーンフィールド（新規開発）には便利だけど、そもそも新しいソフトウェアを素早く叩き出すのは、古いコードをいじるより常に簡単だったんだ。それに、コンテキストウィンドウが奇跡的に巨大になったとしても、人間が持つような理解力を彼らが持てるわけじゃない。

答えは当然、典型的なテック企業内のトレンドセッターたちが、今や完全に「正体不明の素人（非技術者、パワーユーザーではない層）」に入れ替わっており、彼らがビジョナリーを演じ続けているからだ。破損や劣化した挙動に気づき、優れたデザインを構想できる人々（エンジニアやパワーユーザー）は、製品に何を入れるかの決定権を持っていない。だから良くなることを期待してはいけない。彼らは素人たちが自分がやったと主張できるような変化を絶え間なく起こすだけであり、上層部はそれが本当に改善かどうかも分かっていないんだ。解決策は、プロダクト部門を解体し、リーダー層をエンジニアと入れ替え、最も熱狂的なユーザーを何人か雇うことだ。彼らは意見を述べることと、毎日製品を使うこと以外何もする必要はない。彼らをトップエンジニアたちと同じ部屋に入れれば、ソフトウェアは不思議と良くなっていくはずだ。こんなことは何十年も前から明らかだったのに、今は誰もがテック企業で楽な仕事をして、友達も同じように就職させることばかり考えている。その結果、偽物だらけになった。「インポスター症候群」という言葉が一般化したのは、専門知識の欠如を正当化するためだよ。「誰も何をしているのか分かっていない、仕事のやり方を知らなくても大丈夫」。それが、プロダクトマネージャーが毎朝鏡に向かって自分に言い聞かせている言葉さ。