タイトルの「アカウント管理基盤に対する後からの要件追加に耐えるSaaS設計」というのは、今僕が作っているプロダクトが解決したい課題の一つです。
この課題はどういうものなのか解説します。
1. 課題と背景
多くの企業がアカウント管理基盤を作るとき「まずはアプリを横断してSSOができれば十分」と考えてスタートします。
しかし、ユーザー数が増え利用シーンが広がるにつれて、次のような要件が出てきます:
- 「チームで使いたい」「組織ごとにユーザーを管理したい」
- 「権限をもっと細かく制御したい」
- 「組織やプロジェクト単位で利用状況を把握したい」
これらのアカウント管理基盤に対する要件に後から対応しようとすると、データモデルの再設計、API互換性の破壊、ビジネスロジックの全面改修といった大掛かりな再開発が必要になります。
2. 要件に可逆性を持たせるという考え方
後からの変化に耐えるためには、最初から将来を見据えたアーキテクチャを意識することが重要です。
再構築なしで要件の進化に対応できる仕組みは、次の3つを後方互換性を維持したまま実現できる必要があります:
- 主語の拡張ができる：ユーザー単位 → チーム単位へ
- コンテキストの分離ができる：同一ユーザーが複数チームを行き来できる
- 権限モデルの細分化ができる：粗いロール → 詳細なポリシーへ
これらを後付け可能にしておくことで、成長段階での仕様変更が再開発ではなく拡張として扱えるようになります。
3. 再開発を防ぐ「区画設計」
理想的な設計は、「家を建てたあとに配管を掘り返す」のではなく、最初から区画を整備しておくことに近い考え方です。
可逆性がないと: 「後からの変化＝再開発」になり、コストと複雑性が増大
可逆性があると: 「後からの変化＝設定変更」で済み、開発速度を落とさず進化できる
4. 結論: 「共通資産」としてのアカウント基盤を作る
IDやチーム管理、権限制御といった領域は、アプリケーションの一機能ではなく、全体を支える共通資産になりえます。
- 新機能の追加や要件の変化を恐れずに進化できる
- 既存ユーザーへの影響を最小化できる
- 複数のプロダクトやサービス間で再利用できる
小さく始めるサービスこそ、「後からの変化」に耐えられる基盤を持つことが、将来の成否を大きく左右すると考えています。
詳しくはリンク先の記事「シングルサインオンから始めるSaaS開発 ─ 増築に強いID基盤」をご参照ください。
https://www.tc3.co.jp/from-sso-to-mutitenant-saas-tactna/
プロダクトはこちら: Tactna - https://www.tactna.com