週次報告の担当者が、急に体調を崩して休んだとします。代わりに数字をまとめられる人がいなければ、報告そのものが止まります。問い合わせ対応の一次窓口も、経理の締め処理も、同じことが起こり得ます。特定の一人にしかできない仕事があると、その人が抜けた瞬間に仕事全体が止まります。
なぜ一人が抜けただけで、チーム全体の仕事が止まるのでしょうか。この章では、その問いをコンピュータの世界の言葉で読み直します。
ある月曜日に起きること
具体的な場面から始めます。月曜の朝、週次報告の担当者Aさんから、体調不良で休むという連絡が届きます。
上司は「今週の報告はどうする」とチームに尋ねますが、すぐに答えられる人がいません。「代わりにやりましょうか」と手を挙げた同僚Bさんも、数分後に困った顔で戻ってきます。Aさんしか、集計に使う元データの置き場所と、まとめ方の手順を知らないからです。「どのファイルを開けばいいのか、フォルダを見ても分かりません」とBさんは言います。
結局、報告は水曜まで延期され、会議の議題もそのぶん後ろにずれます。遅れた報告を待つ他部署からは、「今週も遅れるのか」という小さな不信が積み重なります。
木曜に復帰したAさんに、上司は「大変だったね、次からどうしよう」と声をかけます。Aさんは「手順書を作ります」と答えますが、通常業務に戻ると、その約束は忘れられがちです。次にAさんが休んだときも、同じやり取りが繰り返される可能性が高いままです。
この一連の流れは、特別に運の悪い出来事ではありません。特定の1人に手順が集中している職場では、繰り返し起こる構造的な出来事です。Aさんの体調が原因なのではなく、手順の置き場所の設計が原因だと考えると、見え方が変わります。
同じパターンは他の業務でも起きる
週次報告だけの話ではありません。経理の月末締め処理も、特定の1人しか仕訳のルールを把握していなければ、同じことが起きます。「今月は締められません、担当が有給なので」という一言で、支払いのスケジュール全体が遅れます。
問い合わせ対応の一次窓口も同様です。「この件は前にも問い合わせがあったはずだが、経緯を知っているのは辞めた前任者だけだ」という状況では、同じ質問に毎回ゼロから対応し直すことになります。
3つの場面に共通しているのは、業務の種類ではありません。「その手順を再現できる人数」が1人しかいない、という構造そのものです。週次報告、月末締め、問い合わせ対応は、表面上まったく違う仕事に見えます。しかし、単一障害点という同じレンズで見ると、まったく同じ形の弱点として並びます。
属人化を「設計の問題」として見る
この状況は、日本語の職場ではよく「属人化」と呼ばれます。特定の業務のやり方や判断が、特定の個人の頭の中にしかない状態を指す言葉です。
属人化は精神論の問題として語られがちです。「あの人に頼りすぎている」という反省です。しかし、見方を変えると、これは仕組みの設計の問題として説明できます。
チームや業務プロセスは、複数の担当者が仕事を分担して処理する仕組みです。これは、複数のコンピュータが協力して仕事をこなす「分散システム」と、同じ構造を持っています。分散システムとは、複数の処理装置をネットワークでつなぎ、1つの仕事をこなす仕組みのことです。
段階を追って考えます。まず最も単純な形は、1台のコンピュータだけで動くアプリです。そのコンピュータの電源が落ちれば、アプリはそのまま止まります。これは分散していない状態です。
次に、同じアプリを2台のコンピュータで動かす場合を考えます。ただ2台に増やすだけでは、どちらが今の担当かを決める仕組みがなければ、かえって混乱します。そこで、普段どちらが処理を受け持ち、もう1台はいつ代わるのかを、あらかじめ決めておきます。
壊れる前提で、壊れても止まらない形を先に作ること。これが分散システムの基本発想です。数を増やすだけでなく、増やした部品をどう連携させるかまでを、セットで設計します。
チームの仕事が止まる理由も、まったく同じ理屈で説明できます。違いは、部品がコンピュータではなく、人と手順書だという点だけです。
「うちは規模が小さいから関係ない」という反論
ここで、よくある反論に触れておきます。「大企業のシステムの話であって、うちのような小さなチームには関係ない」という反論です。
しかし、単一障害点は組織の規模と関係なく生まれます。むしろ小さなチームほど、1人あたりの担当範囲が広く、属人化しやすい傾向があります。3人のチームで1人が抜ければ、残った2人の業務量は単純計算で3割以上増えます。
「うちは3人しかいないから、誰が何をやるかは全員分かっている」という声もあるでしょう。しかし、「分かっている」ことと、「その人がいなくても再現できる」ことは別です。頭の中で把握していることと、他人が引き継げる形になっていることの間には、大きな差があります。その差を埋める作業こそが、この章で扱う設計です。
試しに、チームリーダーが「では、あなたの担当業務の手順を1つ、口頭で説明してみて」とメンバーに頼んでみたとします。多くの場合、途中で「ここは感覚でやっている」「この判断はケースバイケースです」という言葉が出てきます。それこそが、まだ他人に引き継げる形になっていない部分です。言葉にできない部分を1つずつ書き出していく作業が、次のページ以降の出発点になります。
大企業の分散システムの話は、規模の大きさそのものではなく、「壊れることを前提に、壊れても止まらない形を先に設計する」という考え方の話です。考え方そのものは、チームの人数を問わず、そのまま使えます。
この章で見る4つの視点
この章では、分散システムの設計から、4つの視点を仕事に翻訳します。
1つめは、単一障害点です。これは、そこが壊れると全体が止まってしまう1箇所を指す言葉です。まず、自分のチームのどこにそれがあるかを見つける視点を持ちます。先ほどのAさんの例で言えば、「週次報告の集計手順」がその単一障害点にあたります。
2つめは、冗長化とフェイルオーバーです。冗長化とは、同じ役割を果たせるものを複数用意しておくことです。フェイルオーバーとは、主担当が動けなくなったときに、控えへ処理を切り替える仕組みです。不在の人がいても仕事が止まらない設計を考えます。Aさんの例なら、副担当が手順書だけを見て、代わりに集計できる状態を指します。
3つめは、負荷分散です。仕事を1人に集中させず、複数人に均等に配る技術です。特定の人だけが忙しくなり続ける状態を避ける考え方を扱います。
4つめは、結果整合性です。これは、関係者全員が「今この瞬間」に同じ情報を持っていなくても、仕組みとして最終的にそろえば問題ない、という考え方です。情報共有を完璧に同期させようとして疲弊するチームへの処方箋になります。
なぜ属人化は「気合」では解決しないか
属人化への対策として、「もっと共有しよう」という掛け声だけで終わる職場は少なくありません。実際にありがちな流れを、段階を追って見てみます。
まず、Aさんが休んだ翌週、上司が朝会で「情報共有を徹底しよう」と呼びかけます。チームは一時的に、議事メモを丁寧に書くようになります。
しかし2週間もすると、通常の業務量に押されて、丁寧なメモは元の簡素な形に戻ります。掛け声は、日々の業務の忙しさの前では長続きしません。
なぜ長続きしないのかを、もう一段掘り下げます。掛け声そのものが、仕組みになっていないからです。「共有しよう」という意志は、毎日その意志を思い出し続けることを本人に求めます。思い出す負担がある限り、忙しい日には必ず後回しにされます。
分散システムの設計者は、意志の力ではなく、構造で壊れにくさを作ります。どこが壊れやすいかを名指しし、代役の仕組みを先に用意し、仕事の配り方そのものを変えます。
構造として組み込むとは、たとえば「集計手順を文書化しないと、今月の報告を締めてはいけない」というルールを、業務フローそのものに組み込むことです。思い出す努力ではなく、そうしないと先に進めない仕組みにします。仕組みを一度作ってしまえば、その後は誰の記憶力にも頼らずに回り続けます。
意志を否定しているのではありません。意志だけに頼る対策は、担当者の体調や気分に左右され、長続きしないという話です。仕組みとして組み込んでおけば、誰かの頑張りに依存せずに済みます。
属人化はゼロにできるか
念のため補足すると、属人化を完全にゼロにすることが目的ではありません。専門性の高い判断を、経験を積んだ1人に委ねること自体は自然です。たとえば、長年の取引先との関係づくりや、難しい技術判断は、経験によって質が上がります。それ自体を無理に分散させる必要はありません。
たとえば、難しい契約交渉を任されているベテランのCさんがいるとします。交渉の勘所そのものをマニュアル化するのは、現実的ではありません。一方で、「今どの案件が進行中か」「次の連絡はいつ必要か」という進捗の情報までCさんの頭の中にしかないなら、それは別の話です。判断の質は1人に委ねつつ、進捗という情報だけは外に出しておく、という切り分けができます。
問題になるのは、その1人が抜けたときの代わりが、まったく用意されていない状態です。専門性を保ちながら、代わりが動ける仕組みを重ねて持つことが、この章のゴールです。
この章を読み終える頃には、あなたのチームのどこに単一障害点があるかを、名指しできるようになっているはずです。そして、それを構造として直すための、具体的な語彙を手にしているはずです。
冒頭のAさんの例に戻ると、必要だったのは「もっと頑張って共有する」ことではありません。週次報告という工程を、1人ではなく2人以上が回せる形に、あらかじめ組み替えておくことでした。次のページから、その組み替え方の第一歩である、単一障害点の見つけ方を具体的に見ていきます。
持ち帰り
- 属人化は精神論の問題ではなく、仕事の分担という設計の問題として扱える
- チームは、複数の担当者が仕事をこなす分散システムとして見られる
- 単一障害点・冗長化とフェイルオーバー・負荷分散・結果整合性の4視点で読み解く
やってみる
明日、自分のチームの業務を1つ選び、「この仕事は今、誰か1人しかできない状態か」を書き出してみてください。