先日とある講演を聞いた際に、「ベンダーロックインを避けるため」という言葉を耳にしました。 発表の流れもありましたが、この言葉にとても違和感を覚えました。
IT業界で開発や構築に携わっている方であればよく聞くこの言葉。では、どれだけベンダーロックインを避ける必要があるのでしょうか？

まず、ベンダーロックインなどのいわゆるロックインの文脈で重要なのが「移植性」です。 つまり、使用している技術やサービスを変更したとしても容易に動かせるかどうかという話です。
どういう時にこの移植の話になるのでしょうか？考えられるケースとしては、サービスの終了、制限や限界、サポート切れ、利用料の高騰、サービスを知っている人がいなくなった、などが挙げられます。 しかし、面白いことにこれらは直近の話ではなく、少し先の未来の話です。
つまり、ロックインを避けるというのは、いつか起きるかもしれない未来に対する投資ということです。 それが割に合う選択なのか？という疑問を持つ必要があるはずです。その疑問を持たずに、ただ避けるという選択をするのはよくないです。
同じ話で、業界標準だからいいというわけではありません。そのサービスがシステムに合っていないのに業界標準という理由で選定するのはロックインを避けているのと同じです。

次に、プロダクトのターニングポイントです。
世の中の作られたプロダクトの多くは、ほとんどが使われず終わります。 また、使われているけど大してメンテされず動いているものも多いです。 なら、ちゃんとメンテされているプロダクトはずっと生き続けるのかというとそんなことはないです。 ライブラリやサービスのサポート切れや、今の業務に合わないことや、規模に対してスケールしないなど様々な理由で、捨ててリプレイスされることは多いです。
つまり、ほとんどのサービスは生きるだけで精一杯なのです。サービスを変更するほど長生きした先を考えるよりも、目の前の開発しやすさや、保守しやすさを重視した選択を取るべきです。

使用している特定のサービスだけボトルネックになっていて、これを変更したら改善されるかも？というケースもあり得ます。 しかし、それで改善されるケースは局所的なことが多く、全体を改善するために特定のサービスを変更するとなると、どうしても大掛かりな変更になります。 実際、サービスの変更は大体ちゃんと予算確保しますし、テストもしっかりします。基本そんなに気軽に変更しないです。 ちゃんと準備しますし、承認や確認の嵐です。
もしロックインからのサービス変更での工数拡大が心配で、今その分、初期開発の工数をかけるというのなら、そもそも、サービス変更には工数をかけるものだから今そんなに心配しなくてもいいと思います。

結局は「ロックインを避ける」というのもトレードオフの一つです。それは、銀の弾丸でもベストプラクティスでもなく、ただの選択肢なんだというのが僕の考えです。
もちろん、同じような選択肢の最後の一押しとして、「ロックインを避けられるから」というのはあると思います。でも、ほとんどのケースでもっと色々な違いがあるので、それで決定することがあるなら、もうちょっと考えた方がいいかも、と立ち止まるべきなんじゃないかと思います。