ソフトウェア工学の幻滅を再び語る
# ソフトウェアエンジニアリングおよそ6年前、僕は「ソフトウェア工学の幻滅」というタイトルの文章を読んだことがある。
僕は、飛行機や建築をソフトウェア開発の比喩にするのはあまり適切ではないと思っている。というのも、前者はあまり変化しないプロセスであるのに対し、ソフトウェア開発は継続的な反復を前提にしているからだ。両者は性質が異なり、単純に同列には語れない。これは、家の建設途中でホールの移動城のような機能を追加してほしいとは僕が思わないのと同じで、家は自力で移動できなければならない、という話でもある。
AI が登場してから、最初は（2023年時点では）大したことはないし、日常的な開発を置き換えるにはまだ遠いと思っていた。2025年には AI 支援で開発するのが当たり前になり、自動補完はすでに欠かせない機能になった。そして今では、コードの90%以上が AI によって直接生成されている。ソフトウェア工学の幻滅が、別の形で再び押し寄せてきたのだ。
昔はエンジニアが自分で酷い code を書いていたが、今は AI が大量の、一見動きそうで誰も本当には理解していない code を生み出している。
今の AI ありのソフトウェア開発は、大きく分けて二派に分かれる。一方は、コードを書くことはすべて AI に任せるべきで、保守性や可読性、拡張性など気にする必要はなく、人間は意図や方向性の確認だけすればよいと考える。もう一方は、こうした AI Slop に何の価値もないと考える。
このポストの作者は Hono の作者だ。もしまだ Express を使っているなら、Hono を試してみることを強く勧める。彼は最近、低品質で、明らかに AI が生成した Pull Request に何度も遭遇し、とても困っているという趣旨のポストをいくつも投稿していた。
僕たちは今、LLM が登場した時代と、LLM が成熟した時代との間にある混乱期にいる。
LLM モデルが安定して成熟した時代は、いつか必ず来る。モデルの進歩はソフトウェア開発の姿を根底から変えるだろう。しかし、その日がいつ来るのかは分からない。シンギュラリティがまだ訪れていない以上、僕たちにできるのは流れに身を任せることだけだろう。
痛みと興奮の中にいる
僕は一方で、これからの AI の発展をかなり有望だと見ている。モデルの能力がもっと良く、もっと強くなれば、今は人間の介入が必要な多くのことが、いずれ自然と置き換えられていくだろう。
コードの品質であれ、AI が生成するコードの品質であれ、あるいは作品をより良くするために必要な手間であれ、敷居はどんどん低くなる。
だが最近起きたいくつかの出来事は、僕を少し苦しい気持ちにもさせる。プロジェクトの中でもコミュニティでも、AI が書いたものをレビューもせず、そのまま投げる人をよく見かけるのだ。
それは、読み手の感情を考えていないということだ。コードであれ、ドキュメントであれ、あるいは何かを議論しているときでさえ、相手が Gemini との会話ログをそのまま貼り付けてくることがある。僕は、最低限としてまず自分の考えを持ち、そのうえで AI を使って論点を確認したり強化したりしてから、それを提示すべきだと思っている。そして最初の整理は自分でやるべきだ。そうすることが、読み手への敬意だと思う。
Simon が Anti-patterns: things to avoid で述べているように、AI で数千行のコードを生成し、自分で確認もせずに PR を出すのは、「この code が使えるかどうかを確認する仕事」を reviewer に押し付けているのと同じだ。
Reviewer も AI に書かせればいいなら、お前はいったい何を貢献したのか？
責任ある PR とは、こうあるべきだ。自分で検証しているから、その code が正しく動くという確信がある。変更範囲は十分に小さく、reviewer が開いた瞬間に閉じたくなるようなものではない。PR description には、その変更をなぜ行うのかを説明する十分な文脈がある。AI に、それっぽく見えるが自分では読んでいない説明文を生成させるのではない。 AI によって code の生成があまりに簡単になったからこそ、逆に自分がきちんと関与していることを示す必要がある。
手動テストの記録、実装選択の説明、あるいはスクリーンショット一枚でもいい。そうしたものは、reviewer に対して「僕は読んだ。これはただ投げ捨てたゴミじゃない」と伝えるためのものだ。
品味
僕を苦しめるもう一つの要素は、品味と経験の問題だ。
長くコードを書いていると、自然に anti-pattern を見分けられるようになる。今は動くが、遅かれ早かれ問題になる書き方だと分かるし、修正は数行で済むことさえある。
しかし問題は、今では多くの人が AI に code を出させたらそのまま使い、あまり見直さないことだ（僕自身もそういうことがある）。すると負の循環が生まれる。AI は問題のある code を context として読み込み、その問題のある土台の上に次の code を生成する。結果として、どんどん歪んでいくのに、使う側はそれに気づかない。
具体例をいくつか挙げよう。
React の useEffect の中で setState を呼び、不必要な再レンダリングを引き起こすこと。あるいは設計判断として、CDN を使わずにファイルシステムから静的資源を直接読むこと。
こうしたものはローカルテストではまったく問題ないし、ユーザーが少ないうちは問題にならない。だがトラフィックが増え、コードベースが膨らみ始めてから、直すのに数行では済まないと気づくのだ。
しかも、これは開発者が怠けて検査しなかったという話とは限らない。そもそもどこに問題があるのか分かっていないのかもしれない。そういう罠に踏んだことがないから、見えないのだ。しかし、こうしたことはソフトウェア品質に大きな影響を与える。結局のところ、品質を気にする人ほど苦しむ。Huli や 龍哥 も同じようなことを言っていた。
僕の品味は「堅固な基礎」の上に成り立っている、とも言える。他人の出力が僕の考える基礎を満たしていないと、それが僕の苦しみの一因になる。長い目で見れば、自分自身もその影響を受けてしまう。
僕はまだ答えを探している
ちょうど昨日、Claude Code で人為的ミスにより Source Map が流出し、元のソースコードを簡単に復元できるようになった。Anthropic のような年収1000万台湾ドル超えのエンジニアですらミスを犯すのだ（ただし原因は AI ではないかもしれない）。では、基礎、セキュリティの問題、品質を気にすることは、もう重要ではないということなのか？
Coding is largely solved ——Boris Cherny
囲碁と野球
AlphaGo は10年前にすでに世界一の棋士・李世乭に勝ち、柯潔にも勝った。今では人間の棋士で AI に勝てる者は一人もいない。囲碁はある意味で「解決済み」なのだ。しかし、囲碁はそれで消えてはいない。人々は今も打っているし、プロ棋士もいるし、一局の妙手に心を震わせる人もいる。
野球も同じだ。客観的に見れば、9人に1人が加わってボールを投げ、打ち、走ることは、この世界の動作に実質的な助けなど何も与えていない。あらゆる競技スポーツは、おそらく似たようなものだ。それでも人間は、こういう「役に立たない」ことをやりたがるし、しかも非常に真剣にやる。
もしかすると、AI が生産的な仕事の大半を解決してしまえば、プログラミングも囲碁や野球に近い活動になるのかもしれない。コードを書くのは自分でなければならないからではなく、その過程そのものに価値を感じるからだ。
次の一歩
流れに身を任せること。それが最善の答えなのかもしれない。テクノロジー特異点が来る前に、僕が試してみたいことはいくつかある。
- 僕の中にある品味を、再現可能な基準として具現化すること
- ここ数年のソフトウェア開発経験を共有すること。アーキテクチャや技術選定も含めて
- 日本のソフトウェア開発についてのいくつかの考え
もう一つ、最近かなり深く感じていることがあるが、まだ明確な考えにはなっていない。進展があれば、また皆さんに共有したい。
最後に、『百米』の中で僕がとても好きな財津の一節を紹介する。
不安は対処すべきではない。人生は常に失う可能性に満ちている。そこに命の醍醐味がある。 恐怖は不快ではない。安全は愉快ではない。不安とは君自身が君を試す時の感情だ。 栄光を前に対価を差し出さなきゃならない時、ちっぽけな細胞の寄せ集めの人生なんてくれてやればいい。
不安は対処すべきではない。人生は常に失う可能性に満ちている。そこに生命の真髄がある。恐怖は不快なものではなく、安全もまた愉快なものではない。不安とは、自分自身が自分を試すときに生じる感情だ。栄光の前で代償を差し出さなければならない時は、取るに足らない細胞の寄せ集めでしかない人生なんて、くれてやればいい。
君は何をしたいのか？