絞り込みが進まないのは、比較の出口が定まっていないためです。誰が、いつまでに、何をもって決めるのか。決裁者が見たいのは機能一覧ではなく、なぜその選択肢なのかという説明です。出口が定まっていないと、集める情報の方向も定まりません。
候補を増やすほど判断は遅れます。明らかに条件に合わないものは早い段階で外す判断も必要です。ただし外した理由は記録してください。決裁の場で「なぜ他ではないのか」を問われたときの説明材料になります。
比較軸は技術要件、運用体制、契約と費用、移行作業の四層に分けます。この四つが同時に絡むために判断が難しくなっており、どれか一つだけで決めると後工程で戻るためです。技術要件だけで選べば運用が回らず、費用だけで選べば移行工数が想定を超えます。
技術要件では、必要な機能の充足、可用性の前提条件、既存構成との適合、扱えない用途の有無。運用体制では、日常運用の手順、習熟にかかる期間、監視やバックアップとの連携。契約と費用では、契約単位、保守条件、更新時期、調達方式。移行作業では、移行方式、必要な停止時間、周辺製品の対応可否、切戻しの成立条件を確認します。
|
層 |
何を確認するか |
情報の入手先 |
|
技術要件 |
必要な機能の充足／可用性の前提条件／既存構成との適合／扱えない用途の有無 |
製品情報、販売元への確認、検証 |
|
運用体制 |
日常運用の手順／習熟にかかる期間／監視・バックアップとの連携 |
運用手順書、担当者の経験、サポート条件 |
|
契約と費用 |
契約単位／保守条件／更新時期／調達方式 |
契約書、見積もり、調達部門 |
|
移行作業 |
移行方式／必要な停止時間／周辺製品の対応可否／切戻しの成立条件 |
棚卸し結果、販売元への確認 |
四層のうち、比較の段階で最も粗く扱われやすいのが運用体制です。実際に運用が回るかどうかは、次の四つを分けて確認しないと分かりません。
監視。
既存の監視の仕組みが新しい基盤に対応するか。対応しない場合、通知先としきい値の設計をやり直すことになります。この工数は移行費用に含まれていないことがあります。
バックアップ。
取得と復元の両方が現行と同じ方式で成立するか。復元手順が変わるなら、手順書の作り直しと訓練が必要になります。
権限。
誰が何を操作できるかを、移行を機に整理し直す必要があるか。
一次対応。
障害時の切り分けをどこまで自社で行い、どこからサポートに渡すか。この線引きが決まっていないと、サポート条件を比較しても評価する基準が定まりません。
四層のうち、自社にとってどこが最も制約になっているかを先に決めます。運用を担う人が一人しかいない組織であれば運用体制の重みが大きくなり、止められる時間が極端に短い業務があるなら移行作業の重みが上がります。
重み付けをしない比較表は、項目を並べただけで結論に結びつきません。すべての項目に同じ重さで印をつけると印の数が多い候補が有利になりますが、その候補が自社にとって重要な項目を満たすとは限りません。
重みを決めたら、その根拠を一行で書き残してください。決裁の場で「なぜその軸を重視したのか」を説明する材料になります。
なお、重み付けは技術部門だけで決められないことがあります。費用の制約や判断の期限は経営側の事情に左右されるためです。また、四層を埋めるには現状の構成と契約の整理が必要です。埋まらない欄が出た場合、そこが棚卸しの不足箇所です。
|
【あわせて読みたい】 VMware環境の棚卸し方法｜移行検討前に確認する構成・契約・依存関係 比較軸を埋める前提となる構成・契約・依存関係の洗い出しはこちら。 |
選択肢は製品名で並べる前に、方向性の類型で整理すると見通しがよくなります。
別の仮想化基盤ソフトウェアへ移す方向は、既存のハードウェア資産を一定期間使い続けられる場合に向きます。管理体系が変わることによる運用手順の作り直しが論点です。構成方式ごと見直し集約された構成に寄せる方向は、ストレージを含めた更新時期が近い場合に向き、増設の単位と障害時の影響範囲が変わります。対象システムごとにクラウドへ移す方向は、業務単位で切り出せる構成であることが前提です。
四つめは、現行を継続して時間を稼ぐ方向です。更新時期まで期間があり移行費用が削減効果を上回るなら、合理的な選択肢の一つです。ただし「何もしない」とは違います。継続するなら、いつ再評価するかを決めておく必要があります。この判断は前の記事で扱っています。
見落とされやすいのは、ライセンス以外の費目です。ソフトウェアとハードウェアに加え、移行作業、新旧を同時に持つ並行稼働、担当者の教育、監視やバックアップの設定変更、日常の運用工数、保守費用を積み上げます。
これを単年度ではなく数年間の総額で見ることが前提になります。初年度だけを比較すると初期費用の小さい選択肢が有利に見えますが、運用と保守を含めると順位が入れ替わることがあります。
積み上げた結果、乗り換えた方が高くつくという試算になる場合も考えられます。これは失敗ではなく、比較した結果として正当な結論です。総額で見ないと、この判断ができません。なお、契約単位や保守条件は、自社の契約書と契約窓口で確認する領域です。
例えば、次のような状況を想定してみます。機能比較表を二十項目つくり、候補三件を評価し、最も印の多い候補を推奨として会議に持ち込んだ。ところが返ってきたのは機能の質問ではなく、「他の候補を外した理由は」「これを選んで止まったらどうなるのか」「いつまでに決めないといけないのか」の三つだった。技術的な比較は十分でも、決裁の場で問われるのは別の観点だった、というケースです。
不足しているのは、次の四つのいずれかであることが考えられます。
一つめは、選ばなかった選択肢の説明です。決裁者が知りたい「なぜこれなのか」は、「なぜ他ではないのか」と表裏一体です。
二つめは、リスクの提示です。選んだ選択肢にも必ず不利な点があります。伏せた資料はかえって信用されにくくなります。どう抑えるかまで書けば、判断材料として機能します。
三つめは、判断期限の明示です。逆算の手順は前の記事で扱っています。ここでは、逆算した結果が資料に転記できているかを確認してください。予算が年度で区切られている場合、判断期限は技術的な期限より手前に来ます。
四つめは、体制の裏付けです。移行を誰が担い、移行後の運用を誰が続けるのか。ここが空白のまま製品だけ決まると、実行の段階で止まります。
仮想化基盤は業務システムのほぼすべてが乗る土台です。決裁の場では技術的な優劣よりも、止まったときの影響とそれを避ける道筋を問われる場合があります。資料の構成も、これを想定して組み立てると説明しやすくなります。
進め方は、現状の棚卸し、比較軸の設定と重み付け、候補の絞り込み、検証、評価と結論、決裁の六段階に分けられます。
重要なのは、絞り込みと検証の間で、実機検証に回す候補を決めておくことです。絞り込む数に一般解はなく、確保できる検証機材、割ける人員、判断期限までの残り期間から逆算して決まります。書類で外せるものは外し、実機で確かめないと判断できない点が残る候補だけを検証に回してください。
検証に入る前に、合否の基準を決めておく必要があります。基準がないまま始めると、動いたかどうかしか分からず判断には使えません。何を検証しどう合否を決めるかは、後続の記事「VMware移行PoCで検証すべき項目」で扱います。
|
【あわせて読みたい】 VMware代替の検証はこれで解決！「オールインワン PoCメニュー」で始めるVM Essentials導入ガイド 検証環境の確保が難しい場合の具体的な選択肢を確認したい方はこちら。 |
一律の目安はありません。残せる数は、検証機材、人員、残り期間で決まります。多く残すほど負荷が増え、判断は遅れます。明らかに合わないものは早い段階で外して構いませんが、理由は記録しておくと決裁の場で説明できます。
契約単位、サポート条件、周辺製品の対応可否は資料で確認できますが、実際の操作手順、障害時の挙動、既存環境との組み合わせは動かさないと分かりません。書類で外せる候補はそこで外し、残った候補で判断材料を確定させる進め方が考えられます。
候補が挙がった後の絞り込みは、比較軸をどう設計し重み付けするかで決まります。要点は次のとおりです。
候補を並べることと絞ることは別の作業で、絞るには重み付けが必要になる
比較軸は技術要件、運用体制、契約と費用、移行作業の四層に分ける
運用体制は監視、バックアップ、権限、一次対応の四つに分けて確認する
重み付けは、最も制約になっている層から決める
費用は単年度ではなく数年の総額で見る
検証に回す候補数は、検証機材、人員、残り期間から逆算する
比較を止めているのは、多くの場合、情報量の不足ではなく重み付けの不在です。どこが自社の制約になっているかが決まれば、同じ資料でも順位はつきます。
比較軸の重み付けや候補の絞り込みは、現状の構成と契約が整理されていることが前提になります。ここが埋まらないまま比較を進めると、後工程で戻ることになります。
現行構成の確認や契約条件と更新時期の整理は、外部の視点を入れて進める方法もあります。横河レンタ・リース株式会社では、日本ヒューレット・パッカード社のPlatinumパートナーとして、仮想環境のアセスメントから設計、構築、移行、運用保守までを提供しています。現状の構成・契約情報の整理からご相談いただけます。