現行の構成、契約・保守情報、業務上の依存関係を整理できていない場合は、先にVMware環境の棚卸しを行います。
【 VMware環境の棚卸し方法｜移行検討前に確認する構成・契約・依存関係 】
移行の検討を始める時期は、単一の条件や該当項目の数では決めません。業務への影響、必要な期間、障害時の代替手段、契約条件、予算、体制を組み合わせて判断します。
|
確認結果 |
判断の方向 |
次に行うこと |
|
必要な工程を実施する期間を確保できない。または、業務への影響が大きいにもかかわらず、代替手段を確認できていない |
移行の検討を前倒しするか、計画を見直す |
検討を前倒しできるか確認する。前倒しだけでは必要な期間を確保できない場合は、移行対象、移行時期、現行環境を継続する条件、障害時の代替手段を見直す |
|
必要な期間を確保でき、現行環境を継続する条件と障害時の代替手段を確認できている |
再評価する時期を決めて待つ |
再評価日、確認項目、確認担当者、判断者を記録し、必要な準備を続ける |
|
保守・契約期限、業務への影響、代替手段、必要な工程のいずれかが分からない |
判断の前に追加確認する |
契約書、構成資料、障害履歴、業務部門への確認結果を整理する |
この表は、移行の可否を機械的に判定するものではありません。自社で不足している情報と、次に行うべきことを整理するために使用します。
業務への影響が大きく、代替手段がない場合は、該当項目が一つであっても、早い段階で対応を検討する必要があります。一方、複数の懸念があっても、必要な期間、復旧方法、代替運用、契約条件を確認できている場合は、再評価する時期を決めた上で待つ判断が成立することもあります。
移行を直ちに始めない場合も、判断を無期限に保留しないよう、再評価する時期と確認項目を決めます。
情報収集を続けていても、判断する期限や担当者が決まっていなければ、社内では対応が進んでいない状態になる可能性があります。確認担当者が検討を続けていても、経営層や関係部門には、緊急性の低い案件と受け取られる場合があります。
「検討中」として管理するには、少なくとも次の項目を明確にします。
追加で確認する構成・契約情報
業務部門へ確認する停止の影響
次に判断する時期
判断に使用する条件
情報を集める確認担当者
方針を決める判断者
決裁を行う承認者
判断までに準備する資料
ここでいう確認担当者、判断者、承認者は、それぞれ次の役割を担います。
|
役割 |
主な役割 |
|
確認担当者 |
構成、契約、業務への影響、代替手段などの情報を集める |
|
判断者 |
集めた情報を基に、移行の検討を始めるか、待つかを判断する |
|
承認者 |
予算、移行方針、業務停止、実施計画などを決裁する |
これらが決まっていない場合は、期限のない保留になっていないかを確認します。待つこと自体が問題なのではありません。いつまで待つか、何を確認したら再判断するか、誰が確認し、誰が判断するかが決まっていないことが問題です。
保守終了までの期間が、棚卸し、候補比較、検証、承認、調達、移行に必要な期間より短い場合、取れる対応が限られる可能性があります。その場合は、検討の前倒しだけでなく、移行対象の分割、移行時期の見直し、現行環境を継続する条件の確認、障害時の代替手段の確保など、期限内に実行できる選択肢を整理します。
移行の検討時期を決めるには、技術、契約、予算、業務、体制に関する複数の期限と制約を整理します。主に確認する項目は、次のとおりです。
|
区分 |
確認する内容 |
主な確認先 |
検討時期への影響 |
|
ハードウェア保守 |
保守終了時期、保守範囲、障害時の対応条件 |
保守契約書、資産管理台帳、販売窓口 |
障害時の復旧手段と判断期限 |
|
ソフトウエア契約 |
更新時期、更新条件、契約上必要な手続き |
契約書、注文書、調達部門、販売窓口 |
継続条件と契約を判断する時期 |
|
予算 |
予算申請時期、承認手続き、利用できる予算枠 |
予算部門、経理部門、承認者 |
方針決定と見積もり取得の時期 |
|
業務 |
繁忙期、停止できない期間、業務上の予定 |
業務部門、アプリケーション担当者 |
検証や移行を実施できる時期 |
|
体制 |
確認担当者、判断者、承認者、並行する案件、外部支援の利用可否 |
情報システム部門、プロジェクト責任者 |
検討を始められる時期と作業範囲 |
契約更新まで期間があっても、予算申請や社内承認に必要な時期を過ぎると、希望する時期に作業を始められない可能性があります。一方、保守終了が近くても、障害時の代替手段や現行環境を継続する条件を確認できている場合は、条件を整理した上で、段階的に対応する方法も検討できます。
契約更新時期、更新条件、手続き期限は契約ごとに異なります。契約書、注文書、販売窓口からの案内を確認し、自社に適用される条件を整理します。予算申請の時期も企業ごとに異なります。方針が決まった後に予算の制約が判明しないよう、技術的な期限と予算・承認の期限を並行して確認します。
移行を担う人員がほかのプロジェクトと重なる場合は、体制を確保できる時期も判断へ影響します。技術、契約、予算、業務、体制を一つの工程表にまとめると、確認漏れを防ぎやすくなります。
次のような条件がある場合は、移行の検討を始める時期を前倒しする必要がないか確認します。
ハードウェア保守の終了までに、必要な工程を実施する期間を確保できない可能性がある
ソフトウエアの契約更新が近く、更新後の条件や契約上必要な手続きが確認できていない
障害が発生した場合の業務への影響が大きく、代替運用や復旧手段が限られている
障害の発生状況や復旧時間に変化があり、現行環境を継続する条件を再確認する必要がある
リソースに余裕がなく、増設や構成変更を検討する必要がある
運用担当者の異動や退職が予定され、構成や運用手順を確認できる期間が限られている
業務部門からの要求に対し、現行環境では条件を満たせない可能性がある
監査や取引先との契約上、保守・運用状態の確認が必要になっている
予算申請や社内承認の期限が近い
業務上の繁忙期を避けると、検証や移行を実施できる時期が限られる
検討の優先度は、該当項目の数だけでは決めません。該当項目が一つだけでも、停止した場合の業務への影響が大きく、障害時の代替手段がない場合は、早い段階で対応を検討する必要があります。
必要な期間を確保できないことが判明した場合は、単に作業を急ぐのではなく、次の選択肢を比較します。
検討や確認を前倒しできるか
移行対象を分けられるか
移行時期を見直す必要があるか
現行環境を継続できる条件があるか
障害時の代替手段を確保できるか
外部支援を利用できる工程があるか
障害の発生頻度が上がっている場合は、直ちに基盤移行の理由とするのではなく、原因を確認します。ハードウェアの老朽化だけでなく、設定、運用、アプリケーション、ネットワークなど、別の要因が関係している可能性があるためです。
運用担当者の異動や退職が予定されている場合は、構成や運用手順を確認できる時期も判断材料になります。属人化した情報が残っている場合は、移行の検討と並行して、構成情報、運用手順、設定変更の経緯を記録します。
移行を直ちに始めず、現行環境を継続する判断も、必要な条件を確認できていれば選択肢になります。待つ判断が成立する条件として、次の項目を確認します。
ハードウェア保守の終了までに、移行に必要な工程を実施できる期間を確保している
契約更新後の条件と必要な手続きを確認し、現行環境を継続する条件を整理している
障害履歴と復旧状況を確認し、現行環境を継続する間の業務への影響を受容できると判断している
障害時の連絡先、復旧手段、代替運用を確認している
リソースに余裕があり、現行環境を継続する間に必要となる増設や構成変更を把握している
移行の判断に必要な棚卸しを完了している
再評価する時期と確認項目を決めている
確認担当者、判断者、承認者を決めている
待つ間に受け入れるリスクを記録している
次回の予算申請や契約更新に向けた準備を進めている
「まだ稼働している」「大きな障害が発生していない」という理由だけでは、待つ判断の根拠として十分とは限りません。待つ場合にも、いつ、何を見て再評価するかを決めます。
例えば、次回の契約確認時や予算検討時など、自社の手続きに合わせて再評価する時期を設定します。その際に、保守期限、契約条件、障害履歴、業務への影響、体制の変化のうち、何を確認するかも決めておきます。
待つ間にも、次の準備を進められます。
契約・保守情報の更新
業務上の依存関係の確認
候補比較に使用する評価項目の整理
予算申請に必要な情報の整理
検証対象とするシステムの選定
社内担当者と外部支援範囲の整理
待つことと、何もしないことは異なります。再評価する時期と準備項目を決めておけば、移行を始めると判断した後の作業を進めやすくなります。
移行の判断期限は、保守終了日や契約更新日だけでは決められません。期限までに必要となる工程を積み上げ、保守終了日、契約更新日、業務上の期限を起点として逆算します。
逆算に含める主な工程は、次のとおりです。
現行環境の棚卸し
候補の比較と絞り込み
検証環境の準備と、必要に応じた概念実証（PoC）
見積もり取得、社内承認、予算確保
発注、調達、移行準備
移行作業
安定稼働の確認と運用の引き継ぎ
PoCは、すべての環境で一律に実施するものではありません。候補の機能、既存環境との適合性、運用方法、復旧方法などを事前に確認する必要がある場合に、実施範囲を検討します。
保守終了まで期間があるように見えても、必要な工程を積み上げると、方針決定や予算申請を始めるべき時期が近い場合があります。予算申請や社内承認の時期は企業ごとに異なります。自社の手続きと必要な期間を工程表に含めます。
検証や見積もりでは、関係者や外部の販売窓口との調整が必要になる場合があります。自部門だけでは進められない工程については、問い合わせから回答を得るまでの期間も見込みます。
逆算した結果、計画していた移行時期までに必要な工程を実施できないと分かる場合があります。その場合は、検討を前倒しできるか確認します。前倒しだけでは必要な期間を確保できない場合は、次のような選択肢を比較します。
移行対象を分けて段階的に進める
移行時期を見直す
現行環境を継続する条件を確認する
障害時の代替手段を確保する
依存関係の少ない範囲から検証する
外部支援を利用できる工程を確認する
逆算の目的は、移行日を一つに固定することではありません。いつまでに何を判断しなければ、どの選択肢を取りにくくなるかを把握することです。
次の順番で確認すると、移行の検討を前倒しするか、追加確認を行うか、再評価する時期を決めて待つかを整理できます。
棚卸しが完了していない場合は、現行の構成、契約・保守情報、業務上の依存関係を整理します。棚卸しが完了している場合は、必要な工程を実施する期間の確認へ進みます。
前項で整理した工程を、保守終了日、契約更新日、業務上の期限から逆算し、必要な期間を確保できるか確認します。必要な期間を確保できない可能性がある場合は、移行の検討を前倒しできるか確認します。
前倒しだけでは必要な期間を確保できない場合は、移行対象、移行時期、現行環境を継続する条件、障害時の代替手段を見直します。必要な期間を確保できる場合は、停止した場合の業務への影響の確認へ進みます。
影響する業務
利用部門
停止できない時間帯
取引先や外部サービスへの影響
復旧までに許容できる時間
関連するシステムへの影響
確認できていない場合は、業務部門やアプリケーション担当者へ追加確認します。確認できている場合は、障害時の代替手段の確認へ進みます。
障害時の連絡先
復旧手順
バックアップからのリストア方法
一時的な代替運用
現行環境を継続できる条件
切り戻しの条件
確認できていない場合は、移行の判断を確定する前に、復旧方法と代替手段を整理します。確認できている場合は、契約、予算、体制の確認へ進みます。
契約更新日と更新条件
契約上必要な手続き
予算申請の時期
社内承認に必要な手続き
情報を集める確認担当者
方針を決める判断者
決裁を行う承認者
外部支援を利用する範囲
繁忙期や停止できない期間
確認できていない場合は、確認担当者と確認期限を決めます。確認できている場合は、判断者が移行の検討を始めるか、再評価する時期を決めて待つかを判断します。予算や業務停止などの承認が必要な場合は、承認者へ判断内容を共有します。
このフローは、VMware移行の実施可否を自動的に判定するものではありません。未確認事項を特定し、次の行動を決めるために使用します。
複数のVMware環境を運用している場合、すべてを同時に移行できるとは限りません。検討を始める順番を決める際は、次の観点を使用します。
|
評価項目 |
確認する内容 |
|
業務への影響 |
停止した場合に影響する業務、利用者、取引先 |
|
停止可能時間 |
検証や移行のために確保できる停止時間 |
|
依存関係 |
他のシステム、認証、ネットワーク、外部サービスとの関係 |
|
移行難易度 |
構成の複雑さ、周辺製品、データ量、移行方式 |
|
残期間 |
保守終了、契約更新、業務上の期限までの期間 |
|
代替手段 |
障害時の復旧方法、代替運用、切り戻しの条件 |
|
体制 |
確認担当者、外部支援、並行するプロジェクトとの重なり |
業務への影響が大きく、停止可能時間が短く、依存関係が多いシステムでは、移行準備に必要な確認事項が増える可能性があります。ただし、重要度が高いことと、最初に切り替えるべきことは同じではありません。重要度と移行難易度を分けて評価し、次の二つを分けて考えます。
検証や準備を始める順番
本番環境を切り替える順番
移行難易度の低いシステムから着手すると、移行手順や新しい環境における運用上の課題を確認できる場合があります。一方、重要度の高いシステムの検証や準備を後回しにすると、必要な期間を確保できない可能性があります。
重要度と移行難易度がともに高いシステムでは、早い段階から依存関係の確認やPoCを始め、本番環境の切り替え時期は検証結果を踏まえて決めます。
検討を始める時期を決めても、移行と移行後の運用を担う体制がなければ、計画を実行できません。体制については、次の三点を確認します。
棚卸し、要件整理、設計、構築、検証、移行、運用のうち、社内で担う範囲と外部支援を利用する範囲を分けます。外部支援を利用する場合も、判断基準、受け入れるリスク、判断者、承認者を自社側で確認できる状態にします。
移行先を検討する際は、仮想マシンを稼働できるかだけでなく、次の運用を移行後も継続できるか確認します。
監視と障害の一次対応
バックアップとリストア
アカウントと権限の管理
パッチやバージョンの管理
保守・契約情報の更新
障害時の連絡と判断
管理アクセスと運用ログの確認
運用方法が決まらないまま候補を選ぶと、移行後に監視項目や復旧手順を改めて設計する必要が生じる可能性があります。
外部支援の範囲を決める際は、外部へ委託する作業と、社内で保持する情報管理、判断、承認の役割を分けます。少なくとも、次の役割を明確にします。
構成・契約・業務情報を集める確認担当者
移行対象や検討方針を決める判断者
候補の評価基準を承認する承認者
業務停止を承認する承認者
移行の実施を承認する承認者
移行後の運用を受け入れる判断者または承認者
体制を決める目的は、すべてを社内で実施することではありません。どの情報と判断を社内に残し、どの作業で外部支援を利用するかを明確にすることです。
次の項目を確認し、未確認の項目には確認担当者、情報源、確認期限を設定します。
□ ハードウェア保守の終了日を確認した
□ ソフトウエアの契約更新日を確認した
□ 更新後の契約条件を確認した
□ 契約上必要な手続きを確認した
□ 予算申請と社内承認の時期を確認した
□ 停止した場合に影響する業務を確認した
□ 停止できない時間帯を確認した
□ 関連するシステムと外部サービスを確認した
□ 復旧までに許容できる時間を確認した
□ 障害時の連絡先を確認した
□ 復旧手順を確認した
□ バックアップからのリストア方法を確認した
□ 一時的な代替運用を確認した
□ 現行環境を継続できる条件を確認した
□ 切り戻しの条件を確認した
□ 比較、検証、承認、調達、移行に必要な工程を整理した
□ 各工程に必要な期間を確認した
□ 社内で担う範囲と外部支援を利用する範囲を決めた
□ 確認担当者を決めた
□ 判断者を決めた
□ 承認者を決めた
□ 待つ場合の再評価日を決めた
環境によっては、対象を分けて段階的に進める方法が考えられます。ただし、新旧環境を並行して運用する期間が生じる可能性があるため、運用負荷、費用、監視、バックアップ、障害対応を確認します。
システム間の依存関係が強い場合や、データ更新の整合性を保つ必要がある場合は、移行対象を分けられるかを個別に確認します。
まず、対応を見送った場合の業務への影響と、期限までに実施できる範囲を整理します。その上で、対象を分けて段階的に進める、現行環境を継続する条件を確認する、実施時期を見直すなど、実行できる選択肢を比較します。
調達方法や契約条件は案件ごとに異なるため、予算部門、調達部門、販売窓口へ確認します。対応を見送る場合も、受け入れるリスク、再評価する時期、確認担当者、判断者、承認者を記録します。
VMware移行の検討をいつ始めるかは、他社の動向や固定的な期間ではなく、自社の業務への影響、期限、代替手段、予算、体制を基に判断します。
判断の基本は、次の三つです。
必要な工程を実施する期間を確保できるか
停止した場合の業務への影響を確認できているか
障害時の復旧方法や代替運用を確認できているか
必要な期間を確保できない場合や、業務への影響が大きいにもかかわらず代替手段を確認できていない場合は、移行の検討を前倒しできるか確認します。前倒しだけでは必要な期間を確保できない場合は、移行対象、移行時期、現行環境を継続する条件、障害時の代替手段を見直します。
必要な期間を確保でき、現行環境を継続する条件と代替手段を確認できている場合は、再評価する時期を決めた上で待つ判断もできます。期限、業務への影響、代替手段のいずれかが分からない場合は、移行先を比較する前に追加確認を行います。
本記事の要点は、次のとおりです。
「始める」とは、本番環境の切り替えではなく、棚卸し、候補比較、検証、予算化を含む移行の検討への着手を指す
判断を保留する場合も、再評価する時期と確認項目を決める
確認担当者、判断者、承認者の役割を分ける
該当項目の数ではなく、業務への影響、必要な期間、代替手段、契約条件、予算、体制を組み合わせて判断する
期間が不足する場合は、検討の前倒しだけでなく、移行対象、移行時期、継続条件、代替手段を見直す
待つ場合も、受け入れるリスクと再評価する時期を決める
複数の環境では、検証や準備を始める順番と、本番環境を切り替える順番を分ける
外部支援を利用する場合も、運用情報、判断、承認の役割を社内で確認できる状態にする
待つことと、何もしないことは異なります。待つ場合も、次に確認する事項、再評価する時期、確認担当者、判断者、承認者を明確にし、契約更新、予算申請、検証、調達に必要な準備を進めます。
必要な工程を逆算し、「いつまでに何を確認するか」「誰が確認し、誰が判断し、誰が承認するか」を明確にすることが、移行の検討時期を決めるための第一歩です。
移行の検討を始めるか、条件を確認した上で待つかを決めたら、次は候補を比較するための評価軸を整理します。
次の記事では、機能だけでなく、運用体制、契約条件、既存環境との関係、移行作業まで含めて、VMware代替候補を比較する方法を解説します。
【 VMware代替を検討する前に整理したい判断軸｜VM Essentialsを含む仮想化基盤の見直し方 】
VMware環境の見直しでは、移行先を比較する前に、保守・契約期限、業務への影響、障害時の代替手段、予算申請の時期を整理し、いつまでに方針を決める必要があるかを確認します。必要な工程を逆算した結果、期間が不足する場合は、検討を前倒しするだけでなく、移行対象の分割、移行時期の見直し、現行環境を継続する条件の確認も必要です。
横河レンタ・リースでは、仮想化基盤の見直しに向けた現行環境の整理、構成の確認、契約・保守情報の確認、複数環境の優先順位に関する相談を受け付けています。相談前には、現行の構成、契約・保守期限、業務上の制約、社内で決まっている移行条件など、確認できる情報を整理しておくと、相談したい内容や未確認事項を明確にしやすくなります。