ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
プロバイダーの予告期間が移行にとって意味すること
プロバイダーの告知期間、つまり非推奨化や提供終了が発表されてから実際に発効するまでの期間は、強制的な移行において最も価値がありながら、最もよく無駄にされる資源の1つです。これは連携しているチームが秩序立って対応する時間を確保するためにこそ存在しますが、それでも驚くほど多くの移行が、結局は最後の数日で慌ただしく行われています。告知期間の最初の数週間は、期限が現実味を帯びる前に、他の優先事項に費やされがちだからです。
根本的な誤りは、遠い期限を期限がないのと同じように扱うことです。数か月の告知期間は、最初のうちは、都合のよいときにいつでも移行を計画できる十分な時間があるように見えます。しかし、都合のよい状態が長く続くことはめったにありません。他の仕事はそれぞれの都合でやって来続けますし、十分に先だと感じていた期限は、ある時点で一気に差し迫ったものになるものです。
告知期間のよりよい使い方は、「時間は十分にある」ところから始めてスケジュールを他のことで埋めてしまうのではなく、実際の締め切り日から逆算し、移行に本当に必要なレビューとテストの時間を組み込むことです。数か月の告知期間であれば、妥当な内訳は次のようになるでしょう。
- 期間の最初の4分の1:非推奨となるサービスに依存しているものの全体像を評価し、すべての呼び出し箇所を洗い出し、代替を選ぶ
- 中間の2分の1:エラー処理、割り当ての挙動、自社データ特有のエッジケースを含め、代替の連携を構築してテストする
- 最後の4分の1:可能であれば両方のプロバイダーを並行して稼働させ、食い違いを監視し、期限ぎりぎりではなく、バッファとして実際に時間を残した状態で切り替えを完了する
この構成では、告知期間の最後の部分を実際の作業を行う期間としてではなく、避けられない遅れのためのバッファとして扱います。慌ただしい移行がうまくいかなくなるのは、たいていこの部分だからです。
非推奨となるプロバイダーの互換ホストが存在するなら、中間フェーズ、つまり代替の連携の構築とテストが実際にどれだけ必要かが変わります。対応する互換ホストがあれば、アプリケーションがすでに持っているレスポンスの解析コードを書き直す必要はまったくなく、新しい認証情報で新しいホストに向けるだけで済むからです。My Geocodeの17の互換ホストは/compatibility/に一覧があり、かなりの範囲のプロバイダーについてまさにこのシナリオをカバーしています。互換ホストがあれば不要になるかもしれない解析ロジックの一からの書き直しにエンジニアリングの時間を投じる前に、告知期間の早い段階、まさに評価の段階でこの一覧を確認しておく価値があります。
実際のスケジュールがどうなるにせよ、最も重要な規律は、期限が近いと感じ始めた週ではなく、告知が届いたその日に評価フェーズを始めることです。