はじめに
本記事は、Luup Advent Calendar 2025の3日目の記事になります。
こんにちは、株式会社LuupのSoftware部でPlatform / Technology Enabling (Backend TL) を担当している安元（やっすー）です。
先日開催された「Architecture Conference 2025」にて、「LUUPの事業成長と変化の速さに耐えるモジュラーベースアーキテクチャの設計思想」というテーマで登壇しました。
本記事では、その登壇内容をベースに、LUUPが直面していた課題と、それを解決するためにどのようなナラティブを持ってアーキテクチャ選定と組織への浸透を進めてきたのかについてご紹介します。
急成長する事業と、見えてきた「開発の限界」
まず、LUUPの現在の事業フェーズについて触れておきます。
2025年11月現在、LUUPのポート数は全国で 15,500箇所以上 に達しました。これは2022年5月の約1,200箇所と比較して10倍以上の拡大です。展開エリアも東京・大阪・京都などの主要都市に加え、全国各地へと広がっています。
事業が成長するということは、それだけ扱うデータ数が増え、オペレーションが複雑化し、ドメイン領域が拡大することを意味します。これに伴い、バックエンド開発においては以下の2つの大きな課題が浮き彫りになっていました。
1. 複雑性と緊急性のジレンマ
独自ドメインを含め事業領域が広く、かつ重要度・緊急度の高い施策が次々と発生します。その結果、複雑なドメインが絡み合っているにも関わらず、保守性向上のためのリファクタリングやアーキテクチャ改善の優先度が上がりにくい状況でした。
2. 開発手法のサイロ化
LUUPのバックエンドチームは、大きく分けて「User」「Ops」「IoT」といった複数のチームが存在します。これまではチームごとにレイヤー設計やビジネスロジック、エンティティ定義の方針が異なっていたため、ドメイン知識が共有されず、再利用性が低い状態（サイロ化）が進んでいました。
「街じゅうを駅前化する」ためのアーキテクチャ意思決定
私たちのミッションは「街じゅうを『駅前化』するインフラをつくる」ことです。
単なるマイクロモビリティシェアのサービスに留まらず、さまざまな自治体と連携協定を締結しながら、移動に関連する課題を一緒に解決する取り組みを行っており、都市の機能・利便性を高めるインフラとして街づくりの核心に深く関与していきます。この目標を達成するためには、今後さらに複雑なサービス・ドメインが入り混じり、相互関係が深まることが予想されます。
「サーバー開発がビジネスの複雑性に耐えきれず、事業成長のボトルネックになってはいけない」
ミッション実現のためこの危機感をチーム全体で共有し、アーキテクチャの動機づけの基盤としました。
Enabling Team の役割とナラティブ
私の所属するチームは、特定のプロダクト開発のみを担当するのではなく、横断的に各チームと伴走しながら、アーキテクチャ選定やDevEx（開発者体験）向上を担うチームです。
重視したのは、単に「新しいアーキテクチャを決めたから守ってくれ」と押し付けることではなく、「なぜ変化が必要なのか」という文脈（ナラティブ）を共有し、チームと共に移行を進めるアプローチです。
- 週次ミーティングでの対話: Backend全体および各チームと週一回の密なミーティングを行い、ナレッジ共有と連携を強化しました。
- 柔軟な移行プロセス: 緊急度が高く、理想的なアーキテクチャへの即時移行が難しい場合も現実を受け入れ、サポートや後続チケットによる管理を地道に行うことで、開発スピードを落とさずに改善を進めました。
具体的な解決策：モジュラーベースアーキテクチャ
複雑なドメインを整理し、チーム間の共通理解を生むために採用したのが、DDD（ドメイン駆動設計）に基づいたモジュラーモノリス構成（Modular Base Architecture） です。
1. ドメイン知識の整理とコンテキストマップ
まず、一般的なDDDのプラクティスに基づき、ドメインモデルとコンテキストマップを作成しました。これにより、コンテキスト境界と依存関係、そしてユビキタス言語を定義し、チーム間での認識のズレを解消していきました。
2. モジュラーモノリスによる実装
ディレクトリ構成としては、/src/Modules 配下に /Ride（ライドモジュール）や /Device（車両モジュール） といったモジュールを配置し、各モジュールごとにオニオンアーキテクチャ（Onion Architecture）のレイヤー構成を採用しました。
- 高凝集・疎結合: 関連するロジックをモジュール内に閉じ込め、外部への依存を最小限にする設計を目指しました。
- 品質の伝播: 一つ目のモジュールの品質を高めることで、人間だけでなくAIが模倣しやすくなり、全体のコード品質が底上げされる効果を狙いました。
3. 移行と品質管理のアプローチ
ビッグバンリライトは避け、ストラングラーパターンを用いて既存機能を残しつつ、イテレーティブに移行を進めています。
また、モジュール間の依存関係が崩れないよう、dependency-cruiser 等を利用して依存を管理し、CIでのチェックや可視化による品質向上を目指しています。さらに、各モジュールの特性をスコア化（モジュール性成熟度）し、品質と高凝集性を保つ仕組みの導入も進めています。
導入による効果とまとめ
このアーキテクチャと組織的なアプローチを取り入れたことで、以下の効果を実感しています。
-
ドメイン知識の共通理解と保守性の向上
コンテキストマップとモジュール化により、再利用性が向上し、複雑なドメインの共通理解が進みました。 -
認知負荷の低減と開発効率の維持
開発方針が統一されたことで、エンジニアの認知負荷が低減されました。また、AIコーディングツール（Agentic Coding）との親和性も高く、開発スピードを落とさずにリアーキテクチャを進められています。 -
将来的な可搬性の確保
ドメイン層の依存を適切に管理することで可搬性が高まり、将来的にインフラレベルのリアーキテクチャが必要になった際にも対応しやすい構造を確保できました。
関連記事として、AI活用事例も併せてご参照ください：
最後に
ミッションである「街じゅうを『駅前化』するインフラをつくる」を実現するためには、ソフトウェア・ハードウェア両面でまだまだ解決すべき課題が山積みです。
しかし、私たちはこの複雑性と向き合い、プロジェクトを成長させていくことを楽しんでいます。
「街全体を変えるプロダクト開発」というスケール感、そして法規制やハードウェア制約も含めた複合的な課題解決に興味がある方は、ぜひカジュアルにお話ししましょう！
Discussion