前のページで、単一障害点を見つける方法を見ました。見つけたあと、どう手を打てばよいのでしょうか。このページでは、代わりを用意しておくという2つの技術を扱います。冗長化と、フェイルオーバーです。
冗長化とは何か
冗長化とは、同じ役割を果たせるものを、あらかじめ複数用意しておくことです。コンピュータシステムでは、重要な部品ほど二重、三重に用意します。サーバーを2台用意し、片方が壊れてももう片方が動き続けるようにします。電源も、通信回線も、同じ考え方で複数用意されます。
「同じものを2つ用意するのは無駄ではないか」と思うかもしれません。普段は無駄に見えても、壊れた瞬間にその価値が現れます。冗長化のコストは、保険料と同じ性質を持っています。
保険料にたとえると、もう少し判断しやすくなります。火災保険は、火事が起きない限り「払って終わり」の費用に見えます。しかし、万一火事が起きたときの損失を考えれば、払う価値があると判断されます。冗長化も同様で、「普段のコスト」と「止まったときの損失」を天秤にかけて決めるものです。どんな業務にも一律にかけるものではなく、損失が大きい業務から優先して考えます。
フェイルオーバーとは何か
冗長化された代わりが、実際に仕事を引き継ぐ仕組みを、フェイルオーバーと呼びます。フェイルオーバーとは、主担当が機能しなくなったとき、控えへ処理を自動的に切り替える仕組みのことです。
ここで重要なのは「自動的に」という部分です。控えを用意していても、切り替えに人の判断と時間がかかるなら、その間は仕事が止まったままです。優れた設計は、切り替えの手順そのものをあらかじめ決めておきます。誰が、何を見て、どう動くかを、壊れる前に書いておく作業です。
たとえば、サーバーの世界では「主担当が10秒応答しなければ、控えに自動で切り替える」というように、切り替えの条件そのものを数値で決めておきます。人が現場に駆けつけて状況を確認してから判断するのでは、その間ずっと止まったままです。仕事の世界でこの発想を借りるなら、「誰が休んだら、いつまでに、誰が引き継ぐと判断するか」を先に決めておくことにあたります。
段階を追って整理すると、フェイルオーバーには3つの要素が必要です。1つめは、切り替えの引き金です。「当日朝9時までに出社連絡がなければ」のような条件です。2つめは、切り替え先です。「誰が引き継ぐか」を、あらかじめ名前で決めておきます。3つめは、切り替えに必要な材料です。手順書やデータの置き場所そのものです。このどれか1つでも欠けていると、いざというときに切り替えが機能しません。
仕事の言葉に翻訳する
仕事における冗長化は、複数担当制や、バックアップ担当の指名にあたります。1つの業務に、主担当と副担当をあらかじめ両方割り当てておくことです。
仕事におけるフェイルオーバーは、「主担当が動けないとき、副担当がどう引き継ぐか」の手順そのものです。連絡先の共有だけでは足りません。副担当が実際に、途中から作業を再開できる状態を指します。
具体的な場面
1つめの場面は、週次報告です。報告担当が1人だと、その人の不在がそのまま報告の欠落になります。週次報告のデータ取得手順と、まとめ方の型を文書にしておき、副担当がその文書だけを見て代われる状態にしておきます。これが、報告業務における冗長化です。
手順の文書には、次のような具体的な粒度が必要です。「どのシステムの、どの画面から、どの期間のデータを取得するか」「取得したデータを、どの順番でどう集計するか」「最終的にどの形式で、誰に、何時までに送るか」。この3点が抜けていると、副担当は文書を読んでも手が止まります。
2つめの場面は、顧客からの問い合わせ対応です。特定の取引先とのやり取りが、担当者の記憶だけに残っていると、その担当者が不在のとき、対応の質が落ちます。やり取りの経緯を、担当者以外も見られる場所に記録しておくことが、フェイルオーバーを機能させる前提になります。記録がなければ、控えの人がいても、実際には引き継げません。
たとえば、副担当が電話を代わりに受けたとします。「その件は担当のBが対応しております」としか言えなければ、顧客は不安になります。一方、記録があれば「先週いただいたご相談は、今こういう状況です」と即答でき、顧客は担当者の不在に気づかないまま話が進みます。
3つめの場面は、会議の進行です。特定の1人しか会議を回せない状態は、進行役という工程の単一障害点です。進行の手順、決めるべき項目、次のアクションの確認方法をテンプレート化しておけば、別の人でも進行を代われます。これは、進行役という役割の冗長化にあたります。
たとえば、いつもの進行役が急に休んだ会議を想像してください。テンプレートがなければ、参加者は「今日は何を決める会議でしたっけ」から話し始めることになり、本題に入るまでに時間を取られます。テンプレートに「今日決めること」「持ち帰り事項の確認方法」が書かれていれば、別の人が読み上げるだけで、会議の骨格は保たれます。
この3つの場面に共通しているのは、代わりの人が「ゼロから考えなくてよい」状態です。副担当が自分の頭で手順を組み立て直す必要があるうちは、まだ本当の意味での冗長化にはなっていません。
主担当が動けなくなったとき、あらかじめ決めた手順で副担当に処理が切り替わる様子です。
「時間がなくて手順書まで書けない」という反論
冗長化の話をすると、「手順書を書く時間がそもそも取れない」という反論がよく出ます。これは正直な感想であり、否定する必要はありません。
ただし、比較すべき相手を間違えないようにします。比較すべきは、「手順書を書く時間」と「何も書かないでいる時間」ではありません。「手順書を書く時間」と「担当者が不在になったときに毎回発生する混乱の時間」の比較です。不在は1回きりではなく、体調不良や急な休暇のたびに繰り返し発生します。
最初から完璧な手順書を目指す必要もありません。まずは、先ほど挙げた3点(取得元・手順・提出先)だけを箇条書きで書き出すことから始めます。小さく始めて、実際に副担当が使ってみた後で、抜けていた点を追記していく方が現実的です。
落とし穴
冗長化には、2つのよくある落とし穴があります。
1つめは、「連絡先を共有しただけ」で冗長化した気になることです。副担当の名前を決めても、手順やデータの在り処が担当者の頭の中にしかなければ、実際には引き継げません。冗長化は、人を割り当てるだけでなく、引き継ぐための材料を外に出す作業とセットです。
2つめは、冗長化を全部の業務に均等にかけようとすることです。すべての業務を二重化するコストは、通常の業務量を圧迫します。まず、単一障害点として深刻な工程から、優先順位をつけて冗長化することが現実的です。止まったときの損失が小さい業務にまで手をかけると、冗長化そのものが新しい負担になってしまいます。
たとえば、10個の業務すべてに副担当を立て、手順書を書こうとしたチームがあったとします。本来の業務時間を削って手順書作成に追われ、数か月後には「手順書を書く余裕がないから後回し」という、本末転倒な状態に陥りました。前のページで見た単一障害点の地図から、影響の大きい上位2、3個に絞って着手していれば、こうはならなかったはずです。
冗長化とフェイルオーバーは、単一障害点の地図に対する、直接の返答です。弱点を見つけたら、代わりを用意し、切り替え方まで決めておく。この2ページで、代わりが動ける状態までは作れました。
しかし、代わりを用意しても、日々の仕事の量そのものが1人に偏っていれば、その人はいずれ疲弊します。次のページでは、仕事の量を複数人にどう配るかという、負荷分散を扱います。不在対策と、日々の偏り対策は、似ているようで別の課題であり、両方が揃って初めて盤石になります。
持ち帰り
- 冗長化とは、同じ役割を果たせる代わりを、あらかじめ複数用意しておくこと
- フェイルオーバーは、主担当が動けないときに副担当へ切り替える手順そのもの
- 連絡先の共有だけでは冗長化にならず、引き継ぐ材料を外に出す必要がある
やってみる
自分の主担当業務を1つ選び、その手順を、副担当が読むだけで再現できる形で書き出してみてください。