こんにちわ、hanetsukiです。
プラットフォーム開発では、役割ごとにアプリケーションを分割しつつも、
ユーザー体験としては一続きに感じられるUIを提供したい、という場面があると思います。
この記事では、以下の内容を統合認証基盤の事例をもとに整理していきます。
- 認証基盤とマイページという役割の異なるWebアプリを分離した背景
- その前提条件の中でなぜデザインシステムをモノレポで管理する判断をしたのか
- その結果として得られた副次的なメリット
前提：プラットフォーム開発では「役割の分割」が求められる ☺️
近年のプラットフォーム開発では、1つの巨大なアプリケーションにすべてを詰め込むというよりも、
- 責務を明確に分ける
- 変更しやすさや安定性を高める
- 将来的なスケールを見据える
といった理由から、役割ごとにアプリケーションを分割する設計を取ることが多い印象です。
今回のケースでも、役割としては大きく次の2つに分かれていました。
① 認証基盤（認証前）
- 複数サービスの入り口になる
- トラフィックが集中しやすい
- 何より「落ちてはいけない」
上記のような性質から、S3 + CDN による静的配信を前提とし、安定性とレスポンスを最優先する構成を選択しました。
② マイページ（認証後）
- アカウント情報の編集
- 外部サービス連携
- 仕様変更や追加要件が比較的多い
こちらは独立したコンテナで提供し、
要件に合わせて比較的自由に改修できる構成を重視しています。
この2つを無理に1アプリにまとめてしまうと、
- マイページ側の障害が認証基盤に影響する
- 認証基盤の制約によって、マイページの開発がやりづらくなる
といったリスクが出てきます。
そのため、アプリケーション自体は分けるという判断は自然なものでした。
課題：役割は分かれても、体験は分断したくない 😵💫
一方で、アプリケーションを分けたことで新たに出てきた課題があります。
それが、サービス体験の一貫性です。
ユーザーから見れば、認証画面と認証後のマイページは「別アプリ」ではなく、
同じサービスの延長線上にあります。
色や余白、フォント、コンポーネントの挙動が少し違うだけでも、
なんとなく違和感のある体験になってしまいます。
役割は分けたいけれど、体験は分断したくない。
このあたりが、今回の悩みどころでした。
選択肢：デザインシステムをどう管理するか 🤔
UIを統一する方法としては、
- デザインシステムを別リポジトリとして管理する
- npmパッケージとして各アプリから参照する
といった選択肢が一般的だと思います。
特に人数の多いチームや、大規模なプロダクトでは有効な方法だと感じます。
ただ、今回の開発体制では次のような前提がありました。
今回の前提条件
- TPM兼FEとして、プロジェクトの開発を横断的にみている
- 実質的に少人数（ほぼ1人）での開発
- UIだけでなく、
i18nなども個別で管理しておきたい背景がある - AI駆動の開発を進める中で、AIに読み込ませる文脈はなるべく一つにしたい
この状況でポリレポ構成を取ると、
- UI変更のたびにリポジトリをまたいだ作業が発生する
- 変更の伝播コストや認知負荷が高くなる
- AIにとっても、参照する情報が分散してしまう
といった点が気になりました。
解決策：デザインシステムをモノレポで管理する 💡
そこで今回は、「役割は分けるが、強く共有したいものはまとめる」 という割り切りをして、
- アプリケーションは分離
- デザインシステムや共通資産はモノレポで管理
という構成を採用しました。
.
├── apps/
│ ├── auth/ # 認証基盤 (Next.js / export)
│ ├── mypage/ # マイページ (Next.js / standalone)
│ └── ...
├── packages/
│ ├── ui/ # 共通UI（デザインシステム）
│ ├── i18n/
│ ├── constants/
│ └── ...
└── turbo.json / pnpm-workspace.yaml / ...
この構成にしたことで、
- UI変更を一箇所で完結できる
- 「今どのUIが正なのか」で迷わなくなる
- 文脈が1つにまとまり、AIを用いた開発とも相性が良い
といった効果が得られました。
shadcn/uiをベースにした/uiパッケージ 💕
共通UIの実装には、shadcn/uiのアプローチを採用しています。
ライブラリとして依存するのではなく、
コンポーネントの実体をプロジェクト内に取り込む形式のため、
- ブランドに合わせた細かな調整がしやすい
- 中身がブラックボックスにならない
という点が、今回の「小さく始めるデザインシステム」とかなり相性が良いと感じました。
カスタマイズが増えるほどupdateのコストは上がる印象ですが、
それ以上に、柔軟性と理解しやすさのメリットが勝っている印象です。
個人的には、𝑩𝑰𝑮 𝑳𝑶𝑽𝑬 な構成です。
振り返り：モノレポは前提条件次第で強い選択肢になる ↩️
今回の構成は、
- 少人数
- 強く結合したいドメイン（認証・UI）
- 高い変更頻度
- AIを用いた開発
といった前提条件だからこそ、うまくハマった選択だったと思っています。
モノレポかポリレポかは二元論ではなく、
「今の前提条件で何が一番ボトルネックになるか」 を見て選ぶものだな、と改めて感じました。
今後、チームやサービスが成長していけば、リポジトリ分割やCI/CDやVRTの本格導入といったフェーズも自然にやってくるはずなので、次に備えておきたいと思います。
参考
Discussion