Dynamics 365 Finance and Operations（F&O）とDataverse上のCustomer Engagementアプリを両方使っている企業から、最近よく相談されるのが「dual-write」の移行設計です。名前の響きから単純なデータ連携の仕組みに思えますが、実際に本番カットオーバーの計画を立てる段階になると、想像以上に検討事項が多いことに気づきます。
dual-writeは「双方向」であることを前提に設計する
まず押さえておきたいのは、dual-writeが一方向のエクスポートではなく、F&OとDataverse間でほぼリアルタイムに双方向同期される仕組みだという点です。プランニングの現場でよくある誤解が「F&Oからのデータをただ一度きりエクスポートし、あとは手動で更新すればいい」というものですが、これは半分しか正しくありません。片方の変更はもう片方にも伝播するため、一方向の仕組みとして設計してしまうと、想定外のタイミングでデータが上書きされるといった事故につながります。
もう一つ重要なのが、「どちらのシステムが何の意思決定における正とするか」を明確にすることです。フィールドが両方のシステムに技術的に存在していても、それを両方が管理すべきとは限りません。与信限度額、商品属性、価格、顧客分類、出荷状況、ベンダー情報など、プロセスごとにどちらが正とするかを事前に定義しておく必要があります。
ダウンタイムを避けるカットオーバー戦略
カットオーバーで特に注意すべきは、データ移行とdual-writeの初期同期（Initial Write）を混同しないことです。Initial Writeは低ボリュームの初期データ作成には向いていますが、データ移行の代替として使うべきではありません。数十万〜数百万件規模のデータがある場合は、dual-writeを有効化する前に、それぞれのアプリへ個別にデータを移行しておくのが基本です。
実務での進め方としては、まずカットオーバーウィンドウの外でデータ移行を完了させ、企業情報などのマスターデータをDataverse側に用意しておきます。その上でdual-writeのマッピングを有効化し、実行中のマッピングは絶対に「一時停止」ではなく「停止」してから変更する、という運用ルールを徹底することが重要です。マッピングを一時停止のまま24時間以上放置すると、キューレコードのエラーが発生することが知られています。
よくある落とし穴
標準マッピングを安易にカスタマイズしすぎるのも典型的な失敗パターンです。Microsoftは列マッピングのカスタマイズ、変換、フィルタを許可していますが、変更は慎重に行う必要があります。また、CEのオプションセットとF&Oの列挙型（enum）が正しく対応しているか、価格・取引先番号のようなキーがどちらのシステムを起点に採番されるかを、実装前に決めておかないと、後から競合する番号が生成されてしまうといった問題が発生します。
私たちSapotaCorpのチームも、X++でのF&O拡張開発からdual-writeの設計、複数国展開のロールアウトまで、Dynamics 365案件を数多く手がけてきました。カットオーバー計画を「金曜日の午後にマッピングを流すだけ」で済ませず、システム・オブ・デシジョンの定義から逆算して設計する、という進め方を徹底しているのは、過去の案件で番号採番の競合やデータ不整合に苦労した経験があるからです。詳しい実装パターンはSapotaCorpのDynamics 365ページにまとめています。
まとめ
dual-writeは「設定すれば動く」ツールではなく、業務プロセスごとに正のシステムを決める設計作業そのものです。カットオーバー前のデータ移行計画と、マッピング停止時の運用ルールさえ押さえておけば、ダウンタイムを最小限に抑えた移行が可能になります。
D365のカットオーバー計画や既存dual-write構成の見直しについて相談したい方は、SapotaCorpまでお気軽にご連絡ください。