序章：あるスタートアップの物語
物語は十数人の小さなチームから始まる。
社長の要求はシンプルだった。「とにかくビジネスを回して、稼げるようにしてくれ！」
そこでエンジニアたちは立ち上げの速さを優先し、PHP や Node.js を選び、大規模なモノリシックアプリを構築した。バックエンドは MySQL ひとつで全体を支えていた。
ビジネスは予想以上に急成長し、ユーザーは爆発的に増え、社長は毎日ご機嫌。
しかし開発チームは限界に達していた。
「このコード誰が書いたんだ？バグだらけで、1つ直すと全部壊れる！テストも丸一日かかる！」
ついに誰かがこう叫んだ。「マイクロサービスに分割しよう！」
第1段階：マイクロサービス分割 —— ビジネスドリブンの“消火的”リファクタリング
なぜ分割するのか？
モノリスは肥大化し、変更はまるで爆弾処理。新人はバグ修正しかできず、誰もコアロジックに手を出せない。
チームは一致して決めた。ビジネス境界に従ってサービスを分割し、まずは出血を止める。
分割のプロセス
- 最初に分割したのは境界が明確なモジュール：ユーザー、注文、決済。
- その後、商品、在庫、マーケティング、リスク管理も独立。
- 各システムは独自の DB を持ち、RPC/HTTP 経由で通信。
システムはようやく疎結合となり、チームは大きく息をついた。
技術スタックのリファクタリング
分割と同時に技術スタックも刷新された。
当初は PHP、Node、Python とバラバラ。
この機に Java + Spring Boot に統一し、開発ガバナンスが整備され、コードも理解しやすくなった。
言語の再多様化
だが安定は長く続かなかった。システムが専門化するにつれ、言語は再び多様化する。
- レコメンドやアルゴリズムチームは柔軟性重視で Python を導入。
- リアルタイム処理はパフォーマンス最優先で Go を採用。
- コア取引やリスク管理は安定性を重んじ Java を維持。
今回は初期の混乱とは違い、意図的な専門分業だった。
👉 この進化については別の記事で掘り下げたい。
第2段階：共通基盤 —— 能力を供給する“工場”としての存在
なぜ共通基盤が必要か？
マイクロサービスを分割した後、会社は急速な拡張期に入った。
各事業ラインが同じ機能を繰り返し開発していた。ユーザー管理、商品管理、決済など、各チームがそれぞれ実装。
非効率に社長は焦った。「共通基盤を作って、みんなで使えないのか？」
共通基盤の誕生
そこで「共通基盤」が登場した。
- 商品センター、ユーザーセンター、決済基盤、コンテンツ基盤、データ基盤が次々と構築。
- フロントの事業は API を呼ぶだけで能力を再利用できる。
- まるで工場のように、基盤が部品を作り、前台がそれを組み合わせて製品化する。
効果
- 重複開発が減り、納期が大幅短縮。
- 新規サービスは数か月ではなく数週間でリリース可能に。
- 共通基盤チームの地位は急上昇し、全社の“能力提供者”として認知された。
第3段階：データウェアハウス —— 共通基盤の裏方化、大フロント + データウェアハウスの構造
なぜ共通基盤が影を潜めたのか？
ビジネスが成熟すると、多くの“標準化能力”は安定し、頻繁な改修は不要になった。
共通基盤チームはもはやイノベーションの主役ではなくなった。
裏方への転身：単一の真実の源泉
共通基盤は消えたのではなく、裏方に潜り込み、業務データウェアハウスへと進化した。つまり企業の Single Source of Truth となった。
- 全システムの行動データを蓄積し、定義を統一。
- ミッションは“ビジネス支援”から“データモデルの安定支援”へ。
- まるで企業の「アーカイブ室」として、公認のデータ基盤を提供する存在になった。
アーキテクチャの変化：大フロント + データウェアハウス
この時期、アーキテクチャは 大フロント + データウェアハウス へと整理された。
-
大フロント：
- 市場とユーザーに直結し、迅速な試行錯誤と柔軟な提供を重視。
- プロダクト、キャンペーン、マーケティングなどが中心で、敏捷性を最優先。
-
データウェアハウス：
- 裏方に回り、安定した統一データを提供。
- 表舞台に立つ俳優ではなく、舞台裏の電力設備や照明制御のような存在。
この組み合わせによりバランスが取れた。
- フロントは常に変化し、市場とユーザーに適応。
- バックのデータウェアハウスは安定を維持し、長期的な資産を提供。
データウェアハウスの価値
この構造下でデータウェアハウスの価値は一層拡大。
- ユーザー属性分析 → 精密マーケティング
- レコメンドアルゴリズム → コンバージョン率向上
- 財務分析 → 精緻な経営管理
- サプライチェーン最適化 → コスト削減
競争力は「機能をいかに早く出すか」ではなく、「データからどれだけ継続的な価値を引き出せるか」に移った。
まとめ：アーキテクチャの進化と未完の物語
これまでの進化を振り返ると：
- 少年期（マイクロサービス）：混沌の中でスピードを追求。
- 青年期（共通基盤）：標準化とスケール化。
- 成熟期（大フロント + データウェアハウス）：安定とデータ還元。
しかしこれは終点ではない。
- データウェアハウスの上には、リアルタイム DWH、データプロダクト、AI 活用が次々と登場している。
- フロントは依然として市場に迅速に適応し、バックの DWH は安定して価値を出力する。
- アーキテクチャは進化し続け、未来にはさらに新しい形態が待っている。