機能分割型SaaS構築支援の裏側：大企業グループ横断で使える「機能単位提供型アプリ基盤」の構築事例
はじめに：機能分割型SaaSという考え方が注目される背景
多くの大企業がグループ企業や複数事業部を抱える中、業務システムの共通化と個別最適化の両立は永遠の課題です。従来のオンプレミス中心の基幹システムでは対応が難しく、SaaS導入が加速していますが、以下のようなジレンマが生じます：
- 子会社・部署ごとに業務プロセスや用語が微妙に異なる
- 一部は自社開発、他は市販SaaSを利用していて全体最適が難しい
- 個別対応しすぎるとコストが膨れ、保守が困難に
こうした中で注目されるのが、「機能単位での導入・統合・停止」が可能な、柔軟性と拡張性を両立する機能分割型SaaSです。本記事では、大手流通グループ向けに開発されたこの形式のSaaSアーキテクチャについて、構築の舞台裏を詳述します。
プロジェクトの概要と課題定義
対象企業は、全国20社以上の事業会社を傘下に持つ流通グループであり、共通業務（稟議申請、備品発注、勤務表提出など）を効率的に標準化したいという要望を持っていました。ただし、以下のような制約が存在しました：
- 統一パッケージでは現場からの反発が予想される
- フルスクラッチ開発では各社展開のコスト・スピードに課題がある
- セキュリティ・認証は統一されているが、UIや入力項目に柔軟性が求められる
この状況を打開するため、「機能ごとに分離されて提供可能でありながら、共通認証とデータ統合が可能」なSaaSアーキテクチャが採用されました。
要件定義：”共通化”と”差分吸収”の両立を設計に反映
プロジェクト開始時に最も重視されたのは、共通要素と個別要件の分類です。次のようなアプローチで要件整理が進められました：
- グループ全社に共通する業務フロー（ログイン、承認、コメント、アーカイブなど）を共通コンポーネントとして定義
- 各社独自のルール（回覧順、通知タイミング、必要項目など）はJSON形式で設定できるように分離
- アプリはあくまで”機能単位”で提供し、組み合わせやカスタマイズを受け入れる前提で設計
この設計思想により、スモールスタートでの導入から、大規模な横展開まで対応できる柔軟性を確保しました。
技術構成：モジュール性と疎結合を両立するアーキテクチャ
拡張性と再利用性を最優先に、次のような技術構成が採用されました：
- UIフレームワーク：React + Vite + TailwindCSS
- マイクロアプリ統合：Webpack Module Federation + iframeベース共通シェル
- 権限認証：Keycloak + OAuth2.0 によるロールベース認可
- API連携：FastAPI + gRPC による高パフォーマンス通信
- データベース：PostgreSQL、リアルタイム系はFirebaseと併用
- 継続的デリバリ：GitHub Actions + ArgoCD による自動デプロイ
これにより、各業務ユニット（例：申請、通知、承認）を別アプリとして独立管理しながら、UXやログイン状態、エラートラッキングなどは共通レイヤーで統一しています。
実装の工夫：スケーラビリティと運用性を意識した設計
ユーザー属性ベースでUIと機能を動的制御
ユーザーが所属する会社・部署・ロールに応じて、表示UIや有効な機能をリアルタイムに切り替え。1つのコードベースで複数企業に対応できる構造が実現しました。
汎用ワークフローエンジンを活用
複雑な承認フローや条件分岐が各社異なるため、ワークフロー定義はYAMLベースで管理。これにより、UIやロジックに手を加えることなく、現場側で仕様を調整できるようになりました。
非同期APIとリアルタイム更新
機能間の連携はWebhooks＋PubSubを活用して非同期で構成し、レスポンスを待たずに処理を進行。UI側はFirebaseと連携し、更新を即時反映させることで高い操作性を実現しました。
導入の成果と現場の声
- 初期展開対象の3社 → 半年で15社へスムーズに展開
- 各社独自の設定変更ニーズの95%以上をコード修正不要で対応
- システム導入部門の8割以上が「他部門展開に向いている」と回答
- 「必要な機能だけ導入できるのが軽くて良い」という現場評価が多数
導入後も、社内からの要望に設定のみで応えられる点、導入スピードの早さ、説明コストの低さが評価されています。
受託開発パートナーとして求められた視点
このような構成を支えるには、単なる技術力ではなく次のような視点が求められました：
- 全社共通業務の本質を抽出し、モジュール化可能な単位へ分解できるスキル
- 開発しやすさよりも「展開・運用しやすさ」を重視したアーキテクチャ提案
- 仕様変更を「設定」で吸収する前提の設計とUI実装力
特に「どの単位で汎用化し、どこで柔軟にするか」を見極める力が、クライアント側からの信頼を勝ち取る鍵となりました。
まとめ：未来のSaaSは「業務構造×設定」で運用される
「モノリシックなSaaS」から「業務単位のマイクロサービス」へ。今後のSaaS開発では、「画面のデザイン」ではなく「構造と使い方の分離」「変更に強い設計」が重視されていくでしょう。
本事例のような構造であれば、業務の変化・組織改編・新会社の参加などにも柔軟に対応できます。開発会社としては、「構築・運用・展開・変更」のすべてを設計に織り込んだ提案こそが、新たな競争力の源となるはずです。
