事例から考える、Salesforce社サービスへのデータ移行2つの課題

業務システムの新たな移行先として、Salesforce社のサービスが選ばれることが増加しています。いざSalesforce社のサービスへシステムを移行するとなった場合、注意しなくてはいけないポイントはなんでしょうか？

この記事では事例をもとに、Salesforce社のサービスへデータ移行する際の、2つの課題についてご説明します。

SaaSを選ぶメリットをおさらい

特にSalesforce社では、営業の状況を可視化する営業支援サービスと、担当者以外の情報を一元管理するための顧客管理サービスに魅力を感じるお客様が多いようです。他システムと連携して活用する事例が多いところも魅力でしょう。ラックでは、自社でSalesforce社のサービスを利用することはもちろん、お客様の要望に応えるために、Salesforce社のサービスに関わるエンジニアが増えています。

新たなシステム導入における2つの課題

新たなシステムへの移行を考えた場合、まずは既存業務の仕組みを整理・分類し、機能単位でシステム化の要否を判断します。その上でシステム選定、システム開発、システム運用・保守を行う流れは、どんなシステムでも同じでしょう。

そうしたシステム移行で考慮するポイントのうち、Salesforce社のサービスへの移行の場合、最初の想定より苦労するポイントの1つにデータ移行があります。SaaSにおける最大のメリットである優秀な機能群を利用するために、他者と外部リソースを共有する際に現れる制約の1つです。

今回は、Salesforce社のサービスへのデータ移行について、どんな点に悩まれているかをご紹介したいと思います。ただし、データ移行に限った話であっても、システム規模、業務、システムの運用状況によって取りうる方法は変わります。あくまで取り組み事例の1つである点をご了承ください。

さて、これからご紹介するのは大手人材サービスの基幹システムの移行事例です。独自開発していたWebアプリケーションを持つ既存の大規模システムからSalesforce社のサービスへ移行するために、システム全般の刷新を行いました。

移行対象になったSalesforceのオブジェクト（テーブル）は約60、対象データ件数は5千万件以上でした。一般的なRDBMS（リレーショナル・データベース・マネジメント・システム）からSalesforce側へのデータ移行です。この場合、RDBMSからRDBMSへの移行と異なり、SaaSへ移行する際の特有な問題があります。SaaSでは、バックグラウンドで多くのユーザーがリソースを共有しているため、特定のユーザーがリソースを占有できないようにするための制約があります。

このため、以下のようなことが発生しがちです。

• データ移行に時間がかかる
• 制約による移行時のエラーが出やすい

大手人材サービスではこれらの課題に対して、どのように取り組んでいったのでしょうか。

課題① 移行に時間がかかる

多くの場合、入力規則のチェック等の処理があるため、データ登録に時間がかかります。そのため、処理時間の計測や計画を立てることが重要です。大手人材サービスの例では、約1か月かけてデータ移行を実施することになりました。もちろん、1か月経過すれば稼働中の移行元データには、データ追加や更新が発生します。そのため三段階で移行をしました。

課題② データ移行の制約が多い

データ移行には、トランザクションごとのクエリ数、実行時間の長いAPIのコールアウト、Salesforce組織内のリソース消費に関するSalesforceアプリケーションの制限があります。さらに、想定していなかったエラーが起きることもあります。一括移行が難しいと判断した場合、最初から分割して移行する方法を検討すべきでしょう。入力規則だけでなく、投入時に関連するデータを自動的に更新してしまうトリガーなどの影響も無視できません。なるべく影響がないようにデフォルト値を設定するなどの対応が必要です。

実装例

大手人材サービスでは、RDBMS側に移行専用テーブルを用意してそこにデータを保持するようにしました。Salesforceでの関係性を維持するため、移行処理後にSalesforce内で一意のデータを示すIDもこちらで保管しています。このテーブルを活用することで、移行処理の利便性を高めました。なお、処理は次のように行います。

1. テーブルにデータを格納（移行元データ）
2. 移行用に加工（移行先の用件に合わせてデータ編集）
3. BulkAPIで移行処理
4. BulkAPIの戻り値で更新

これら一連の作業を逐次実行するコマンド群として実装しました。エラー部分のみの再実行も可能にしています。移行用のテーブルを用意したことにより、登録後のIDを利用することも簡単になりました。

通常、Salesforce側への移行を考えたとき、データローダの使用が考えられますが、データローダを使用する場合、CSVファイルの作成とデータ投入処理を別々に準備する必要があります。コマンド群のプログラムを使ったアプリにより、一括して準備ができます。処理がまとまっていることで、メンバー間でのコーディング方法の統一ができ、作業効率が向上しました。

このように移行の際に利用するデータ投入・更新の仕組みについても、データの件数や質によって検討し、工夫できるところがあります。

さいごに

データ移行には多くの考慮や作業時間が必要です。データ移行をしないで済むように、本当に必要なデータなのか？という観点がより重要です。

既存システムを引き続き利用する場合、既存システム側で参照できないか、サマリ情報の移行で対応できないかなど、運用面やデータ活用を考えて移行方法を検討しましょう。今回はデータ移行の一例のみのご紹介でしたが、他にもSalesforce社のサービスへのシステム移行について、検討すべき点はたくさんあります。

ラックには、Salesforceに関わるエンジニアがいるばかりでなく、スクラッチの開発から、Salesforce以外のSaaSの移行に関わったエンジニアも多く、お客様の要望やシステムフェーズに合わせた対応もできます。Salesforce社のサービスのご活用について、お悩みがある方はぜひラックにご相談ください。