モノレポ戦略

従業員60名のSaaS企業。フロントエンドチーム8名が、管理画面・ユーザー画面・LP・共有UIライブラリ・設定パッケージの5リポジトリを運用していた。

課題:

• 共有UIライブラリを更新するたびに、他の4リポジトリにそれぞれPRを出す必要があった（月平均20件の横断PR）
• npm publishの手順でミスが多く、バージョン不整合で月に2〜3回ビルドが壊れた
• ESLintとTSConfigの設定が各リポジトリで微妙に異なり、コードレビューで揉めていた

移行: Turborepoを採用し、2か月かけて段階移行。まず共有UIライブラリとconfig、次にアプリケーション3つを統合。

結果:

• 横断PRが月20件 → 0件に（アトミックコミットで同時変更）
• ビルド破損: 月2〜3回 → 月0.2回（四半期に1回程度）
• CIの平均実行時間: Turborepoのキャッシュにより12分 → 3分
• lint設定を一元化したことで、コードレビューの「スタイル指摘」が70%減

120名規模のフィンテック企業。バックエンドはGoで書かれた8つのマイクロサービス、フロントエンドはTypeScript（Next.js）で構成されていた。各サービスのリポジトリは独立しており、API型定義はOpenAPIスキーマから各リポジトリで個別にコード生成していた。

課題:

• スキーマ変更後にフロントのコード生成が漏れ、本番でAPI不整合が発生（四半期に3〜4件）
• サービス間のgRPC型定義も各リポジトリに散在し、protobufの同期に毎回半日かかっていた

移行: Nxを採用し、OpenAPIスキーマとprotobuf定義をpackages/schemasに集約。各サービスは同じリポジトリ内から型を参照する構成に変更。

結果:

• API型の不整合による本番インシデント: 四半期3〜4件 → 0件
• スキーマ変更の反映漏れ: CIが影響範囲の全サービスを自動テストするため検出率100%
• protobuf同期の工数: 半日 → 不要（同一リポジトリ内で直接参照）
• 新サービスの立ち上げ: テンプレートジェネレータにより2日 → 2時間

創業1年目、エンジニア6名のスタートアップ。Webアプリ（Next.js）、管理画面（Next.js）、バックエンドAPI（Node.js）、バッチ処理（Node.js）の4つのアプリケーションを開発していた。

創業当初はポリレポで始めたが、3か月目で共有コードのコピペが蓄積し、「同じバリデーションロジックが4か所にある」状態になった。

移行: pnpm workspacesとTurborepoで構成。半日でモノレポに統合（まだコードベースが小さかったため）。

構成:

apps/web        ... ユーザー向けWebアプリ
apps/admin      ... 管理画面
apps/api        ... バックエンドAPI
apps/batch      ... バッチ処理
packages/db     ... Prismaスキーマ・マイグレーション
packages/auth   ... 認証ロジック
packages/types  ... 共有型定義
packages/config ... ESLint・TSConfig

結果（移行6か月後）:

• 共有コードの重複: 4か所 → 1か所（packages/に集約）
• Prismaスキーマ変更時の反映漏れ: 月2〜3回 → 0回
• 新機能の開発速度: エンジニアの主観で「体感1.5倍」（横断的な変更が1PRで済むため）
• オンボーディング: 新メンバーがgit clone1回で全環境を手元に構築でき、初日からPRを出せた