企業は自分でコードを書かない。
それは、当然だった。

企業は、自分でコードを書いてこなかった。それは怠慢ではなく、旧来のコスト構造のもとでの合理的な選択だった。自立編は、その選択を一層ずつ解いてきた ── 認証も文書もコードもメールも、ベンダーの束から自分の側へ移した。転換編は、ここから産業構造の帰結を見ていく。

その帰結はすべて、一つの前提から出る。企業 IT が二つの世界に分かれて並立していたこと、そしてその並立が AI によって解けることだ。

自前で書くのは非効率だった

なぜ企業は自分でコードを書かなかったのか。非効率だったからだ。

コードを書くとは、大量の人月を投じる労働だった。一つの業務システムを作るには、設計者・コーダー・テスター・PM が、月単位・年単位で張り付く。その規模の専門人員を、一社が自前で抱えるのは割に合わない。しかも、仕事が途切れないように維持し続けねばならない。ほとんどの企業にとって、それは無理だった。

ここを誤読してはならない。企業が自前開発を避けたのは、技術への無理解でも、 IT 軽視でもない。効率が悪いから避けた。多重下請け構造が成立したのも同じ理由による。コードを書くのに必要な大人数を、一社で抱えずに調達する仕組みが要ったからだ(構造は 3-07 で詳述する)。

書かない、という合理的な選択。これが企業 IT を、二つの世界に割った。

事務は買い、基幹は外注した

「自分で書かない」を実装すると、選択肢は二つに分かれる。買うか、外注するかだ。そして企業 IT は、この二つにきれいに割れた。

• 事務系 ── 文書、表計算、メール、スケジュール。どの会社でもほぼ同じ、汎用の仕事だ。汎用なら、自分で作る理由がない。だからパッケージを買う ── Microsoft Office、そして Microsoft 365。
• 基幹系 ── 受発注、在庫、会計、生産管理。会社ごとに固有の、その企業の業務そのものだ。固有なら、既製品では足りない。だから外注する ── SIer に委託する。

この二つは、別の世界として育った。コンピュータ化された時期が違い、担当するベンダーが違い、人材プールが違う。事務系は世界共通の製品ベンダーが担った。基幹系は国内の SIer ピラミッドが担った。同じ会社の中にありながら、二つはほとんど交わらずに並び立った。

繋がりは、薄い継ぎ目が二つだけだった。2-01: Microsoft と Google から自立するで見たとおり、認証(Entra ID)と、文書共有(SharePoint)である。基幹システムとオフィスの世界が共有していたのは、この二点に過ぎない。

並立していたから、税は二度かかった

二つの世界が並立していたということは、ロックインも地代も二重にかかっていたということだ。

• Microsoft 税 ── 事務系の世界で。文書も予定もメールも一社のスイートに束ねられ、人数 × 月額が永続的に課された。
• SIer 税 ── 基幹系の世界で。独自フレームワーク、多年の運用保守契約、業務知識の囲い込みによって、別の選択肢へ動けなくなった。

この二つの税は、別々に発生し、両方とも払われた。事務系で Microsoft に縛られていることと、基幹系で SIer に縛られていることは、別の現象として、それぞれ独立に企業を捉えていた。一方を逃れても、他方は残る。

だがこれは、当時としては不経済ではなかった。旧来のコスト構造のもとでの、合理的な均衡だった。買う・外注するほうが、自前で作るより、本当に安かったからだ。コードを書くのに人月が要る以上、汎用は買い、固有は外注するのが、文句なく合理的だった。

AI が、前提を反転させる

その均衡を支えていたのは、たった一つの前提だった。「コードを書くには人月が要る、だから自前は非効率」という前提だ。AI が実行を取ったとき、この前提が消える。

自立編で示したとおり、一人 + AI が、二つの世界を同じ OSS の土台の上にまとめて立てられる。事務系も基幹系も、もはや別々のベンダーに分けて調達するものではない。

• 事務系 ── PostgreSQL、PocketBase、adoc と Forgejo(2-03: 土台を据える・2-07)
• 基幹系 ── PostgreSQL、FastAPI、同じ認証・同じ共有(2-12: API を作る)

二つは、同じデータ基盤・同じ門番・同じコードの上に乗る。汎用も固有も、一人 + AI が立てる。「買う・外注するほうが安い」という前提そのものが消えた。 自前で書くことが、もはや非効率ではなくなったからだ。

並立が解けると、二つの産業は同時に崩れる

ここが本章の核心だ。事務系と基幹系が同じ土台に乗ると、二つを隔てていた継ぎ目が消える。認証も文書共有も、もはや二つの世界を繋ぐ細い橋ではなく、一つの土台の一部になる(2-01 の「この土台は、そのまま基幹システムの土台になる」)。

そして、ここから帰結が出る。Microsoft の事務系支配と、SIer の基幹系支配は、もともと別々の現象ではなかった。両者は、「自前で書かない」という一つの合理的選択が生んだ、一つの並立構造の表と裏だった。

• 汎用を買う合理性が、Microsoft の地代を生んだ。
• 固有を外注する合理性が、SIer の地代を生んだ。
• 両方とも、同じ前提から出ていた。コードは大人数の人月だ、という前提である。

その前提が反転した今、二つは同時に崩れる。一方が AI で解け、他方が別の理由で残る、ということにはならない。並立構造そのものが解けるのだから、二つの支配は一緒に外れる。

これが転換編全体の前提だ。続く章は、この一つの崩壊を、それぞれ別の面から見ていく ── デジタル主権と Microsoft 問題(3-03)、SIer 委託の不経済 (3-04)、ロックインの正体(3-05)、ビルダーの直接雇用(3-06)、日本固有の転換(3-07)、革命が下から起きること(3-08: AI 革命は下から起きる)、近い将来の転換と逆転ゆえの不可逆 (3-09)。どれも、同じ一つの崩壊を、別の角度から照らした像だ。

作り直しが、新しい既定値になる

最後に一段引いて見る。企業が自分でコードを書かなかったのは、怠慢でも無能でもなかった。合理的だった。自前で書くより、買い、外注するほうが、本当に安かったからだ。

その合理性が、反転した。AI が実行を取った今、買う・外注するほうが安いという前提は崩れた。だから「自分で作り直す」は、もはや特別な決断ではない。汎用は OSS で立て、固有は AI と書く。これが、新しい合理的な既定値になる。

かつて自前を避けたのと同じ合理性が、今度は自前を選ばせる。前提が変わったのだから、結論が変わるのは当然だ。問われているのは「やるか」ではなく、「いつ、誰が主導でやるか」だけだ。

まとめ

本章は、転換編の前提を据えた。事務と基幹の並立、二重の税、そして AI による前提の反転である。続く章は、二つの世界それぞれの帰結を、別の面から照らしていく。

その前に、一つ道具を置く。ベンダーの語りを、一次情報で検算する作法だ。次の章でそれを置き、その次の 3-03 で事務(Microsoft)側に当てる ── なぜ OSS とソブリン AI のほうが、いまや経済でも安全保障でも有利なのかを、その作法で確かめる。

関連記事

• 2-01: Microsoft と Google から自立する ── 全体像と対応表
• 3-04: SIer委託モデルの構造的不経済
• 2-04: 処理を書く ── Python と Flet で、自分の道具を持つ