はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day13 の記事です。 弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
今回はマルチテナントSaaS視点で、マルチプロダクトを支える技術基盤についてご紹介していきたいと思います。
B2B SaaS文脈におけるマルチプロダクト戦略
マルチプロダクトという概念自体については、目新しい概念ではありません。特定の一つ企業がプロダクトを複数提供することはソフトウェアの登場以来から自然な流れでした。
なかでもB2Bの文脈で言えば、プロダクトのUI/UXの体験の統一は業務向けのアプリケーションとしての一貫性につながること、ビジネス観点においては、あるサービスの導入企業に対して、別プロダクトをそのまま営業することが営業効率観点でも優れていること、そして開発者目線でも、何度も同じ認証画面をつくる、デザインを別々に作るなどよりも、統一した基盤があるほうが本質的なサービス価値の向上につながるメリットが生じます。
近年のバズワードとしては「コンパウンド戦略」という言葉が使われています。国内ではLayerXさんのバクラクがその筆頭でしょう。
今回は個別具体の基盤について語るとキリがないため、マルチプロダクトにおける「基盤」の種類を概観と参考になる記事をご紹介したいと思います。
認証/認可基盤
マルチプロダクト環境において、認証基盤は最も重要な共通基盤の一つではないでしょうか。
特に「認証」については、複数のプロダクトをまたいで、一度のログインで全てのサービスにアクセスできる体験は、ユーザーにとって大きな価値となります。OAuth 2.0やSAML、OpenID Connectなどの標準プロトコルを用いた認証基盤を構築することで、プロダクト間のシームレスな認証体験を実現できます。
「認証」については、プロダクトごとに構築するには非常に構築コストが重いのですが、比較的歴史も深く、共通できる仕様も確立されているため、まずは認証から基盤を構築するという例は非常に多く事例があります。
デザインシステム
デザインシステムは、プロダクト間の一貫したUI/UX体験を実現する基盤と呼べます。エンドユーザーにとっても、プロダクトごとにUI（レイアウト）の統一性が高く、それ自体がプロダクトの認知負荷の軽減につながるのです。エンジニアやデザイン観点では、再利用可能なUIコンポーネントを共通化することで、開発速度の向上と品質の均一化を同時に実現することができます。
ボタン、フォーム、テーブルなどの基本コンポーネントやデザイントークン（色、タイポグラフィ、スペーシング）の統一あたりになってきます。FigmaのDev Modeを利用して生成AIの入力としてそのままデザイン情報をプロンプトに渡すなども可能であるため、開発効率の向上にもつながります。デザインシステムについては、メガベンチャーレベルになると、そのデザイン自体がインターネット上に公開されていることもあります。
通知基盤
複数プロダクトからの通知を統一的に管理・配信する基盤です。メール、SMS、プッシュ通知、Webhook等の通知/配信は、各プロダクト側から実装するコストが高い領域です。特にワークロードの予測が難しくスパイクしやすい構造でもあるため、アプリケーション設計としてカプセル化したい領域でもあります。
インフラストラクチャー基盤
顧客体験とは異なりますが、開発者観点ではインフラ（クラウド）環境の統一した整備も非常に重要になってくることでしょう。アプリケーションの開発者目線では、プロダクトの機能を磨き込むためにも、そのバックエンドを支えるインフラ環境で迷わないことも大切です。多くの企業ではインフラ基盤については、専任のインフラエンジニア/SREなどで構成されるチームで運営することも多く、インターネット上での事例も非常に多いです。
データ(分析)基盤
ビッグデータが集まる時代において、各種プロダクトから収集されたデータを加工・表示する基盤も重要です。それらを蓄積・活用するデータ加工ロジックは基盤化して共通して利用させることも一般的です。特に生成AIの文脈においては、サービス上に蓄積されるデータこそが価値になる時代です。
さいごに
マルチプロダクトを支える基盤の種類と参考になる記事を今回は紹介してきました。すべてを基盤化する必要があるわけではありませんが、シナジーの効きやすい領域においては基盤を整備することが企業のプロダクト作りを大きく支えてくれることでしょう🏄♂️