乗り換えられる設計に、いくら払うか。クラウドの独自機能を避ける前に試したい「出口」

あるクラウドの管理サービスを使えば、運用の多くを任せられる。しかし設計審査では「他社へ移せなくなるから採用しない」と言われる。そこで共通機能だけで作り直し、運用手順と監視を自分たちで用意する。移りやすさは得られても、開発期間と日々の作業が増えたとしたら、その選択は得だったのだろうか。

ベンダーロックインは、依存があるかないかの二択ではない。何に依存し、離れるときにどの作業が必要になるかという問題だ。どこでも動くという説明も、実際にデータを移し、必要な性能と運用を再現できなければ、出口の証拠にはならない。

本稿では、独自機能の便益が大きく、必要なときに許容できる時間と費用で離れられる範囲では依存を受け入れる。出口が事業上の期限に間に合わない重要部分は、分離や移植性へ先に投資するという選び方を提案する。

独自機能を避けることにも、費用がある

英国政府のクラウド指針は、技術的な依存を完全には避けられないとし、管理サービスの便益と乗換えの難しさを比較するよう勧める。特定事業者への依存が運用負担を下げる場合もあるという立場だ。英国の公共調達・サービス開発向け指針で、日本企業の採用効果を測った実験ではない。GOV.UK「Managing technical lock-in in the cloud」

例えば、監視、バックアップ、更新作業をサービス側へ任せる場合、その分の社内作業が減る可能性がある。独自機能を使わない案を比較するなら、製品利用料だけでなく、その作業を誰が行い、どの時間を使うかまで入れる。

一方、「任せられる」と「自社の責任がなくなる」は別である。データの扱い、利用者への約束、設定や契約の判断は残る。削減できる作業を具体化せず、管理サービスだから安いと見積もることも避けたい。

ここでの選択は、依存をゼロにするための技術的な美しさではなく、現在の仕事をどれだけ減らし、将来の変更をどれだけ難しくするかの比較になる。

市場の障壁と、自社の便益を同じ結論にしない

英国CMAの2025年のクラウド市場調査の最終報告は、乗換えや複数クラウドの利用に関する技術的・商業的な障壁を扱っている。英国の市場を対象とした競争当局の調査であり、個々の企業が複数クラウドへ移れば必ず利益が増えるという実証ではない。CMA「Cloud services market investigation・Final decision report」

前の政府指針と、これは矛盾するとは限らない。独自サービスに利用上の便益があることと、離れる際の障壁が競争を弱め得ることは同時に成立する。前者だけで出口を無視することも、後者だけで全機能の共通化を正解とすることもできない。

企業の判断に引き戻すには、契約、データ、実行環境、運用知識を分けたい。解約が可能でも、データを取り出して使える形に戻す作業が重ければ移れない。プログラムが動いても、障害時の操作を誰も知らなければ本番を引き受けられない。

料金条件や転送料の扱いは変更され得るため、過去の一般論を現在の自社契約へ当てはめない。評価時点の契約条件と、必要な移行作業を分けて確認することが必要になる。

出口を「全システムの移行計画」にしない

乗換え可能性を確かめるため、最初から別クラウドへ同じ構成を全部作る必要があるとは限らない。価値が大きい確認箇所へ絞ることができる。

本稿の提案では、まず事業を続けるために不可欠なデータを取り出し、別の環境で読めるかを試す。次に、重要な処理を一つ移し、結果と性能を確かめる。その後に監視、権限、障害対応を含めて運用できるかを確認する。順序は一律の標準ではなく、失うと困るものから試すための整理だ。

「CSVで出せる」という説明だけでは、添付資料や変更履歴、データ同士の関係まで再現できるとは限らない。また、取り出すことに成功しても、稼働を止められる時間内に全量を移せるかは別の確認になる。

出口の試行で想定より手間がかかったなら、それ自体が成果である。移りやすいという前提を訂正し、どの部分を分離すれば費用が下がるかを具体化できる。乗換えを実行することだけが出口検証の目的ではない。

同じ独自機能でも、採否が逆転する場面

仮に、社内向けの小さな分析サービスを考える。データは毎日、別環境でも読める形で保存され、処理は数日で再構築できる。独自機能により日々の運用作業を大きく減らせるなら、その依存を受け入れる案には理由がある。必要な期間は説明用の仮定であり、製品の移行性能を示した値ではない。

条件を変え、その処理が全社の受注に組み込まれ、短い停止しか認められない場合はどうか。取り出したデータだけでは履歴を再現できず、代替処理の性能も分からないなら、同じ便益があっても依存を広げる前の準備が必要になる。データの境界を分ける、重要な処理だけを別方式にする、移行に必要な時間を検証するなどの案を比較する。

さらに契約終了の時期が既に決まっているなら、出口の費用は遠い将来の可能性ではない。現在の独自機能を増やすほど終了時の作業が増える場合、短期の開発速度だけで採用を決めにくい。逆に、出口を試して十分短い期間で移せると分かれば、独自機能を使える範囲が広がる。

複数クラウドなら、自由になるのか

事業者が二社になっても、両社を結ぶ自作の仕組みへ依存することはある。監視画面、権限管理、費用の集計が二つに増え、双方に詳しい人が必要になる。複数化は依存をなくす魔法ではない。

一方、停止への備えや契約上の条件から、複数環境を維持する価値がある場合もある。そのときは乗換え可能性と、障害時に別環境へ切り替える能力を分ける。数か月かけて移れることは、障害の最中に数分で切り替えられることを意味しない。

比較表には、通常時の費用、出口を維持する費用、実際に移る費用を別々に載せたい。複数環境を常時動かす案と、データと手順を保管して必要時に再構築する案では、得る能力も支払う費用も違う。何に備える投資なのかを先に決める。

出口の検証結果には、成功した部分と未確認の部分を併記する。小さなデータで処理が動いても、全量の移送、並行運用中の更新、移行後の権限までは試していないかもしれない。「移行できた」という一つの印で終えず、どの条件を変えると再試験が必要かを残す。

費用の比較期間もそろえる。初年度の利用料の安さと、複数年分の移植性対策費をそのまま比べれば、採用案へ有利な表になる。反対に、使う予定のない代替環境を永久に維持する前提なら、出口を過大評価し得る。契約終了が既知なのか、将来の選択肢を残したいのかによって、必要な準備を分ける。

「いつか移れる」を、見直せる条件に変える

採用後も、依存は増える。新機能、蓄積データ、独自の認証や運用手順が加われば、当初の移行見積もりは古くなる。すべてを毎月移し直すのではなく、重要な機能追加や契約更新時に、出口の費用と時間を見直す運用が考えられる。

出口の担当を一人に固定し、その人しか復元できない状態にするのも危うい。手順から別の担当者が作業できるかを確認すれば、製品への依存と、社内の知識の偏りを別々に改善できる。

乗換え可能性は、すべての独自機能を避けることで得るものとは限らない。重要な出口を実際に試し、現在の便益と将来の変更費用を比べる。 その上で依存する部分を選べば、移りやすさに払い過ぎることと、移れないまま利用を広げることの両方を避けやすくなる。