01 · ビジネス上の課題
多くのソフトウェア企業や企業のIT部門は、異なる時代に構築されたプラットフォームに依存しています。顧客ごとのシングルテナント導入から始まった製品は、今ではそれぞれ独自のパッチとアップグレードスケジュールを持つ、互いに乖離した多数のインストール環境を抱えています。中核となるビジネスロジックは、全体を理解しているエンジニアがほとんどいないモノリスの内部にあり、リリースのたびに調整されたダウンタイムと手作業によるテストが必要になります。AI機能、オープンAPI、セルフサービスのオンボーディングなど、顧客が期待する新たな機能を安全に追加することは容易ではありません。
現状維持のコストは、目立たないまま積み上がっていきます。インフラ費用は新規顧客が増えるたびに膨らみ、セキュリティ上の脆弱性は古いフレームワークの中に残り続け、経験豊富なエンジニアはモダンな技術スタックを好むため、採用も難しくなります。しかし、全面的な作り直しが現実的な選択肢となることはまれです。ロードマップが凍結され、作業が二重になり、顧客が頼りにしているにもかかわらず誰も文書化していなかった挙動を失うリスクがあるためです。経営層に必要なのは、事業を継続し顧客へのサービスを提供し続けながら、プラットフォームをモダナイズできる道筋です。
02 · ソリューションの提案
iQsolutionsは、段階的なモダナイゼーション戦略を採用します。既存システムを把握してドメインの境界を特定し、レガシーシステムと並行してモダンなプラットフォームを導入したうえで、ストラングラーフィグパターンを用いて機能を新しいサービスへ徐々に移行させます。各ステップは元に戻すことができ、本番環境で検証されるため、顧客は継続性を保ったまま利用でき、その裏側でアーキテクチャは着実に改善されていきます。
その過程で、長く使い続けられるSaaSプロダクトの基盤を確立します。具体的には、テナント分離、ID管理と利用権限、利用量の計測、プロビジョニングの自動化、オブザーバビリティ、継続的デリバリーです。その結果、個別のデプロイなしに顧客をオンボーディングでき、変更を頻繁かつ確信を持ってリリースでき、AI機能などの新たな機能を中核を不安定にすることなく取り込めるプラットフォームが実現します。
03 · システム構成要素
レガシーアプリケーションやシングルテナントのアプリケーションを、クラウドネイティブなマルチテナントSaaSへと段階的にモダナイズします。機能しているものは活かし、制約となるものは廃止し、移行期間を通じて顧客の業務を止めません。
- 01
テナント・IDサービス
テナント管理の一元化、シングルサインオン、ロールベースのアクセス制御、利用権限管理により、コードをフォークすることなく顧客ごとの設定に対応します。SAMLやOpenID Connectを用いた、顧客自身のIDプロバイダーとのエンタープライズフェデレーションにも対応します。
- 02
モジュール型ドメインサービス
モノリスから切り出したビジネス機能を、明確なコントラクトを持ち、境界が明瞭なサービスまたはモジュールとして整備します。それぞれ独立してテストとデプロイが可能で、既存の挙動を維持するルーティングレイヤーの背後に導入されます。
- 03
データ移行パイプライン
レガシーのスキーマと顧客データを新しいモデルへ移行する、反復可能で検証可能な仕組みです。突合チェック、代表的なデータを用いたリハーサル実行、テナントコホートごとのロールバック手段を備えています。
- 04
プラットフォームエンジニアリング基盤
Infrastructure as Code、コンテナオーケストレーション、CI/CDパイプライン、環境構築の自動化により、環境やリージョンをまたいでデプロイを定型的で一貫性があり監査可能なものにし、個人の知識に依存した手作業のリリース手順を置き換えます。
- 05
利用量計測・課金連携
利用状況の追跡とプランの適用をサブスクリプション課金と連携させます。これにより、プロダクトチームと財務チームは、価格設定、パッケージング、利用権限を変更するたびにエンジニアリング作業を必要とすることなく、ビジネスモデルを進化させられます。
04 · エンジニアリングアプローチ
エンジニアリングアプローチ
- 01
変更の前に現状の挙動を把握
何かをリファクタリングする前に、自動化された特性テスト(キャラクタリゼーションテスト)と本番環境のテレメトリによって現在の挙動を把握します。これにより、顧客が気づかないうちに依存している文書化されていないロジックを保護し、その後のあらゆる変更にセーフティネットを用意します。
- 02
段階的で元に戻せるステップ
機能は、フィーチャーフラグとルーティングルールの背後で、小さな単位に分けて新しいプラットフォームへ移行します。どの単位も、移行全体の他の部分に影響を与えることなくロールバックできます。
- 03
目的に適したテナンシー
プール型、サイロ型、ハイブリッド型のテナンシーには、それぞれコスト、コンプライアンス、パフォーマンスの面で異なるトレードオフがあります。顧客要件と規制要件に基づき、データドメインごとに分離モデルを選定します。
- 04
デリバリーもモダナイズ
アーキテクチャの変更が定着するのは、リリースの進め方も併せて変わる場合に限られます。自動テスト、トランクベース開発、デプロイパイプラインは、プログラム終了後ではなく、プログラムの一部として導入します。
05 · 連携の全体像
- AWS / Microsoft Azure / Google Cloud
- KubernetesとTerraform
- Auth0 / Okta / Microsoft Entra ID
- SAML 2.0とOpenID Connect
- Stripe Billing / Chargebee
- PostgreSQL / Amazon Aurora
- Apache Kafka / Amazon SQSによるイベントストリーム
- Datadog / Grafana / OpenTelemetry
- GitHub Actions / GitLab CI
- LaunchDarklyによるフィーチャーフラグ
06 · セキュリティ上の考慮事項
- テナント分離はデータ、アプリケーション、インフラの各レイヤーで強制し、ある顧客が他の顧客のデータに決してアクセスできないことを自動テストで検証します。
- 既知の脆弱性を持つレガシーの依存関係を棚卸ししたうえで、移行計画の一環としてパッチを適用するか、廃止します。
- シークレット、鍵、認証情報は、設定ファイルからマネージドなボールトへ移し、ローテーションとアクセス監査を適用します。
- 顧客データの移行は文書化された手順に従って行い、暗号化と完全性の検証を実施するとともに、契約で求められる場合には必ず顧客へ通知します。
- モダナイズされたプラットフォームは、エンタープライズ顧客から求められることが増えているSOC 2やISO/IEC 27001などのフレームワークに向けた証跡収集を支援できるよう設計されています。
07 · デリバリーのフェーズ
- 1
アセスメント
アーキテクチャ、依存関係、テナンシー、データ、デリバリーの実践状況を把握し、プロダクト責任者とともにモダナイゼーションの目標を定義します。
- 2
ターゲットアーキテクチャ
将来のプラットフォーム、テナンシーモデル、移行の順序、段階的な切り替えのためのルーティング方式を設計します。
- 3
基盤構築
移行するすべての機能が依存することになるプラットフォームエンジニアリング、ID管理、オブザーバビリティ、パイプラインを確立します。
- 4
段階的な移行
ドメインとテナントコホートを元に戻せる単位で移行し、各ステップで挙動とパフォーマンスを検証します。
- 5
廃止と最適化
レガシーコンポーネントを廃止し、コストとパフォーマンスを調整したうえで、文書化され保守しやすいプラットフォームを引き渡します。
08 · ビジネス価値
ビジネス価値
変革中も途切れない継続性
プラットフォームが裏側で進化する間も、顧客は業務を続けられます。一度に大規模な切り替えを行う場合に伴うロードマップの凍結、業務の混乱、リスクを回避しながら、長年の顧客からの信頼も維持できます。
顧客ごとの対応負荷の軽減
共通インフラ、プロビジョニングの自動化、標準化されたデプロイにより、顧客が増えるごとに発生する運用作業を減らし、乖離した個別のインストール環境に一つずつパッチやアップグレードを適用し続ける負担を取り除きます。
より速く、より安全なリリース
自動テストとデプロイパイプラインにより、チームは調整の手間を抑えながら、改善をより頻繁にリリースできます。本番環境で想定どおりに動作しない場合にも、明確なロールバック手段が用意されています。
新たな機能を受け入れる余地
モジュール化され、計測の仕組みが整ったアーキテクチャにより、中核製品を不安定にしたり、既存顧客が待っている改善を遅らせたりすることなく、AI機能、パートナー向けAPI、新たなビジネスモデルを現実的に追加できるようになります。
エンタープライズSaaSモダナイゼーションの取り組みについて相談する
背景をお聞かせいただければ、iQsolutionsのエンジニアが検討のうえ、次のステップをご提案します。ご契約の義務はなく、自動送信の営業メールをお送りすることもありません。