VMware環境の棚卸し方法｜移行検討前に確認する構成・契約・依存関係

VMware移行の前に自社環境を確認する

VMwareの移行先を比較する前に、自社環境の対象範囲と制約を確認する必要があります。

現状が整理されていないと、必要な機能、見積もりの対象、移行時に確認すべき条件を具体化できません。

例えば、次のような状況が考えられます。

• 構成図はあるが、その後の増設や設定変更が反映されていない

• 設定変更の経緯が前任者のメールにしか残っていない

• VMの一覧は取得できても、それぞれの業務用途が分からない

• 契約内容や更新日を技術部門が把握していない

• 業務部門が許容できる停止時間を確認していない

• 使用中のバックアップ製品や監視ツールのバージョンが分からない

この状態のまま代替候補の比較を始めても、機能一覧から自社に必要な機能を選びにくくなります。

見積もりを依頼する場合も、対象となるホストやVM、既存ストレージ、バックアップ、移行範囲を示せなければ、前提条件の確認に時間がかかり、見積もりの精度を上げにくくなります。

最初に確認すべきことは、現状把握を済ませずに製品比較へ入っていないかという点です。情報の出どころが特定の担当者の記憶だけになっている場合は、契約書、構成図、管理画面、運用手順書など、後から確認できる情報へ置き換えます。

棚卸しの目的は、網羅的な資料を作ることではありません。移行の判断に必要な材料をそろえることです。最初に目的と必要な粒度を決めずに進めると、項目だけが増え、作業を区切れなくなる場合があります。

全体方針を先に整理したい場合

現状把握ではなく、VMwareを継続するか、代替候補を検討するかという全体方針を整理したい場合は、以下の記事をご覧ください。

【 VMware代替を検討する前の判断軸 】

VMware環境を3つの情報層に分けて棚卸しする

VMware環境の棚卸しに必要な情報は、仮想基盤、契約、業務という3つの層に分かれています。
3つの層では、情報源と確認担当が異なります。そのため、管理画面の確認だけでは棚卸しを完了できません。

VMware環境の棚卸しで確認する3つの情報層

仮想基盤情報を確認する

仮想基盤情報には、次のような項目が含まれます。

• ホストの構成

• VMの数

• リソースの使用状況

• OSとバージョン

• ネットワーク構成

• ストレージ構成

• バックアップ構成

• 監視対象

これらは、管理画面、管理ツール、構成図、運用手順書などから確認します。

契約情報を確認する

契約情報には、次のような項目が含まれます。

• 契約内容

• 契約数量

• 購入時期

• 購入経路

• 保守期限

• 契約更新時期

• 契約を管理している部門

これらの情報は、技術部門ではなく、調達部門や経理部門が管理している場合があります。契約書や注文書だけでは条件を確認できず、販売窓口への確認が必要になることも考えられます。

業務情報を確認する

業務情報には、次のような項目が含まれます。

• 各VMの業務用途

• 利用部門

• 業務停止時の影響

• 停止可能な時間帯

• システム間の依存関係

• 外部サービスとの接続

• BatchやJobの実行順序

これらは、業務部門やアプリケーション担当者への確認が必要です。

棚卸しを始める前に、3つの層をどこまで、どの粒度で確認するかを決めます。粒度を決めずに着手すると、仮想基盤の構成情報だけが細かくなり、契約情報や業務情報に未確認項目が残る可能性があります。

管理ツールや構成情報の可視化ツールで取得できるのは、主にホスト、VM、リソース、バージョンなどの技術情報です。取得範囲は使用するツールによって異なりますが、契約の残期間、購入経路、業務上の停止可能時間などは、契約書や関係部門への確認が必要です。

ツールを使って収集する項目と、人が確認する項目を分けて計画すると、棚卸しの進捗を管理しやすくなります。

対象・契約・VM・ネットワーク・バックアップを確認する

VMware環境の棚卸し項目は、対象範囲、契約・保守、VM、ネットワーク、バックアップの5つに分けて整理します。

5つの区分に未確認項目が残ると、見積もり、候補比較、移行計画の段階で追加確認が必要になる可能性があります。特に契約・保守とバックアップは、判断期限や移行先候補の条件に影響するため、早い段階で確認します。

対象範囲を確認する

対象範囲では、本番環境だけでなく、検証環境や拠点に設置されている小規模なホストも確認します。

本番環境の構成は把握できていても、開発用に設置したホストや、拠点に残っている旧世代のホストが管理対象から外れている場合があります。移行対象が後から追加されると、費用や作業期間の再確認が必要になります。

契約・保守を確認する

契約書、注文書、資産管理台帳などを確認し、契約内容、数量、購入経路、保守期限、契約更新時期を整理します。

契約条件を技術部門だけで確認できない場合は、調達部門、経理部門、販売窓口など、情報を保有する関係者を確認します。

VMの用途とリソースを確認する

VMごとに、次の情報を確認します。

• 業務用途

• 利用部門

• OSとバージョン

• vCPU、メモリ、ディスクなどのリソース

• 稼働時間帯

• 停止可能時間

• 移行時に確認が必要なアプリケーション

VM一覧を取得するだけでなく、各VMがどの業務に使われているかまで確認します。

ネットワークと外部接続を確認する

ネットワークでは、セグメント、IPアドレス、外部接続、認証、名前解決、ファイアウォールなど、移行後の接続に影響する情報を確認します。

構成図だけでなく、現行の設定情報や運用手順書も確認対象に含めます。

バックアップと監視ツールを確認する

バックアップ製品や監視ツールについては、製品名だけでなくバージョンも記録します。

確認項目の例は次のとおりです。

• バックアップ製品とバージョン

• バックアップ対象

• 保存先

• 保持世代

• リストア手順

• 監視製品とバージョン

• 監視対象

• 主な通知先

使用中の製品が移行先候補に対応していない場合は、別製品への変更、構成の見直し、その候補を採用しない判断を含めて比較する必要があります。

棚卸しの時点で周辺製品まで確認しておくと、その後の候補比較で確認すべき条件を具体化できます。

システム間と業務上の依存関係を確認する

構成情報だけでは確認しにくい項目の一つが、システム間や業務上の依存関係です。

管理画面から、どのホストにどのVMが配置されているかは確認できます。しかし、そのVMがどのシステムや業務と連携しているかは、VM一覧だけでは判断できない場合があります。

確認する依存関係の例は、次のとおりです。

• 業務システム間のデータ連携

• 夜間のファイル連携

• 認証基盤や名前解決との関係

• BatchやJobの実行順序

• 先行処理の停止によって後続処理へ影響が及ぶ関係

• 取引先や外部サービスとの通信

• 接続元・接続先のアドレス

• 管理アクセスや共有アカウント

• 業務開始前に必要な処理

依存関係は、技術部門だけで確認できるとは限りません。VMの業務用途や停止時の影響について、業務部門やアプリケーション担当者へ確認する必要があります。

依存関係を未確認のまま進めると、検証や移行作業の段階で追加対応が必要になる可能性があります。業務部門への確認には日程調整が必要になるため、構成情報や契約情報の収集と並行して着手します。

業務部門へ停止影響を確認する

業務部門へ確認する際は、技術的な接続先だけでなく、業務への影響も確認します。

• この仕組みが一定時間停止した場合、どの業務に影響するか

• 業務を再開するために、先に起動している必要があるシステムはあるか

• 毎日または毎月、決まった時刻に実行する処理はあるか

• 外部の取引先やサービスとデータを送受信しているか

• 停止できない時間帯や日付はあるか

• 障害時にどの部門や担当者へ連絡しているか

業務部門が技術的な接続関係を把握していない場合でも、業務への影響から関連するシステムを確認できることがあります。

棚卸し結果を更新可能な台帳へまとめる

棚卸し結果は、次回の更改や構成変更でも参照できるよう、情報源、確認担当、更新条件を含む台帳として残します。

一度限りの調査で終わらせると、次の更改時に同じ情報を改めて確認する必要があります。担当者の異動や運用体制の変更があった場合でも確認できるよう、担当者個人の記憶ではなく、更新可能な記録として管理します。

管理項目を決める

対象範囲、契約・保守、VM、ネットワーク、バックアップ、依存関係など、判断に必要な列を決めます。

すべての技術情報を記録するのではなく、見積もり、候補比較、検証、移行計画で使用する項目を優先します。

情報源を記録する

管理画面、契約書、注文書、構成図、運用手順書、関係者への確認など、情報を取得した場所を記録します。

情報源が残っていないと、後から数値や契約条件の根拠を確認できず、再調査が必要になります。

確認担当を記録する

各項目を確認する部門や担当者を記録します。

特定の担当者名だけで管理すると、異動や退職時に更新できなくなる可能性があります。必要に応じて、担当部門や役割も併記します。

更新条件を決める

定期的に見直す項目と、構成変更や契約更新の際に更新する項目を分けます。

更新されない台帳は、古い情報を現行情報として参照する原因になり得ます。更新負荷が高すぎる項目は、必ず台帳へ固定記録するのではなく、必要なときに情報源から確認する運用も検討します。

VMware環境台帳の項目例

既存の資産管理台帳やEOL・EOSL台帳がある場合は、新しい台帳を増やさず、必要な列を追加する方法もあります。

機器全体の保守期限を管理する場合

VMware環境だけでなく、Serverやストレージを含む機器全体の保守期限を管理したい場合は、以下の記事をご覧ください。

【 EOL・EOSL台帳の作り方 】

VMware環境を4段階で棚卸しする

棚卸しは、構成情報の収集、契約・保守情報の確認、業務部門への確認、台帳化という4段階に分けて進めます。

第1段階：構成情報を収集する

管理画面や既存資料から、ホスト、VM、リソース、バージョン、ネットワーク、ストレージ、バックアップなどの構成情報を収集します。

対象となるホストやVMが多い場合は、取得後の整理や重複確認も必要になるため、収集範囲と記録形式を先に決めます。

第2段階：契約・保守情報を確認する

契約書、注文書、資産管理台帳などから、契約内容、数量、購入経路、保守期限、更新時期を確認します。

技術部門で確認できない項目は、調達部門や経理部門、販売窓口へ確認します。依頼から回答までに日数を要する可能性を考慮し、構成情報の収集と並行して依頼します。

第3段階：業務部門へ確認する

各VMの業務用途、利用部門、停止可能時間、業務への影響、システム間の依存関係を確認します。

関係者との日程調整が必要になるため、技術情報や契約情報の収集と並行して依頼します。

第4段階：台帳へ整理して未確認項目を分ける

収集した情報を台帳へ整理し、確認済みの項目と未確認の項目を分けます。

すべての項目が埋まるまで待つのではなく、次の判断に必要な範囲がそろったかを確認します。未確認項目が残る場合は、後工程への影響を記録したうえで、確認を継続するか、条件付きで次へ進むかを判断します。

棚卸しを行わずに見積もりや移行計画へ進むと、対象範囲、依存関係、周辺製品の条件が後から判明し、費用や作業内容の再確認が必要になる可能性があります。

棚卸しは、資料を作ること自体が目的ではありません。見積もり、候補比較、検証、移行計画に必要な条件を事前に整理する作業です。

VMware環境棚卸しチェックリストで確認する

対象範囲

□ 本番環境のホストを確認した

□ 検証環境のホストを確認した

□ 拠点に設置されたホストを確認した

□ 各ホストの設置場所と用途を確認した

契約・保守

□ 契約内容と数量を確認した

□ 購入時期と購入経路を確認した

□ 保守期限と契約更新時期を確認した

□ 契約情報を管理する部門を確認した

VM・リソース

□ VMの一覧を取得した

□ 各VMの業務用途を確認した

□ OSとバージョンを確認した

□ vCPU、Memory、Diskなどのリソースを確認した

□ 停止可能時間を確認した

ネットワーク・ストレージ

□ ネットワーク セグメントを確認した

□ 外部接続を確認した

□ 認証と名前解決との関係を確認した

□ ストレージ構成と接続方式を確認した

バックアップ・監視

□ バックアップ製品とバージョンを確認した

□ バックアップ対象、保存先、保持世代を確認した

□ 監視製品とバージョンを確認した

□ 監視対象と通知先を確認した

業務・依存関係

□ 利用部門を確認した

□ 停止時の業務影響を確認した

□ システム間のデータ連携を確認した

□ BatchやJobの実行順序を確認した

□ 外部サービスや取引先との接続を確認した

台帳管理

□ 各情報の情報源を記録した

□ 確認担当を記録した

□ 最終確認日を記録した

□ 更新条件を決めた

□ 未確認項目と後工程への影響を記録した

棚卸し結果から移行着手時期を判断する

現状が整理できたら、次は契約更新、保守期限、業務への影響、予算、移行に必要な準備期間を基に、移行検討へ着手する時期を判断します。

棚卸しの結果を使い、次の項目を確認します。

• 契約更新や保守終了までに、どの程度の準備期間があるか

• 障害が発生した場合、どの業務へ影響するか

• 現行環境を継続する場合の制約は何か

• 移行候補の比較やPoCに必要な期間を確保できるか

• 予算申請や社内承認をいつ始める必要があるか

• 繁忙期や業務停止が難しい期間と重ならないか

次に読む記事

【 VMware 代替を検討する前に整理したい判断軸｜VM Essentialsを含む仮想化基盤の見直し方 】

VMware環境の構成、契約、業務上の依存関係を整理したら、次は移行検討へ着手する時期を判断します。

契約更新、保守期限、業務への影響、予算、準備期間から、今動く環境と待てる環境を分ける考え方を次の記事で解説します。

VMware環境の棚卸しに関するQ&A

Q1. 棚卸しはどこまで細かく行えばよいでしょうか

判断の目的から逆算します。

見積もりを依頼する段階では、対象範囲、ホストとVMの数、リソース割り当て、既存ストレージ、バックアップなどの情報が必要です。

移行方式まで検討する段階では、停止可能時間、業務用途、依存関係、周辺製品の対応状況も確認します。

最初からすべての項目を埋めるのではなく、次の判断に必要な範囲を決めて着手します。

Q2. 構成情報を取得するツールを使えば、棚卸しを自動化できますか

構成情報の収集は、管理ツールやインベントリツールで効率化できる場合があります。

取得可能な項目はツールによって異なりますが、契約内容、保守の残期間、購入経路、業務上の停止可能時間などは、契約書や関係部門への確認が必要です。

ツールで取得する項目と、人が確認する項目を分けて計画します。

Q3. 担当者が一人でも進められますか

技術情報の収集は一人でも進められる場合がありますが、契約情報や業務情報の確認には、ほかの部門の協力が必要です。

業務部門への確認には、関係者との日程調整が必要になります。対象が多い場合は、業務への影響が大きいシステムから範囲を区切って着手する方法もあります。

Q4. 棚卸し結果は、そのまま見積もり依頼に使えますか

棚卸し結果を見積もり依頼に使う場合は、依頼先が必要とする項目を事前に確認します。

対象範囲、ホストとVMの構成、リソース割り当て、既存ストレージ、バックアップ、監視ツールが整理されていれば、概算条件を提示しやすくなります。

停止可能時間や依存関係が未確認の場合は、その項目を未確定条件として明示します。

まとめ

仮想化基盤の移行を判断するには、製品情報を集める前に、自社の構成、契約、業務上の依存関係を整理する必要があります。

本記事の要点は次のとおりです。

• 自社の対象範囲と制約を整理すると、候補比較や見積もりの前提をそろえやすくなる

• 必要な情報は、仮想基盤、契約、業務という3つの情報層に分かれている

• 棚卸し項目は、対象範囲、契約・保守、VM、ネットワーク、バックアップの5つに分けて整理する

• ツールで取得しやすい技術情報と、契約書や関係部門への確認が必要な情報を分けて収集する

• 業務上の依存関係は、技術的な接続だけでなく、停止時の業務影響からも確認する

• 棚卸し結果は、情報源、確認担当、更新条件、最終確認日を含む台帳として残す

• 未確認項目がある場合は、その項目と後工程への影響を明示する

棚卸しが完了したら、契約更新、保守期限、業務への影響、予算、準備期間を基に、移行検討へ着手する時期を判断します。

次の記事「VMware移行はいつ始めるべきか｜今すぐ動く環境・待てる環境の判断基準」では、本記事で整理した情報を使って、今動く環境と待てる環境を分ける考え方を解説します。

VMware環境の現状整理から確認したい場合

VMware環境の棚卸しでは、ホストやVMの構成情報に加え、契約・保守、既存ストレージ、バックアップ、監視ツール、業務上の依存関係を整理する必要があります。

横河レンタ・リースでは、仮想化基盤の見直しに向けた現状環境の整理、構成確認、契約・保守情報の整理に関する相談を受け付けています。

移行先や製品を決める前の段階でも、自社で確認すべき項目の整理からご相談いただけます。

お問い合わせ (総合) | 法人向けパソコン (PC) ・計測器レンタルなら横河レンタ・リース