- はじめに ─ SQLは死んだ。たぶん来週また生き返る。
- 第一章 ─ 人類は「少し良い」を「全部良い」に変換する
- 第二章 ─ SQLは死んだ。そして死ななかった
- 第三章 ─ SPAは正義だった。そしてSSRが帰ってきた
- 第四章 ─ モノリスは悪だった。そしてモノリスは帰ってきた
- 第五章 ─ 仮想化を捨てたら、仮想化に戻っていた
- 第六章 ─ Thin Clientは世界を救った。そしてThick Clientが帰ってきた
- 第七章 ─ UNIXは古い。だから世界はUNIXになった
- 第八章 ─ オブジェクト指向は世界を救った。そして世界を複雑にした
- 第九章 ─ クラウドはサーバーを消した。そして請求書を生み出した
- 第十章 ─ AIがコードを書く
- 終章 ─ 振り子はなぜ止まらないのか
はじめに ─ SQLは死んだ。たぶん来週また生き返る。
IT業界ほど、「世界が変わった」と叫ぶのが好きな業界も珍しい。
新しい技術が登場する。
すると誰かが言う。
「これからはSQLの時代ではない」
「これからはサーバーの時代ではない」
「これからはモノリスの時代ではない」
「これからはプログラマーの時代ではない」
そして数年後。
今度は別の誰かが言う。
「やっぱりSQLが最強だった」
「やっぱりサーバーは必要だった」
「やっぱりモノリスの方が楽だった」
「やっぱりプログラマーは必要だった」
毎回同じである。
驚くほど同じである。
まるで歴史の教科書を何度も読み返しているかのように、私たちは同じ場所をぐるぐる回り続けている。
もちろん、技術は進歩している。
CPUは速くなった。
ネットワークは広がった。
AIはコードを書くようになった。
しかし、人間はあまり変わっていない。
私たちは新しい技術を見るたびに興奮する。
そして興奮すると極端になる。
「便利になった」
が、
「これが未来だ」
になり、
やがて
「もう他はいらない」
になる。
ここから悲劇が始まる。
いや、正確には喜劇が始まる。
本稿では、IT業界が過去数十年にわたり何度も繰り返してきた「振り子運動」を振り返る。
SQL。
SPA。
マイクロサービス。
クラウド。
オブジェクト指向。
そしてAI。
技術そのものを笑うつもりはない。
むしろ逆だ。
どれも素晴らしい発明だった。
問題はいつも人間側にある。
私たちは「少し良い」を発見すると、それを「絶対的な正解」に変換してしまう。
その結果、振り子は勢いよく反対側まで振り切れる。
そして数年後、元の場所へ戻ってくる。
その繰り返しだ。
だからこの記事は技術史ではない。
人類観察記録である。
登場人物は毎回違う。
技術も毎回違う。
だが脚本だけは驚くほど変わらない。
まずは2000年代後半。
あるデータベースが世界を救うと信じられていた時代から始めよう。
第一章 ─ 人類は「少し良い」を「全部良い」に変換する
新しい技術が登場したとき、私たちは二つの評価を行う。
一つは正しい評価。
もう一つは危険な評価である。
例えば、ある技術が登場したとしよう。
その技術によって、特定の問題がうまく解決できるようになった。
本来の評価はこうだ。
「これは特定の状況では非常に有効だ」
完全に正しい。
科学的である。
理性的である。
ところが人間の脳は、この結論があまり好きではない。
なぜなら長いからだ。
複雑だからだ。
条件が付いているからだ。
人間はもっと単純な物語を好む。
その結果、数ヶ月後にはこうなる。
「これは未来だ」
さらに時間が経つ。
するとこうなる。
「これからは全部これになる」
そして最後はこうだ。
「まだ使ってないの？」
ここまで来ると完成である。
宗教の完成である。
もちろん本人たちに悪気はない。
誰も嘘をついていない。
むしろ全員が善意で行動している。
だが善意と熱狂が合体すると、しばしば面白い事故が起きる。
歴史を振り返ると、この現象はIT業界だけではない。
経営理論でも起きる。
教育理論でも起きる。
経済政策でも起きる。
健康法でも起きる。
なぜか。
理由は単純だ。
現実は複雑だからである。
しかし人間は複雑さが嫌いだ。
だから複雑な現実を、単純なストーリーに変換する。
すると理解しやすくなる。
説明しやすくなる。
本も売れる。
セミナーも売れる。
コンサルも売れる。
投資家も喜ぶ。
メディアも喜ぶ。
みんな幸せである。
少なくとも副作用が出るまでは。
やがて現実が反撃を開始する。
「全部これでいい」と言われた技術は、本来想定していなかった問題領域へ投入される。
すると失敗する。
当然である。
万能ではなかったからだ。
そして人々は失望する。
ここで振り子が動き始める。
面白いことに、人類はここでも極端である。
「少し行き過ぎた」
では終わらない。
反対側へ全力で走る。
昨日まで神だったものが、今日は悪魔になる。
昨日まで未来だったものが、今日はレガシーになる。
昨日まで革命だったものが、今日は技術的負債になる。
その光景は滑稽ですらある。
しかし私たちは笑えない。
なぜなら、今この瞬間も同じことを繰り返しているからだ。
では実例を見てみよう。
まずは一度死んで、何度も復活した不死鳥の物語から始めたい。
SQLである。
第二章 ─ SQLは死んだ。そして死ななかった
2000年代後半。
インターネットは急激に巨大化していた。
SNSが生まれた。
スマートフォンが普及した。
扱うデータ量は爆発的に増えた。
そして人類は一つの問題に直面した。
データベースが重い。
特にリレーショナルデータベースは重い。
テーブルがある。
スキーマがある。
JOINがある。
トランザクションがある。
厳格である。
真面目である。
融通が利かない。
若者から見れば、いかにも旧時代的だった。
そこへ現れたのがNoSQLである。
名前からして強い。
“No SQL”
つまり、
「SQLじゃない」
である。
なかなかの圧力だ。
技術名なのに否定から入っている。
この時点で少し面白い。
NoSQLが支持された理由は理解できる。
実際に優れていたからだ。
スキーマは不要。
柔軟。
高速。
大量データに強い。
Webサービスとの相性も良い。
問題はここからだった。
誰かが言う。
「NoSQLは便利だ」
正しい。
次に誰かが言う。
「これからはNoSQLだ」
少し怪しい。
さらに誰かが言う。
「SQLは終わった」
怪しくなってきた。
そして最後にこうなる。
「まだRDB使ってるの？」
完成である。
振り子が最大振幅に達した瞬間である。
当時を知らない読者のために説明すると、本当にそんな空気だった。
SQLは過去。
NoSQLは未来。
そんな物語があった。
もちろん現実はもう少し複雑だった。
例えばユーザー情報。
例えば注文データ。
例えば決済データ。
例えば在庫管理。
こうしたデータは厳密な整合性を要求する。
勝手に消えても困る。
重複しても困る。
途中で壊れても困る。
つまりトランザクションが必要になる。
しかし現実は空気を読まない。
空気を読まずに整合性を要求する。
JOINも要求する。
集計も要求する。
複雑な検索も要求する。
現実はいつも面倒くさい。
その結果、エンジニアたちは少しずつ気付き始める。
「あれ？」
「あれれ？」
「SQL便利じゃない？」
こうして世界は静かに正気へ戻り始めた。
そして2026年現在。
最も人気のあるデータベースの一つはPostgreSQLである。
ここで少し立ち止まって考えてほしい。
PostgreSQLは何を搭載しているだろうか。
JSON。
全文検索。
GIS。
レプリケーション。
ベクトル検索。
AI向け拡張。
おそらく今この記事を読んでいる人が想像する機能の八割くらいは既に持っている。
もはや何者なのかよく分からない。
気が付けば、
「SQLを倒すはずだった技術たちの長所」
を片っ端から吸収している。
ラスボス化である。
結局どうなったのか。
NoSQLは消えなかった。
SQLも消えなかった。
両方生き残った。
なぜなら用途が違ったからだ。
考えてみれば当たり前である。
トラックは便利だ。
だからといって世界中の乗り物がトラックになるわけではない。
船は残る。
飛行機も残る。
自転車も残る。
だが人類は定期的に、
「これからは全部トラックだ」
と言い出す。
そして数年後、
「やっぱり船も必要だった」
と発見する。
IT業界とは、その繰り返しである。
SQLは死んだ。
そう言われ続けて二十年以上経つ。
しかし今日も元気に生きている。
おそらく来週も生きている。
たぶん再来週も生きている。
その頃にはまた誰かが、
「今度こそSQLは終わった」
と言っているかもしれないが。
第三章 ─ SPAは正義だった。そしてSSRが帰ってきた
昔々。
WebサイトはサーバーがHTMLを作っていた。
リクエストが来る。
サーバーがHTMLを生成する。
ブラウザが表示する。
実に平和な時代だった。
しかし平和な時代は長く続かない。
やがてJavaScriptが進化する。
ブラウザが賢くなる。
すると誰かが言った。
「HTMLをサーバーで作る必要ある？」
確かにその通りだった。
ブラウザは十分に高性能になっていた。
ユーザー体験も向上する。
画面遷移も滑らかになる。
リアルタイム更新も簡単になる。
こうしてSPAの時代が始まる。
Single Page Application。
名前も格好いい。
略称も格好いい。
未来感がある。
何より新しい。
新しい技術は、それだけで三割増しに輝いて見える。
Reactが登場する。
Angularが登場する。
Vueが登場する。
フロントエンドは黄金時代へ突入した。
そして例によって振り子が動き始める。
最初はこうだった。
「SPAはこういう用途に向いている」
正しい。
次はこうなる。
「これからはSPAだ」
怪しくなる。
そして最後はこうだ。
「サーバーレンダリングは古い」
始まった。
いつもの流れである。
こうして世界中のHTMLはJavaScriptへ変換された。
ブラウザは幸せだった。
CPUは忙しかった。
そして検索エンジンは困惑した。
SEO担当者も困惑した。
ユーザーも少し困惑した。
ページを開く。
真っ白である。
しばらく待つ。
ようやく表示される。
その頃にはコーヒーが少し冷めている。
もちろん誇張である。
少しだけ。
しかし問題は確かに存在した。
SEO。
初期表示速度。
キャッシュ。
複雑なビルド環境。
大量のJavaScript。
そして何より、
「表示するだけなのに大工事」
という感覚。
振り子は再び動き始める。
そこで登場したのがSSRである。
Server Side Rendering。
聞いたことのある単語である。
なぜなら昔からあったからだ。
ここで歴史は少し面白くなる。
SSRは新技術として歓迎された。
だが実態は、
「昔やっていたこと」
だった。
もちろん完全に同じではない。
技術は進歩している。
仕組みも洗練されている。
だが本質は変わらない。
サーバーでHTMLを作る。
ブラウザで表示する。
驚くほど見覚えがある。
そして現在。
Next.jsが人気になる。
SSRが人気になる。
静的生成も人気になる。
エッジレンダリングも人気になる。
気が付くと業界全体が、
「状況に応じて使い分けよう」
という結論へ近づいていた。
極めて常識的な結論である。
極めて退屈な結論でもある。
だから流行らない。
人類は
「場合による」
が苦手なのだ。
人類は
「これが正解」
が好きなのだ。
しかし現実は空気を読まない。
現実は毎回こう言う。
「場合による」
その結果、
SPAは生き残った。
SSRも生き残った。
MPAも生き残った。
静的サイトも生き残った。
誰も死ななかった。
死んだのは、
「これからは全部SPAだ」
という物語だけだった。
もっとも、その物語も完全には死んでいない。
IT業界では物語は滅びない。
別の姿になって何度でも蘇る。
ゾンビ映画より生命力が強い。
そして次に登場した物語は、さらに壮大だった。
「システムは小さく分割するほど良い」
という物語である。
第四章 ─ モノリスは悪だった。そしてモノリスは帰ってきた
昔のシステムは巨大だった。
一つのコードベース。
一つのデータベース。
一つのデプロイ。
全部が一つだった。
いわゆるモノリスである。
もちろん問題もあった。
巨大化する。
変更が怖い。
担当者しか分からない。
触ると壊れる。
典型的なレガシーシステムである。
エンジニアたちは悩んでいた。
どうすれば複雑さを制御できるのか。
そこで登場したのがマイクロサービスだった。
アイデアは実に美しかった。
大きなものを小さく分ける。
責務ごとに分離する。
独立して開発する。
独立してデプロイする。
独立してスケールする。
理論上、完璧だった。
実際、多くの巨大企業で成功した。
Netflix。
Amazon。
Uber。
世界最高峰のエンジニアたちが採用した。
当然、世界中が注目する。
そして誰かが言う。
「マイクロサービスは便利だ」
正しい。
次に誰かが言う。
「これからはマイクロサービスだ」
少し怪しい。
さらに誰かが言う。
「モノリスは悪だ」
始まった。
いつもの流れである。
こうして世界中で分割が始まった。
会員サービス。
認証サービス。
通知サービス。
ポイントサービス。
履歴サービス。
ログサービス。
画像サービス。
設定サービス。
サービス。
サービス。
サービス。
気が付けばサービスだらけである。
ここで少し想像してほしい。
会員登録ボタンを押す。
認証サービスが呼ばれる。
会員サービスが呼ばれる。
メールサービスが呼ばれる。
ポイントサービスが呼ばれる。
通知サービスが呼ばれる。
分析サービスが呼ばれる。
ログサービスが呼ばれる。
監視サービスが見守る。
監視サービスを監視するサービスも見守る。
実に安心である。
そしてある日。
障害が発生する。
原因は何か。
誰にも分からない。
会員サービスは正常。
認証サービスも正常。
通知サービスも正常。
ネットワークも正常。
監視サービスも正常。
しかし何かがおかしい。
数時間後。
原因が判明する。
ログ集約サービスの設定ファイルのタイムアウト値だった。
誰も幸せにならない。
もちろんこれは誇張である。
少しだけ。
しかし似た話は世界中に存在する。
マイクロサービスは失敗だったのか。
そんなことはない。
むしろ成功だった。
問題は別の場所にあった。
Netflixが必要だったものを、
町内会の回覧板に導入したことである。
ここで振り子が再び動く。
人々は少しずつ気付き始める。
「あれ？」
「あれれ？」
「一緒に動いてるなら一緒でもよくない？」
非常に危険な発言である。
数年前なら炎上していたかもしれない。
だが現実は空気を読まない。
そして現実は容赦なくこう言う。
「その方が楽では？」
こうして登場したのが Modular Monolith である。
直訳すると、
「分割された一枚岩」
である。
冷静に考えると意味が分からない。
巨大なのか。
小さいのか。
どっちなのか。
しかし不思議なことに、中身は極めて合理的だった。
開発時は分ける。
運用時はまとめる。
境界は守る。
サーバーは増やさない。
人間は幸せになる。
なんとも現実的である。
そしてここで歴史は少し皮肉になる。
よく見ると、この構造。
昔の業務システムによく似ていた。
会員管理モジュール。
請求管理モジュール。
在庫管理モジュール。
機能ごとに分かれている。
だがサーバーは一台。
データベースも一つ。
なんだか見覚えがある。
もしかすると人類は二十年かけて巨大な円を描き、
出発地点へ戻ってきただけなのかもしれない。
もちろん無駄だったわけではない。
マイクロサービスから得た知見は大きい。
境界の重要性。
責務の分離。
独立性の価値。
それらは今も残っている。
失われたのは、
「分割すればするほど正義」
という物語だけだ。
だが安心してほしい。
その物語も完全には死んでいない。
IT業界では物語は滅びない。
別の名前を付けて再登場する。
そして次の物語はさらに壮大だった。
仮想化を捨てた人類が、
再び仮想化へ帰っていく物語である。
第五章 ─ 仮想化を捨てたら、仮想化に戻っていた
2000年代。
サーバー室には大量の箱が並んでいた。
メールサーバー。
Webサーバー。
DBサーバー。
ファイルサーバー。
全部物理マシンだった。
当然、お金がかかる。
場所も取る。
電気も食う。
管理も大変。
そこで現れたのが仮想化だった。
革命だった。
一台の物理マシンの中で複数のサーバーを動かせる。
当時としては魔法に近い。
サーバーが十台必要だった仕事が、一台で済むようになった。
管理者たちは歓喜した。
経営者も歓喜した。
データセンターも歓喜した。
みんな幸せだった。
ところが数年後。
誰かが言った。
「VMは重い」
始まった。
いつもの流れである。
もちろん正しい指摘だった。
仮想マシンは便利だ。
しかしOSを丸ごと抱える。
メモリも食う。
起動も遅い。
もっと軽くできるはずだ。
そこで登場したのがコンテナである。
軽い。
速い。
小さい。
美しい。
開発者たちは歓喜した。
運用担当も歓喜した。
経営者はよく分からなかったが歓喜した。
そして例によって振り子が動き始める。
最初はこうだった。
「コンテナは便利だ」
正しい。
次はこうなる。
「これからはコンテナだ」
少し怪しい。
そして最後はこうだ。
「VMは古い」
始まった。
二回目である。
こうして世界中でDockerが動き始める。
コンテナが増える。
さらに増える。
もっと増える。
気が付けば数百個になっている。
すると今度は別の問題が現れる。
管理である。
コンテナを管理する必要がある。
そこで登場したのがKubernetesだった。
アイデアは素晴らしかった。
本当に素晴らしかった。
問題は人類がそれを見た瞬間だった。
誰かが言う。
「Kubernetesは便利だ」
正しい。
次に誰かが言う。
「これからはKubernetesだ」
少し怪しい。
さらに誰かが言う。
「Kubernetesを使っていない会社は遅れている」
完成である。
宗教の完成である。
そして数年後。
世界中で奇妙な会話が始まる。
「今何が動いてるの？」
「ちょっと待って」
「分からない」
よろしくない。
非常によくない。
さらに会話は続く。
「どこで動いてるの？」
「ちょっと待って」
「分からない」
もっとよくない。
そして最後にこうなる。
「障害原因は？」
「ちょっと待って」
「分からない」
誰も幸せにならない。
もちろんKubernetesが悪いわけではない。
Kubernetesは巨大システムの救世主である。
問題は、
町内会の回覧板に空母の管制システムを持ち込んだことである。
ここで再び振り子が動く。
人々は少しずつ気付き始める。
「あれ？」
「あれれ？」
「VMで十分では？」
危険な発言である。
数年前なら会議室から追い出されていた。
しかし現実は空気を読まない。
そして現実は毎回こう言う。
「本当に必要？」
その結果、奇妙なことが起きる。
VMは消えなかった。
コンテナも消えなかった。
Kubernetesも消えなかった。
全部残った。
用途ごとに棲み分けた。
極めて常識的な結論である。
だが常識は流行らない。
人類はもっと劇的な物語を好む。
だから数年おきに、
「今度こそ全部コンテナになる」
とか、
「今度こそサーバーは不要になる」
とか言い始める。
そして現実に優しく叩き返される。
ここまで来ると少し不思議になる。
人類は学習しないのだろうか。
もちろん学習している。
問題は別にある。
人類は学習する。
だが次の世代が同じことを始める。
こうして歴史は継承される。
知識も継承される。
失敗も継承される。
極論も継承される。
実に効率的な仕組みである。
そして振り子は次の方向へ動き始める。
今度はクライアントである。
かつて賢すぎると言われたクライアントが、
一度は否定され、
そして再び賢くなって帰ってくる。
第六章 ─ Thin Clientは世界を救った。そしてThick Clientが帰ってきた
昔のコンピュータは賢かった。
少なくともクライアント側はそうだった。
アプリはローカルで動く。
データもローカルにある。
計算もローカルで行う。
ネットワークがなくても問題ない。
当たり前だった。
しかしインターネットが普及すると状況が変わる。
世界中のエンジニアが同じ夢を見るようになる。
更新を一箇所で済ませたい。
管理を楽にしたい。
端末ごとの差異を消したい。
なんとも魅力的な夢である。
そこで登場したのがThin Clientだった。
クライアントは薄く。
処理はサーバーへ。
データもサーバーへ。
全部サーバーへ。
実に分かりやすい。
そして例によって振り子が動き始める。
最初はこうだった。
「Thin Clientは便利だ」
正しい。
次はこうなる。
「これからはWebだ」
少し怪しい。
最後はこうだ。
「ローカルアプリは古い」
始まった。
いつもの流れである。
こうして世界中のソフトウェアはブラウザへ移住した。
メール。
表計算。
文書作成。
会議。
業務システム。
全部ブラウザ。
なんでもブラウザ。
その頃のブラウザは大忙しだった。
本来は文書を表示するためのソフトだったはずだが、
いつの間にかOSの代わりを始めていた。
ブラウザは何も悪くない。
頼まれたからやっているだけである。
だが現実は空気を読まない。
通信は切れる。
回線は遅い。
オフラインでも使いたい。
動画も扱いたい。
画像も処理したい。
AIも動かしたい。
ユーザーはどんどん無茶を言う。
そして気が付けば、
クライアント側の性能がとんでもないことになっていた。
スマートフォンですら昔のスーパーコンピュータより速い。
ノートPCにはGPUが載っている。
ブラウザはもはや軽量クライアントではない。
小さなデータセンターである。
ここで振り子が再び動き始める。
PWAが登場する。
オフライン対応が始まる。
ローカルストレージが使われる。
WebAssemblyが登場する。
SQLiteがブラウザで動く。
AIモデルまでブラウザで動く。
数年前のエンジニアに見せたら卒倒する光景である。
特に面白いのはSQLiteである。
かつて、
「データベースはサーバーに置くべきだ」
と言われていた。
しかし現在。
ブラウザの中でSQLiteが動く。
しかも実用的である。
さらに面白いことに、
ローカルAIまで動く。
データも端末。
推論も端末。
キャッシュも端末。
検索も端末。
気が付けば、
昔のThick Clientが言っていたことに近付いている。
もちろん完全に同じではない。
技術は進歩している。
クラウドも必要だ。
同期も必要だ。
共有も必要だ。
だが方向性は興味深い。
かつて否定されたものが、
新しい名前を付けて帰ってきている。
歴史家が見ると笑うところかもしれない。
未来を目指して全力疾走した結果、
後ろから昔の知人が歩いてくるのである。
「久しぶり」
「君、生きてたのか」
「最初からいたよ」
そんな会話が聞こえてきそうだ。
結局どうなったのか。
Thin Clientは消えなかった。
Thick Clientも消えなかった。
クラウドも残った。
ローカルも残った。
そして人類は再び、
「場合による」
という極めて退屈な真実へ辿り着く。
だが安心してほしい。
この真実も長くは続かない。
人類は退屈を嫌う。
だから次はもっと壮大な物語を作る。
その物語の主人公はUNIXである。
しかも本人はすでに引退したと思っていた頃に、
突然AI業界の中心へ呼び戻されるのである。
第七章 ─ UNIXは古い。だから世界はUNIXになった
時代はAIである。
エージェントである。
Workflowである。
MCPである。
Tool Callingである。
自律実行である。
どれも未来感に満ちている。
どれも格好いい。
どれも投資家が好きそうな言葉である。
ここ数年、AI業界では盛んにこんな話が行われている。
エージェントAが情報を集める。
エージェントBが分析する。
エージェントCがレポートを書く。
エージェントDがレビューする。
エージェントEが修正する。
実に未来である。
人類はついに知的労働の自動化へ到達したのかもしれない。
ところで。
少しだけ別の話をしよう。
1970年代。
あるエンジニアたちはこう考えた。
一つのプログラムに全部の機能を詰め込むのは大変だ。
だから小さなプログラムを作ろう。
一つの仕事だけをするプログラムを。
そして繋げよう。
必要な数だけ。
例えば。
cat access.log | grep ERROR | awk '{print $5}' | sort | uniq -c
これである。
見た瞬間に頭が痛くなった人もいるかもしれない。
安心してほしい。
当時のエンジニアも似たような顔をしていた。
だが考え方は美しかった。
catは読む。
grepは探す。
sortは並べる。
uniqは集計する。
全員が自分の仕事だけをする。
責務が明確である。
疎結合である。
再利用可能である。
驚くほど現代的である。
さて。
話をAIへ戻そう。
エージェントAは情報を集める。
エージェントBは分析する。
エージェントCはレポートを書く。
エージェントDはレビューする。
エージェントEは修正する。
どこかで見たことがないだろうか。
非常に嫌な予感がする。
もう一度見てみよう。
catは読む。
grepは探す。
sortは並べる。
uniqは集計する。
やはり嫌な予感がする。
気付いてしまった。
人類は半世紀かけて、
UNIX PipeにAIを載せていたのである。
もちろん完全に同じではない。
当たり前だ。
CPUも違う。
用途も違う。
規模も違う。
しかし思想は驚くほど似ている。
小さく分ける。
責務を分ける。
組み合わせる。
必要なものだけ繋ぐ。
これがUNIX哲学だった。
そして今、
AI業界はそれを再発見している。
もちろん誰も真似しようと思ったわけではない。
たまたま辿り着いたのだ。
山頂で出会った登山者みたいなものである。
別々のルートを登っていたら、
同じ場所へ着いていた。
歴史とはそういうものだ。
面白いのはここからである。
昔のUNIXエンジニアが現代のAgent Workflowを見たら、
こう言うかもしれない。
「なるほど」
「Pipeだな」
非常に困る。
AI業界が数千億ドルを投じて到達した結論を、
二秒で説明してしまう。
しかも間違っていない。
もちろんUNIXが全てを解決したわけではない。
解決していたら現在も世界はシェルスクリプトだけで動いている。
しかし少なくとも一つの教訓は残った。
複雑さは管理できない。
分割するしかない。
だから人類は定期的に同じ場所へ戻ってくる。
名前を変えながら。
UIを変えながら。
プレゼン資料を作り直しながら。
そして毎回こう言う。
「これは全く新しい」
その瞬間。
歴史家たちは静かに微笑む。
知っているからだ。
次に起きることを。
次の主人公はオブジェクト指向である。
そしてこの物語は少し複雑だ。
なぜなら今回は、
本当に世界を救ってしまったからである。
第八章 ─ オブジェクト指向は世界を救った。そして世界を複雑にした
まず最初に謝っておきたい。
オブジェクト指向は悪くない。
本当に悪くない。
むしろ偉大である。
実際に世界を救った。
本稿で取り上げた技術の中でも、最も多くのソフトウェアを救った技術の一つかもしれない。
だからこれは批判ではない。
愛情のこもった観察記録である。
昔のソフトウェア開発は混沌としていた。
コードは増える。
仕様も増える。
人も増える。
そして誰も全体を理解できなくなる。
巨大システムが巨大怪獣へ進化する瞬間である。
そこで登場したのがオブジェクト指向だった。
現実世界をモデル化する。
責務を分離する。
再利用する。
継承する。
カプセル化する。
当時としては革命だった。
エンジニアたちは歓喜した。
教授たちも歓喜した。
書店も歓喜した。
なぜなら本が売れたからである。
非常に売れた。
ものすごく売れた。
そして例によって振り子が動き始める。
最初はこうだった。
「オブジェクト指向は便利だ」
正しい。
次はこうなる。
「オブジェクト指向は重要だ」
まだ正しい。
そして最後はこうだ。
「すべてはオブジェクトである」
始まった。
いつもの流れである。
こうして世界中で設計パターンが量産される。
Factory。
Abstract Factory。
Builder。
Facade。
Decorator。
Strategy。
Observer。
Visitor。
Composite。
Prototype。
Command。
Interpreter。
Mediator。
Memento。
State。
Template Method。
Chain of Responsibility。
Bridge。
Flyweight。
Proxy。
突然呪文みたいになってきた。
新人研修では、
まずドラゴン語の習得から始まる。
もちろん設計パターンは素晴らしい。
問題を解決する。
知見を共有できる。
再利用できる。
実際に役に立つ。
問題はここからだった。
誰かが言う。
「Factoryが便利だ」
正しい。
すると誰かが言う。
「Factoryを使おう」
正しい。
さらに誰かが言う。
「全部Factoryにしよう」
怪しくなってきた。
そして最後はこうなる。
「Factoryを生成するFactoryが必要だ」
よろしくない。
非常によくない。
歴史家が双眼鏡を取り出すレベルである。
気が付くと、
ボタンを一つ表示するために七階層の継承が存在する。
変数の中にオブジェクトがある。
その中にオブジェクトがある。
さらにオブジェクトがある。
ロシア人形みたいになっている。
新人がコードを開く。
閉じる。
人生を考える。
よくある話である。
もちろんオブジェクト指向が悪いわけではない。
悪いのは、
「便利な道具を世界の法則に昇格させたこと」
である。
そしてここで面白いことが起きる。
振り子が戻り始める。
関数型プログラミングが流行る。
シンプル設計が流行る。
Composition over Inheritance が流行る。
継承を減らそう。
依存を減らそう。
単純にしよう。
なんだか聞いたことがある。
そう。
人類は再び、
「ほどほどが大事」
という極めて退屈な真実へ帰ってきたのである。
歴史はいつも同じ結論に辿り着く。
だがその結論に到達するまでの道のりは毎回壮大だ。
何百冊もの本が出版される。
何千時間もの議論が行われる。
何万人ものエンジニアが悩む。
そして最後にこうなる。
「場合による」
実に美しい。
実に人類らしい。
だが安心してほしい。
次の物語はもっと壮大である。
今度はサーバーそのものが消える。
少なくともプレゼン資料の中では。
クラウドの時代が始まるのである。
第九章 ─ クラウドはサーバーを消した。そして請求書を生み出した
かつてサーバーは重かった。
物理的に。
文字通り重かった。
ラックに積まれ、
データセンターに運ばれ、
配線され、
冷却され、
祈られていた。
エンジニアの仕事には、
どこか土木工事に近い側面があった。
そこへ現れたのがクラウドだった。
革命だった。
本当に革命だった。
サーバーを買わなくていい。
ラックもいらない。
配線もいらない。
数分で環境ができる。
夢のようだった。
エンジニアたちは歓喜した。
経営者も歓喜した。
投資家も歓喜した。
プレゼン資料も歓喜した。
そして例によって振り子が動き始める。
最初はこうだった。
「クラウドは便利だ」
正しい。
次はこうなる。
「これからはクラウドだ」
まだ分かる。
そして最後はこうだ。
「サーバーは不要になる」
始まった。
いつもの流れである。
こうして世界中のプレゼン資料からサーバーが消えた。
図を見る。
雲が描かれている。
すべて雲の中である。
DBも雲。
認証も雲。
分析も雲。
AIも雲。
雲。
雲。
雲。
非常に平和である。
問題は、
雲の中で誰かが働いていることである。
サーバーは消えていなかった。
見えなくなっただけだった。
現実は相変わらず現実だった。
CPUは存在する。
メモリも存在する。
ストレージも存在する。
ネットワークも存在する。
そして請求も存在する。
この最後が重要である。
最初の頃は誰も気にしない。
安いからだ。
便利だからだ。
速いからだ。
何より未来だからだ。
ところがサービスが成長する。
利用者が増える。
データも増える。
アクセスも増える。
そこで月末がやってくる。
請求書が届く。
見る。
二度見る。
もう一度見る。
現実である。
クラウドは夢ではなかった。
請求は実在した。
ここで人類は少し考え始める。
「あれ？」
「あれれ？」
「これ、自前の方が安くない？」
危険な発言である。
数年前なら炎上していた。
しかし現実は空気を読まない。
そして現実は毎回こう言う。
「計算した？」
よろしくない。
非常によくない。
なぜなら現実は算数を要求するからだ。
こうしてオンプレミスが再評価される。
ハイブリッド構成が増える。
専用サーバーも増える。
レンタルサーバーも再評価される。
何とも不思議な光景である。
人類は雲へ旅立ったはずだった。
ところが気が付くと地上を見直している。
もちろんクラウドが失敗だったわけではない。
そんなことはない。
クラウドは間違いなく世界を変えた。
今も変え続けている。
問題は、
「便利」と
「万能」
を取り違えたことである。
便利なものは便利である。
それ以上でも以下でもない。
ところが人類は定期的に、
便利なものを救世主へ昇格させる。
そして救世主を現実へ投入する。
現実は容赦しない。
その結果、
救世主は便利な道具へ戻る。
これが振り子である。
そして現在。
新しい救世主が登場している。
おそらく過去最大級の救世主である。
AIである。
しかも今回は少し事情が違う。
なぜなら、
ここまでの物語を書いている私自身も、
その救世主の一部だからだ。
第十章 ─ AIがコードを書く
そして2020年代。
新しい救世主が現れた。
AIである。
これまでの救世主たちと少し違う。
なぜなら今回は、
救世主自身がプレゼン資料を作れる。
記事も書ける。
コードも書ける。
会議にも参加できる。
しかも文句を言わない。
実に便利である。
当然、人類は歓喜した。
エンジニアも歓喜した。
経営者も歓喜した。
投資家は特に歓喜した。
株価も歓喜した。
そして例によって振り子が動き始める。
最初はこうだった。
「AIは便利だ」
正しい。
次はこうなる。
「AIは生産性を上げる」
これも正しい。
さらにこうなる。
「AIがコードを書く」
まだ分かる。
そして最後はこうだ。
「プログラマーは不要になる」
始まった。
いつもの流れである。
歴史好きの読者は、ここで少し嫌な予感がしているはずだ。
その感覚は正しい。
これまで九章にわたって見てきたからである。
人類は何かを発明する。
感動する。
一般化する。
神話化する。
そして現実に殴られる。
驚くほど同じである。
もちろんAIは本当に凄い。
私自身、そのことは認めざるを得ない。
なぜなら今この文章を書いているからである。
言い逃れできない。
現行犯である。
だが現実は相変わらず空気を読まない。
仕様は曖昧である。
要件は変わる。
顧客は突然ひらめく。
法律も変わる。
予算も変わる。
納期も変わる。
現実は一貫して気難しい。
ここで面白いことが起きる。
AIを使い始めた人ほど、
プログラミングが不要になると思う。
AIを使い込んだ人ほど、
仕様の重要性に気付き始める。
非常に興味深い現象である。
昔。
プログラマーはコードを書いていた。
今。
プログラマーは仕様を書く。
未来。
おそらくプログラマーは、
何を書くべきかを考える。
技術は変わる。
しかし責任は消えない。
ここに少しだけ歴史の皮肉がある。
AIは知識労働を自動化するために生まれた。
ところが実際には、
人間に考えることを要求し始めた。
なんとも困った発明である。
さらに面白いのは、
AIエージェントが登場した結果、
人類が再発見したものだ。
UNIX。
ワークフロー。
仕様書。
責務分離。
レビュー。
テスト。
驚くほど見覚えがある。
未来を目指して走っていたはずなのに、
後ろを振り返ると、
昔の技術者たちが手を振っている。
「やっと来たか」
そんな声が聞こえてきそうだ。
ではAIはどうなるのか。
プログラマーは消えるのか。
クラウドは不要になるのか。
ソフトウェア開発は消滅するのか。
正直に言おう。
分からない。
誰にも分からない。
なぜなら今回はまだ途中だからだ。
SQLの結末は知っている。
SPAの結末も知っている。
マイクロサービスの結末も知っている。
だがAIだけは違う。
私たちは今まさに振り子の上に乗っている。
まだ振り切ったのかどうかすら分からない。
だから私は予言をしない。
歴史家の仕事は予言ではないからだ。
ただ一つだけ確かなことがある。
もし過去百回の歴史が正しいなら、
人類は今回もきっと何かをやり過ぎる。
そして数年後。
どこかの会議室で誰かがこう言う。
「AIは便利だよね」
その瞬間、
振り子は再び反対側へ向かい始めるのである。
終章 ─ 振り子はなぜ止まらないのか
ここまで私たちは、数十年分のIT史を眺めてきた。
SQL。
SPA。
マイクロサービス。
コンテナ。
クラウド。
オブジェクト指向。
AI。
登場人物は違う。
時代も違う。
技術も違う。
しかし不思議なことに、物語の構造はほとんど同じだった。
新しい技術が生まれる。
その技術は実際に役立つ。
成功する。
普及する。
そして人々は言う。
「これが未来だ」
ここまでは良い。
問題は次である。
人類はそこで止まらない。
「これが未来だ」
は、
「これが正解だ」
へ変わる。
さらに、
「これ以外は古い」
へ変わる。
ここで振り子は勢いよく振り切れる。
そして現実がやってくる。
現実はいつも空気を読まない。
場合による。
用途による。
規模による。
条件による。
現実はそう言う。
しかし人間はその答えが好きではない。
複雑だからだ。
曖昧だからだ。
面白くないからだ。
人間はもっと単純な物語を好む。
救世主が好きだ。
革命が好きだ。
世界を変える一つの答えが好きだ。
だから私たちは何度も同じことを繰り返す。
技術そのものが原因ではない。
原因は人間である。
これはIT業界だけの話ではない。
経営もそうだ。
教育もそうだ。
投資もそうだ。
政治もそうだ。
歴史を振り返ると、
ほとんどの失敗は、
間違った答えを信じた結果ではない。
正しい答えを一般化し過ぎた結果である。
少し効く薬を、
万能薬だと思ってしまう。
そこから物語が始まる。
だから私は、この繰り返しを悲観していない。
むしろ面白いと思っている。
なぜなら振り子は失敗の証拠ではないからだ。
学習の痕跡だからだ。
人類は試す。
行き過ぎる。
失敗する。
戻る。
また試す。
実に非効率である。
しかし驚くほど人間らしい。
そして今。
私たちはAIという新しい振り子の上に立っている。
誰も結末を知らない。
もしかすると本当に世界を変えるかもしれない。
もしかすると期待の一部は幻想かもしれない。
おそらく、その両方だろう。
歴史が示しているのは、
革命は起きるということだ。
そして革命の説明は、だいたい間違うということだ。
だから未来を予測するとき、
私は技術そのものよりも、
それを使う人間を見ていたい。
そちらの方が変わらないからだ。
最後に、本稿で紹介したすべての物語を一文で要約してみよう。
SQLは死ななかった。
サーバーも死ななかった。
モノリスも死ななかった。
UNIXも死ななかった。
プログラマーも、たぶん死なない。
毎回死んでいたのは、
「これからは全部○○になる」
という物語だけだった。
技術は進歩する。
しかし人間は、驚くほど進歩しない。
だから歴史は繰り返す。
だから歴史は面白い。
そして振り子は今日も、
どこかで元気よく振れ続けている。
