保守期限が近いサーバーが複数あり、どれも古い。しかし予算にも人手にも限りがあり、今期にすべてを更改することはできない。こうした状況で、多くのIT責任者が「どのサーバーから更改すべきか」という優先順位付けに悩みます。
古い順に並べるだけでは、事業への影響が大きいサーバーが後回しになりかねません。かといって担当者の感覚で決めると、経営層に根拠を説明できず、稟議が通らないこともあります。更改の優先順位は、技術的なリスクだけでなく、事業影響や運用負荷、他システムとの依存関係まで含めて評価する必要があります。
本記事では、サーバー更改の優先順位を決めるための4つの評価軸を示し、それらを組み合わせて優先順位表に落とし込む方法、そして棚卸しから稟議までの進め方を整理します 。
お問い合わせ
お気軽にご相談ください。
まず押さえたいのは、優先順位付けがどんな場面で必要になるかです。
多くの現場では、導入時期の近いサーバーが数年後に一斉に保守期限を迎えます。ある年に複数台の更改時期が重なり、予算の枠にも人手にも収まりきらない、という状況は珍しくありません。すべてを同時に更改できない以上、どれを先に、どれを後に回すかを決めなければ前に進めません。
ここで検討の出発点になるのが、限られた予算と人手をどこに配分するかという発想です。技術的に古いという理由だけでなく、止まったときにどれだけ事業に響くか、運用にどれだけ手がかかっているか、他のシステムとどうつながっているかを合わせて考える必要があります。
現場でありがちなのは、「導入が古い順」や「担当者の感覚」だけで順序を決めてしまうことです。この決め方では、比較的新しくても止まると事業全体が止まるようなサーバーが後回しになり、いざというときに大きな影響が出ることがあります。まずは自社のサーバーを棚卸しし、複数の観点で見比べるところから始めるのが現実的でしょう。
サーバー更改の優先順位付けが難しいのは、判断に関わる要素が一つではないためです。
保守期限だけを見れば順番は付けられそうに思えます。しかし実際には、止まったときの事業影響、日々の運用にかかる負荷、他システムとの依存関係、そして予算と稟議の制約が絡み合います。これらは必ずしも同じ方向を向きません。保守期限が最も近いサーバーが、事業影響では最も小さい、ということも起こります。
担当者が迷いやすいのは、どのサーバーもそれぞれの観点で重要に見えて、順序を付けきれない場面です。さらに、順位を付けても、その根拠を経営層に説明できなければ稟議は通りません。「なんとなく古いから」では予算の裏付けを得にくく、更改そのものが先送りされてしまいます。
こうした難しさを乗り越えるには、複数の観点を明示的な評価軸として整理し、順序の根拠を見える形にすることが求められます。単一の基準で並べるのではなく、軸を分けて評価することが出発点になります。
サーバー更改の優先順位は、次の4つの評価軸で整理すると考えやすくなります。技術・事業・運用・構成という異なる側面から見ることがポイントです。
|
評価軸 |
見るべき観点 |
|
EOL・保守期限 |
メーカー保守の終了時期、部品供給、セキュリティー更新の有無 |
|
障害時の事業影響 |
停止したときに止まる業務の範囲、復旧までの許容時間 |
|
運用負荷・属人化 |
日々の運用にかかる手間、特定担当者しか扱えない状態か |
|
他システムとの依存関係 |
連携するシステムの有無、更改が他へ及ぼす影響 |
保守が切れると、故障時の部品供給やセキュリティー更新が受けられなくなり、リスクが高まります。ただし、保守期限が近いことは重要な要素ではあっても、それだけで最優先とは限りません。
そのサーバーが止まったときに、どの業務が、どれだけの時間止まるのか。影響範囲が広く、許容できる停止時間が短いものほど、優先度は高くなります。
古いサーバーは、運用に手間がかかり、特定の担当者しか対応できない状態になりがちです。運用負荷が高く属人化が進んでいるものは、更改によって負荷と属人化の両方を軽くできる場合があります。
単体では影響が小さく見えても、多くのシステムが依存しているサーバーは、更改の影響も大きくなります。依存関係は、優先度だけでなく更改の順序そのものにも関わります。
これらの軸の重みは、事業特性によって異なります。自社にとって何を重視するかを踏まえて、軸ごとの重み付けを考えることが必要です。
|
あわせて読みたい EOL・EOSL台帳の作り方|更改漏れを防ぐ管理項目と更新ルール 評価の前提となる棚卸しと台帳整備から始めたい方はこちら。 |
4つの評価軸が整理できたら、それらを組み合わせて優先順位に落とし込みます。単独の軸ではなく、掛け合わせて見ることが重要です。
進め方としては、各サーバーを軸ごとに評価し、たとえば高・中・低といった段階でスコア化します。そのうえで、事業影響と緊急度 (保守期限の近さ) を2つの軸に取った優先度マトリクスに配置すると、「事業影響が大きく、かつ保守期限も近い」ものが最優先として見えてきます。運用負荷や依存関係は、この配置を補正する要素として加味します。
ここで注意したいのは、スコアを単純に合計して順番を機械的に決めない、という点です。スコアはあくまで議論の出発点であり、実際の順序は依存関係によって前後します。たとえば、優先度が高いサーバーでも、先に別の基盤サーバーを更改しないと移行できない、という制約があれば、順序は入れ替わります。
向いているのは、評価軸を共通のものさしとして関係者で合意し、順序の根拠を説明できる状態にする使い方です。逆に、スコアの数字だけを絶対視して現場の制約を無視すると、計画倒れになりやすい点に注意が必要です。
優先順位表を作る過程で、見落としやすい点がいくつかあります。ここは順序を決めた後に問題化しやすいところです。
一つは、依存関係のある機器の存在です。あるサーバーを更改すると、連携する機器やソフトも同時に更新が必要になることがあります。これを見落とすと、更改したものの連携がうまくいかず、想定外の作業や費用が発生します。優先順位を付ける段階で、単体ではなく関連する機器をまとめて捉えておくことが必要です。
もう一つは、優先順位表を作ること自体が目的化してしまうことです。順序を決めても、予算の裏付けと実行する体制がなければ更改は進みません。とくに予算は年度で区切られるため、優先度が高くても今年度に枠を取れなければ翌年度に回さざるを得ない、という制約もあります。更改しない場合に高まるリスクと、表を作っても実行できない場合のリスクの両方を見据えて、予算計画と一緒に進めることが求められます。
優先順位付けを具体的に進める場合、次のような段階を踏む進め方が現実的です。
棚卸し:対象サーバーの導入時期、保守期限、用途、依存関係を一覧化する
評価:4つの評価軸で各サーバーを評価し、段階でスコア化する
優先順位付け:事業影響と緊急度のマトリクスに配置し、依存関係で補正する
更改計画:優先度の高いものから、予算年度と体制に合わせて更改の時期を割り当てる
稟議:優先順位の根拠と、更改しない場合のリスクを添えて経営層に説明する
とくに最初の棚卸しが不十分だと、評価も優先順位も稟議の根拠も精度が落ちます。台帳として現状を整理しておくことが、優先順位付けの土台になります。まず棚卸しで現状を把握し、評価軸で順序を付け、根拠を添えて稟議に上げる。この順序で進めることが、判断を誤らず、かつ経営層の合意を得やすくする進め方と考えられます。
|
あわせて読みたい サーバー運用は引き継げる状態か - 続けられる体制を測るための視点 運用負荷や属人化という評価軸を、体制の視点から掘り下げたい方はこちら。 |
保守期限を迎える前に、余裕を持って検討を始めることが望ましいでしょう。更改には棚卸しや稟議、調達、移行の期間が必要なため、保守が切れてから動き始めると、リスクの高い状態が長引くことがあります。台帳で保守期限を把握し、逆算して計画することが現実的です。
環境によって異なります。一般には、止まったときの事業影響が大きく、かつ保守期限が近いものから優先することが多いと考えられます。ただし、運用負荷や依存関係によって順序は変わるため、複数の評価軸を組み合わせて判断することが必要です。
選択肢の一つと考えられます。ただし、先送りは無条件に許容されるものではなく、更改しない間に高まるリスク (障害時の影響、保守切れ) を把握したうえでの判断が前提です。先送りする場合も、リスクを記録し、次年度以降の計画に組み込んでおくことが望ましいでしょう。
更改の際には、同じ構成で買い替えるだけでなく、クラウド移行やレンタルといった選択肢も含めて検討する余地があります。優先順位付けで対象を整理したうえで、それぞれのサーバーに適した調達方式を個別に検討することが望ましいでしょう。
サーバー更改の優先順位は、保守期限という単一の基準ではなく、複数の評価軸を組み合わせて決めることが要点になります。この記事の要点を整理すると、次のとおりです。
すべてを同時に更改できない前提で、順序を決める必要がある
評価軸は、EOL・保守期限、障害時の事業影響、運用負荷・属人化、依存関係の4つ
各軸をスコア化し、事業影響と緊急度のマトリクスで優先度を整理する
スコアは目安であり、依存関係で順序は前後する。機械的な合計だけで決めない
優先順位表を作るだけでは進まず、予算と体制の裏付けが必要
まず棚卸しで現状を把握し、評価軸で順序を付け、根拠を添えて稟議に上げる。この順序で進めることが、更改計画を実行に移すための現実的な進め方と考えられます。
自社のサーバー更改について、どこから手を付けるか、優先順位をどう付けるかの判断が難しい場合は、現状の棚卸しや評価軸の重み付けを一緒に整理する選択肢もあります。検討の入り口として、更改にむけた現状のアセスメントを実施するのも有効な一手です。
横河レンタ・リース株式会社では、日本ヒューレット・パッカード社のPlatinumパートナーとして、IT 機器のレンタル・販売に加え、サーバーの調達から更改計画、運用保守までを組み合わせて提供しています。
更改の優先順位付けや調達方式の検討を自社だけで進めるのが難しい場合は、現状の整理やご相談から始める選択肢もございます。お客さまのIT基盤戦略に合わせてワンストップでのご支援も可能となっていますので、ぜひお気軽にご相談ください。
この記事を書いた人
横河レンタ・リース株式会社
私たちはお客さまに寄り添い、マルチベンダーの強みを活かして、安心して長く使えるITインフラを設計から運用まで一緒につくるシステム事業を展開しています。
お問い合わせ
お気軽にご相談ください。
HVM は、単⼀のインターフェイスからKVMベースとVMwareベース両⽅の仮想マシンをプロビジョニングや管理することが可能です。
横河レンタ・リース株式会社
160-0023 東京都新宿区西新宿1-23-7 新宿ファーストウエスト
Google Map
Copyright©Yokogawa Rental & Lease Corporation All Rights Reserved.