技術記事
Perfex CRMからの移行が、行を単純にコピーするのではなく、識別子を照合し例外を報告することを意味した理由。
自らを単純なコピー操作——古い行を読み込み、新しい行を書き込む——として扱うレガシーデータ移行は、実際には完了していないのに完了したように見えてしまいます。長年稼働してきたレガシーのPerfex CRM環境からのOmnitech CRMの移行は、これとは異なる前提のもとに設計されました。すなわち、レガシーデータの移行とは照合(リコンサイル)の問題であり、移行の役割は何を移したかだけでなく、何を解決できなかったかを明確に示すことにある、という前提です。
実績の読み方
レガシーシステムの識別子、関連関係、アクセスルールは、異なる前提のもとに構築された新しいスキーマにきれいに対応することはほとんどありません。行をそのままコピーすると、新しいスキーマが旧システムの不整合を引き継ぐか、当てはまらないレコードが黙って欠落するかのいずれかになります。CRM移行における黙った欠落は、顧客レコードの消失や、担当者不在のサポートチケットを意味しかねません。照合とは、移行処理がレガシーの識別子を新しいスキーマに対して能動的に突き合わせ、その一致を自動的に行っても安全かどうかをレコードごとに判断することを意味します。
実績の読み方
Omnitech CRMの移行処理はトランザクション的かつ冪等です。途中で失敗しても移行先データベースが中途半端な状態のまま残ることはなく、同じ移行ステップをすでに移行済みのレコードを重複させることなく安全に再実行できます。これは、信頼性の高いAPI設計全般で用いられているのと同じ冪等性の規律を反映したものです——Laravelのデータベーストランザクション処理が、複数ステップからなる移行ステップをアトミックにするための具体的な仕組みとして用いられています(下記に引用)。
実績の読み方
この移行処理は、確信を持って照合できないレコードを推測で処理して先に進むのではなく、明示的に報告します。この報告こそが、照合を最優先する移行の本当の成果物です——不明な数の見えないデータ問題を、既知でレビュー可能なリストに変えるのです。移行元のPerfex CRM環境にあった8つのレガシーロールすべてを保持したことも、同じ原則に従っています。ロール定義は破棄して作り直すのではなく、新しい権限システムに対して照合され、その結果、既存スタッフのアクセスルールは黙ってリセットされることなく引き継がれました。
実績の読み方
レガシー移行が完了したと言えるのは、行数が一致したときではなく、何を移行し、何を自動的には解決できず、何について人間の判断が必要かを正確に示せたときです。この基準は、レガシーシステムがCRMであれ、ECプラットフォームであれ、十年分のスプレッドシートであれ変わりません。静かなデータ損失を実際に防ぐのは、より大がかりなインポートスクリプトではなく、照合結果の報告なのです。
リファレンス
Written by
AI/MLアーキテクチャ、技術戦略、プラットフォームアーキテクチャ、エンジニアリングリーダーシップ、システムインテグレーション、セルフホスト型AI。
同じような課題を抱えていますか？
プラットフォームの変更が遅く、危険になってきたSaaS創業者・エンジニアリング責任者向け。
アセスメントを依頼するLet's build what's next
アイデアの段階でも、既存プラットフォームの刷新でも、システムの拡張でも、まずはご相談ください。
Better Technology.
Brighter Possibilities.
