EOL・EOSL対応の進め方｜対象システムの洗い出しから予算化・更改まで

EOL・EOSL対応を「作業」ではなく「計画」として組み立てる

EOL・EOSL対応は7つの工程に分けられます。個別に処理していくと、依存関係の順序と予算年度の制約でつまずくことがあります。

期限が近いものから順に手を付ける。一見すると合理的な進め方に思えますが、実務ではこれが手戻りを生む場面があります。

たとえば、保守期限が最も近いという理由で、あるアプリケーションサーバーを先に更新したとします。ところが数か月後、そのサーバーが参照しているデータベースサーバーの更改が始まる。データベース側のバージョンが上がった結果、先に更新したアプリケーション側の設定を再度見直すことになった。こうした流れは、依存関係を把握しないまま着手した場合に起こり得ます。

対応を工程として捉えると、全体像は次のようになります。

判断のポイントは、単年度で完了する規模なのか、複数年度にまたがるのかを早い段階で見極めることです。対象が数台であれば工程を厳密に分ける必要はありませんが、数十台規模で依存関係が複雑な場合、計画として組み立てないと途中で行き詰まります。

一方で、計画を立てること自体が目的化する状態も避けたいところです。詳細な工程表を作ることに時間を使い、肝心の着手が遅れては本末転倒になります。計画の粒度は対象の規模に合わせるのが現実的でしょう。

なお、EOLとEOSLの違いや、保守終了後に生じるリスクについては【 EOL・EOSLとは？メーカー保守終了後のリスクと対応策  】で整理しています。用語の確認から始める場合は、そちらを先にご覧ください。

なぜ対応順序を決めにくいのか

順序を決めにくいのは、技術的な期限、業務上の重要度、予算年度という3つの軸が一致しないためです。

この3つは、それぞれ別の論理で動いています。保守期限はメーカーの都合で決まり、業務上の重要度は事業の状況で変わり、予算年度は社内の規定に従います。担当者がどれだけ整理しても、この3つが自然に揃うことはありません。

技術的な期限と業務上の重要度のずれ

保守期限が最も近い機器が、業務上最も重要とは限りません。逆に、期限まで2年以上あるサーバーが基幹業務を支えている、という状況もあります。

ここで判断に迷うのは、どちらを優先すべきかという問いに一般的な答えがないことです。判断のポイントは、止まった場合に業務がどう影響を受けるかを、対象ごとに書き出してみることです。期限の近さだけで並べると、影響の大きい資産が後回しになる場合があります。

単体で見るか、依存関係で見るか

対象を単体で評価すると、順序を誤ることがあります。ある機器の期限に余裕があっても、それが他システムの前提になっていれば、連携先の都合で先に手を付ける必要が出てくるためです。

依存関係の把握は手間がかかる作業ですが、着手前に整理しておくと後工程の判断が楽になります。

保守期限と予算年度のずれ

実務で最も詰まりやすいのが、この論点です。

保守期限が年度の途中にある場合、前倒しで対応するか、期限を過ぎてから対応するかの判断が必要になります。前倒しすれば、まだ使える機器を早めに更新することになり、費用の発生時期も前倒しになります。期限を過ぎてから対応すれば、その間は保守を受けられない状態が続きます。

さらに、予算要求のタイミングは年度単位で決まっているのに対し、調達には一定のリードタイムがかかります。予算が通ってから見積もりを取り始めると、納品が翌年度にずれ込むこともあります。

この3つのずれは解消できるものではありません。どれを優先するかを決める問題として捉えるほうが、判断は進みやすくなります。

工程1・2 - 洗い出しと優先順位付けをどこまでやるか

洗い出しの完了条件は、網羅性ではなく、次工程に進める状態になっているかどうかです。

「まず洗い出しから」と考えて着手したものの、いつまでも終わらない。この状態は、完了の基準が決まっていないときに起こります。

洗い出しの完了条件

対象範囲は、物理サーバーやネットワーク機器だけでなく、OS、ミドルウェア、仮想化ソフトウェアのライセンスまでが含まれます。ただし、すべてを同じ精度で調べようとすると着手できません。

次の3点が満たされていれば、優先順位付けへ進める状態と考えられます。

• 対象一覧が業務システム単位で紐付いている

• 主要な対象について依存関係が把握できている

• 期限をメーカーの公表情報で確認しており、推測で埋めた欄が残っていない

注意したいのは、完璧を目指すことと、依存関係を放置することの両方が、後工程で問題になる点です。前者は着手が遅れ、後者は計画そのものが崩れます。網羅性より、判断に必要な情報が揃っているかを基準にするほうが実務的でしょう。

台帳に何を載せ、誰がどの頻度で更新するかについては【 EOL・EOSL台帳の管理項目の決め方 】で扱っています。Windows Serverが対象に含まれる場合、OS、Active Directory、アプリケーション、保守を分けて整理する観点は【 Windows Server更改で確認すること 】にまとまっています。

優先順位表を計画へ変換する

優先順位を付けただけでは、まだ計画にはなりません。順位表は「どれから着手すべきか」を示しますが、「いつ実施するか」までは決めていないためです。

ここで必要になるのが、順位を年度へ割り付ける作業です。今年度に何件、次年度に何件という配分を決め、それぞれの予算要求時期と突き合わせます。この段階で、順位の高い対象が予算の都合で次年度になる、といった調整が発生します。

優先順位をどのような軸で評価するかは【 サーバー更改の優先順位はどう決める？ 】で解説しています。

工程3 - 方針を対象群ごとに割り当てる

方針は全社一律である必要はありません。業務影響度と残存期間の組み合わせで、対象群ごとに異なる方針を取り得ます。

「延命でいくのか、更新でいくのか」を一つに決めようとすると、判断が止まります。対象によって条件が違うためです。

たとえば、業務影響が小さく残存期間も短い機器と、基幹業務を支えていて数年は使い続けたい機器とでは、適した対応が異なります。前者は更新のタイミングを他の対象と合わせる判断もあり得ますし、後者は保守の受け皿を確保しながら計画的に移行する形も考えられます。

判断のポイントは、対象群をどの粒度で分けるかです。細かく分けるほど各群に適した方針を選べますが、契約や更新時期の管理は複雑になります。3つか4つの群に整理し、それぞれに方針を割り当てる形が扱いやすい場合があります。

一方で、方針を分けることの負荷も見ておく必要があります。契約の種類が増えれば、期限管理の対象も増えます。担当者が限られている環境では、管理のしやすさを優先して方針を絞る判断も選択肢の一つと考えられます。

延命、更新、Cloud移行、レンタル・リースといった選択肢について、それぞれがどの条件に適しているかは【  保守切れサーバーを延命するか更新するか 】で比較しています。いずれの方式にも向いている環境と向いていない環境があり、環境によって適合性は異なります。

工程4 - 概算費用と予算化の進め方

予算要求の時期から逆算すると、見積もり取得を始める時期が決まります。予算が通ってから見積もりを取り始めると、納期が年度内に収まらないことがあります。

この工程は、技術的な検討が一段落した後に始まると考えられがちですが、実際には方針の検討と並行して進める必要があります。

予算要求の時期から逆算する

社内の予算要求スケジュールは、多くの場合、年度の数か月前に締め切りがあります。そこへ間に合わせるには、概算の見積もりが手元にある状態を作らなければなりません。

見積もりを取るには、構成をある程度固める必要があります。構成を固めるには、方針が決まっている必要があります。この連鎖を逆算すると、予算要求の締め切りから相当さかのぼって着手すべきことが見えてきます。

判断ミスが起きやすいのは、この順序を逆にしてしまう場面です。「予算が付いてから具体的に検討しよう」と考え、承認後に見積もりを依頼する。ところが機器の納期が想定より長く、年度内の納品に間に合わない。結果として、予算を翌年度へ繰り越すか、構成を変更するかの判断を迫られることになります。

単年度と複数年度の分け方

対象が多い場合、すべてを単年度で処理するのは現実的ではありません。複数年度に分割する場合、どこで区切るかの判断が必要になります。

区切り方の考え方としては、依存関係のまとまりで分ける方法があります。相互に連携するシステム群を同じ年度に配置すれば、移行時の整合性を取りやすくなります。逆に、依存関係の途中で年度をまたぐと、中間状態が長く続くことになります。

なお、費用の分類や社内での扱いは、調達の方式によって変わります。技術部門だけで判断せず、早い段階で経理部門と認識を合わせておくことが望まれます。支出の時期や社内での扱いについて認識が食い違うと、後工程で計画の見直しが必要になる場合があります。

工程5・6 - スケジュール調整と事前確認

台帳と優先順位が整っていても、業務停止の合意が取れなければ実行できません。停止調整は計画段階から並行して進める必要があります。

技術的な準備が整い、予算も確保できた。あとは実施するだけ、という段階で計画が止まる。その原因の多くが、この工程にあります。

停止調整はいつから始めるか

サーバーの更改には、多くの場合、業務の停止が伴います。夜間や休日に作業する場合でも、翌営業日に問題が起きた際の対応を含めて、業務部門との合意が必要です。

判断のポイントは、停止の相談をいつ始めるかです。実施日の直前に相談すると、業務部門の都合で数か月先へずれることがあります。繁忙期や決算期など、業務側に動かせない期間があるためです。

対象システムを使う部門が複数にまたがる場合、調整の相手も増えます。誰に、どの順番で話を通すかを整理しておくと、調整の期間を短縮できる場合があります。

ここで見落とされやすいのが、外部委託先の稼働状況です。作業を委託している場合、こちらの希望日に対応できるとは限りません。委託先のスケジュールを早めに確認しておかないと、社内の調整が整った時点で作業者が確保できない、という事態になります。

切り戻しの判断基準を決めておく

更改作業には、想定どおりに進まない可能性が常にあります。移行後の動作確認で問題が見つかった場合、元の状態へ戻すかどうかの判断が必要になります。

この判断基準を事前に決めていないと、当日の状況で判断することになります。作業が長引き、判断する人も疲弊している状況では、適切な判断が難しくなります。

事前に決めておきたいのは、次の3点です。

• どの状態になったら切り戻すか

• 何時までに判断するか

• 誰が判断するか

注意点として、台帳や管理ツールが整っていても、この部分は自動的には埋まりません。停止の合意も、切り戻しの基準も、人が決めて合意する必要があります。ツールの導入だけでは解決しない領域があることは、計画段階から想定しておく必要があります。

事前の検証と移行後の確認項目

切り戻しの基準を決めるには、その前提として「何をもって正常と判断するか」が定まっている必要があります。

事前の検証をどこまで行うかは、対象の重要度と、検証環境を用意できるかによって変わります。本番と同等の環境を用意できる場合と、限られた範囲でしか確認できない場合とでは、取れる手段が異なります。検証の範囲を決める際は、どこまで確認すれば移行の判断ができるかを基準にすると、過不足を抑えやすくなります。

あわせて用意しておきたいのが、移行後の確認項目です。サーバーが起動したことと、業務が正常に動くことは別の問題です。連携先のシステムからの接続、定期実行しているバッチ処理、業務部門が日常的に使う機能。これらのうち何を確認するかを事前にリスト化しておくと、当日の判断が速くなります。確認項目は、切り戻しの判断基準とそのまま対応させておくと運用しやすいでしょう。

先送りした場合に何が起きるか

停止調整が後手に回ると、実施時期が業務都合で数か月ずれることがあります。保守期限まで余裕があれば吸収できますが、期限が迫っている場合、そのずれがそのまま保守切れの期間になります。

保守を受けられない状態で運用を続ける期間が生じると、その間に障害が発生した際の復旧手段が限られます。また、期限直前に慌てて手配すると、費用や納期の面で不利な条件を受け入れざるを得ない場合もあります。

対応を先送りする判断そのものが誤りとは限りません。ただし、先送りによって何が起きるかを把握したうえでの判断と、把握しないままの先送りとでは、意味が異なります。

工程7 - 実施後に何を残すか

更改の完了は次のサイクルの起点です。次の担当者が一から調査を始めずに済む状態にすることが、この工程の目的になります。

作業が終わると、そこで一区切りついた気持ちになります。しかし記録を残さないまま次の業務へ移ると、数年後に同じ調査を繰り返すことになります。

残しておきたいのは、更改後の状態だけではありません。なぜその方針を選んだのかという判断の経緯が、次回の検討で役立ちます。延命を選んだ理由、Cloud移行を見送った理由。当時の条件とあわせて記録しておくと、次のサイクルで同じ検討を一からやり直す必要がなくなります。

担当者の異動や退職は、多くの現場で起こります。保守期限を把握しているのが特定の担当者だけ、という状態は、その担当者がいなくなった時点で情報が失われることを意味します。

台帳をどう更新し続けるかについては【  EOL・EOSL台帳の更新ルールの作り方 】で扱っています。更新のきっかけを決めておくことが、形骸化を防ぐうえで有効な場合があります。

よくある質問

Q1. 予算年度をまたぐ場合、どのように分割すればよいですか

分割の方法に一般的な正解はありませんが、依存関係のまとまりで区切る考え方があります。相互に連携するシステムを同じ年度に配置すれば、移行時の整合性を取りやすくなります。逆に、依存関係の途中で年度をまたぐと、旧環境と新環境が混在する期間が長くなります。ただし、対象の規模や予算の制約によって取り得る分け方は変わるため、環境によって異なります。分割の方針が固まった段階で、早めに経理部門と認識を合わせておくことが望まれます。

Q2. 停止調整はいつから始めればよいですか

一律の目安を示すことは難しく、対象システムを使う部門の数や、業務側の繁忙期の有無によって変わります。考え方としては、実施希望日から逆算し、業務部門での検討期間、社内の承認手続き、外部委託先の日程確保に必要な期間を積み上げる方法があります。相談を始めた結果、業務側の事情で数か月先になることもあるため、余裕を持った着手が望まれます。

Q3. 担当者が一人しかいない場合、どこから着手すべきですか

すべての工程を同じ精度で進めることは現実的ではありません。優先度が高いのは、対象の洗い出しと依存関係の把握です。この2つが未整理のまま先へ進むと、後工程で計画の見直しが発生しやすくなります。一方、方針の詳細な比較や複数年度の計画は、対象が絞り込まれた後でも間に合う場合があります。また、記録を残す工程は、担当者が一人であるほど重要になります。属人化した状態で情報が失われると、次の対応時に一から調査を始めることになるためです。

まとめ

EOL・EOSL対応は、対象の洗い出しから更改後の記録まで7つの工程に分けられます。すべてを一度に進める必要はなく、自社がどの工程で止まっているかを見極めることが出発点になります。

各工程の完了の目安は、次のとおりです。

判断が難しくなるのは、技術的な期限、業務上の重要度、予算年度という3つの軸が一致しないためです。この3つのずれは解消できるものではなく、どれを優先するかを決める問題として扱うほうが、判断は進みやすくなります。

次に行う作業としては、自社の対象一覧を見ながら、どの工程まで進んでいるかを確認することが挙げられます。特に、停止調整と切り戻しの基準が未整理であれば、計画段階のうちに着手しておくと、実行時の負荷を減らせる場合があります。

自社の構成で判断が難しい場合は、現行環境の確認や更改方針の整理について相談する選択肢もあります。

 横河レンタ・リース株式会社では、日本ヒューレット・パッカード社のPlatinumパートナーとして、IT 機器のレンタル・販売に加え、サーバーの調達から更改計画、運用保守までを組み合わせて提供しています。
保守切れサーバーへの対応方針の検討を自社だけで進めるのが難しい場合は、現状の整理やご相談から始める選択肢もございます。お客さまのIT基盤戦略に合わせてワンストップでのご支援も可能となっていますので、ぜひお気軽にご相談ください。 

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