ある業務フローの中に、たった1つ壊れるだけで全体が止まる箇所があるとします。その1箇所を、単一障害点と呼びます。単一障害点とは、そこが機能しなくなると、システム全体が機能を失ってしまう、たった1つの弱点のことです。このページでは、単一障害点をどう見つけ、どう扱うかを考えます。
コンピュータの世界での単一障害点
コンピュータシステムでは、単一障害点は真っ先に潰すべき設計ミスとして扱われます。段階を追って考えると分かりやすくなります。
まず、利用者からのアクセスをすべて1台のサーバーだけで受けているとします。そのサーバーの電源が落ちれば、サービス全体が止まります。これがもっとも単純な単一障害点です。
次に、サーバーを2台にしたとします。それでも、両方が同じ1本のネットワーク回線につながっていれば、その回線が切れた瞬間に、通信は途絶えます。部品を増やしても、増やした部品が同じ1点に依存していれば、意味がありません。
さらに、データの保存先を考えます。処理するサーバーを何台に増やしても、データを1箇所にしか保存していなければ、その保存先が壊れた瞬間に、データそのものが失われます。単一障害点は、いつも1種類とは限らず、階層ごとに隠れています。
設計者はこうした箇所をあらかじめ洗い出し、地図として持っておきます。「ここが壊れたら、何が止まるか」を先に書き出しておく作業です。壊れてから気づくのでは遅く、壊れる前に名指しすることが仕事になります。
なぜここまで手間をかけて先回りするのでしょうか。理由は単純で、壊れてから対策を考えるのでは、利用者が困っている間ずっと手が打てないからです。壊れる前に地図を作ることは、壊れた瞬間に迷わず動くための準備でもあります。地図がなければ、障害が起きてから「どこが原因か」を探すところから始めることになり、復旧までの時間がそのぶん長くなります。
仕事の言葉に翻訳する
単一障害点を仕事に翻訳すると、次のようになります。「その人が休むと、業務全体が止まる担当者」や、「その1つのファイルが壊れると、誰も作業を続けられない資料」です。
見つけ方は単純です。ある業務プロセスを1本の流れとして書き出し、各工程に「担当できる人数」を書き添えます。担当できる人数が1人しかいない工程が、単一障害点です。
もう少し手順に落とすと、次の3段階になります。1つめは、業務を工程ごとに分解して紙やホワイトボードに書き出すことです。2つめは、各工程の横に「今この工程を担当できる人」の名前を全員分書き込むことです。3つめは、名前が1つしか書けなかった工程に印をつけることです。印がついた工程が、そのチームの単一障害点の一覧になります。
ある5人のチームで、この3段階を実際にやってみたとします。業務を10工程に分解し、担当できる人数を書き込んでいくと、「請求書の発行」と「顧客データの更新」の2つに、名前が1つしか書けませんでした。残りの8工程には、2人以上の名前が書けています。このとき手をつけるべきは、印がついた2工程だけです。残りの8工程まで手を広げる必要はなく、対象を絞れることも、この作業の利点です。
具体的な場面
1つめの場面は、承認フローです。稟議や見積もりの承認が、特定の上長1人の押印を必ず経由する設計だとします。「部長が出張中で、承認印がもらえません」と担当者が困る場面を想像してください。その上長が出張や休暇で不在になると、案件はすべて止まります。「代理承認をお願いできませんか」と担当者が総務に相談しても、「規定上、代理を立てる手順が決まっていません」と返され、結局待つしかありません。承認という工程そのものが、1人に依存した単一障害点になっています。
2つめの場面は、顧客対応の窓口です。特定の取引先の担当が1人に固定され、その担当者しか取引先の背景や過去のやり取りを把握していないとします。新しく引き継ぐ人が「前回どんな条件で話が進んでいたか分かりません」と言えば、取引先に一から説明を求めることになり、信頼を損ないかねません。担当者が退職すれば、取引先との関係そのものが失われかねません。人が持つ暗黙の知識が、事実上の単一障害点になっている状態です。
3つめの場面は、ツールやファイルです。特定の集計作業が、ある1人の個人パソコンにしか入っていない表計算のマクロに依存しているとします。「あの人のパソコンが壊れたら、集計のやり方自体が分からなくなる」という状態です。そのパソコンが故障すれば、集計のやり方そのものが失われます。道具が1箇所にしか存在しないことも、単一障害点になり得ます。
複数の依頼が1人の担当者に集まり、その担当者が動けなくなると全体が止まる様子を示した図です。
「それはうちのエースだから仕方ない」という反論
単一障害点の一覧を上司に見せると、「それはAさんが優秀だからそうなっているだけで、仕方のないことだ」という反応が返ってくることがあります。
この反論には、一部の理があります。優秀な人に仕事が集まるのは、自然な結果でもあるからです。しかし、「仕方ない」で止めてしまうと、対策は何も進みません。優秀さを認めることと、その人がいなくなったときの備えをすることは、両立できます。
分けて考えると次のようになります。「Aさんが優秀だから今の判断の質が保たれている」ことと、「Aさんが休んだ日に、他の誰にも代わりが務まらない」ことは、別の問題です。前者は今のままでよく、後者だけを、この章の技術で埋めていきます。
実際のやり取りにすると、こう返すことができます。上司が「Aさんだから仕方ない」と言ったら、「Aさんの判断力はそのままで構いません。ただ、Aさんが不在の日の代わりだけ決めませんか」と返します。この言い方なら、Aさんの評価を下げる話ではないことが伝わり、話が前に進みやすくなります。
落とし穴
単一障害点探しには、よくある落とし穴が2つあります。
1つめは、「エース社員に集中させるのは効率がよい」という判断です。短期的には、最も得意な人に仕事を集める方が速く進みます。しかし、それは同時に、単一障害点を自ら作る判断でもあります。効率と壊れにくさは、しばしば逆方向を向きます。どちらを優先するかは、その業務が止まったときの損失の大きさで判断します。
たとえば、社内の定例資料の作成は、多少遅れても大きな損失にはなりません。効率を優先し、得意な1人に任せたままでもよい業務です。一方、顧客への請求処理が1人にしか担当できない状態は、止まった瞬間に実害が出ます。すべての業務を同じ基準で扱う必要はなく、損失の大きさで優先順位をつけます。
判断に迷ったときの目安は、「この工程が3営業日止まったら、誰にどんな迷惑がかかるか」を具体的に想像してみることです。社内で完結する迷惑と、顧客や取引先にまで広がる迷惑とでは、優先度が変わります。
2つめは、単一障害点を見つけただけで満足してしまうことです。どこが弱いかを地図にすることは、対策の前提にすぎません。地図を作った後に何もしなければ、弱点は弱点のまま残り続けます。次のページで扱う冗長化とフェイルオーバーまで進めて、初めて手が打てます。地図を作った直後は「対策した気分」になりやすいところですが、地図はあくまで出発点であり、実際に代わりが動ける状態を作るところまでが対策です。
持ち帰り
- 単一障害点とは、そこが止まると全体が止まる、たった1つの弱点のこと
- 業務フローを1本の流れに書き出し、担当できる人数が1人の工程を探す
- 効率のために仕事を1人に集中させることは、単一障害点を作る判断でもある
やってみる
自分の担当業務を1つ選び、「自分が今週休んだら、何が止まるか」を紙に書き出してみてください。