VMware移行はいつ始めるべきか｜今すぐ動く環境・待てる環境の判断基準
契約・保守期限、予算、繁忙期、必要な工程を基に、移行検討を始める時期の考え方を整理しています。
PoCで結論が出ない原因の一つは、目的と合否基準を決めないまま検証を始めることです。作業が順調でも、その結果が採否のどの判断につながるのか分からなければ、報告書をまとめる段階で手が止まります。
動作確認では対象機能が動くかを確かめます。一方、PoCで判断するのは、その機能や構成が自社の要件に合うか、移行後も運用を続けられるかという点です。
PoCの結果を使って何を判断するか
書類だけでは判断できない項目は何か
どの条件を満たせば候補に残すか
どの事象が発生したら候補から外すか
誰が検証結果を確認するか
誰が、いつまでに採否を判断するか
|
開始前の確認項目 |
確認済み |
未確認 |
|
PoCによって判断する内容を決めた |
□ |
□ |
|
書類では判断できない検証項目を選んだ |
□ |
□ |
|
検証項目ごとの合否基準を決めた |
□ |
□ |
|
検証環境と本番環境の差を整理した |
□ |
□ |
|
判定者と判定日を決めた |
□ |
□ |
|
未確認事項が残った場合の扱いを決めた |
□ |
□ |
未確認の項目があっても、直ちにPoCを中止する必要はありません。ただし、判断内容、合否基準、判定者は検証前に決めます。未確認の項目には、確認先、担当者、期限を設定してから検証へ進みます。
PoCでは、本番環境の条件をすべて再現できるとは限りません。機材、仮想マシン数、業務負荷、ネットワーク構成などに差が生じます。報告書には、規模、負荷、使用データ、接続した周辺製品など、本番環境と異なる条件を記載します。
仮想マシンを作成、変更する手順
管理画面と権限の設定方法
監視ツールとの連携
バックアップの取得と復元
障害発生時の切り替え動作
障害箇所を特定する手順
PoCで問題が見つからなかったとしても、本番環境で同じ動作を保証する結果にはなりません。どの条件で、どこまで確認したのかを残してください。
本番環境をPoCに転用できず、検証用機器の購入も難しい場合は、検証環境付きのPoCメニューや短期レンタルが選択肢になります。機材の確保だけを先行させず、PoCで何を判断するのかを整理した上で必要な構成を決めます。
|
区分 |
確認する内容 |
判断の観点 |
|
性能 |
業務に相当する負荷での応答、リソース使用状況 |
現行環境の実績値や業務要件と比較して許容できるか |
|
可用性 |
ホスト停止時の挙動、切り替え条件、必要な操作 |
許容停止時間と業務再開条件を満たすか |
|
運用 |
日常操作、監視、権限、更新、障害時の切り分け |
移行後の運用体制で継続できるか |
|
復旧 |
バックアップの取得、復元、復元後の確認 |
復旧目標と業務再開条件を満たすか |
性能値は測定するだけでは合否を決められません。現行環境の実績値や、業務部門が許容できる処理時間と比較して評価します。
業務に相当する処理を実行した場合の応答
CPU、メモリー、ストレージの使用状況
複数の仮想マシンを稼働させた場合の変化
現行環境と候補環境の測定条件の違い
業務部門が許容できる処理時間
可用性の検証は、仮想マシンが別のホストへ切り替わった時点では終わりません。切り替え後に対象業務を再開できるかまで確認します。
可用性機能を利用するための構成要件
ホスト停止時の仮想マシンの動作
切り替え先で仮想マシンを稼働できるか
切り替えに必要な操作
切り替え後の業務確認方法
業務が許容できる停止時間
移行後の運用を成立させるには、管理画面を操作できるだけでは不十分です。誰が、どの権限で、どの手順を担当するのかまで確認します。
仮想マシンの作成、変更、停止
リソース使用状況とアラートの確認
管理画面へのアクセス経路
管理者権限を付与する範囲
監視ツールとの連携と通知先
ソフトウェアやファームウェアの更新
障害発生時の一次切り分け
バックアップが正常に終了していても、業務を再開できるとは限りません。復元後のデータやアプリケーションまで確認します。
バックアップの取得方法と保存先
仮想マシンまたはデータの復元方法
復元に必要な操作
復元後のデータ整合性
アプリケーションの起動状態
業務を再開するための確認手順
定めた復旧目標を満たすか
PoCの合否基準は、結果を見る前に決めておきます。結果を見た後で基準を変えると、得られた数値や挙動に合わせた評価になりかねません。基準を決めた担当者、判定者、決定日も記録します。
現行環境の実績値は候補環境との差を説明する材料になります。ただし、規模、負荷、使用データ、ネットワークが異なる場合は、その差も併記します。
停止時間、業務再開条件、戻す必要があるデータの時点、処理時間、代替手段を業務部門へ確認し、合否基準へ反映します。
合否基準はすべてを数値にする必要はありません。対象アプリケーションを起動できない、必要な周辺製品と連携できない、復元後の整合性を確認できないなど、不合格とする事象も定めます。
PoCを始める前に、実施期間、関係者、成果物を決めます。終了条件を先に置くことで、検証範囲が広がり過ぎることを防ぎます。
|
記録項目 |
記載内容 |
|
PoCの目的 |
PoC結果を使って判断する内容 |
|
検証環境 |
使用した機器、構成、設定、データ |
|
本番との差 |
規模、負荷、ネットワーク、周辺連携などの差 |
|
検証項目 |
何をどの条件で確認したか |
|
合否基準 |
検証前に定めた判断条件 |
|
結果 |
実際に確認できた内容 |
|
判定 |
合格、不合格、条件付き、未判定 |
|
未確認事項 |
PoCでは確認できなかった内容 |
|
追加確認 |
内容、方法、担当者、期限 |
|
判定者・判定日 |
誰が、いつ判断したか |
|
検証項目 |
合否基準 |
結果 |
|
ホスト停止時の切り替え |
許容停止時間内に業務確認まで完了 |
切り替え完了。業務アプリケーションは未確認 |
|
判定 |
未確認事項 |
次の行動 |
|
条件付き |
起動とデータ整合性 |
業務担当者が追加確認し再判定 |
|
判定 |
判定の考え方 |
次に行うこと |
|
合格 |
合否基準を満たし、採否に必要な項目を確認できた |
採用候補として比較表へ反映する |
|
不合格 |
必要な条件を満たさず、追加対応による解消も難しい |
候補から外す理由を記録する |
|
条件付き |
追加対応を前提に候補へ残せる可能性がある |
対応内容、担当者、期限、再判定条件を決める |
|
未判定 |
採否に必要な情報を取得できなかった |
追加確認の方法、確認先、担当者、期限を決める |
短期間のPoCでは、長期運用時の安定性、繁忙期の負荷、本番環境と同じ規模での性能、本番環境でなければ再現できない周辺連携を十分に確認できない場合があります。製品資料やサポート条件の確認、運用手順の整備、本番移行後の確認計画などで補います。採否を決められない項目は「未判定」として追加確認へ引き継ぎます。
検証項目、機材の準備、関係者の日程を基に決めます。環境構築と結果整理に必要な作業も実施期間に含めます。
書類で判断できる候補まで一律にPoCを行う必要はありません。実機でなければ確認できない事項が残る候補を対象にします。
技術条件は情報システム部門と技術担当者、停止時間や業務再開条件は業務部門と確認します。契約やサポート範囲が影響する場合は、調達・契約担当者や販売窓口にも確認します。
PoCを採否判断につなげるには、検証を始める前の設計が欠かせません。検証項目は性能、可用性、運用、復旧の4区分で整理し、合否基準、本番環境との差、判定者を事前に決めます。
合格
不合格
条件付き
未判定
特に「条件付き」と「未判定」は曖昧なまま残さず、次の行動、担当者、期限、再判定の条件まで成果物へ記録します。PoC報告書は、候補を採用するか、追加確認するか、候補から外すかを判断するための資料です。
条件付きまたは未判定の項目が残った場合は、PoCの結果を候補比較の判断軸へ戻します。
VMware代替候補をどう比較するか｜技術・運用・契約・移行の判断軸
PoCの結果を技術、運用、契約、移行の観点から再評価する場合に参照してください。
PoCで確認する範囲や合否基準を自社だけでは整理できない場合があります。本番環境との差が明確になっていない場合も、検証環境を用意する前に確認事項を整理します。
横河レンタ・リースでは、現状の環境、候補となる構成、関連する契約情報の整理についてご相談いただけます。書類で判断できる項目と、PoCで確かめる項目を分け、検証範囲を具体化します。