データ処理契約:ベンダーを切り替えると何が変わるのか
位置データのベンダーの切り替えは、技術的な判断だけではありません。移行にあたって、データ処理とプライバシーの面で確認すべき点を紹介します。
ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ZapierやMakeで構築された自動化には、より大きなワークフローの中にジオコーディングのステップが組み込まれていることがよくあります。フォームから新しいリードが届き、担当地域の割り当てを確認するためにその住所がジオコーディングされ、その結果がチェーンのさらに先でルーティングの判断をトリガーする、といった具合です。こうしたワークフローは、ソフトウェアエンジニアリングの経験がない人によって、その時点でプラットフォームが提供していた既製のアプリコネクターや汎用HTTPモジュールを使って構築されていることが多く、そのため移行の実際の姿は、独自のコードベースの場合とは異なります。
現在のジオコーディングのステップが専用のアプリコネクター、つまりZapierやMakeがそのプロバイダー専用に構築したファーストパーティの連携を使っている場合、同等の専用コネクターがないプロバイダーに移行するには、そのステップを汎用のHTTPモジュールやWebhookモジュールに切り替え、新しいプロバイダーのAPIを直接呼び出すように設定する必要があります。これは単なる認証情報の入れ替えではなく、自動化の構築方法そのものの実質的な変更です。事業の他の部分が依存している本番稼働中の自動化に手を加える前に、隔離されたテスト用シナリオで代替のステップを十分にテストする価値があります。
この切り替えの具体的な手順は次のとおりです。
- 既存の自動化をその場で編集するのではなく、プラットフォームのビルダーで既存の自動化を複製します。こうすれば、代替のバージョンが十分にテストされるまで、動作中のバージョンが稼働し続けます
- ジオコーディングのステップを汎用HTTPモジュールに置き換え、新しいプロバイダーのエンドポイントと認証情報で設定します。クエリパラメータのキーや
Authorization: Bearerヘッダー(どちらもここでサポートされています)は、専用のコネクターがなくても汎用HTTPモジュールで簡単に設定できます - 自動化のデータマッピングのステップでレスポンスのフィールドを手動でマッピングします。汎用HTTPモジュールは生のレスポンスデータを返すため、多くの場合このマッピングを自動で行ってくれる専用コネクターとは異なり、自動化の後続ステップが想定するフィールドに明示的にマッピングする必要があります
- 一部だけの住所や珍しい書式などのエッジケースを含め、さまざまな実際の入力でテストします。スクリプトのように「コード」そのものをレビューのために見ることができないノーコードツールでは、まさにこの種のテストを省略しがちだからです
- トリガーをテスト版から、複製して検証済みの自動化に切り替えます。そして、新しい自動化が本番データでしばらく正しく動作していることを確認してから、はじめて元の自動化を無効にします
互換ホストはなじみのあるプロバイダーのレスポンス形式をそのまま再現するため、元の自動化のジオコーディングのステップが、たまたまここに対応する互換ホストがあるプロバイダーを呼び出していた場合、上記の手順3のフィールドマッピングは、元のコネクターが内部ですでに使っていたマッピングとよく似たものになる可能性があり、この移行を大幅に短縮できることがあります。互換ホストの全一覧は/compatibility/にあります。フィールドマッピングを一から作る必要があると決めつける前に確認する価値があります。
事業にとって重要な自動化では、本番環境を直接編集するのではなく複製でテストするという慎重さは、わずかな追加の準備時間をかける価値があります。リードのルーティングを行う自動化が壊れると、すぐに、しかも技術チーム以外の人に気づかれがちだからです。