EOLは製品としての終わり、EOSLはメーカーに頼れる最後の期限を指します。似た言葉ですが、この違いが、自社に残されている選択肢を左右します。
EOLは End of Life の略で、製品ライフサイクルの終了を意味します。メーカーが製造を終了し、技術サポートを段階的に縮小していく局面を指します。EOLの段階では、多くの場合すでに新規の調達が難しくなっており、サポートの範囲も限られていきます。
EOSLは End of Service Life の略で、メーカーが提供する保守、修理、技術支援といったサービスが完全に終了するタイミングを指します。EOLが「製品としての終わり」を示すのに対し、EOSLは「メーカーに頼れる最後の期限」と捉えると整理しやすいでしょう。
IT関連の資料では EOS という略語も頻繁に登場します。
|
用語 |
正式名称 |
意味 |
主な影響 |
|
EOS |
End of Sale |
製品の販売終了 |
新規購入不可。既存ユーザー向け保守は継続する場合あり |
|
EOL |
End of Life |
製品ライフサイクルの終了 |
製造終了。サポートが段階的に縮小 |
|
EOSL |
End of Service Life |
メーカー保守・サポートの終了 |
修理、技術支援、セキュリティー更新が終了 |
一般には、販売終了から保守終了へ向かって段階的に進むと整理されます。ただし段階の名称と順序はメーカーによって異なり、End of Life を最終段階として扱う例もあります。社内で共有する際は、対象製品のメーカーが使う名称に合わせて確認してください。
学校の教科書にたとえるなら、製造終了は絶版になって書店で買えなくなった状態、保守終了は出版社に問い合わせても正誤表を出してもらえなくなった状態にあたります。
ここで一つ注意が必要です。EOS を End of Sale の意味で使うメーカーもあれば、End of Support として使うメーカーもあります。用語だけで判断せず、対象製品の公式情報で「何が、いつ終了するのか」を確認することが欠かせません。
EOLやEOSLが設けられるのは、メーカーが古い製品を切り捨てるためではありません。OSやセキュリティー基準、通信プロトコルは絶えず進化しており、旧世代の設計では新しい要件に対応しきれなくなります。加えて、製造終了から年数が経つと交換用部品の在庫が払底し、修理に必要な技術者の確保も難しくなります。
利用する企業にとっては、EOSLまでの期間が「次の環境へ安全に移行するための準備期間」にあたります。この見方に立つと、EOLやEOSLは対応を迫られる期限ではなく、計画を組み立てるための起点として扱えるようになります。
保守が終了した機器を使い続けるリスクは4つに整理できます。ただし実務で問題になるのは、それらが同時に、しかも判断の選択肢が狭まった状態で表面化する点です。
|
リスク |
内容 |
|
障害時の復旧遅延 |
部品交換と技術支援を受けられず、復旧が長期化する |
|
セキュリティー |
脆弱性が見つかっても修正プログラムが提供されない |
|
コスト増加 |
部品の市場在庫が枯渇し、調達費用が上昇する |
|
コンプライアンス |
取引先や監査に対する説明が難しくなる |
このうち、復旧遅延とコスト増加は切り離せない関係にあります。メーカー保守が終わった機器で障害が発生すると、部品を市場在庫から探すことになり、そこで初めて価格の高さと納期の長さに直面します。復旧が長引けば業務停止の損失も積み上がり、結果として計画的に更新していれば発生しなかった費用が生じることになります。
セキュリティー面の懸念も見過ごせません。修正プログラムの提供が止まった機器は、新たな脆弱性が公表されても対処が難しい状態に置かれます。製品によっては、サポート終了後に限定的な更新提供の仕組みが用意される場合もありますが、恒久的な対策とは異なります。近年は取引先から情報セキュリティーの体制について確認を求められる機会も増えており、保守切れの機器が残っていること自体が、説明の難しい状況につながる場合があります。
対応が後手に回る背景には、いくつかの共通した判断のつまずきがあります。
最も多いのは、「まだ動いているから」という理由で先送りするケースです。稼働しているうちは業務に支障が出ないため、更新の優先度は下がり続けます。しかし障害が起きてから動き始めると、比較検討も相見積もりも取れないまま、目の前にある選択肢を選ぶしかなくなります。先送りは判断を保留しているように見えて、実際には将来の選択肢を減らす決定になっています。
次に多いのが、サーバーだけを更新し、周辺のソフトウェアや連携先を見落とすケースです。ハードウェアの更新計画は立てたものの、その上で動いているミドルウェアのバージョン、他システムとの連携条件、業務アプリケーションの動作要件までは確認していなかった。切り替えの直前になって、想定していなかった追加作業や費用が判明する、という流れです。ハードウェアの期限だけを追いかけると、こうした見落としが起きやすくなります。
期限直前の駆け込み手配も、費用と納期の両面で不利な条件を招きます。また、延長保守や第三者保守を恒久的な解決策と捉えてしまうケースもあります。これらは時間を確保する手段として有効な場合がありますが、提供期間には限りがあることを前提に扱う必要があります。
こうした遅れの背景に、保守契約の期限を把握しているのが特定の担当者だけ、という状況が横たわっていることも少なくありません。担当者の異動や退職をきっかけに、期限が誰にも見えなくなる。管理の仕組みそのものを見直す必要がある場合は、EOL・EOSL台帳の管理項目の決め方を参照してください。
EOL・EOSL対応は、「洗い出し」「優先順位」「方針決定」「予算化」という4つの判断に分けられます。どこで止まっているかを見極めることが、着手の出発点になります。
|
ステップ |
やること |
主な判断 |
|
1 |
対象を洗い出す |
どこまでを対象範囲にするか |
|
2 |
優先順位を付ける |
何から着手するか |
|
3 |
方針を選ぶ |
延命、更新、Cloud移行のどれか |
|
4 |
予算化・稟議へ進める |
費用をどう整理し、誰に説明するか |
|
5 |
実施と継続管理 |
更改後、何を残すか |
本記事では各ステップの要点を示します。詳細は各ステップの解説記事で扱います。
まず、何が対象になるのかを把握します。物理サーバーやネットワーク機器といったハードウェアだけでなく、OS、ミドルウェア、仮想化ソフトウェアのライセンスまでが対象範囲に含まれます。完璧な網羅を目指すと着手できなくなるため、業務への影響が大きい資産から始めるのが現実的です。
期限そのものは、メーカーが公表する情報を基本の情報源とします。多くのメーカーは、製品のライフサイクルやサポート期限に関する情報を公式サイト上で公開しており、型番や製品名から検索できる仕組みを備えている場合もあります。
ただし、情報の掲載場所は製品分野ごとに分かれていることが少なくありません。サーバー、ネットワーク機器、ソフトウェアで参照先が異なるケースもあるため、対象ごとに確認先を控えておくと、次回以降の棚卸しが楽になります。掲載内容は変更される場合があるため、参照時点も記録しておくことが望まれます。
管理項目の設計と更新の運用については、【 EOL・EOSL台帳の管理項目と更新ルール 】で扱っています。
洗い出した対象に、着手の順番を付けます。
ここで注意したいのは、保守終了時期の近さだけで並べると、業務影響の大きい資産が後回しになる場合があることです。期限まで余裕のある機器でも、基幹業務を支えていたり、他システムの前提になっていたりすれば、先に手を付けるべき対象になり得ます。時期は判断材料の一つであって、それだけで順番が決まるわけではありません。
優先順位を評価する具体的な方法については、【 サーバー更改の優先順位はどう決める? 】で解説しています。
対象と順番が決まったら、それぞれにどう対応するかを選びます。取り得る選択肢は大きく4つです。
|
選択肢 |
概要 |
|
更新 |
新しい機器や環境へ入れ替える |
|
延長保守・第三者保守 |
保守の受け皿を確保して稼働を継続する |
|
Cloud移行 |
基盤の持ち方そのものを変える |
|
レンタル・リース |
契約更新のタイミングで環境を切り替える |
いずれも万能な解決策ではなく、適合性は環境によって異なります。同じ社内でも、対象システムごとに異なる方針を選ぶ判断もあり得ます。それぞれの判断条件については、【 保守切れサーバーを延命するか更新するか 】で比較しています。
方針が固まったら、社内で説明できる形に整えます。ここでつまずきやすいのは、技術的な必要性は説明できても、費用の見え方が想定と違う場合があることです。
調達方式によって、費用がいつ、どのような形で発生するかは変わります。同じ機器を導入する場合でも、購入とレンタル、リースでは支出の時期も社内での扱いも異なるため、技術部門だけで判断せず、早い段階で経理部門と認識を合わせておくことが望まれます。費用の考え方については、【 システム構築費用の勘定科目はどう決まる? 】で整理しています。
自社がどの段階にあるかによって、次に確認すべき内容は変わります。
|
あわせて読みたい 対象がまだ把握できていない方へ。何を管理項目に含め、誰がどの頻度で更新するかを整理しています。 |
|
あわせて読みたい 何から着手するか迷っている方へ。EOL、障害影響、運用負荷を組み合わせた評価方法を扱っています。 |
|
あわせて読みたい 延命か更新かを判断したい方へ。4つの選択肢を、判断条件とあわせて比較しています。 |
|
あわせて読みたい 社内説明・予算取得の段階の方へ。費用の分類と、調達方式による違いを整理しています。 |
稼働そのものが止まるわけではありません。EOLは製造とサポートの縮小を示すもので、電源を入れれば動作を続けます。ただし、故障した際に修理や部品交換を受けられない状態に近づいていきます。動作しているかどうかと、支援を受けられるかどうかは別の問題です。どの段階でどこまでのサポートが残るかは、製品や契約内容、メーカーの方針によって環境ごとに異なります。公式情報での確認が必要です。
時間を確保する手段としては、選択肢の一つと考えられます。ただし、対象機種や交換部品の確保状況によって提供の可否が変わり、すべての機器で利用できるとは限りません。提供期間にも限りがあるため、恒久的な解決策としてではなく、更新計画を整えるための猶予として位置付けるのが現実的でしょう。判断条件の詳細は【 保守切れサーバーを延命するか更新するか 】で扱っています。
一律の目安を示すことは難しいのが実情です。対象機器の台数、他システムとの依存関係の複雑さ、社内の予算年度との兼ね合いによって、必要な期間は大きく変わります。考え方としては、切り替え完了日から逆算し、検証、調達、設計、方針決定、現状把握の順に必要な期間を積み上げていく方法があります。
EOLとEOSLは、それぞれ製品ライフサイクルの終了と、メーカー保守の終了という異なる段階を指します。自社の機器がどちらの段階にあるかによって、取れる選択肢は変わります。放置した場合のリスクは、復旧遅延、セキュリティー、コスト増加、コンプライアンスの4つに整理できますが、実務上の最大の問題は、対応が遅れるほど判断の選択肢が狭まっていくことにあります。
対応そのものは、洗い出し、優先順位付け、方針決定、予算化という4つの判断に分解できます。すべてを一度に進める必要はなく、自社がどこで止まっているかを見極めることから始まります。なお、個別製品の保守期限については、必ずメーカーの公表情報で確認してください。今日の時点で持ち帰れることがあるとすれば、自社の機器のうち、保守期限を答えられないものがどれだけあるかを把握することでしょう。
横河レンタ・リース株式会社では、ITインフラの棚卸しから設計・構築・運用支援まで、お客さまの課題に寄り添った最適解をご提案します。EOSL対応でお悩みの方は、ぜひお早めにご相談ください。