DEVELOPER’s BLOG

技術ブログ

SaaS導入後に考える、各システムの連携方法の紹介

2024.09.12 竹中 涼香
コラム
SaaS導入後に考える、各システムの連携方法の紹介

目次

  1. はじめに
  2. SaaS活用に至る変遷
  3. 連携基盤構築のアプローチ
  4. 事例

 

はじめに

デジタル化が進んだことでSaaSの活用が増えています。

SaaSはクラウドサービスの一部で、総務省の「令和4年通信利用動向調査」によると、クラウドサービスを一部でも利用している企業の割合は、2022年には72.2%に達しています※ 総務省 令和4年通信利用動向調査
そのうち、クラウドサービスの効果について、「非常に効果があった」または「ある程度効果があった」と回答した企業の割合は87.1%と、多くの企業が導入効果を感じており、今後もSaaS利用は加速していくでしょう。

SaaSは便利ですが、その急速な普及に伴い、システム企画部門にとって新たな課題が生じています。
各部署で独自に導入されたSaaSのデータ連携や、異なるSaaS間での業務効率の低下などが代表的な課題です。

本ブログでは、複数のSaaSの組み合わせ・データ連携に頭を悩ませている方向けに、当社がおすすめしている解決策を紹介いたします。


SaaS活用に至る変遷

以前は、スクラッチ開発で自社業務にマッチしたシステムや、SaaS追加開発し、ひとつのシステムで関連業務をすべてまかなうシステムが多く構築されていました。
その方法では、導入までに時間がかかること、SaaSのバージョンアップで追加開発箇所に不具合が生じることなど、導入前後に大きな課題を引き起こしました。

これを解消するために、近年はではSaaSは追加開発せず、複数SaaSを組み合わせて利用することが増えました。

そのため、「どの組み合わせが最適か」「複数のSaaSが業務に合わせてデータが繋がらず、データを2重管理している」など、新たな課題が出現しています。

SaaSを連携させるためのデータ連携基盤を構築し、APIで連携させるアーキテクチャを提案しています。
SaaS同士のデータ連携はもちろん、連携すべきシステムを追加する際も、連携基盤へ連携するため将来的なメンテナンス性も高まります。

複数のSaaSシステムがそれぞれ連携するイメージと、今回提案している、SaaSを連携させるためのデータ連携基盤を構築するイメージを図で表現します。


複数のSaaSシステムがそれぞれ連携する

複数のSaaSシステムがそれぞれ連携


それぞれのSaaSシステム同士が直接繋がっており、連携の数が増えるに従って接続の複雑さが増していくことがわかります。 このような接続方法では、各システムごとに個別の連携開発が必要となり、効率が悪くなる傾向があります。






提案:データ連携基盤を介して複数システムが連携する

データ連携基盤をハブにして各システムを連携


各SaaSシステムはデータ連携基盤に接続されており、システム同士が直接繋がるのではなく、連携基盤を通じてデータがやり取りされます。
これにより、各システム同士の個別の接続開発が不要となり、連携の複雑さが大幅に削減されます。 このようなアーキテクチャは、拡張性とメンテナンスのしやすさを向上させる効果があります。



連携基盤構築のアプローチ

連携基盤を構築し各SaaSを連携させていくためのステップを紹介します。

(1) 現状分析と要件定義
- 連携する各SaaSシステムの現状を把握し、どのデータがどのシステムで必要かを明確にする。
- 各システム間のデータの流れや連携頻度、形式を定義する。

(2) アーキテクチャ設計
- 連携基盤の基本アーキテクチャを設計。APIゲートウェイ、メッセージキュー、ETL(Extract/Transform/Load)ツール、データ変換機能などの必要なコンポーネントを検討する。
- セキュリティやデータの可視性・統制を含め、どのようにデータを管理するか設計する。

(3) APIおよびデータフォーマットの標準化
- すべてのシステムが統一されたAPIを介して接続できるようにする。
- 連携データのフォーマット(JSON、XML、CSVなど)やバージョニングの標準化を行う。

(4) データ変換・マッピング
- 各SaaSシステムが異なるデータ形式やフィールドを使用している場合、データのマッピング・変換処理を設計する。ETLツールを活用してデータの抽出、変換、ロードを実行する。

(5) リアルタイム連携とバッチ処理の設計
- リアルタイムでデータ連携が必要なケースと、バッチ処理で定期的に連携するケースを分け、システムに負荷がかからないよう設計する。
- それぞれに適したメッセージングツールやスケジューリングツールを導入する。

(6) セキュリティとアクセス管理
- APIアクセスの認証・認可を設置し、データの暗号化やログ管理を実施する。
- 連携するシステムごとにアクセス権を細かく設定し、データの安全性を確保する。

(7) モニタリングとエラーハンドリング
- 連携基盤に対する監視を導入し、リアルタイムでエラーやパフォーマンス問題を検知できるようにする(例:ログ管理ツールやアラートシステム)。
- エラーが発生した場合のリトライやエラーハンドリングの設計も重要。

(8) テストと検証
- 各SaaSシステム間のデータのやり取りを詳細にテストし、データが正しく連携されることを確認する。
- スケーラビリティやパフォーマンスのテストも実施し、将来的な負荷に耐えられるか検証する。

(9) 運用と保守
- データ連携基盤を運用に移行し、定期的なメンテナンスやシステム更新、データフォーマットの変更に対応できる体制を整備する。
- 新しいSaaSシステムが追加された際に、スムーズに統合できるように柔軟性を持たせる。

これらのアプローチを順次実行することで、安定したデータ連携基盤を構築できます。構築後は、継続的な監視と改善が重要です。

事例

 

ここでは2つの事例を紹介します。

Salesforceをデータ連携基盤に使用した事例

複数店舗を持たれている to C向けの事業を実施している会社様です。
店舗やコールセンターで得られたお客様からの声を、適切に本社に連携し、分析用にデータを蓄積する必要があります。
もともとはSalesforceが導入されていましたが、店舗やコールセンターでは機能が過剰であること、データ分析はもっと高性能な機能が必要であることから当社に相談いただきました。

アプローチ

  • 店舗・コールセンターのデータ入力用の画面を構築し、データはSalesforceにAPI連携。
  • データ分析は、BI専用ツール(Amazon QuickSight)を導入し、Salesforceと簡単に連携。

システム構成イメージ

スクリーンショット 2024-09-09 6.37.03.png

メリット:既存システムを活かし、業務の効率化とデータ分析の強化

  • 既存のSalesforceおよび蓄積されたデータを活かすことができたこと
  • 店舗・コールセンター業務に特化したシステム導入により、現場のキャッチアップ期間を最低限にできたこと
  • BIツールは、AWSマネージドサービスを活用し、構築費用・期間を最低限にできたこと


SaaSとスクラッチ開発を組み合わせた事例

百貨店などに出店されている to C向けの商品の販売・製造を実施している会社様です。
百貨店内の店舗から注文され、在庫を確認し、出荷する一連の流れを、電話やExcel管理・目視チェックなど、ややアナログな環境で運用されていました。
今後の事業拡大(=注文数・生産数増加)を見越して、業務効率を上げるためにシステム化を検討され、当社に相談いただきました。

アプローチ

  • 標準化しやすいい業務はSaaSに置き換え
  • 標準化しにくく、お客様独自の業務がスクラッチで開発
  • 各システムを連携するハブを構築し、APIでデータ連携

システム構成イメージ

スクリーンショット 2024-09-09 6.37.11.png

メリット:システムの柔軟性は維持したまま、業務の標準化

  • SaaSとスクラッチ開発を組み合わせることで、構築費用・期間を最低限にできたこと
  • 各システムを疎結合にし、システムリプレイス・システム追加構築をしやすい構成にしていること


業務と密接に関わっているSaaSの連携は「これだけやればいい」といった正解がありません。
お客様ごとの業務をヒアリングし、適切な構成を提案いたします。ぜひお気軽にご相談ください。


X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

「コスパならBigQuery」?実験で比較してみた【Redshift vs. BigQuery】

.blue-link, .blue-link:visited { color: blue; } 目次 「費用対効果」で選ぶには? 結果:BigQueryは「安定」している 実験条件 データセット データウェアハウス設定・計測条件 クエリ コード集 前処理 データロード等 計測記録の取得(BigQuery) リザルトキャッシュの無効化(Redshift Serverless) クエリ1-1:小規模構造化データ、単純集計 ク

記事詳細
「コスパならBigQuery」?実験で比較してみた【Redshift vs. BigQuery】
AWS コラム データ分析
【Redshift vs. BigQuery】「運用性でRedshift」という選び方

.blue-link, .blue-link:visited { color: blue; } 目次 結局、何が違うのか? Redshiftの運用性 1. AWS上の対向システムとの統合容易性 2. 機械学習ベースの管理タスク自動化 3. Glue/Lake Formation による一元的なメタデータ・アクセス権限管理 まとめと次回予告 出典(いずれも記事公開時点閲覧) 結局、何が違うのか? こんにちは、アクセルユニバ

記事詳細
【Redshift vs. BigQuery】「運用性でRedshift」という選び方
AWS コラム データ分析
SREを外部委託するメリットと課題:適切なパートナー選びの重要性

導入 SREにおける視点の違い SREを外部に委託する利点 SRE外部委託の課題とコストの問題 自社の一員として動いてくれるSREパートナーを選ぶ SREを社内で運用するか外部に委託するかの選択 まとめ SRE(Site Reliability Engineering)の外部委託における利点と課題について、システム運用の効率化とコスト管理の観点で適切な委託先の選び方を解説します。 1. 導入 SREは、システムの安定運用と信頼

記事詳細
SREを外部委託するメリットと課題:適切なパートナー選びの重要性
SRE コラム
生成AI導入案件の30%が中止見込み、従来システム導入と大きく異なるアプローチ

Gartner社による生成AIのレポート 生成AI導入の進め方 まとめ Gartner社による生成AIのレポート Gartner社は、データ品質の低さ、リスク管理の不十分さ、コストの増大、ビジネス価値の不明確さなどの理由で、2025年末までに生成AIプロジェクトの30%がPoC以降に中止されるだろうと発表しました。 2024/07/29に発表されたGartner社によるレポート 2024/7/29にシドニーで開催されたGartner Data

記事詳細
生成AI導入案件の30%が中止見込み、従来システム導入と大きく異なるアプローチ
コラム 生成AI

お問い合わせはこちらから