オンプレミスからクラウドへの移行判断 ― 5年TCOの比較
ある中堅企業が、5年前に導入した基幹システム(Web/AP/DBの3台構成)の更新時期を迎えている。情報システム部はクラウド移行を提案しているが、経営層から「TCOが悪化するのではないか」と問われている。
現行の年間コストは、ハードウェア保守180万円、電気・空調120万円、ラック費60万円、運用要員0.4人月/月(人月単価80万円)で年間384万円、合計744万円である。ハードウェアは償却済みで簿価はゼロ。ただし老朽化により、5年以内に再調達2,400万円が必要で、ベンダのサポート終了も2027年3月に迫っている。また、事業継続の観点から災害対策サイトの構築が経営課題になっており、オンプレミスで実現する場合は初期1,500万円・年間運用200万円と試算されている。
クラウド案は、マルチAZ構成と別リージョンへのバックアップを含めて月45万円、ネットワーク月8万円、監視SaaS月5万円。運用要員は0.25人月/月に削減できる見込み。移行費用は一括1,200万円で、移行期間中は3か月間オンプレミスと並行稼働となる。
1. 5年間のTCOを比較せよ。また、情報システム部が当初提示した比較にはどのような費用が不足していたと考えられるか。
Read the worked answer
現行のまま(オンプレミス)5年
- 年間運用:744万円 × 5年 = 3,720万円
- ハードウェア再調達:2,400万円
- 災害対策サイト:初期1,500万円 + 年間200万円 × 5年 = 2,500万円
- 合計:3,720 + 2,400 + 2,500 = 8,620万円
クラウド案 5年
- 年間:(45 + 8 + 5)万円 × 12か月 = 696万円、運用0.25人月 × 12か月 × 80万円 = 240万円、計936万円
- 5年:936万円 × 5年 = 4,680万円
- 移行費用:1,200万円
- 合計:4,680 + 1,200 = 5,880万円
差額は約2,740万円で、クラウドが有利となる。
当初の比較で不足していた費用 第一に、ハードウェアの再調達費である。償却済みで簿価ゼロの資産を「コストゼロ」として扱うと、5年の間に必ず発生する2,400万円が比較から抜け落ちる。第二に、災害対策の費用で、これは経営課題として既に意思決定済みの要件であり、比較の前提に含めなければならない。第三に、並行稼働中の二重コスト(3か月間はオンプレミスの744万円×0.25年とクラウド費用が同時に発生する)。第四に、移行に伴う社内工数(データ移行検証・テスト・教育)で、ベンダ費用1,200万円には含まれていないことが多い。
逆に、クラウド側で見落としやすいのはデータ転送料とストレージの増加、そして監視SaaSのライセンスが利用者数に比例する場合はその増加分である。単価の見積りは初年度の想定であり、5年後のデータ量増加を織り込む必要がある。
2. この比較結果が逆転する条件を、感度分析の観点から2つ以上挙げよ。
Read the worked answer
条件1:災害対策要件が不要、または既に別手段で満たされている場合 オンプレミス側の2,500万円が消えると、8,620万円は6,120万円になり、クラウドの5,880万円との差は約240万円まで縮む。ここに移行の社内工数や並行稼働コストを積むと、ほぼ互角か逆転し得る。「BCPが本当に必要なのか」「既存の遠隔バックアップで代替できないか」を先に確認しないと、比較の前提が崩れる。
条件2:クラウドの運用削減効果が実現しない場合 クラウド案の優位は、運用要員を0.4人月から0.25人月に減らせるという前提(年間144万円の削減)に依存している。クラウド化しても監視・課金管理・IAM運用などの新規作業が発生し、実際には0.35人月程度しか減らないことも多い。0.35人月だと年間削減は48万円にとどまり、5年で240万円の目減りとなる。
条件3:利用量の増加(データ量・トランザクション) クラウド費用は従量課金であり、データ量が年20%増えると5年間のストレージ・バックアップ費用は単純比例以上に増える。逆にオンプレミスは固定費なので、利用量が増えるほど1件あたりのコストは下がる。5年後にデータ量が2倍になる想定では、クラウド側の年間費用が936万円から1,100万円台に膨らみ、差は1,000万円程度まで縮む。
条件4:再調達の先送り 「2027年3月のサポート終了」は、実務上は延長サポート契約で1〜2年先送りできることが多い。延長費用が5年で500万円程度なら、再調達2,400万円を6年目にずらすことで、5年間の比較ではオンプレミスが有利に見える。ただし先送りは将来のコストを消すのではなく移すだけであり、判断の妥当性は別に問われる。
結論として、この比較は「災害対策を要件に含めるか」「運用削減がどこまで現実的か」の2点に強く依存する。資料には必ずこの前提条件を明記し、単一の結論だけを示さない。
3. 移行を決断する場合のリスクと、実施の進め方を述べよ。
Read the worked answer
主要リスク
- ベンダロックインと退出コスト:マネージドサービスを多用するほど、他社への移行が困難になる。コンテナや標準的なミドルウェアを優先し、データのエクスポート手順を移行時点で文書化しておく。
- 並行稼働中の二重管理:3か月間は両系が生きるため、マスタデータの同期方針を決めないと、どちらが正しいか分からなくなる。移行期間中は「書き込み系は新系のみ」など明確なルールを敷く。
- スキル不足:運用が「机器を触る」から「構成をコードで管理する」に変わる。IaCやIAMの習熟を移行前に済ませないと、稼働後に設定ミスが集中する。
- 性能・課金の想定外:本番移行後にクエリの実行計画が変わり、従量課金が急増する例は多い。
進め方
- まず非機能要件の確定を行う。RTO・RPO、可用性目標、コンプライアンス要件(データの保管場所)を数値で決める。これが決まらないと、マルチAZや別リージョンバックアップの要否も費用も確定しない。
- 次にパイロット移行として、影響の小さいサブシステム1つを対象に、移行手順・性能・運用手順を検証する。ここで見積りとの乖離を測る。
- 段階移行を基本とし、一括カットオーバーは避ける。切り戻し手順と判断基準(例:移行後1週間でエラー率が基準値を超えたら戻す)を事前に合意する。
- 移行後のコスト監視を最初から仕込む。タグ設計と予算アラートを移行前に設定し、月次で実績と見積りを突き合わせる。
- 経営層に対しては、5年TCOの数値に加えて「前提条件が変わったら再評価する」トリガーをセットで報告する。