「サーバールームをなくす」ロードマップ|中小企業のオンプレ脱却計画

サーバールームの維持コストは見えにくい

自社でサーバーを運用している中小企業は、目に見えるコスト(ハードウェア購入費、電気代)だけでなく、空調・UPS・ラック等の設備費、保守契約費、障害対応の人件費、BCP対策のためのバックアップサイト費用など、多くの隠れコストを負担しています。

さらに、サーバーの老朽化に伴うリプレース費用は3〜5年ごとに発生します。クラウド移行を検討するなら、このリプレース時期が最良のタイミングです。

コストの棚卸し項目

移行の判断材料として、まず現状の総額を出してください。次の項目を5年分で積み上げると、比較可能な数字になります。

分類含めるもの
ハードウェアサーバー本体、ストレージ、UPS、ラック、ネットワーク機器
ソフトウェアWindows Server / CAL、仮想化基盤、バックアップソフトのライセンス
設備専用空調の電気代、サーバー室の面積相当の賃料
保守ハード保守契約、ソフトの年間サポート、ベンダーの運用委託費
人件費障害対応、パッチ適用、バックアップ確認にかかる自社工数
リスク障害時の業務停止による損失(発生確率×影響額で概算)

見落とされやすいのは、サーバー室の賃料相当と自社の人件費です。「元々ある部屋だから」「担当者の業務のうちだから」と計上しないと、オンプレ側が実際より安く見えます。

一方で、クラウドが常に安いわけでもありません。大容量のファイルサーバーをそのままIaaSに載せると、ストレージ費用と通信費で割高になることがあります。数字を出したうえで判断してください。コスト削減が目的でなく、運用負荷の軽減とBCP強化が主目的になるケースも多くあります。

段階的にサーバールームをなくすロードマップ

ステージ0:現状の棚卸し(1〜2ヶ月)

移行計画の前に、何が動いているかを確定させます。ここを飛ばすと、移行の直前や直後に「このサーバーは何だったのか」という問題が必ず出ます。

  • 物理・仮想サーバーの一覧(用途、OS、サポート期限、利用部門)
  • 各サーバーが提供している機能と、依存関係(どのシステムがどれに繋がっているか)
  • 誰も用途を説明できないサーバーの特定
  • ライセンスの保有状況と、クラウド移行時の扱い(持ち込み可否)

用途不明のサーバーは必ず存在します。 停止して問題が起きないかを確認する期間を計画に織り込んでください。いきなり廃棄せず、一定期間停止して様子を見る手順が安全です。

ステージ1:メール・ファイルのクラウド化(3〜6ヶ月)

最もリスクが低く、効果が大きい移行対象です。オンプレミスのExchange ServerをExchange Online(M365)に、ファイルサーバーをSharePoint/OneDriveに移行します。この段階で物理サーバーの半分程度は不要にできるケースが多いです。

ファイルサーバーの移行は、容量より構造が問題になります。 そのまま移すと、深すぎる階層、長すぎるパス、権限が個人単位で付与されたフォルダがそのまま持ち込まれます。移行を機に、部門・プロジェクト単位で整理する前提で計画してください。全社で使われていない古いデータは、アーカイブとして別途保管する判断もあります。

ステージ2:業務システムのSaaS化(6〜12ヶ月)

オンプレミスで稼働している業務システム(会計、人事、販売管理等)をクラウドSaaSに置き換えます。すべてのシステムがSaaS化できるわけではないため、「SaaS化できるもの」「IaaS上に移行するもの」「オンプレに残すもの」を仕分けます。

仕分けの判断軸は次のとおりです。

  • 業務プロセスを変えられるか — SaaSは自社の運用に合わせて作り込めません。業務側の変更を受け入れられるかが最大の論点です
  • データ移行が可能か — 過去データをどこまで移すか。移行できない場合、旧システムを参照専用で残す期間が発生します
  • カスタマイズの度合い — 独自開発の機能が多いほどSaaS化は困難になります

ステージ3:残存サーバーのIaaS移行(3〜6ヶ月)

SaaS化できなかったシステム(自社開発システム、特殊なパッケージソフト等)をAzure VMやAWS EC2に移行します。リフト&シフト方式で、アプリケーションの変更なしに移行できます。

ただしリフト&シフトは「移しただけ」の状態である点に注意してください。オンプレミスの構成をそのまま持ち込むため、運用負荷(OSのパッチ適用、バックアップ、監視)は基本的に残ります。コスト面でも、常時稼働のVMは想定より高くなりがちです。移行後に、停止可能な時間帯のシャットダウンやインスタンスサイズの見直しを行う前提で計画してください。

ステージ4:サーバールームの廃止

すべてのワークロードがクラウドに移行したら、物理サーバーを廃棄し、サーバールームを別の用途に転用(または賃借面積を縮小)します。

廃棄時はデータの消去を確実に行ってください。ディスクを物理的に破壊するか、証明書が発行されるデータ消去サービスを使います。とくにサーバーには顧客情報や人事情報が残っているため、廃棄業者任せにせず、消去証明を受け取る運用にしてください。

サーバー室の解約や転用は、契約や設備工事が絡むため前倒しで動く必要があります。移行完了と同時に賃料が下がるわけではない点は、稟議上の説明で重要になります。

完全クラウド化が難しいケース

製造業の生産管理システム(工場のPLCと直接通信が必要)、特殊なハードウェアドングルが必要なソフトウェア、レイテンシが極めて低くなければならないシステムなど、オンプレに残さざるを得ないケースもあります。その場合は、ハイブリッド構成(一部オンプレ+クラウド)が現実的な解です。

このほか、次のケースでも完全な廃止が難しくなります。

  • 業務システムのベンダーがクラウド非対応 — サポート対象外になるため移行できない。ベンダーのロードマップ確認が先になります
  • 取引先の要件でオンプレ保管が指定されている — 契約条件の確認が必要です
  • 回線が細く、クラウドに耐えられない — 全員がクラウド上のファイルを扱う前提になるため、回線増強が先行投資として必要になります

1台でもオンプレに残ると、サーバー室・空調・UPS・保守契約は残ります。 「9割クラウド化」ではコスト削減効果が想定より小さくなるため、残る1台をどう扱うか(データセンターへの預け入れ、ベンダーのハウジング利用など)まで含めて計画してください。

移行を成功させるための実務ポイント

切り戻し手順を決めてから移行する。 移行当日に問題が起きた場合、いつまでに判断してどう戻すかを事前に合意しておきます。判断期限を決めていないと、復旧作業が長時間化します。

繁忙期を避ける。 決算期、月次締め、大型案件の納品直前は避けてください。トラブル対応の余力がなくなります。

旧環境をすぐ捨てない。 移行後、一定期間(1〜3ヶ月)は旧環境を参照可能な状態で残します。「あのファイルが見つからない」という問い合わせは必ず発生します。

利用者への周知を軽視しない。 保存先が変わる、アクセス方法が変わるといった変更は、技術的には小さな変更でも現場の混乱要因になります。移行前の説明と、移行後の問い合わせ窓口を用意してください。

まとめ

  • 判断の前に5年分の総コストを棚卸しする。サーバー室の賃料相当と自社の人件費を必ず含める
  • クラウドが常に安いとは限らない。大容量ファイルサーバーのIaaS移行は割高になることがある
  • 目的がコスト削減ではなく、運用負荷の軽減とBCP強化になるケースも多い
  • 計画前に**ステージ0(現状の棚卸し)**を置く。用途不明のサーバーは必ず存在する
  • ファイルサーバー移行は容量より構造の問題。階層と権限を整理する前提で計画する
  • SaaS化の最大の論点は機能比較ではなく、業務プロセスを変えられるか
  • リフト&シフトは「移しただけ」。運用負荷は残り、常時稼働VMは想定より高くなる
  • 廃棄時はデータ消去の証明を受け取る。業者任せにしない
  • 1台でも残るとサーバー室・空調・保守は残る。残す1台の扱いまで計画に含める
  • 移行は切り戻し手順を決め、繁忙期を避け、旧環境を一定期間残す

「サーバールームをなくす」は一朝一夕にはできませんが、ステージを分けて段階的に進めれば、18〜24ヶ月で達成可能です。

情シス365では、オンプレ環境のアセスメントからクラウド移行計画の策定、移行実行、移行後の運用代行まで対応しています。無料相談で現状の棚卸しからご相談いただけます。

あわせて読みたい

Support365 — ネットワーク・インフラ運用

社内ネットワーク・サーバ・回線の設計から、日々の運用と障害の切り分けまで。構成図もパスワードも残っていない状態からの引き継ぎに対応します。

情シスのお悩み、ご相談ください

専門スタッフが貴社の課題に合わせたご提案をいたします。

メールでのお問い合わせはこちら →
60分無料相談