メーカーから保守終了の案内が届く。前任者が異動し、設定の経緯を知る人がいなくなる。「システムが遅い」という問い合わせに対して、端末なのか回線なのかサーバーなのか切り分けられない。中小企業の情報システム担当者から寄せられる相談は、たいていこうした形で始まります。
このとき困るのは、対処法が分からないことではありません。対処すべき場所が複数あり、どれを先にすべきか決められないことです。1 つずつ潰していけば、そのたびに費用と工数がかかります。かといってまとめて刷新すれば、予算が通らない。
「まず全体像を把握しましょう」という助言はもっともですが、把握したうえで何をどう判断するのかまでは、あまり語られません。全体像は、描いて終わりにすると机上の資料で止まります。
機器とプログラムと回線、という 3 分類から入り、そこへ端末や保管領域、防御の仕組みを並べていく。解説の型はおおむね共通しています。基礎の理解としては有効で、社内説明の土台にもなります。
ただし、この一覧には次の 3 つが含まれていません。
時間軸。それぞれの機器やソフトウエアが、いつ保守終了を迎えるのか
契約。どこまでがメーカー保守で、どこからが自社対応なのか
人。誰が運用し、その人がいなくなったら誰が引き継ぐのか
構成要素が同じでも、この 3 つが違えば、取るべき順序はまったく変わります。5 年前に導入したサーバーが 2 台あっても、片方の保守が半年後に切れ、もう片方が 3 年残っているなら、扱いは別です。
つまり構成要素の把握は必要ですが、それだけでは判断に届きません。全体像を「地図」として使うなら、地形だけでなく、期限と担当者を重ねて描く必要があります。
判断に使う前提で整理するなら、次の 4 層に分けると扱いやすくなります。層ごとに更新サイクルも、判断を迷わせる要因も異なるためです。
手元で触れるものが該当します。朝いちばんに電源を入れ、業務システムへログインし、日中は資料と会議に使う。不具合の申告が真っ先に集まるのもこの層です。
一方で、更新サイクルは 4 〜 5 年程度と比較的短く、台数と時期さえ把握できていれば判断は組み立てやすい層です。判断を迷わせるとすれば、OS のサポート期限と会計上の償却期間がずれる場合でしょう。
社内 LAN、無線 LAN、インターネット回線、ルーター、スイッチ、VPN などです。ここが不安定になると、ファイル共有の遅延、Web 会議の切断、業務システムへの接続失敗といった形で表面化します。
厄介なのは、症状がほかの層のせいに見えやすい点です。「サーバーが重い」と報告された事象の原因が、実は回線の帯域不足だったというケースは珍しくありません。判断を迷わせるのは、原因の切り分けに必要なログや監視の仕組みが、そもそも用意されていないという状況です。
サーバー、ストレージ、仮想化基盤、そしてクラウドサービスがここに入ります。データの保存場所であり、業務システムが動く土台でもあります。
この層は 1 回の判断で数百万円規模の支出と、その後 5 年程度の運用が決まります。オンプレミスを維持するのか、クラウドへ寄せるのか、あるいは両方を併用するのか。判断を迷わせるのは、初期費用と月額費用の比較だけでは答えが出ないという点です。移行作業の工数、既存システムとの連携、社内の運用スキルまで含めて見ないと、後から想定外の負担が出てきます。
誰に何を許すかを決める仕組み、外からの侵入を防ぐ仕組み、失ったときに戻す仕組み。加えて、日々の監視と問い合わせ対応がここに含まれます。これらは特定の層に属するのではなく、全体を横断して支えます。
判断を迷わせるのは、この層の状態が最も数値化しにくいことです。機器の台数や保守期限と違い、「運用が回っているかどうか」は担当者の実感でしか測れない場合が多く、限界が来るまで表面化しません。
4 層に整理できたら、次は各層を横断して弱点を探します。以下の 4 観点で見ると、優先順位の議論がしやすくなります。
|
観点 |
確認すること |
危険信号 |
|
保守・EOL |
メーカー保守の終了時期、延長保守の可否と費用 |
保守終了後も稼働している機器がある |
|
属人化 |
設定内容の記録、手順書の有無、代替できる人の存在 |
特定の 1 人しか触れない領域がある |
|
運用負荷 |
障害対応の頻度、夜間休日の対応、定型作業の時間 |
通常業務が運用対応で圧迫されている |
|
費用 |
保守費、更新費、クラウド利用料の推移 |
支出が増えているが内訳を説明できない |
このうちどれを優先すべきかは、企業によって変わります。保守終了が迫っているなら期限が最優先ですが、期限に余裕があっても担当者が 1 人しかいない状態なら、属人化の解消が先になる場合もあるでしょう。一律の正解を置かず、自社の状況で順序を組み替える前提で使うことをおすすめします。
なお、4 つとも問題を抱えているケースも珍しくありません。その場合は「すべて解決する」ではなく、業務が止まったときの影響が大きい順に並べ替えるところから始めるのが現実的です。
機器の棚卸しを済ませ、構成図を作った。それでも判断できない、という相談があります。原因の多くは、図に描けない情報が抜けているためです。
保守契約の残期間と範囲：
機器そのものは動いていても、保守が切れていれば故障時に部品が手に入りません。逆に、契約は残っていても対象が本体のみで、ストレージは対象外というケースもあります。
運用手順の所在：
バックアップの取得方法、障害時の連絡先、復旧の手順。これらが個人のメモや記憶にとどまっていると、担当者の不在時に何も進みません。
権限の付与状況：
誰がどのシステムに、どこまでアクセスできるのか。退職者のアカウントが残っている、共有アカウントが使われている、といった状態は構成図には現れません。
外部委託の責任範囲：
ベンダーに任せている領域について、どこまでが委託先の責任で、どこからが自社の責任なのか。障害発生時に初めて認識のずれが判明することがあります。
構成図を作ると「整理が終わった」という感覚が生まれやすいのですが、判断に効くのはむしろこちら側の情報です。図が完成したときこそ、描けなかったものを一覧にしておくとよいでしょう。
最も相談が多い分岐がここです。一括更新は費用が大きく、稟議のハードルも上がります。かといって部分的な延命を繰り返すと、場当たり的な対応が積み上がり、構成がさらに複雑になっていきます。
どちらが正しいという話ではなく、条件によって適した選択が変わります。
一括更新が検討しやすいのは、複数の機器の保守終了時期が近く、更新後の構成を作り直したい場合や、担当者の交代を機に運用手順を整理し直したい場合です。移行作業をまとめられるぶん、総工数を抑えられる可能性があります。
部分的な延命が現実的なのは、業務システム側の刷新計画が数年後に控えており、その時点まで持たせたい場合や、予算の平準化を優先せざるを得ない場合です。ただし延命には、延長保守の費用が年々上がること、代替部品の確保が難しくなること、対応できるベンダーが減っていくことといった注意点が伴います。
判断材料としては、次の 3 点を並べて比較すると議論しやすくなります。
5 年間の総支出 ( 更新費と延命費を同じ期間で比較する )
業務が止まった場合の影響時間
運用にかかる工数の変化
整理を後回しにしても、すぐに業務が止まるわけではありません。だからこそ先送りされやすいのですが、時間の経過とともに次のような状態が起こり得ます。
更新の判断が常に後手になる：
保守終了の通知を受けてから慌てて検討を始めるため、選択肢を比較する時間が取れず、提案されたものをそのまま受け入れることになりやすくなります。
費用の説明ができなくなる：
何にいくらかかっているのか整理されていないと、予算の妥当性を経営層へ説明できません。結果として、必要な投資も通りにくくなります。
障害対応が長引く：
構成が把握できていない環境では、原因の切り分けに時間がかかります。復旧までの時間が延びるほど、業務への影響も広がります。
引き継ぎができない：
担当者が交代する際、記録がなければ引き継ぎは口頭に頼ることになります。抜け落ちた情報は、次のトラブルまで気付かれません。
いずれも「必ず起きる」ものではありませんが、放置している期間に比例して発生確率は上がっていきます。
「ツールを入れれば台帳は自動で埋まる」という期待は、導入検討の場でよく聞かれます。ある程度までは事実ですが、埋まらない欄も残ります。
まず、ツールが可視化するのは現在つながっている機器の状態です。保守契約の残期間や、運用手順の所在、外部委託の責任範囲といった情報は、人が入力しない限り反映されません。前章で挙げた「図に描けないもの」は、ツールでも自動では埋まらないのです。
次に、可視化された情報は判断そのものを代行しません。「このサーバーの CPU 使用率が高い」という事実が分かっても、増強するのか、負荷を分散するのか、クラウドへ移すのかは人が決めることになります。
さらに、情報の鮮度を保つには継続的な運用が必要です。導入直後は整っていても、更新作業が反映されなければ、半年後には実態とずれた資料が残るだけになります。
とはいえ、ツールが不要という話ではありません。手作業では追いきれない範囲を継続的に把握する用途では有効です。期待する範囲を絞り、「ツールで賄う部分」と「人が判断する部分」を分けて設計するという考え方が現実的でしょう。
最後に、着手前に決めておくと止まりにくくなる前提を挙げます。
範囲：
全社の全機器を一度に対象にすると、まず終わりません。業務が止まったときの影響が大きい領域、あるいは 2 年以内に保守終了を迎える領域に絞るところから始める方法があります。
粒度：
機器 1 台ずつの詳細仕様まで記録するのか、システム単位でまとめるのか。判断に使うのが目的であれば、多くの場合はシステム単位で足ります。細かくしすぎると、更新する手間のほうが大きくなります。
期限：
いつまでに、どの状態になっていれば終わりとするのか。「全部把握できたら」という基準では終わりが来ません。「次回の予算検討までに、更新候補を 3 つに絞る」といった形で、出口を先に決めておくとよいでしょう。
完璧な全体像を作ることが目的ではありません。判断に必要な粒度で、期限内に、更新し続けられる形にすることが目的です。
一律の基準はありませんが、機器の追加や撤去があったタイミングと、年 1 回の予算検討前を目安にする企業が多い印象です。頻度を上げるより、更新の担当と手順を決めておくほうが、結果的に鮮度は保たれます。
範囲を絞った記録の作成から始める方法があります。すべてを文書化しようとすると負担が大きいため、まずは「その人がいないと復旧できない作業」を洗い出し、その手順だけを残すという進め方です。属人化の解消は時間がかかるため、全体の整理と並行して少しずつ進めるのが現実的でしょう。
管理対象が減る面はありますが、なくなるわけではありません。代わりに、誰がどの契約を持っているか、月額がなぜ増えたか、社内システムとどうつなぐか、といった問いが増えます。オンプレミスとの併用が続く場合は、むしろ把握すべき範囲が広がることもあるため、移行前に運用体制を確認しておくことをおすすめします。
稼働しているからといって安全とは言えませんが、即時の更新が唯一の選択肢でもありません。延長保守の可否、代替部品の入手性、故障時の業務影響、更新までの猶予といった条件を並べたうえで判断することになります。少なくとも「故障したらどうするか」を先に決めておくことは必要でしょう。
IT インフラの全体像は、構成要素を並べるだけでは判断材料になりません。端末、ネットワーク、基盤、横断機能の 4 層に整理したうえで、保守終了 ( EOL )、属人化、運用負荷、費用という観点を重ねることで、ようやく「どこから手を付けるか」の議論ができる状態になります。
そのうえで、構成図には描けない契約や運用手順、権限の情報が抜けていないかを確認する。可視化ツールに任せられる範囲と、人が判断する範囲を分ける。範囲と粒度と期限を先に決めて、終わらせ方を用意しておく。こうした準備があると、整理が資料作りで終わらずに済みます。
横河レンタ・リースでは、IT 基盤の構築や運用支援、保守終了への対応、クラウド活用の検討など、お客さまの状況に合わせた支援を行っています。どこから整理すべきか判断に迷う段階でのご相談も承っています。現状の棚卸しからご一緒することも可能ですので、必要に応じてお声がけください。
横河レンタ・リース株式会社では、日本ヒューレット・パッカード社のPlatinumパートナーとして、サーバーの販売から構築、運用や管理をご支援するサービスを提供しています。自社サーバーの導入・リプレースをご検討中、またはサーバーの運用に課題をお持ちの企業さまは、ぜひお気軽にお問い合わせください。