金曜日の夕方、受発注システムを動かしていた一台のサーバーが、うなるような異音を上げて止まった。担当者はその場でリセットボタンを押した。何も起きなかった。電源を入れ直した。ファンが回る音すらしなかった。
その会社では、受注データの入力も、在庫の引き当ても、出荷指示も、すべてがそのサーバー一台の上で完結していた。購入したのは八年前。当時の担当者はすでに転職していて、機種も型番も、詳しい人間が社内にいなかった。メーカーに問い合わせると「その型はもう生産終了で、部品の在庫もありません」という回答だった。
結局、代替機を手配し、バックアップからデータを復元し、動作確認を終えるまでに三日かかった。その三日間、受注は電話とファックスと手書きのメモで受け止め続けるしかなく、出荷はゼロだった。得意先には頭を下げて回り、社員は普段しない作業に追われ、月末の数字は目に見えて落ち込んだ。
誰かがサボっていたわけではない。むしろ、その会社の担当者は真面目に日々の運用をこなしていた。ただ、その真面目さが向いていた先が、目の前の業務であって、「もしこの一台が壊れたら」という問いには向いていなかっただけだ。そしてこれは、特別に運が悪い会社の話ではない。多くの中小企業の情報システムの現場に、同じ構造が静かに眠っている。
単一障害点(SPOF)とは何か、身構えずに理解する
単一障害点、英語でSingle Point of Failure、略してSPOFと呼ばれる考え方がある。言葉だけ聞くとエンジニア向けの難しい概念に思えるが、中身はシンプルだ。ある一つの部分が壊れると、それだけでシステム全体、あるいは業務全体が止まってしまう箇所のことを指す。
橋に例えるとわかりやすい。何本もの支柱で支えられている橋なら、一本が傷んでも他の支柱が荷重を支え、橋そのものは落ちない。しかし支柱が一本しかない橋なら、その一本が折れた瞬間に橋全体が使えなくなる。業務システムにおけるサーバーやネットワーク回線、担当者のスキルも、これと同じ構造を持っている。
大切なのは、単一障害点そのものが「悪」ではないということだ。すべての部品を二重化・三重化していたら、コストはいくらあっても足りない。単一障害点は、どんな組織のどんなシステムにも必ず存在する。問題は、それに気づかないまま、壊れて初めて存在を知ることだ。そうなったときには、もう選択肢がなく、ただ復旧を待つしかない。事前に気づいていれば、備え方を選べたはずの場面で、である。
中小企業の業務システムに潜みがちな単一障害点
単一障害点は、大がかりなサーバー室だけに存在するわけではない。むしろ中小企業の現場では、もっと身近な場所に潜んでいることが多い。代表的な四つのパターンを見てみたい。
1台のサーバー
冒頭の事例のように、受発注、会計、勤怠、生産管理などの基幹システムが、社内の一台のサーバーに集約されているケースは今も少なくない。バックアップは取っていても、そのバックアップから実際に復元する手順を試したことがない、という会社は驚くほど多い。バックアップの存在と、復旧できることは、まったく別の話だ。
1人の担当者
システムに詳しいのが社内でただ一人、という状態も立派な単一障害点になる。その人が体調を崩したり、有給休暇で連絡が取れなかったり、あるいは退職したりした瞬間、パスワードの在り処すらわからなくなる。設定変更のたびに「あの人に聞かないとわからない」という業務は、その人自身が単一障害点になっている証拠だ。属人化という言葉で片付けられがちだが、実態は人というSPOFである。
1つのインターネット回線
クラウドサービスへの依存が進むほど、インターネット回線そのものが業務の生命線になる。回線事業者の障害や、社屋前の道路工事による断線が起きると、クラウド上の会計システムにも、メールにも、チャットツールにもアクセスできなくなる。オフィスが一つで回線契約も一本という会社ほど、この種の障害に脆い。
1つの認証基盤
近年増えているのが、IDとパスワードを一元管理する認証基盤、いわゆるシングルサインオンの仕組みに関わる障害だ。便利さと引き換えに、その認証基盤がダウンすると、連携しているすべてのサービスに誰もログインできなくなる。利便性のために導入した仕組みが、そのまま最大の単一障害点になっている、という皮肉な構図が起きやすい。
すべてを冗長化する必要はないという現実
ここまで読むと、「うちも危ないかもしれない、今すぐ全部二重化しなければ」と焦りたくなるかもしれない。しかし、その反応こそが実は危険だ。
サーバーを二重化し、回線を二本引き、認証基盤も予備を用意し、担当者も常に複数名体制にする。理屈の上ではそれが理想かもしれないが、現実の予算と人員でそれをやろうとすると、多くの中小企業にとっては費用対効果が見合わない。年に一度あるかないかの障害のために、毎月の固定費を倍にするような投資判断を経営者に迫るのは、誠実な提案とは言えない。
冗長化は、リスクをゼロにする魔法ではなく、リスクとコストの交換である。何を交換する価値があり、何は交換しなくていいのか。その線引きをせずに「念のため全部」とやってしまうと、限られた予算がすり減るだけで、本当に守るべき場所への投資が手薄になる。すべてを守ろうとして、結局どこも守れていない状態は、意外なほど多くの現場で起きている。
だからこそ問われるのは、技術力ではなく判断力だ。自社にとって本当に止まってはいけないものはどれか。その一点を見極める力こそが、限られたリソースで会社を守る担当者に求められている。
自社にとって優先すべき単一障害点の見極め方
すべての単一障害点を平等に扱う必要はない。優先順位をつけるために、三つの物差しで自社のシステムを棚卸ししてみてほしい。
- 止まったときの影響度 — その部分が止まったら、売上や出荷、給与計算、顧客対応など、どの業務がどれだけの規模で止まるか。一部の社員が困る程度なのか、全社の売上が丸ごと止まるのか、影響の大きさはまったく違う。
- 復旧にかかる時間 — 壊れてから元に戻るまで、何時間、何日かかるか。部品調達に時間がかかる古い機種か、即日交換できる汎用品か。この見積もりがないまま「大丈夫だろう」で済ませている会社は多い。
- 代替手段の有無 — システムが止まっている間、手作業やアナログな方法で業務を続けられるか。受注を電話とファックスで受けられるなら被害は限定的だが、システムがなければ何もできない業務は、代替手段のない単一障害点として最優先で扱うべきだ。
この三つを掛け合わせると、影響が大きく、復旧に時間がかかり、代替手段もない箇所が浮かび上がる。冒頭の会社で言えば、受発注サーバーがまさにこれに当たる。逆に、影響が小さく、復旧も早く、代替手段もある箇所は、当面は今のままでいいという判断も十分に成り立つ。すべてを同じ熱量で心配するのではなく、こうして優先順位をつけること自体が、担当者にできる最初の、そして最も費用対効果の高い仕事だ。
予算をかけずにできる備えと、投資が必要な備え
優先順位が見えてきたら、次はその備え方を二種類に分けて考えるといい。お金をかけずに今日から始められることと、腰を据えた投資が必要なことだ。
予算をかけずにできる備え
- 手順書の整備 — サーバーが止まったとき、誰が、何を、どの順番で確認するのか。パスワードの保管場所、業者の連絡先、代替の受注方法までを一枚の紙にまとめておくだけで、いざというときの混乱と時間のロスは大きく減る。
- 代替機の確保 — 新品を買う必要はない。使わなくなった旧型のパソコンを一台残しておく、リース会社にスポット交換の条件を確認しておくなど、応急処置の選択肢を事前に洗い出しておくことは、ほぼコストゼロでできる備えだ。
- 複数人への引き継ぎ — 一人だけが知っている状態を崩すために、簡単な操作マニュアルを作り、月に一度でいいので別の社員にも触ってもらう。担当者本人にとっても、自分がいなくても回る仕組みを作ることは、決して自分の価値を下げることではない。むしろ、その人がいなくても会社が困らない体制を作れる人こそが、本当に信頼される担当者だ。
投資が必要な備え
- 冗長構成 — サーバーを二台体制にする、回線を二系統契約するなど、機材そのものを増やす投資。影響度が大きく代替手段のない基幹業務には、こうした投資判断が必要になる。
- クラウド移行 — 自社サーバーへの依存をやめ、クラウド上のサービスに業務を移すことで、機材の故障という単一障害点そのものを事業者側に肩代わりしてもらう考え方。移行には費用も労力もかかるが、老朽化した自社サーバーを個別に更新し続けるより、長期的には合理的な場合が多い。
この切り分けをせずに、「お金をかけないと備えられない」と思い込んでしまうと、多くの現場では結局何も手をつけないまま先送りになる。まず今日、手順書を一枚書くこと。それだけでも、次に何かが止まったときの三日間は、確実に短くなる。
よくある失敗パターン
単一障害点への対策で、現場がつまずきやすい典型を三つ挙げておきたい。
- バックアップは取っているが、復元したことがない — データはあるのに、いざ復元しようとすると手順がわからず、結局メーカーや業者に頼らざるを得なくなる。バックアップは、取ることより戻せることを確認して初めて意味を持つ。
- 担当者が一人で抱え込み、周囲もそれを良しとしてしまう — 「あの人がいれば大丈夫」という空気は、一見信頼のように見えて、実は組織にとって最も危うい状態を放置していることに等しい。担当者を責めるのではなく、仕組みとして分散させる責任は経営側にもある。
- 被害の大きさを想像せずに対策の優先順位を決めてしまう — 声の大きい人の心配事や、直近で起きた小さなトラブルにばかり気を取られ、実際には影響度も復旧時間も甚大な箇所が放置されているケースは珍しくない。感覚ではなく、影響度・復旧時間・代替手段の三つの物差しで淡々と棚卸しをすることが、この失敗を防ぐ一番の近道になる。
どれも、悪意や怠慢から生まれる失敗ではない。日々の業務に真剣に向き合っているからこそ、目の前のことで手一杯になり、「もしも」への備えが後回しになる。それは責められることではなく、多くの現場に共通する自然な流れだ。だからこそ、意識的に立ち止まって棚卸しをする時間を作ることに価値がある。
まとめ
一台のサーバーが止まっただけで、受注も出荷もすべてが止まった三日間。その裏側にあったのは、特別な不運ではなく、どの会社にも起こりうる単一障害点という構造だった。壊れて初めて気づくのではなく、壊れる前に「もしこれが止まったら」と問いを立てられるかどうかが、会社の底力を分ける。
すべてを冗長化する必要はない。大切なのは、影響度、復旧にかかる時間、代替手段の有無という三つの物差しで自社を見つめ直し、本当に守るべき箇所を見極めることだ。そして、その見極めさえできれば、手順書を一枚書く、代替機を一台確保しておく、操作を一人でも多くの社員と共有するといった、お金をかけずにできる備えから今日始められる。
限られた予算と人員の中で、どこまで備えるべきかを判断しようとしているあなたの努力は、決して地味な作業ではない。目に見える成果が出にくいからこそ評価されにくいが、いざというときに会社を止めないための、最も価値のある仕事の一つだ。壁の向こうにあるリスクを一つずつ見つめ、越えていく。その積み重ねが、次に何かが起きたときの三日間を、三時間に変えてくれる。