Dry Runで安全に本番投入する手順

はじめに

本番のCRMにいきなり大量のDealを書き込む——想像するだけで少し緊張しませんか。
マッピングにミスがあれば、誤ったDealが何百件も作られてしまうかもしれません。

そこで私が取り入れたのが**Dry Run（ドライラン）**という考え方です。実際には書き込まず、「何が起きるか」だけを先に確認する。この一手間があるだけで、本番投入の安心感がまるで違うんです。この記事では、その仕組みと運用手順を解説します。

Dry Runとは何か

「書かずに確認する」モード

Dry Runは、同期処理を最後まで走らせるものの、CRMへの書き込みだけを行わないモードです。取引の取得、名寄せ、Deal・LineItemへの変換までは通常どおり実行し、「本番なら作成・更新されるはずの内容」をレポートとして出力します。

つまり、本番と同じ道のりをたどりながら、最後の一歩だけ踏み込まない。これが安全確認の肝になります。

なぜ必要なのか

同期のバグは、往々にして「実データを流して初めて」見つかります。テスト環境では気づかなかった表記ゆれや、想定外の店舗コード、名寄せの取りこぼしなどです。

Dry Runで何を確認するか

作成・更新の件数と内訳

Dry Runのレポートでは、まず全体の件数感を確認します。「新規Contactが何件、既存への紐づけが何件、Dealが何件作られるか」——この数字が想定と大きくずれていたら、どこかにミスがあるサインです。

特に「新規Contactが想定より極端に多い」ときは、名寄せキーがうまく効いていない可能性が高く、要注意です。

名寄せとOwnerの妥当性

件数だけでなく、中身のサンプルも確認します。数件を抜き出して「この取引が、正しい顧客・正しい担当者に結びつくか」を目で見てチェックするんです。

名寄せは、この顧客番号のこの取引が、既存のあのContactに当たっているか。Ownerは、この店舗コードが正しい担当者に解決されているか。マッピング設計とOwnerマップが意図どおり動いているかを、本番に触れる前に確かめられます。ここで違和感があれば、マッピング設計やOwnerマップを見直します。

本番への切り替えと運用

段階的に本番投入する

Dry Runで問題がないと確認できたら、いよいよ本番です。ただ、初回はいきなり全件を流さず、期間や店舗を絞って小さく本番投入し、CRM上の結果を確認してから全体に広げると安心です。

一度で完璧を目指さず、確認しながら広げていくのが結局いちばん早く、安全でした。

日次同期と手動実行の併用

本番が安定したら、通常運用はQStash経由の日次自動同期に任せます。前日の取引を毎日取り込む形で、CRMは自動的に最新に保たれます。

あわせて手動実行も残しておきます。「特定期間を再同期したい」「取りこぼしを今すぐ埋めたい」といった場面で使えるほか、設定を変えたあとにまずDry Runで手動確認する、という使い方もできます。自動と手動、そしてDry Runと本番を切り替えられる構成にしておくと、運用の自由度が高まります。

まとめ

Dry Runは、本番CRMに触れる前に「何が起きるか」を確認できる安全網です。件数の内訳とサンプルの妥当性をチェックし、不備を直してから段階的に本番投入する——この手順を踏むだけで、大量データの同期がぐっと怖くなくなります。

Dry Runで確認するマッピングやOwnerの中身については、マッピング設計とOwnerマップ運用で詳しく解説しています。取り組み全体の狙いはハブ記事をご覧ください。