Mistake #39 : Vendor Lock-in

ホテル・カリフォルニア

「いつでもチェックインできるが、二度と出ることはできない」。
便利な独自機能(SaaS)を使えば使うほど、あなたは自由を失っていきます。
ある日、支配人(クラウドベンダー)が「来月から宿泊費を3倍にします」と言った時。
あなたは笑顔で「Yes」と言うしかありません。

🏨 監禁状態診断
  • 特定のクラウド独自のDB(DynamoDBやFirestore等)にビジネスロジックが依存している
  • 「他社へ移行するより、値上げを受け入れた方がマシ」と諦めている
  • プロプライエタリな(独自仕様の)APIを大量に使っており、標準規格を知らない
  • そのツールがサービス終了したら、自社のビジネスも終了する
⚠️ 警告:あなたは顧客ではなく「囚人」です。
あなたのビジネスの生殺与奪の権を、他社に握られています。

01. 甘い罠

Hotel Vendor-Lock
"You can check out any time you like,
but you can never leave!"

クラウドベンダーは、魅力的で簡単な独自機能を提供してくれます。
「コードを書かずに認証機能が作れます」「ボタン一つでAI解析ができます」。
開発初期、これは魔法のように見えます。開発工数が劇的に下がるからです。
しかし、その「魔法」を使いすぎると、コードは標準的な構成から離れ、
そのベンダーの環境でしか動かない「キメラ」と化します。

楽(ラク)をした分だけ、
後で高い利子を払うことになる。
それがロックインの契約書だ。

02. 3倍の値上げ通告

ある日突然、ベンダーの方針が変わります。
無料プランの廃止、APIの仕様変更、あるいは大幅な値上げ。
「嫌なら他へどうぞ」と言われますが、もう移行できません。
データを吸い出すのに莫大なコストがかかるか、あるいは独自形式すぎて変換できないからです。
あなたは文句を言いながら、高い請求書を払い続けることになります。

03. 出口戦略を持つ

ロックインを完全に避けることは不可能ですし、避けるべきでもありません(独自のメリットも大きいため)。
重要なのは「いざという時に逃げられるか(Exit Strategy)」です。
可能な限り、コンテナ(Docker)や標準規格(SQL、OIDCなど)を使いましょう。
「ここを使っているが、いつでも他へ移れる」という状態こそが、
ベンダーとの対等な交渉力を生むのです。

執筆:IT調達・購買戦略室

特定のベンダーに依存しない「マルチクラウド戦略」の策定者。
TCO(総保有コスト)を監視し、常に最適なインフラを選定し続ける。