ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
独自形式に縛られていることを示す警告サイン
ロックインが1つの決定でやってくることはめったにありません。便利な近道を1つずつ積み重ねるうちに徐々に蓄積し、ある1社のプロバイダーとの妥当な連携として始まったコードベースが、いつの間にかそのプロバイダーから切り離すこと自体が難しいものになってしまうのです。いくつかの具体的なパターンは、警告サインとして認識しておく価値があります。どれも、起きた時点では1つ1つが無害に見えるからです。
プロバイダーのフィールド名が、自社のデータモデル全体でそのまま使われている。データベースのスキーマ、社内APIのレスポンス、フロントエンドのコードがすべて、境界で一度だけ変換した自社独自の命名ではなく、特定のプロバイダーのフィールド名(formatted_address、display_name、あるいはそのプロバイダーがたまたま付けた何らかの名前)を使っているなら、アプリケーションのすべての層が、その1社のベンダーの慣習への依存を取り込んでしまっています。
プロバイダー固有のクセへの対処が、連携の境界で隔離されず、ビジネスロジックの中にコーディングされている。あるプロバイダーが特殊なケースの住所をどう整形するかというクセへの回避策が、そのプロバイダーと通信する限定的な関数の中ではなく、一般的なビジネスロジックの中にあると、移行する際には、見た目上ジオコーディングとは何の関係もないコードの中からその回避策を探し出し、解きほぐさなければなりません。
コードベースの中でプロバイダーを名前で参照している箇所がいくつあるか、誰もすぐに答えられない。「どこでこのベンダーに依存しているのか」に答えるのに、すぐに自信を持って答えるのではなく入念な監査が必要なら、その不確かさ自体がロックインの兆候です。誰かが積極的に追跡してきた範囲よりも、依存が広がってしまっていることを意味するからです。
クライアントライブラリ固有のオブジェクト型が、コードの他の場所で関数シグネチャとして使われている。ジオコーディングと無関係な関数が、特定のプロバイダーのSDKのレスポンス型を引数として受け取っているなら、そのプロバイダーの型システムは事実上アプリケーション自身の型システムの一部になっています。それを取り除くには、ジオコーディングのコードだけでなく、その型を参照するすべての関数に手を入れる必要があります。
連携が稼働してからの数年間、移行を一度も、部分的にさえテストしたことがない。理論上は別のプロバイダーに移行できても、実際に一度も試したことのない連携は、誰かが実際にテストするまでは、実務上まったく移行できない連携と大きな違いはありません。
これらのパターンは、どれもそれだけで致命的なものではなく、ほとんどの連携は少なくとも1つを抱えたまま、長いあいだ実害なく動いています。これらを認識する価値は、ロックインを誰も選んでいない偶発的なものではなく、意図的で許容できるトレードオフにできる点にあります。利便性が結合度に見合うこともあります。特に小規模なプロジェクトでは、完全な移行にかかるエンジニアリングの時間が、柔軟性の価値を上回ることがあります。問題になるのは、ロックインが目に見えないまま進み、事前に認識して意図的に受け入れるのではなく、期限付きの強制的な移行の最中という最悪のタイミングで発覚する場合だけです。
現在依存しているプロバイダーの互換ホストがすでに存在するなら、このリスクの一部は自然に低くなります。17の互換ホストがあるということは、少なくとも1つの有力な移行経路では、フィールドレベルのロックインを解きほぐす必要がまったくなく、ホストとキーを変更するだけで済むことを意味するからです。すぐに移行する予定のない連携であっても、備えておくのに妥当な保険と言えます。