序章：あるスタートアップの物語

物語は十数人の小さなチームから始まる。
社長の要求はシンプルだった。「とにかくビジネスを回して、稼げるようにしてくれ！」
そこでエンジニアたちは立ち上げの速さを優先し、PHP や Node.js を選び、大規模なモノリシックアプリを構築した。バックエンドは MySQL ひとつで全体を支えていた。

ビジネスは予想以上に急成長し、ユーザーは爆発的に増え、社長は毎日ご機嫌。
しかし開発チームは限界に達していた。
「このコード誰が書いたんだ？バグだらけで、1つ直すと全部壊れる！テストも丸一日かかる！」
ついに誰かがこう叫んだ。「マイクロサービスに分割しよう！」

第1段階：マイクロサービス分割 —— ビジネスドリブンの“消火的”リファクタリング

モノリスは肥大化し、変更はまるで爆弾処理。新人はバグ修正しかできず、誰もコアロジックに手を出せない。
チームは一致して決めた。ビジネス境界に従ってサービスを分割し、まずは出血を止める。

分割と同時に技術スタックも刷新された。
当初は PHP、Node、Python とバラバラ。
この機に Java + Spring Boot に統一し、開発ガバナンスが整備され、コードも理解しやすくなった。

だが安定は長く続かなかった。システムが専門化するにつれ、言語は再び多様化する。

今回は初期の混乱とは違い、意図的な専門分業だった。
👉 この進化については別の記事で掘り下げたい。

マイクロサービスを分割した後、会社は急速な拡張期に入った。
各事業ラインが同じ機能を繰り返し開発していた。ユーザー管理、商品管理、決済など、各チームがそれぞれ実装。
非効率に社長は焦った。「共通基盤を作って、みんなで使えないのか？」

そこで「共通基盤」が登場した。

ビジネスが成熟すると、多くの“標準化能力”は安定し、頻繁な改修は不要になった。
共通基盤チームはもはやイノベーションの主役ではなくなった。

共通基盤は消えたのではなく、裏方に潜り込み、業務データウェアハウスへと進化した。つまり企業の Single Source of Truth となった。

この時期、アーキテクチャは 大フロント + データウェアハウス へと整理された。

大フロント：
- 市場とユーザーに直結し、迅速な試行錯誤と柔軟な提供を重視。
- プロダクト、キャンペーン、マーケティングなどが中心で、敏捷性を最優先。
データウェアハウス：
- 裏方に回り、安定した統一データを提供。
- 表舞台に立つ俳優ではなく、舞台裏の電力設備や照明制御のような存在。

この組み合わせによりバランスが取れた。

この構造下でデータウェアハウスの価値は一層拡大。

競争力は「機能をいかに早く出すか」ではなく、「データからどれだけ継続的な価値を引き出せるか」に移った。

これまでの進化を振り返ると：

しかしこれは終点ではない。