基礎知識

クラウド移行の進め方。3つの方式と、つまずきやすい点

自社の設備からクラウドへ移す。判断も作業も大がかりになる取り組みです。この記事では、どう進めるのか、どこでつまずくのかを整理します。

なぜ移行するのか

クラウド移行の動機は、企業によって異なります。主なものを挙げます。

機器の老朽化。更新の時期に、買い替えるか移行するかの判断が生じます。最も多いきっかけです。

災害対策。拠点が被災した場合の継続性。地理的に分散した構成を取りやすくなります。

柔軟性。需要の変動に応じて規模を変えられます。繁忙期だけ増やす運用が可能です。

運用負担の軽減。機器の管理、更新作業を事業者に任せられます。

「クラウドだから安い」という理由で始めると、多くの場合失望します。単純な費用比較では、必ずしも安くなりません。

移行の3つの方式

移し方には段階があります。手間と得られる効果が比例します。

• そのまま移す／構成を変えず、置き場所だけクラウドへ。最も速いが、利点も限定的
• 一部を作り替える／データベースなどをクラウドのサービスに置き換える。運用負担が減る
• 作り直す／クラウド前提の構成に設計し直す。効果は最大だが、費用と期間も最大

実務では、1つ目から始めて段階的に進めるのが一般的です。まず動かすことを優先し、その後で最適化します。

いきなり3つ目を目指す計画は、多くの場合破綻します。既存システムの理解と作り直しを同時に行うためです。

進め方の順序

実際の進行を段階で示します。

①現状の把握。何が動いているか、どこにデータがあるか、誰が使っているか。この段階で把握できていないシステムが見つかることが多くあります。

②対象の選定。すべてを一度に移さず、優先順位をつけます。影響が小さく、依存関係の少ないものから。

③移行先の設計。構成、ネットワーク、権限、監視。

④試験移行。本番と切り離した環境で動作を確認します。

⑤本番切り替え。停止できる時間帯、切り戻しの手順を決めておきます。

⑥最適化。移行後に費用と性能を見直します。

つまずきやすい点

移行が難航する典型的な原因を挙げます。

依存関係が分からない。そのシステムが何とつながっているか。資料がなく、動かして初めて判明することがあります。

古い技術が動かない。クラウド環境で動作しない、あるいは対応していない構成。作り替えが必要になります。

データ量が想定外。移すのに何日もかかる。回線の速度が制約になります。

ライセンス。ソフトウェアの利用条件が、クラウド上では異なる場合があります。

担当者がいない。作った人が退職し、仕様を知る人がいない。調査から始める必要があり、期間が読めなくなります。

移行後に起きること

移してからが本番だという点も、押さえておくべきです。

費用が想定を超える。使っていない資源、過剰な構成、通信量。移行直後は特に発生しやすくなります。

運用の方法が変わる。機器の管理は不要になりますが、代わりに設定の管理、権限の管理、費用の管理が必要になります。仕事がなくなるのではなく、内容が変わります。

止まったときの対応が違う。自社で機器を持っていれば自分で対処できますが、クラウドでは事業者の復旧を待つ場面があります。

最適化の余地が残る。そのまま移した構成は、クラウドの利点を活かしきれていません。段階的な見直しが続きます。

費用の見積もり方

移行の判断には、費用の比較が必要です。整理すべき項目を示します。

移行そのものの費用。調査、設計、作業、検証。一時的な支出です。

移行後の運用費用。月額の利用料。使用量に応じて変動します。

現状の費用。機器の減価償却、保守契約、電力、設置場所、運用の人件費。ここを正確に出せていない企業が多く、比較が成立しません。

比較の期間。3年か5年か。機器の更新周期に合わせるのが一般的です。

移行費用を含めると、短期では高くなることが普通です。長期での比較が必要になります。

移行すべきか判断する

最後に、判断の材料を整理します。

移行の効果が大きい場合。需要の変動が大きい、災害対策が必要、機器の更新時期が来ている、運用の人手が足りない。

慎重に検討すべき場合。負荷が一定で変動がない、規制でデータの所在に制約がある、既存システムが特殊な構成、社内に扱える人がいない。

すべてを移す必要はありません。一部をクラウド、一部を自社設備という構成も一般的です。

目的を明確にすることが最も重要です。「クラウド化」自体を目的にすると、費用が増えただけという結果になりかねません。

全部を移さない選択

すべてをクラウドへ移す必要はありません。併用する構成が一般的です。

移しにくいものがあります。特殊な機器と接続しているシステム、規制でデータの所在に制約があるもの、大量のデータを常時やり取りするもの。

これらは自社設備に残し、他をクラウドへ移す構成が現実的です。

注意点は、両者をつなぐ設計です。専用の接続や暗号化された通信路が必要になり、遅延の影響も検討します。

運用は二重になります。両方の知識を持つ体制が必要です。この負担を見込まずに併用を選ぶと、運用が回らなくなります。

移行後の最適化

そのまま移した状態は、出発点にすぎません。

費用の見直し。使っていない資源を止める、構成の大きさを実際の負荷に合わせる、長期利用の割引を適用する。初期の設定のままでは、確実に無駄が生じます。

可用性の向上。複数の拠点に分散する、自動で復旧する構成にする。クラウドの利点を活かせる部分です。

運用の自動化。手作業の設定をコードに置き換え、再現できる状態にします。

段階的な作り替え。効果の大きい部分から、クラウド向けの構成に変えていきます。

移行を完了と考えず、その後の改善を計画に含めるべきです。