伸びてきたスタートアップを足止めする、よくある3つのアーキテクチャ失敗

はじめに

スタートアップでは スピード が正義。プロダクトを検証して、機能を出して、市場を証明する。

その一方で、当時は正しかった判断が、あとから「足かせ」になることがある。悪いわけじゃない、文脈が変わっただけ。よくあるパターンと、どう手を打つかを書いた。

一つのシステム（コードベース）で複数のドメインを扱うと、最初は楽。でも大きくなるほど、全部が絡み合う：機能の結合、脆いデプロイ、一部だけスケールさせづらい。

対策： 責務を分ける。いま少しだけ構造を入れておくと、あとがだいぶ楽になる。

「ここは誰の責務？」を決めずに伸ばし続けると、ロジックの重複、曖昧な責任の所在、変更のたびに予期せぬ影響。

対策： ドメインの境界をはっきりさせる。どこを触ればいいか分かるので、変更が予測しやすくなる。

パフォーマンスや利用状況が見えてないと、障害やボトルネックに気づくのが「ユーザーからクレーム」のときになる。

対策： 監視とオブザーバビリティを入れる。地味だけど、信頼性と安心感が全然違う。

最初のアーキテクチャの選択が、その後の伸びを左右する。この3つを早めに避けておくと、イノベーションしつつ安定したシステムを保ちやすい。