仕組みが壊れるのは、属人化のせいではなかった

仕組みを作り終えたとき、私はいつも少しだけ不安になります。

キャリアの初期、まだ20代だったころの話です。
担当していた業務フローを整理して、はじめてまともなマニュアルを作りました。ステークホルダーへの連絡タイミング、書類の処理手順、各所への確認ルートを整理して、「これで誰でもできるはずだ」と思って完成させた。

でも、作り終えた瞬間から、漠然とした違和感がありました。
「これで本当に渡せるのか」という感覚です。手順は書いた。でも日々のステークホルダーとのやり取りの中で生まれる細かい判断、イレギュラーなケースが起きたときの対応、フローとフローのあいだにある「ちょっとした対応」、こういったものはドキュメントに書けていない。書こうとしたけれど、どこまで書けばOKなのかのラインが自分でもわからない。
完璧に文書化しようとすると終わりがなく、かといって省くとそこが後で問題になる気がして、手が止まりました。

その当時は「経験が少ないから、マニュアルの書き方がわからないのだろう」と思っていました。でも仕事を続けるうちに、問題の本質は別のところにあると気づきはじめました。

退職が決まってから作るマニュアルが機能しない理由

マニュアルや仕組みの引き継ぎが失敗するとき、多くの場合、同じ条件が揃っています。その人が組織を離れることが決まってから、急いで作られているという条件です。

退職や異動が決まってから作るマニュアルには、構造的な限界があります。日常業務を回しながら限られた時間で書くため、ポイントを押さえた手順書になります。形式的には整っていても、実務で必要な判断の文脈が抜け落ちます。

なぜ判断の文脈が抜けるのか。それは、引き継ぐ本人がその判断を当たり前のこととして意識していないからです。
自分がどういうときにどう動くか、何を見て異常を察知しているか、どのタイミングでどちらの選択肢を選ぶか。これらは長年の実務を通じて体に染み込んでいて、自分では特別なことと認識していない。だから、マニュアルには手順が書かれても、「なぜその手順なのか」「何がおかしければ手を止めるのか」が書かれない。

引き継ぎを受けた側は、手順通りに動くことはできます。でも「いつもと違う」という感覚を持てない。異常を異常として検知できないまま、少しずつ現実から乖離した運用になっていく。これが、引き継ぎで仕組みが壊れるときに起きていることです。

本当に機能するマニュアルは、日々のオペレーションの中で少しずつブラッシュアップされながら作られるものです。イレギュラーが起きるたびに記録を更新する。判断に迷った事例を残す。こうして積み重ねることで、マニュアルに判断の文脈が宿っていきます。離れることが決まってから作るマニュアルは、その積み重ねの時間がない。だから、形は整っていても機能しません。

属人化の本当の正体は、異常に気づけない設計にある

引き継いで仕組みが崩れる原因として、多くの場合「属人化」が挙げられます。特定の人物しか理解できない業務が、その人の不在によって機能しなくなる、という説明です。

しかし私が現場で繰り返し経験したのは、少し別の現象でした。
引き継ぎ後に崩れた仕組みの多くは、属人的だったから崩れたのではなく、崩れていることに誰も気づけなかったから崩れたのです。

マニュアルが整備されていても、フローが文書化されていても、「今、仕組みがちゃんと動いているかどうか」を判断する基準がなければ、逸脱は静かに蓄積していきます。1週間に1ミリのズレが、半年後に取り返しのつかない乖離になる。そのプロセスに誰も気づけないのは、正常な状態がどういう状態かが定義されていないからです。

属人化を解消しようとするとき、多くの組織はドキュメントの整備とスキルの移転に集中します。それは必要なことです。でも、もう一つ必要なことがある。仕組みが正常に動いているとはどういう状態かの定義です。
手順書があっても、「今日の処理件数がいつもより30%少ない」「この承認ステップで毎回詰まっている」という事実に気づける人がいなければ、逸脱を検知できません。正常状態が定義されていないと、異常が見えない。見えない異常は、ゆっくりと組織の内側から蓄積していきます。

マニュアルの本質は、再現ではなく異常検知の基盤づくりだ

私がBizOpsの仕事をする中で大切にしていることの一つが、標準化の目的を、異常検知の基盤を作ることと捉えるです。

マニュアルをつくる目的を再現性の確保に置くと、どうしても手順書になります。何をどの順番でやるか、が書いてある文書です。それはそれで必要ですが、それだけでは足りない。
私が設計の段階で必ず書き込むようにしているのは、この仕組みが正常に動いているときの状態像です。数値でも、頻度でも、定性的な描写でも構わない。「この数字がこの範囲に収まっていれば問題ない」「この確認が週次で行われていれば大丈夫」という基準線を、引き継ぐ相手が自分で判断できる形で残す。

そうすることで、私がいなくてもおかしいと気づける人を、仕組みの設計の側から育てられます。判断は人が持つのではなく、仕組みが持つ。それが、引き継いでも崩れない仕組みの条件です。
属人化を語るとき、問題はその人しかできないことに置かれがちです。でも本当の問題は、その人がいなくなったとき、誰も異常に気づけないことです。手順を渡すことと、異常検知の目線を渡すことは、全く別の作業です。

仕組みは、設計者の目線で完結させてはいけない

引き継いだ後に崩れた仕組みを振り返ると、ほぼ共通して同じことが言えます。設計者が動くことを確認した段階で、仕事を終えたと思っていた。
動くことと、壊れずに動き続けることは、別のことです。

仕組みが壊れていないことを確認するには、正常な状態がどういう状態かを定義し、それが保たれているかを定期的に確認できる構造が必要です。設計者がその場にいるあいだは、設計者自身の感覚がその機能を担っています。でも設計者がいなくなった瞬間、その感覚は失われます。

20代のころ私が感じていた、渡しきれない部分の不安の正体は、これだったと思います。手順は書けた。でも「何がおかしければ立ち止まるか」という感覚は、ドキュメントに書いていなかった。それを言語化して渡すことが、引き継ぎの本質だったのに、当時の私はその言語化の方法を知らなかった。

属人化を解消したいと思っているなら、まず問うべきは手順は書いてあるかではなく、正常状態を定義してあるかです。
設計者の目線が去った後でも、仕組みがおかしいと気づける状態になっているか。その問いに答えられてはじめて、本当の意味での引き継ぎが完了します。

仕組みは、作った人がいなくなってからが本番です。
もしこの記事が、仕組みをつくる人の設計の問い直しに少しでも役立てば幸いです。

#BizOps #組織設計 #仕組み化 #業務改善 #マニュアル

正しく動く仕組みは、なぜ誰にも見えないのか
本記事が「なぜ壊れるか」を扱ったとすれば、こちらは「なぜ機能していても誰にも見えないのか」という逆説的な問いを深掘りしています。仕組みの設計に向き合う人に、あわせてお読みいただきたい一本です。

Xでは、記事にする前の断片や
現場で感じた違和感を ほぼ毎日書いています。
よかったら、のぞいてみてください。
https://x.com/kakushiaji_inc