判断の出発点
同期は最新の行を複製することではなく、情報の意味を保つことです。各項目をどちらが管理し、利用者がどこで変更できるかを定めます。双方向に書く前に照合と削除の規則を決めます。
具体例で考える
架空の営業業務で担当営業はCRM、請求先住所は請求システムが管理します。顧客がメールを変更する間に営業が電話番号を変えた場合、行全体の上書きでは正しい変更を失います。項目ごとの責任と版の確認で扱いを明示します。
選択肢とその負担
責任が明確なら片方向は単純です。実際に双方で編集するなら双方向が役立ちますが競合を扱います。時刻だけでは意味を判断できない項目は、後勝ちより確認キューが適する場合があります。
見落としやすい点
変更や共有のあるメールを無条件で永続IDにしないことです。保管停止と削除を区別し、相手の複製を新更新と認識して無限に往復しないようにします。
二つの正当な更新が衝突する場合を定める
ポータルのメール変更と営業の電話変更では、項目の版と発生元を残します。所有ルールが許せば両方を保持します。同じ旧版から同じ項目が変わったら双方の候補を残し、明示規則で処理します。端末の時計が違う場合など、時刻だけでは権限を表せません。
旧値、候補、発生元、関連活動を確認者に示します。効果を理解してから承認させ、名前が似るだけで自動統合しません。固定識別子と明確な対応は、変えられるメールより信頼できます。統合承認者と、活動、添付、会社関係を残る識別子へ移す方法を決めます。
訂正と削除を追跡可能にする
互いのコピーを新規編集と扱うと循環します。変更識別子と発生元を保持し、再通知前に意味のある値を比較します。空白や同等の電話表記を試し、マッピング規則を版管理します。全件の書式変更が大量の業務更新に見える事態を避けます。
保存終了、統合、消去は適用方針に沿った別のイベントです。古い取込みやバックアップで削除が復活しないよう、必要なら余分な個人情報のない非公開削除記録などを用います。大量書込み前に統合、権限変更、中断復旧を練習します。CRM管理者が意味とアクセスを、連携担当が転送と未解決作業の証拠を管理します。
依頼前に確認すること
競合を誰が解くか。両方の値と由来を確認できるか。統合時に関連活動はどうなるか。大量同期の前に重複と削除の例を連携の検討へ持ち込みます。