ITインフラ刷新の候補をどう絞る？採用・見送り条件の整理方法

製品比較の前に、今回の判断範囲を決める

最初に決めるのは、候補の順位ではありません。今回の刷新で何を変え、何を変えないのかという判断範囲です。

保守期限を迎える機器だけを更新するのか。性能や容量も見直すのか。監視、バックアップ、障害対応、構成管理まで対象に含めるのか。ここが曖昧だと、候補ごとに評価している範囲が変わります。

例えば、機器の機能と価格だけを比較した候補と、移行や運用支援まで含めた候補を同じ表に並べても、条件はそろいません。次の3点を一文ずつ書き出し、比較の対象範囲を固定します。

• 今回の刷新で解決したいこと

• 今回変更する対象

• 今回は変更しない対象

刷新の完了条件も決めておきます。機器が動作した時点を完了とするのか、業務を再開できた時点なのか、監視やバックアップを含む通常運用へ移れた時点なのか。完了条件によって、候補へ求める内容が変わります。

ITインフラ全体の対象範囲や更新の優先順位をまだ整理できていない場合は、ITインフラの全体像をどう捉えるかで棚卸しの単位を確認してください。同記事では、端末、ネットワーク、基盤、横断機能の4層に分け、保守終了や属人化、運用負荷などから優先順位を考える方法を解説しています。

本記事では、その後の候補選定に焦点を絞ります。

採否を左右する「変えられない条件」を先に出す

構成候補を比べる前に、自社側では変更しにくい条件を洗い出します。ここで見つかった条件は、単なる確認項目ではなく、候補を残すかどうかの基準になります。

業務停止と移行期限

はじめに確認したいのは、どの業務を、いつ、どこまで止められるかです。

必要な機能を備えた構成でも、移行に必要な停止時間を確保できなければ、そのまま採用には進めません。調達、検証、切り替えを期限までに終えられるかも確認します。

すべての業務へ同じ条件を当てはめず、次のように分けます。

• 停止できない業務

• 限られた時間だけ停止できる業務

• 停止中の代替手段を用意できる業務

• 段階的に移行できる業務

この段階で詳細な移行手順を作る必要はありません。候補構成に必要な移行方法が、自社の停止条件で成立するかを見極めます。

現行環境との依存関係

続いて、採否へ直接影響する依存関係を確認します。

対象機器や基盤だけでなく、業務アプリケーション、ネットワーク、認証、データ、外部接続、バックアップ、監視との関係を見ます。すべてを詳細に説明できなくても、変更によって影響する範囲は把握しておかなければなりません。

比較表には、次の問いに対する確認結果を記録します。

• 現行の業務アプリケーションを継続して利用できるか

• 認証や権限の仕組みを引き継げるか

• データの移行と整合性確認が成立するか

• 外部システムとの接続を継続できるか

• 現在のバックアップや監視を引き継げるか

• 既存契約の変更や解約が必要になるか

現行構成の棚卸し方法は、ITインフラ構築の進め方で詳しく扱っています。同記事では、現状把握、要件定義、設計、調達、構築・移行、運用引き継ぎまでの流れを整理しています。

本記事の比較表には、候補の採否に影響する依存関係だけを転記します。

採用条件は「必須」と「希望」に分ける

本記事では、候補の評価軸や重み付けではなく、候補を残すか、外すか、追加確認へ回すかを管理する方法に焦点を当てます。

仮想化基盤における技術、運用、契約、移行の比較軸については、VMware代替候補をどう比較するかで詳しく整理しています。同記事では、四つの層による比較と、各項目の重み付けを扱っています。

候補を絞れない原因の一つは、必須条件と希望条件が同じ表に並んでいることです。

性能を高めたい、管理方法を統一したい、将来の増設に備えたい。いずれも意味のある要望ですが、すべてが採用に欠かせないとは限りません。条件を増やすほど、小さな機能差に目が向き、判断しにくくなります。

満たさなければ候補に残せない必須条件

必須条件は、満たせなければ候補として残せない条件です。

業務の継続に必要な機能、現行環境との接続、データ移行の成立、セキュリティー要件、保守を受けるための条件などが該当します。

「あると便利」という要望まで必須条件へ入れないことがポイントです。満たさない場合に何ができなくなるのか、業務へどのような影響が出るのかを説明できる条件に絞ります。

範囲や時期を調整できる条件

希望条件の中には、範囲、時期、運用方法を見直すことで調整できるものがあります。

一度にすべてを移行せず段階的に進める、対象範囲を分ける、運用開始後に機能を追加するといった選択肢です。ただし、調整によって費用、期間、責任範囲がどう変わるかは別途確認します。

調整できるという理由だけで、採用条件を満たしたとは扱いません。調整内容とあわせて、承認する担当者も決めておきます。

追加対応で補える可能性がある条件

製品単体では満たせなくても、別の仕組み、契約、運用作業によって補える場合があります。

追加対応の内容と実施担当が決まっていなければ、補完可能とは判定できません。少なくとも、次の項目を記録します。

• 追加する仕組みや作業

• 追加対応の担当者

• 費用やスケジュールへの影響

• 追加対応後の確認方法

• 条件を受け入れる承認者

追加対応が成立するか確認できるまでは、採用判断を確定せず、回答待ちの条件として管理します。

見送り条件を決めると、比較表が判断表に変わる

採用条件だけを並べると、各候補の利点を足し上げる比較になりがちです。見送り条件を先に決めておくと、候補を外す理由を自社の要件に沿って説明できます。

見送り条件は、製品や方式の欠点を示すものではありません。今回の業務、移行、運用条件に適合しないことを示す基準です。

業務・技術に関する見送り条件

• 必須の業務要件を満たせない

• 現行環境との接続や連携を確認できない

• 必要なセキュリティー要件を満たせない

• 追加対応による補完方法を確認できない

移行に関する見送り条件

• 許容できる停止時間内で移行できない

• データ移行の成立条件を確認できない

• 問題発生時の切戻し方法を決められない

• 業務再開の確認条件を設定できない

運用・契約に関する見送り条件

• 導入後の監視や障害対応を担当できない

• 保守や支援の対象範囲を確認できない

• 社内と委託先の責任分界を決められない

• 追加対応による費用、期間、体制への影響を受け入れられない

見送り条件に該当しても、直ちに候補から外すとは限りません。追加対応によって補える可能性があるなら、確認を継続する候補として残します。

ただし、その状態で採用判断は確定しません。追加対応の内容、確認先、判断者、期限を決めた上で再判定します。

空欄のまま比較表を完成扱いしない

比較表の空欄は、単なる記入漏れなのか、回答待ちなのか、実機でなければ確認できないのかが分かりません。

空欄を埋める前に、その未確認事項が採否へ影響するかを確認します。

未確認事項には、少なくとも次の情報を付けます。

• 何が分かっていないか

• 採否へどう影響するか

• 資料確認、問い合わせ、PoCなど、どの方法で確認するか

• 誰に確認するか

• 誰が確認を担当するか

• いつまでに回答を得るか

• 回答後に誰が判断を更新するか

条件が変わった場合に再評価するかどうかも記録します。現時点で採用できない候補でも、運用体制、契約条件、移行期限などが変われば、評価を見直せる可能性があるためです。

なお、この分類は候補の状態と次の行動を整理するための、本記事独自の方法です。

見送った理由も比較表に残す

候補を外すときは、候補名を比較表から削除するだけで終わらせず、見送った理由を残します。

社内説明では、「なぜこの候補を選んだのか」と同じくらい、「なぜほかの候補ではないのか」を問われます。見送り理由が残っていなければ、検討の経緯を改めて調べなければなりません。

記録する内容は、長い評価書でなくても構いません。

• 該当した見送り条件

• 確認した資料または確認先

• 補完方法の有無

• 判断した担当者

• 判断日

• 条件変更時の再検討要否

見送り理由は、製品や方式の一般的な欠点として書かないことも大切です。

「この方式は運用が難しい」ではなく、「現在の体制では必要な運用担当者を配置できない」と、自社条件との関係で記録します。条件が変われば、将来の評価も変わる可能性があるからです。

移行できるかを採否条件に含める

構成の採用を決めてから移行方法を考えると、切り替え条件が成立せず、候補の見直しが必要になる場合があります。

比較段階では詳細な作業手順を作るのではなく、次の条件が成立するかを確認します。

• 移行対象と対象外を分けられるか

• 許容できる停止時間内で進められるか

• 移行前後の確認項目を決められるか

• 問題が見つかった場合に切り戻せるか

• どの状態をもって業務再開とするか

• 旧環境を廃止できる条件は何か

システムが起動しただけでは、業務を再開できるとは限りません。業務アプリケーション、データへのアクセス、外部連携、監視、バックアップまで確認する必要がある場合は、それらも採用条件へ含めます。

続行、中止、切戻しを判断する担当者も決めておきます。移行方式やデータ同期の方法によって、戻せる範囲や判断時点は変わります。一律の手順を当てはめず、対象環境に合わせて条件を定めます。

導入後に誰が判断し、誰が動くのかを決める

技術要件を満たしていても、運用体制を確認できるまでは採用判断を保留する必要があります。

ここで整理するのは、内製か外部委託かという二択ではありません。障害やセキュリティー上の異常が発生した後の流れを、作業単位で分けます。

「監視を委託する」「保守契約を付ける」という表現だけでは、障害後に誰が動くのか判断できません。

保守契約と業務復旧も分けて確認します。機器の交換や技術問い合わせが保守対象でも、設定の復元、システム全体の動作確認、業務アプリケーションの確認まで同じ範囲に含まれるとは限りません。

運用を外部へ任せる場合も、委託する作業だけでなく、社内に残る判断を明らかにします。業務の優先順位、停止の許容範囲、構成変更の承認、セキュリティー方針、業務再開の判断など、社内で担う領域を確認します。

公共機関向けの記事ですが、運用、調達、委託範囲を含む確認方法は、公共のITインフラ更改で決めておくことでも詳しく解説しています。同記事では、監視後の判断、保守範囲と業務復旧の違い、外部支援を利用する際の責任分界を扱っています。

ITインフラ刷新の採否判断シート

候補ごとに、次の項目を一つの表へまとめます。

「条件の扱い」には、必須、調整可能、追加対応で補完可能のいずれかを記載します。

「確認状況」には、確認済み、回答待ち、PoCなどの追加確認が必要、条件不一致といった具体的な状態を記載します。空欄のままにせず、次に必要な行動が分かる表現にしてください。

詳細を管理する場合は、別表で次の項目を追加します。

• 確認方法

• 確認先

• 担当者

• 確認期限

• 判断を更新する担当者

• 条件変更時の再評価要否

このシートは、候補を点数で順位付けするものではありません。採用できない理由、追加確認が必要な理由、次に誰が動くのかを共有するためのものです。

※本シートは、ITインフラ刷新の検討事項を整理するためにSysBiz編集部が作成したものです。公的機関やメーカーが定めた基準ではありません。必要な項目は、対象システム、移行方式、契約、運用体制に合わせて調整してください。

まとめ

候補を増やす前に、見送り条件を決める

ITインフラ刷新で構成候補を絞れないときは、製品情報を追加で集める前に、判断条件を見直します。

今回の対象範囲を定め、必須条件と希望条件を分け、何を満たさなければ見送るかを決めます。分からない項目は空欄にせず、採否への影響、確認方法、確認先、担当者、期限を記録してください。

移行できるか、導入後に誰が判断し、誰が動くかも採用条件へ含めます。技術的に導入できても、移行や運用の条件を確認できなければ、採用判断を確定できません。

採用した理由と見送った理由を同じ表に残せば、比較結果を社内で説明しやすくなります。次に集めるべき情報も明確になります。

候補を増やすことより、判断条件をそろえること。それが構成選定を前へ進める出発点です。

あわせて読みたい

現行環境の対象範囲を整理したい方

棚卸しから構築・移行までの流れを確認したい方

運用、セキュリティー、調達をまとめて検討したい方

仮想化基盤の候補を比較している方

ITインフラ刷新の判断条件を整理できない場合は

構成候補の比較では、機器の仕様だけでなく、移行、監視、障害対応、保守、導入後の運用まで含めた整理が必要です。

構成候補を比較しても、採用条件、移行条件、導入後の運用体制や責任分界を整理しきれない場合は、当社、横河レンタ・リースへぜひご相談ください。

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