サービスの成長には「後からの変化」がつきものですよね。
最初は「ユーザーが1人で使うサービス」だからまずはシングルサインオン（SSO）ができればよしとして始めたアプリが、利用規模の拡大とともに「チームで使いたい」「組織の管理をしたい」といった要望が増えていきます。
この記事では、「後からの変化」にどう備えるかに焦点を当てて、そこにどう Tactna が貢献するかを解説します。
目次
TL;DR
マルチテナント対応を後付けしようとすると、データモデルは壊れ、APIは互換性を失い、フロントエンドは作り直しに近い改修が必要になる。こうして「要件追加＝再開発」になってしまうのが、従来の開発プロジェクトの常でした。
Tactna が提供するのは、この「後からの変化」そのものを前提にした基盤です。
互換性のある基盤を使っていれば上モノを取り替えて新しいユーザーのニーズに追随していけるのです。
Tactna は開発プロセスにおける根幹である要件定義に可逆性をもたらす
Tactna を導入していると、最初に toC 向けに構築されたアプリでも、後から toB、いわゆるマルチテナント（チーム、組織）の概念を導入できるようになっています。
つまり、以下のような進化を破壊的変更を限りなく小さく行えるのです。
1. 主語の拡張が後付けできる
初期リリースでは「ユーザーがアプリを使う」という単純な利用シナリオ（要件）だけでも構いません。
Tactna 上に載せておくだけで、後から「チームがアプリを使う」という複合的なシナリオを追加できるようになっています。
2. コンテキスト分離を後付けできる
同じユーザーでも「チームAの場合」「チームBの場合」といったコンテキストの切り替えが可能になります。
アプリが利用するID・アクセストークン、APIインターフェースは互換性を維持したまま、既存アプリは知らないうちに多層的なユーザーデータアイソレーションモデルに対応していきます。
3. 権限モデルを後付けできる
最初は「一般ユーザー」と「システム管理者」だけの粗いロール構成だけでも構いません。
Tactna 上に載せておくだけで、後から「経理部」「サポートメンバー」「代理店」のようにユーザーのロールを細分化していくことができます。
「区画整備された街」に家を建てるようなもの
要するに、Tactna はあらかじめ一般的なシナリオを網羅できる区画整備された領域を提供していて、そこに必要な要件をフィットさせていくため、密結合になりにくく、ユーザーデータモデルに関連する要件の追加・削除が容易になるのです。
Tactnaの世界は、例えるなら「あらかじめ区画整備された街」のようなものです。
そこに新しい家（アプリやその追加要件）を建てても、既存の構造と密結合せずに済み、建て替えや増築が容易になります。
逆に、何も区画整備されていない原野に家を建てると、水道管や道路、電柱などは家ごとに直結してしまい、後から拡張するときに大工事が必要になります。
可逆性がないと「後からの変化＝再開発」になる
多くのSaaSや業務システムでは、最初はシングルサインオンだけで使う想定で作ったID基盤やその上に乗るアプリが、成長するとこういう要求に直面しています:
- チーム単位で使いたい
- 組織構造を反映したい
- 権限を細かくしたい
ところが、可逆性のない設計だと、これらは後から足せないため、
- DBスキーマを全面改修
- APIをv2にして移行ガイドを出す
- 互換モードを何年も維持する
…といった大規模な再開発プロジェクトになっていきます。
再開発は、単に工数がかかるだけでなく:
- プロダクト開発が止まる（機会損失）
- 古い利用者との互換運用コストが発生する
- コードが複雑化して監査・運用コストが増える
といった副作用を生み、未来の成長コストが雪だるま式に膨らんでいくのです。
可逆性があると「後からの変化＝ただの設定変更」になる
Tactna が提供する要件定義の可逆性は、まさにこの再開発地獄を防ぐものです。
つまり、大規模な作り直しが必要だったものが小さな追加開発で済むようになります。
| 設計アプローチ | 例えるなら… | 特徴 |
|---|---|---|
| 密結合な実装 | 原野に家を直接建てる | 配管・道路が直結しており、増改築には破壊的工事が必要 |
| Tactna | 区画整備された街に家を建てる | 既存構造と緩やかに接続し、取り外し・拡張が容易 |
具体的には
| 要件 | アプリ個別開発時 | Tactna導入時 |
|---|---|---|
| ユーザーからチーム構造への対応 | – チーム管理画面作成 – セルフサインアップ機能改修 – メンバー招待機能追加 – チームでのアプリ利用開始・停止機能追加 など | 左の機能を有効にし、あとは各アプリ側の固有機能の改修にフォーカスできます |
1ユーザーが複数チームに所属する対応 | – ログイン時のチーム選択画面 – チームごとのID・アクセストークン変更 – チーム別のユーザーID採番 など | アプリとTactnaの間のI/F（API, JWTなど）は互換性を保った状態で対応できます |
境界事故リスク低減 | – チームAのユーザーが、チームBのデータにアクセスできてしまう – 管理者権限を持たないメンバーが、他メンバーの設定や招待を行えてしまう | Tactnaは「テナント → チーム → ユーザー」という多層境界を認証・認可段階で強制できるため、アプリ側の実装ミスがあっても、構造的にデータ混線が起きにくい仕組みになっています |
上記対応にかかるコストだけを比べれば、初期開発5,000万のプロジェクトだった場合、改修にかかるコストはアプリを含めて6分の1程度になると予想しています（サービスの複雑さ次第）。
仮に改修コストが1,800万円の場合、Tactna 導入済みであれば300万円程度に収まる試算です（1500万円削減）。これは当然アプリが増えるほど効いてくるため、アプリが5個あった場合、1500万円 x 5 = 7,500万円のコスト削減に繋がります。
Tactna 導入は保険ではなく攻めの投資
上記は一見防御的な性質に思えますが、実はこれは成長速度を落とさないための、未来を見据えた攻めの投資です。
- 新しい利用シナリオを怖がらず追加できる
- 既存ユーザーを壊すリスクを恐れず進化できる
- PMF後の展開フェーズで、開発チームがスピードを維持できる
結果として、コスト削減だけでなく、成長を止めないというもっと本質的な価値をもたらします。
まとめ: 進化を前提にしたID基盤 = 共通資産
まずは小さく出して、後から育てていく。これはリーン開発の基本です。
しかし、IDや認証・権限といった基盤が後からの進化に耐えられないと、その原則は現実になりません。
Tactna は、アプリの成長とともに変わっていく要件に可逆性をもたらします。
それは、プロダクトが未来の要求に追われて作り直されるのではなく、自然に進化していくための前提です。
Tactnaは事業に収益をもたらす資産になる
これこそが Tactna が提供する最大の価値のひとつです。
華やかなUIや派手なAI連携よりも前に、後からの進化を当たり前にするという土台なのです。
Author Yuki Sanada, Tech Lead, Tactna
