はじめに：機能分割型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開発では、「画面のデザイン」ではなく「構造と使い方の分離」「変更に強い設計」が重視されていくでしょう。 本事例のような構造であれば、業務の変化・組織改編・新会社の参加などにも柔軟に対応できます。開発会社としては、「構築・運用・展開・変更」のすべてを設計に織り込んだ提案こそが、新たな競争力の源となるはずです。