data import wizard で実際にやらかした判断、それは初期フェーズで「この程度のデータ量なら、手軽にGUIでサクッと終わらせよう」と安易に判断し、プロジェクトメンバーにもその選択肢を提示してしまったことです。
当時、ある新規Salesforce導入プロジェクトのアーキテクトとして参画していました。初期のデータ移行対象は、ごく少量のマスターデータ（部署マスタ、ユーザーマスタなど、数千件レベル）と、一部の既存契約データ（数万件程度）でした。Salesforceに不慣れなメンバーが多かったこともあり、「まずは慣れてもらうためにも、シンプルにData Import Wizard (DIW) を使ってみましょう」と提案しました。Data Loaderはもう少し学習コストがかかるし、ましてや外部ETLツールの導入なんて、この段階ではオーバーストップだと考えていたのです。この判断が、後々大きな後悔につながります。
DIWの利用当初は、確かにスムーズでした。単一オブジェクトへの数千件のインポートは数分で終わり、エラーも少なく、非開発者でも直感的に操作できるため、メンバーの受けも良かった。「よし、これでいけるぞ」と、当時はそう思ったものです。
しかし、プロジェクトが進むにつれて、データ移行のスコープと複雑性が増していきました。
まず、対象レコード数の増加です。初期の見込みよりもはるかに多くの履歴データや、途中で追加された関連オブジェクトのデータも移行対象となりました。特に、取引先（Account）と取引先責任者（Contact）は初期段階で数万件だったものが、本番移行のフェーズでは数十万件に膨れ上がりました。DIWは50,000レコードという制限がありますが、これが明確に問題として浮上しました。
具体的にやらかしたのは、あるカスタムオブジェクトの履歴データ移行です。初期には約3万件と見積もっていたため、DIWで十分と考えていました。しかし、データクレンジングを進める中で、実は過去10年分のデータが必要だという要件が浮上し、最終的に約15万件にまで膨らんでしまったのです。
「まさかこんなに増えるとは」と思いながらも、当初の「DIWでやろう」という流れを変えるのは手間だと感じ、CSVを数回に分割してDIWでインポートしようと試みました。これが地獄の始まりでした。
- まず、5万件ギリギリのファイルをDIWでアップロードすると、進捗状況が見えにくく、途中でフリーズしたのか、本当に処理しているのか判別がつきませんでした。
- 処理が終わったと思っても、インポートされたレコード数が指定したCSVの行数と合わないことが頻繁に発生しました。
- エラーファイルが出力されても、エラーメッセージが抽象的で、「インポートに失敗しました」としか表示されない行が多く、具体的な原因特定に時間がかかりました。特に、参照整合性エラーや重複エラーは、DIWの画面上では分かりにくく、CSVファイルを何度も修正しては再アップロードする手間が発生しました。
- 複数オブジェクトにまたがるデータは、依存関係（親オブジェクトを先にインポートし、そのレコードIDを使って子オブジェクトを関連付ける）が複雑になり、DIWのGUIだけでは管理しきれなくなりました。特に外部IDを使った参照更新は、DIWでも可能ですが、複数のファイルを跨いだ整合性の確認やエラー時のリカバリは絶望的に手間でした。
この履歴データ移行だけで、当初の見込みの3倍以上の時間を費やしてしまいました。手動でCSVを分割し、エラーを見つけ、修正し、再アップロードする作業の繰り返し。この時、「なぜ最初からData Loaderや、もっと言えば簡単なETLツールを使わなかったんだ」と、自分の判断を深く後悔しました。
アーキテクトとして、初期の「手軽さ」や「学習コストの低さ」だけを重視し、将来的なデータ量の増加、複雑性の増大、そして自動化や再実行性への考慮が甘かったと痛感しています。プロジェクト初期の段階で、データ移行の要件をより深く掘り下げ、今後の規模拡大や継続的なデータ連携の可能性を考慮し、Data LoaderまたはETLツールの導入を強く推奨すべきでした。一度「これでいける」と決めてしまうと、後から方針転換するコストは想像以上に大きいものです。
今なら、少しでも「繰り返しの可能性があるデータ投入」「5,000件を超えるデータ量」「複数のオブジェクトを跨ぐ関連付け」が見えた時点で、DIWの利用は避ける判断をします。
これは当時の自分向けのメモだ。
コメント
コメントを投稿