01｜「別のクラウドに移せますか」と聞かれて
クラウドを使い始めて数年が経つと、こんな相談をいただくことがあります。
「いまのクラウドから、別のクラウドに移せますか」
理由はさまざまです。料金が上がった。別の事業者のほうが条件がよい。付き合いのある会社が違うクラウドを使っている。親会社の方針が変わった。
そして多くの場合、調べてみると思っていたより手間がかかる状態になっています。移せないわけではありません。ただ、想像していたよりも時間と費用がかかることに、そこで初めて気づくことになります。
この「乗り換えにくさ」は、ベンダーロックインと呼ばれます。避けるべきものとして語られがちですが、避けようとすると別の問題が起きます。 今回は、その点も含めて整理します。
02｜避けようとすると、かえって高くつく
まず、よくある対策から見ていきます。
「特定のクラウドに縛られないよう、複数のクラウドを併用しよう」
これはマルチクラウドと呼ばれる考え方です。理屈は通っていますが、実務では運用の負担が大きくなります。
理由は単純です。クラウドごとに、画面も用語も設定方法も違います。扱える人材をそれぞれ確保する必要があり、監視やセキュリティの仕組みも二重に持つことになります。 クラウド間をつなぐ通信にも費用がかかります。
ある調査では、ロックイン回避を目的にマルチクラウドを導入した結果、想定の2〜3倍の運用コストになっている例が少なくないと報告されています。
技術で解決しようとしても、うまくいきません。コンテナ技術を使えばどのクラウドでも動くはずだ、という考え方がありますが、各社の提供している基盤は挙動が異なり、そのまま移せるわけではないのが実情です。
移行は、起きるとしても数年に一度です。 起きるかどうかも分からないことのために、毎日の運用を複雑にするのは割に合いません。
大事なのは、依存をなくすことではなく、どういう依存をしているかを知っておくことです。
03｜3種類に分けて考える
乗り換えにくさは、大きく3つに分けられます。
| 種類 | 何が問題になるか |
|---|---|
| データ | 取り出せるか。正しく移ったか確かめられるか。いつ作業するか |
| 技術 | その事業者にしかない仕組みに合わせて作ってある |
| 契約 | 最低利用期間がある。途中解約に条件がついている |
順に見ていきます。
データの問題
保存してある情報を、そのまま新しい環境へ移せるかどうかです。独自の形式で保存されていると、他では読めません。
軽く見られがちですが、段取りを誤ると期間が延びます。 詳しくは次の章で扱います。
技術の問題
その事業者にしかない仕組みに合わせて、システムを作ってある状態です。
クラウド事業者は、便利な機能を数多く用意しています。データベース、通知、認証、画像の処理。これらを組み合わせると、短い期間で安く作れます。ただし、他社に同じものがあるとは限りません。 似た機能があっても、書き方や制約が違えば、その部分は書き換えることになります。
移行の負担が最も大きくなるのは、たいていここです。 書き換える範囲が広ければ、データの移行より、アプリケーションの改修のほうが期間も費用もかかります。
どこまで手を入れることになるかは、実際に調べてみないと分かりません。
契約の問題
最低利用期間が決まっている、途中解約に条件がある、値引きの条件として長期契約を結んでいる。こうした取り決めです。
技術的には移せても、契約が残っていて動けないことがあります。見落とされがちですが、確認は簡単です。
04｜データ移行は、段取りで決まる
3種類のうち、移行の段取りを最も左右するのがデータです。進め方を決めないと着手できないため、計画の出発点になります。
論点は3つあります。取り出せるか、確かめられるか。どこに置くか。いつ作業するか。順に見ていきます。
取り出せるか、確かめられるか
まず、書き出す機能が用意されているか。出てきたものが、他で読める形式か。いま使っているサービスの仕様を見れば分かります。
次に、移した結果を確かめられるか。移行の失敗は、動かなくなることよりも、一部だけ欠けていたり、文字が化けていたりする形で表れます。しかも、しばらく気づかないことがあります。件数や項目の値を新旧で突き合わせる手順を、移し終えてから考えるのでは間に合いません。
どこに置くか
データが国内にあるのか海外にあるのかで、扱いが変わることがあります。とくに個人情報を含む場合、保存される国によって必要な手続きが違ってきます。
移行先を選ぶときは、どの地域に置くのかも確認してください。
いつ作業するか
よくあるのは、土日などにサービスを1日止めて、その間に切り替えてしまうやり方です。分かりやすく、段取りも組みやすいため、多くの移行がこの形を取ります。
ただし、データの量が増えると成立しなくなります。 移すだけで1日では終わらなくなるためです。
量が多いと、取り出す作業そのものがシステムに負担をかけます。 当社が担当した案件では、稼働中のデータベースからデータを書き出すと、業務で使っている画面の反応が遅くなるという問題が起きました。サーバーが1台構成で、書き出しの負荷を逃がす先がなかったためです。
そこで、データを何回かに分けて移し、そのつど差分を反映していく形を取りました。移す作業は、業務への影響が小さい深夜や土日を選びます。 そして切り替え当日に、最後の差分だけを反映して移行を終えます。
図の②に近いやり方を、専用のサービスを使わずに組み立てたことになります。
通信の速さだけの問題ではありません。通信料そのものはわずかで、かかる費用の大半は作業の人件費です。 動いているシステムを止めずに移せるかどうかで、期間も金額も変わります。
移行を助ける仕組みもあります
こうした負担を軽くするために、クラウド事業者が移行専用のサービスを用意しています。 AWSのDMS（Database Migration Service）などがそれにあたります。
実務上ありがたいのは、移している最中も、元のシステムを動かし続けられることです。まず全体を移し、そのあとは変更された分だけを追いかけて反映していきます。業務を止める時間を、切り替えの瞬間だけに縮められます。
ただし、対応している組み合わせには限りがあります。移行先を検討する段階で、こうしたサービスが使えるかどうかも判断材料に入れてください。
05｜設計書よりも、ソースコードを
技術の問題は、書き換える範囲が分からないと見積もれません。ここで効いてくるのが、手元に何が残っているかです。
移行のご相談をいただくと、多くの場合に同じことが起きます。当時の設計書が見つからない。あるいは残っていても、その後の改修が反映されておらず、実物と合っていない。
システムは動いている間に何度も手が入ります。設計書を毎回直すのは手間がかかるため、更新が止まりがちです。 数年経つと、書かれている内容と実際の動きが食い違います。
こうしたとき、私たちはソースコードをお預かりして解析するところから始めます。 それも難しい場合は、データベースの構造や、外部から見える動きを手がかりにします。
ここで申し上げたいのは、設計書よりもソースコードのほうが役に立つということです。
理由は2つあります。ひとつは、ソースコードは実物そのものだからです。 設計書は書かれた時点の姿ですが、ソースコードは今動いているものと必ず一致します。
もうひとつは、AIがソースコードを読めるようになったことです。 以前は、コードから仕様を読み解く作業に熟練した技術者が数か月かけていました。いまはAIが処理の流れや構造を短期間で整理してくれます。解析にかかる期間が、大きく縮まりました。
つまり、設計書がなくても移行できる時代になりました。 ただしそれは、ソースコードが手元にあればの話です。
契約のときに、確認しておいてください
ここで気をつけていただきたいことがあります。開発を外部に委託した場合、ソースコードの著作権は、何も取り決めなければ開発した会社に残ります。 費用を負担したかどうかは関係ありません。
契約書に、成果物の著作権を譲り受ける旨が書かれているかどうかで決まります。書かれていなければ、納品されたシステムを自由に改修したり、別の会社に引き継いだりできない可能性があります。
いま動いているシステムについて、ソースコードが手元にあるか、契約上どうなっているかを確認してください。 これは移行のときだけでなく、開発会社を変えるとき、機能を追加するときにも効いてきます。
新しく開発を委託するときは、契約の段階で取り決めておいてください。 後から交渉するより、はるかに簡単です。
06｜いつ、何をしておくか
3つの種類が分かったところで、いつ何をするかを整理します。
契約する前に ── 出口を確かめておく
- データを書き出せるか。 どの形式で、どうやって出すのか
- データがどの国に保存されるか。 個人情報を扱うなら、とくに確認してください
- 解約したあと、データがいつまで残るか
- 最低利用期間はあるか
- 開発を委託するなら、ソースコードの著作権を譲り受ける取り決めがあるか
契約前なら、どれも調べられます。 後から知ると、選択肢が狭まります。
使っている間に ── 記録と把握を続ける
- どの機能を使っているか、一覧にしておく。 とくに、その事業者にしかない機能を使っている箇所
- 年に一度、実際にデータを書き出してみる
- ソースコードが手元にあるか確かめる。 改修のたびに最新のものを受け取っているか
「書き出せるはず」と思っていたものが、やってみるとできなかった、ということが起こります。バックアップの確認と同じで、試していないものは当てになりません。
移行を考えたとき ── 3つに分けて見積もる
- データは、量・形式・確かめ方を決める。 どれだけ時間がかかるか、業務を止めるか、移った結果をどう突き合わせるか
- 移行を助けるサービスが使えるか確認する。 使えれば、業務を止める時間を大きく縮められます
- 技術は、作り直す範囲を洗い出す。 ここが費用を左右します。ソースコードがあれば、この見積もりが早く正確になります
- 契約は、残りの期間と解約の条件を読む
この順で見ていくと、移行の難しさが具体的な数字になります。 「移れるか分からない」という状態から抜け出せます。
リハーサルの期間を、忘れずに見込む
移行は、多くの場合、専門の会社に任せることになります。そのとき必ず提案に含まれるのがリハーサルです。本番と同じ手順を、事前に通しで試しておくものです。
1回では終わりません。時間が見積もりと違う、想定外のデータが出てくる、手順に抜けがある。見つかったものを直して、もう一度試す。 移行を手がける会社であれば、これを複数回見込んだ計画を出してきます。
発注する側として気をつけたいのは、スケジュールの引き方です。 移行日から逆算して期間を見込んでおかないと、後から削られるのはたいていリハーサルです。
もし、リハーサルのない計画が出てきたら、理由を確認してください。 規模が小さくやり直しがきく場合もありますが、止められない業務を扱うのであれば、一度きりの移行は危険です。
07｜まとめ
クラウドの乗り換えにくさは、なくすものではなく、把握しておくものです。
起きるかどうか分からない移行のために、毎日の運用を犠牲にする必要はありません。代わりに、データ・技術・契約の3つに分けて、自社がどこで依存しているかを知っておいてください。
データは、量が増えるほど段取りが難しくなります。 業務を止めずに移す手段があるか、リハーサルの期間を見込めているか。契約は読めば分かります。
移行の負担を最も左右するのは、技術の問題です。 書き換える範囲が広ければ、アプリケーションの改修が費用も期間も押し上げます。
ここに効くのが、ソースコードを手元に持っておくことです。設計書が古くなっていても、ソースコードがあれば実物から読み解けます。AIが解析できるようになり、その作業はかつてより短い期間で済むようになりました。設計書を完璧に保つより、ソースコードを確実に持っておくほうが現実的です。
そのうえで、契約前に出口を確かめ、使っている間は記録を残し、年に一度データの書き出しを試す。この習慣は、移行しない会社にも役立ちます。 担当者が変わったときや、開発会社を変えるときに、同じものが支えになるからです。
「いま使っているクラウドから移れるだろうか」と気になったときは、まず現状を整理するところから始めてください。 移るかどうかは、そのあとで決められます。
ワイズラボでは、クラウドの構成を整理し、どこでどのように依存しているかを可視化するところからお手伝いしています。移行するかどうかを決める前の段階でも、お気軽にご相談ください。
お問い合わせはこちらから。
