先代の代からのサーバーが壊れたら何が止まる？単一障害点の洗い出し方
先代が導入した社内サーバーが、いまも事務所の隅やサーバールームの棚で唸りを上げて動いている。そんな会社は少なくない。購入時の記録は残っておらず、設定を知っているのは当時関わったベテラン社員か、もう連絡が取りにくくなった地元のIT業者だけ。普段は誰も気にしていないが、もしこの1台が今夜壊れたら、明日の受発注、請求書発行、給与計算のどれが止まるのか——即答できる社長は、実はそう多くない。
結論から言えば、答えは「調べてみないとわからない」ではまずい。サーバーが止まったときに何が止まるかは、業務ごとに紙一枚で洗い出せる。そしてその作業は、専門知識がなくても、社長自身が主導してできる。本稿では、先代から引き継いだ古いサーバーを念頭に、どこが「単一障害点」になっているかを洗い出す具体的な手順と、洗い出したあとにどう手を打つかを、承継社長の目線で整理する。
この記事は、次のような状態にある方に向けて書いている。
- 先代の代に導入されたサーバーやパソコンが今も現役で稼働しており、いつ壊れてもおかしくないと薄々感じている
- サーバーの中身や配線図を把握している社員が1〜2人しかおらず、その人が辞めたり倒れたりしたらどうなるか考えたことがない
- 「バックアップは取っているはず」とは思うが、実際に復元を試したことは一度もない
- 株式の承継や登記の変更は税理士・司法書士に相談できたが、社内システムについては誰に聞けばいいのかわからず、後回しにしてきた
なぜ「単一障害点」という発想が承継社長に必要なのか
単一障害点（単一障害点（SPOF））とは、その1点が壊れるだけでシステム全体、あるいは業務全体が止まってしまう箇所のことを指す。サーバーが1台しかない会社では、多くの場合そのサーバー自体が単一障害点になっている。ネットワーク機器や特定のパソコン、あるいは「その人にしかわからない」というベテラン社員の頭の中も、単一障害点になり得る。
先代の時代は、会社の規模も業務の複雑さも今より小さく、1台のサーバーに全部乗せても大きな問題にならなかった。しかし会社が育ち、取引先が増え、システムに依存する業務が増えるほど、同じ1台に依存し続けるリスクは相対的に大きくなる。専門家の解説でも、受発注・会計・勤怠・生産管理などの基幹システムが社内の1台のサーバーに集約されているケースは中小企業の現場で今も珍しくなく、バックアップを取っていても実際に復元手順を試したことがない企業が多いと指摘されている（単一障害点(SPOF)とは｜中小企業の冗長化判断軸）。
株式承継や登記変更であれば、税理士や司法書士という「聞ける専門家」が最初からいる。ところが社内システムについては、多くの承継社長にとって相談窓口そのものが存在しない。先代が個人的に付き合いのあった地元のIT業者に細々と保守を頼んでいるだけ、というケースがほとんどだ。だからこそ、まず社長自身が「うちのサーバーが止まったら何が止まるか」を紙の上で把握しておくことに意味がある。誰かに聞く前に、自分で見取り図を持てるようになる。
洗い出しの第一歩：「サーバーが止まった日」を想像する
単一障害点の洗い出しは、難しい技術用語を覚えることから始める必要はない。まずは次の問いを自分に投げかけてみてほしい。
「今夜、あのサーバーの電源が入らなくなったら、明日の朝、最初に困るのは誰か」
この問いに答えるだけで、依存関係の輪郭がかなり見えてくる。経理担当者が請求書を出せなくなるのか、工場の生産管理担当が出荷指示を止めてしまうのか、営業が顧客情報を見られなくなるのか。業務ごとに影響範囲を書き出していくと、自然と「このサーバーに何が乗っているか」の棚卸しになる。
ここで重要なのは、社長が一人で想像するのではなく、各部門の責任者に同じ質問を投げて、実際の業務フローを言語化してもらうことだ。現場の人間は「サーバーが落ちたら困る」ことは肌感覚でわかっていても、それを言葉にして共有したことがない場合が多い。この段階で先代時代から勤めている古参社員に話を聞くと、「実はあのサーバーには受注データだけでなく、取引先ごとの特別価格の一覧表も入っている」といった、社長も知らなかった依存関係が出てくることがある。
棚卸しシートで洗い出す：業務・システム・依存先の3点セット
想像だけで終わらせず、実際に一覧化する段階に進む。ここで使うのが、業務・システム・依存先の3点をセットにした棚卸しの考え方だ。これは特別なツールを使わなくても、表計算ソフトや紙のノートで十分にできる。
| 業務 | 使っているシステム・データ | このサーバーが止まったときの影響 |
|---|---|---|
| 受発注 | 販売管理ソフト（サーバー内DB） | 新規受注入力・出荷指示が止まる |
| 請求・入金管理 | 会計ソフト＋Excel台帳 | 請求書発行が遅延、資金繰り把握が困難に |
| 給与計算 | 給与ソフト（サーバー内） | 給与計算・振込データ作成が止まる |
| 顧客情報管理 | Access台帳（サーバー共有フォルダ） | 見積作成・問い合わせ対応が滞る |
| 生産・在庫管理 | 独自Excelマクロ | 出荷可否の判断ができなくなる |
この表を実際に自社に当てはめて埋めてみると、想像以上に多くの業務が1台のサーバーに依存していることに気づくはずだ。特に注意したいのは、「販売管理ソフト」のような目立つシステムだけでなく、誰かが個人的に作ったExcelファイルや、部門内だけで使われているAccessのようなデータベースソフトが、実は業務上欠かせない役割を担っているケースだ。こうした「隠れた基幹システム」は、社長の目にはただのファイルにしか見えないため、洗い出しの際に見落とされやすい。
このタイプの見落としは、承継直後の社長には特に起こりやすい。先代が「便利だから」と現場に任せていたツールは、正式な情報システムの導入記録にも、取引先との契約書にも登場しない。存在自体が社長の視界に入っていないのだから、洗い出しの初回で漏れるのはむしろ当然だと言える。だからこそ、書類やシステム台帳の確認だけで終わらせず、必ず現場担当者への聞き取りを組み合わせる必要がある。
サーバーの中に眠る「もう一つのリスク」：属人化
サーバーそのものだけでなく、そのサーバーを「動かし方を知っている人」も単一障害点になり得る。よくあるのが、先代時代から在籍する情報システム担当者や、たまたまパソコンに詳しかった経理担当者が、一人でサーバーの設定・バックアップ・トラブル対応をすべて担っている状態だ。これは属人化と呼ばれる状態で、その人が退職・異動・病気で不在になった瞬間に、サーバーの復旧作業そのものが止まってしまう。
実際に、次のような事態は多くの現場で起きている。
- サーバーの管理者パスワードを知っているのが退職した元社員だけで、パスワードの再設定すら誰もできない
- バックアップの取得先や復元手順がその人の頭の中にしかなく、マニュアル化されていない
- 保守を委託しているIT業者との窓口がその人一人で、他の社員は連絡先すら知らない
こうした状態は、サーバー本体の物理的な故障と同じくらい、あるいはそれ以上に深刻な単一障害点になる。ハードウェアはお金を払えば交換できるが、頭の中にしかない知識は、本人がいなくなった瞬間に失われるからだ。棚卸しの際は「モノ」だけでなく「人」の依存関係も必ず書き出しておきたい。
老朽化そのものがリスクである理由
先代の代から使い続けているサーバーは、単一障害点であると同時に、物理的な老朽化という別のリスクも抱えていることが多い。税法上、サーバーは「器具・備品」のうち「電子計算機」に分類され、減価償却の基準となる法定耐用年数は5年と定められている（LAN設備の耐用年数の取扱いに関する質疑応答｜国税庁）。これはあくまで会計上の基準であり、5年を過ぎたら即座に壊れるという意味ではないが、実務上もサーバーの物理的な安全稼働の目安として3〜5年程度が意識されることが多く、劣化した部品が突発的に故障するリスクは年数とともに高まっていく。
先代が10年、15年前に導入したサーバーが今も現役で動いているとすれば、それは耐用年数の目安を大きく超えて稼働し続けていることになる。ハードディスクやファンといった機械的に動く部品は経年劣化を避けられず、いつ壊れてもおかしくない状態にあると考えたほうがよい。加えて、古いサーバーはOSやソフトウェアのサポート期限（EOL（サポート終了））が切れていることも多く、修理部品の在庫がメーカー側になくなっていて「壊れたら代わりの部品が手に入らない」という事態も起こり得る。これは単一障害点の深刻度をさらに引き上げる要因になる。
サーバーリプレイスにかかる現実的なコスト感
いざ「サーバーを入れ替えよう」と決めたとき、次に社長が知りたいのは費用感だろう。専門業者の解説によれば、サーバーのリプレイスには小規模な構成でも50万円から100万円程度の費用がかかるとされ、サーバー本体の価格だけでなく、周辺機器・ネットワーク設計・構築費用・運用保守費用まで含めた総額で検討する必要があるという（サーバーの耐用年数は何年？寿命サインとリプレイスの進め方を解説）。
この金額を見て「そんな余裕はない」と後回しにしたくなる気持ちはよくわかる。しかし比較すべきなのは、リプレイス費用そのものではなく、「サーバーが実際に止まったときに発生する損失」との差だ。受発注が1日止まれば、その日の売上機会を失うだけでなく、取引先からの信用にも影響する。給与計算システムが止まれば、社員への支払いに遅れが出かねない。こうした損失は目に見えにくいが、サーバー入れ替え費用よりもはるかに大きくなり得る。
「壊れてから慌てて手配する」場合、緊急対応費用は通常の入れ替えより高くつくことが多く、しかも代替機の在庫がすぐに見つかるとは限らない。計画的な入れ替えのほうが、結果的に安くつくケースが大半である。
事業継続力強化計画という選択肢
サーバーの単一障害点対策は、単なる社内のIT担当者任せの話ではなく、経営レベルの事業継続計画（BCP）の一部として位置づけることができる。中小企業庁は「事業継続力強化計画」の策定を推奨しており、その手引きの中では、自然災害や事故によって事業が停止するリスクに備え、ネットワークを分離する機能を持つ設備やバックアップ設備の導入が推奨されている（事業継続力強化計画 策定の手引き｜中小企業庁）。
事業継続力強化計画の認定を受けると、税制優遇や低利融資などの支援策を利用できる場合がある。サーバーの入れ替えやバックアップ体制の整備を、単なる「経費」ではなく「事業継続のための投資」として位置づけ直すことで、社内での説明もしやすくなるし、外部の支援策を活用できる可能性も出てくる。先代の時代にはなかった発想かもしれないが、承継したタイミングだからこそ、こうした制度を新たに取り入れる余地がある。
洗い出しの結果、何を優先すべきか
すべての業務・システムを同時に冗長化しようとすると、コストが際限なく膨らんでしまう。中小企業向けの解説でも指摘されている通り、理論上はすべてのサーバー・回線・システムを二重化するのが理想だとしても、実際には多くの中小企業にとって費用対効果が見合わないことが多く、発生頻度が年1回未満の災害のために毎月の固定費を倍にするのは現実的でない場合がある（単一障害点(SPOF)とは｜中小企業の冗長化判断軸）。
だからこそ、洗い出した結果をもとに優先順位をつける作業が欠かせない。判断軸としては、次の2つの掛け合わせで考えるとわかりやすい。
- 止まったときの業務影響の大きさ：売上に直結する受発注・出荷業務が止まるのか、それとも社内の一部業務が滞る程度で済むのか
- 実際に故障・停止が起きる可能性の高さ：老朽化が進んでいる、部品供給が終わっている、担当者が一人しかいないなど、リスクが顕在化しやすい要素があるか
この2軸で洗い出した業務・システムをマッピングすると、「影響が大きく、かつ発生可能性も高い」項目が自然と浮かび上がる。先代の代からのサーバーが受発注や生産管理を丸ごと抱えている場合、多くの会社でこの象限に該当することになるだろう。逆に、影響が限定的な社内資料の共有フォルダ程度であれば、優先度を下げて構わない。
洗い出しを「一度きり」で終わらせないために
単一障害点の洗い出しは、一度紙にまとめて終わりにするものではない。会社の業務は日々変化し、新しいソフトを導入したり、担当者が異動したりするたびに、依存関係も変わっていく。せっかく洗い出した情報も、更新されなければすぐに現状と乖離してしまう。
ここで役立つのが、洗い出した内容を一覧管理するシステム管理台帳という考え方だ。どのサーバー・システムが、どの業務を支え、誰が管理しているのかを一枚の台帳にまとめておけば、次に担当者が変わったときも、新しい経営者が引き継ぐときも、迷わず全体像を把握できる。台帳自体は特別なソフトを使う必要はなく、表計算ソフトのシート1枚で十分に始められる。重要なのは、更新のタイミングをあらかじめ決めておくこと、たとえば新しいシステムを導入したときや、担当者が交代したときには必ず台帳を見直す、というルールを社内で共有しておくことだ。
古参社員との対話が洗い出しの精度を左右する
単一障害点の洗い出しを社長一人の視点だけで進めると、どうしても抜け漏れが出る。特に先代の時代から会社にいる古参社員は、社長自身がまだ知らない業務プロセスや、サーバーに眠っている古いデータの存在を知っていることが多い。たとえば「あのサーバーには、もう取引のない古い顧客の与信情報も入っている」「昔使っていた別の受発注システムのデータが、実は今のシステムの一部と連携している」といった情報は、日常業務の中では意識されないが、いざ移行や復旧を考えるときに重要な手がかりになる。
洗い出し作業を進める際は、古参社員に対して「責める」姿勢ではなく、「教えてもらう」姿勢で臨むことが重要だ。属人化した状態を作ったこと自体を咎めても何も生まれない。むしろ、その人が持っている知識を今のうちに言語化してもらい、台帳や手順書に落とし込むことこそが、会社にとっての資産になる。先代の時代からの信頼関係がある社員だからこそ、社長からの「一緒に整理させてほしい」という声かけが効果を持つ場面は多い。
バックアップは「取っているか」ではなく「復元できるか」で判断する
洗い出しの過程で、多くの会社が「バックアップは一応取っている」と答える。しかし専門家の指摘でも繰り返し強調されている通り、バックアップを取得していても、実際に復元を試したことがない企業は非常に多い（単一障害点(SPOF)とは｜中小企業の冗長化判断軸）。バックアップデータ自体が破損していたり、復元に必要なソフトウェアのライセンスが失効していたり、そもそもバックアップの保存先がサーバーと同じ建物内にあって、火災や水害の際に一緒に失われてしまったりするケースは珍しくない。
BCPの観点からも、バックアップデータを地理的に離れた場所、たとえばクラウドストレージなどに分散して保管しておくことが推奨されている。地震によるラックの転倒、集中豪雨による浸水や漏電、大規模停電によるデータ破損といった事態は、一瞬にして経営を揺るがしかねないためだ。単一障害点の洗い出しと合わせて、「このバックアップは本当に復元できるのか」を一度実際に試してみることを強くすすめたい。年に一度でもいいので、テスト復元の日を決めて実施するだけで、いざというときの安心感がまったく違ってくる。
老朽化サーバーで動く独自マクロという隠れた依存
先代の時代に作られたExcelの自動処理マクロが、サーバー上の共有フォルダで今も動き続けている、というケースも承継企業ではよく見られる。受発注の集計や在庫管理、給与計算の補助など、業務の要となる処理を、専門知識のない社員が独学で組んだマクロが担っていることがある。作成した本人がすでに退職している場合、中身を修正できる人が社内に誰もいない、という状態に陥りやすい。
このようなマクロは、サーバーが壊れて新しいマシンに移行する際、Excelのバージョンの違いや設定の違いによって動かなくなることがある。単一障害点の洗い出しをする際には、「公式な基幹システム」だけでなく、こうした草の根的に生まれたマクロやツールも漏れなくリストアップしておく必要がある。担当者にヒアリングする際、「サーバーの中に、誰かが個人的に作った便利ツールはないか」と具体的に聞いてみると、思わぬ発見があることが多い。
こうしたマクロやツールは、作った本人にとっては「ちょっとした工夫」に過ぎなかったとしても、時間が経つほど業務に深く組み込まれ、誰も全体像を把握できない状態になっていく。棚卸しの段階で見つかったマクロについては、少なくとも「何をしているファイルなのか」「誰が最後に触ったのか」「止まったら何に影響するのか」の3点だけでもメモに残しておくと、後々の対応がぐっと楽になる。
見積もりを取る前に、洗い出しの結果を「仕様書」に変換する
サーバーの入れ替えやシステムの再構築を外部業者に依頼する際、多くの承継社長がつまずくのが「何を頼めばいいのかわからない」という壁だ。先代の時代からの付き合いで業者に丸投げしてきた場合、自社の業務が何にどう依存しているかを言語化した資料がそもそも存在しないことが多い。
ここで、単一障害点の洗い出し作業で作った業務・システム・依存先の一覧表がそのまま役に立つ。この一覧表を業者に見せるだけで、「うちは何がどう止まると困るのか」を口頭で説明する手間が省け、見積もりの精度も格段に上がる。逆に、この資料なしに「古いから新しくしてほしい」とだけ伝えると、業者側も過不足のある提案しかできず、結果的に「聞いていた話と違う」というトラブルにつながりやすい。洗い出しは社内の安心のためだけでなく、外部との交渉を有利に進めるための武器にもなる。
洗い出し後にすぐできる、コストをかけない応急処置
本格的なサーバー入れ替えや冗長化には予算と時間がかかる。しかし、洗い出しが終わった直後からコストをほとんどかけずに着手できる対策もいくつかある。
- 管理者パスワードやログイン情報を、複数の信頼できる社員と社長自身で共有し、金庫や施錠できる場所に書面でも保管しておく
- 外部のIT業者との保守契約の内容を再確認し、緊急時の連絡先と対応可能時間を社内で共有しておく
- バックアップの保存先を、最低でも1つはサーバーと物理的に離れた場所（クラウドや別拠点）に用意する
- 依存度の高い業務については、紙やExcelでの手動運用に一時的に切り替える手順を簡単にでも用意しておく
これらは新しい機材を買わなくても、社内の合意と数時間の作業で実施できるものばかりだ。単一障害点の洗い出しは、大きな投資判断の前段階として、まずこうした小さな備えから着手できる点も知っておいてほしい。
セキュリティ更新の放置も単一障害点を悪化させる
老朽化したサーバーほど、OSやソフトウェアのセキュリティ更新が適用されないまま放置されているケースが多い。更新が行われていないサーバーは、既知の脆弱性を突かれてランサムウェアなどの被害に遭うリスクが高く、物理的な故障とは別の角度から単一障害点になり得る。特に、公式サポートが終了したOSを使い続けている場合、新しい脆弱性が見つかってもメーカーから修正プログラムが提供されないため、リスクは時間とともに積み上がっていく一方だ。
洗い出しの際には、「このサーバーのOSやソフトウェアは、いつまで公式サポートを受けられるのか」も併せて確認しておきたい。サポート期限がすでに切れている、あるいは近く切れる予定であれば、それは老朽化した部品と同じくらい優先度の高いリスクとして扱うべきである。ソフトウェアの更新は地味な作業に見えるが、放置期間が長くなるほど、あとから一気に対応するコストと難易度が跳ね上がる。月に一度、更新の有無を確認するだけの簡単なルールを社内で決めておくだけでも、リスクの積み上がりを大きく抑えられる。
承継のタイミングだからこそ着手しやすい理由
システムの見直しは、本来であれば経営が安定している平時にこそ計画的に進めたい取り組みだ。しかし実際には、日々の業務に追われる中で「いつかやらなければ」と思いながら先送りされ続けているケースがほとんどだろう。承継のタイミングは、この先送りを断ち切る数少ない好機でもある。
先代のやり方をそのまま踏襲するのではなく、「なぜこの体制になっているのか」を問い直せるのは、外からの視点を持ち込める承継社長ならではの強みだ。古参社員にとっても、代替わりのタイミングで「これを機に整理しましょう」と持ちかけられれば、これまで言い出しにくかった不安（自分がいなくなったらどうなるのか、という懸念を含めて）を共有しやすくなる。単一障害点の洗い出しは、単なるIT対策の一つではなく、承継後の経営基盤を自分の代でどう固め直すかという経営判断そのものだと捉えてほしい。
複数拠点・複数部門がある会社ほど洗い出しは分業する
従業員が数十人を超え、営業所や工場が複数拠点に分かれている会社では、単一障害点の洗い出しを社長一人、あるいは本社の情報システム担当者一人だけで進めるのは現実的ではない。拠点ごとにローカルのサーバーやネットワーク機器を持っている場合、それぞれの拠点で「何が動いていて、何が止まると困るのか」を把握している人が異なるからだ。
このような場合は、各拠点・各部門の責任者に同じフォーマットの棚卸しシートを配布し、それぞれの立場から記入してもらう分業体制を取るのが効率的だ。本社側は、集まってきたシートを統合し、全社的に見て影響の大きい依存関係を洗い出す役割に徹する。現場ごとの細かい事情まで社長がすべて把握するのは現実的ではないが、「誰が何を知っているか」の地図さえ描けていれば、いざというときに誰に連絡すればよいかがすぐにわかる。これも立派なリスク対策の一つだ。
拠点間で使っているシステムが微妙に異なっている、というのも承継企業ではよくある話だ。本社は新しい会計ソフトに切り替えたが、工場だけは先代時代の古いシステムのまま残っている、といったケースは珍しくない。棚卸しの際にはこうした拠点間の差異も可視化しておくと、将来的なシステム統合の判断材料にもなる。
取引先への影響も洗い出しの視野に入れる
社内業務への影響だけでなく、サーバーが止まったときに取引先にどのような影響が及ぶかも、洗い出しの対象に含めておきたい。たとえば、受発注システムが停止すれば、取引先からの注文を受け付けられなくなるだけでなく、既に受けている注文の納期回答ができなくなる可能性もある。EDI（電子データ交換）で取引先と直接システムを連携している場合は、自社のサーバー障害がそのまま取引先の業務にまで波及することもあり得る。
このような対外的な影響を洗い出しておくことで、万が一の際にどの取引先へ優先的に連絡すべきか、代替手段（電話やFAXでの受発注など)をどこまで用意しておくべきかを、事前に検討できるようになる。特に、特定の大口取引先との取引がシステム経由に一本化されている場合、そのシステムはもはや社内だけの単一障害点ではなく、取引関係そのものを左右する重大な依存点だと認識しておく必要がある。
社長が最初の一週間でできる具体的なアクション
ここまで紹介してきた洗い出しの考え方を、実際にどう動き出せばよいか迷う方のために、最初の一週間でできる具体的なステップを示しておく。
- 1日目：部門責任者を集め、「サーバーが今夜止まったら何が困るか」を一人ずつ発言してもらう場を設ける
- 2〜3日目：各部門から出た内容を、業務・システム・依存先の3点セットで一覧表に整理する
- 4日目：バックアップの取得状況を確認し、可能であれば簡単な復元テストの日程を決める
- 5日目：管理者パスワードや保守業者の連絡先など、属人化している情報を書面に残す
- 1週間後：出来上がった一覧表をもとに、影響の大きさと発生可能性で優先順位をつけ、次の一手（見積もり依頼か、応急処置の実施か）を決める
この5ステップは、外部に費用を払わなくても社内だけで完結できる内容だ。もちろん、その先の本格的なシステム再構築やサーバー入れ替えには専門家の力が必要になる場面も出てくるが、まずは自社の現状を正確に把握するところまでは、承継社長自身の手で十分に進められる。
まとめ：洗い出しは「不安の正体」を紙に落とす作業
先代の代からのサーバーに対して漠然とした不安を抱えている社長は多い。しかしその不安の正体は、実は紙一枚に書き出せるものであることがほとんどだ。「このサーバーが止まったら、どの業務が、どれくらいの期間、どれくらいの影響を受けるのか」を業務ごとに整理し、モノだけでなく人の依存関係も含めて棚卸しする。そのうえで、影響の大きさと発生可能性の掛け合わせで優先順位をつければ、次に何から手をつけるべきかが自然と見えてくる。
株式や登記の承継には税理士や司法書士という相談先があったが、社内システムの承継には決まった相談先がないというのが、多くの二代目・三代目経営者が直面する孤独感だ。しかし単一障害点の洗い出し自体は、専門家に丸投げしなくても、社長自身が古参社員と対話しながら進められる作業である。まずは自社のサーバーについて、「今夜壊れたら何が止まるか」を紙に書き出すところから始めてほしい。それが、先代から受け継いだ会社を次の世代に安全に引き継ぐための、最初の一歩になる。
よくある質問
Q1. サーバーの単一障害点を洗い出すのに、専門的なIT知識は必要ですか。
洗い出しの第一段階では専門知識は不要だ。「このサーバーが止まったら、どの業務が止まるか」を各部門にヒアリングし、業務・システム・影響範囲を一覧化するだけで、依存関係の大部分は見えてくる。専門知識が必要になるのは、洗い出した後に「どう対策するか」を技術的に検討する段階からであり、そこで初めてIT業者や専門家に相談すればよい。
Q2. バックアップを取っていれば、単一障害点の問題は解決したと言えますか。
バックアップの取得と、実際に業務を復旧できることは別の問題だ。バックアップデータが破損していないか、復元に必要なソフトウェアや手順が整っているか、保存先がサーバーと同じ場所にないかを確認しない限り、「取っているつもり」で終わってしまう可能性がある。年に一度でもよいので、実際に復元を試すテストを行うことをすすめたい。
Q3. サーバーの入れ替えにはどれくらいの予算を見ておけばよいですか。
小規模な構成でも、サーバー本体・周辺機器・ネットワーク設計・構築費用・運用保守費用を含めて50万円から100万円程度が目安とされている。ただし業務内容やデータ量によって幅があるため、洗い出しの結果をもとに、どこまでの機能を新しいサーバーに求めるかを整理してから、複数の業者に見積もりを依頼するのが望ましい。
Q4. 属人化しているサーバー管理者に、どう協力してもらえばよいですか。
責める姿勢ではなく、「今のうちに知識を共有してほしい」という協力を仰ぐ姿勢が重要だ。属人化は本人の落ち度というより、これまで整理する機会がなかった結果であることが多い。台帳や手順書に落とし込む作業を一緒に進め、その人がいなくても業務が回る体制を作ることは、本人の負担軽減にもつながる、という説明が受け入れられやすい。
