バックオフィスの仕組み化が失敗する理由｜原因は属人化にある
はじめに
「うちは仕組み化できているはずなんですが、なぜか業務が回っていないんです」
3500社以上のバックオフィスを見てきて、この言葉を何度聞いたかわかりません。
そしてたいてい、こう続きます。
「マニュアルはある」「フローも整備している」「ツールも導入している」
それでも現場はこう言います。
「結局、人に聞かないと分からない」「担当者が変わると再現できない」「想定外の自称が来ると対応できない」
しかし原因はシンプルです。
仕組み化の問題ではありません。属人化の問題です。
結論｜仕組み化が失敗する会社は、例外なく属人化しています
仕組み化が失敗している会社は、例外なく属人化しています。
仕組みがないからではありません。ツールが足りないからでもありません。
属人化している状態で仕組み化しようとしているから失敗するのです。
ここでいう属人化とは、「特定の人しかできない状態」ではありません。「構造が存在しない状態」です。
なぜ仕組み化は失敗するのか——属人化という前提
重要なのはただ一つです。再現できるかどうか。
属人化している状態では、誰も同じように実行できない。判断が人ごとに変わる。イレギュラーで止まる。つまり仕組みが存在していないのと同じです。
さらに危険なのは、表面上は業務が回っていることです。ベテランが抱え込む。周りには見えない。表面上は問題なく進んでいる。この3つが重なると、経営者は安心します。しかし実態は完全なブラックボックスです。
回っているときこそ設計するのが鉄則です。担当者がいなくなった後に初めて問題が表面化するのでは手遅れです。
仕組み化が失敗する4つの理由
① マクロ・ツールが属人化を生む
「マクロで効率化しています」——一見すると仕組み化に見えます。しかし実態は違います。
作った人しか分からない。修正できる人がいない。エラー対応できる人がいない。作成者が辞めるとマクロごと止まります。マクロを組んで業務を効率化していること自体が属人化なのです。
これはAI時代でも同じです。AIで業務を設計した担当者が辞めると、AIも止まります。ツールがマクロからAIに変わっても、「効率化できている人＝設計を独占している人」になっている構造は変わりません。
マクロやAIはその人にとっては効率的なプロセスツールかもしれませんが、組織や会社にとってはブラックボックスの温床となりかねません。
理解できる人が限定されている時点で属人化です。再現できない効率化はすべて属人化です。
② 改善が属人化を加速させる
優秀な担当者ほど業務を改善します。フォーマットを変える。手順を変える。確認ポイントを追加する。本来は良いことです。
しかし問題はマニュアルが更新されないことです。優秀な人ほど自分でやった方が早いため、マニュアルを振り返りません。改善は即座に実装されますが、マニュアルは更新されない。その結果、実務とマニュアルが乖離します。マニュアルが信用されなくなる。誰も見なくなる。この瞬間に仕組みは機能しなくなります。
改善され続ける業務ほど、属人化が進みます。「改善したら必ずマニュアルを更新する」をセットにする設計がなければ、改善はブラックボックス化の加速装置になります。
③ 引き継ぎの言葉が仕組みを壊す
仕組み化を壊す典型的な言葉があります。
「この業務は簡単です」という業務の説明や引継ぎ——これは現場で非常に多く見受けられることです。そしてこれは例外なく失敗します。「簡単」は伝える側のレベル感であり、受ける側の実力を考慮していません。業務の9割は確かに簡単かもしれません。問題は残り1割のイレギュラーです。「簡単」という言葉がその1割の存在を隠し、後任者は細部まで聞く勇気を失い、例外が発生した瞬間に業務が止まります。
「効率的な方法に変えてください」——これも崩壊します。変更した人だけが新しいやり方を知っている。マニュアルは更新されない。次の引き継ぎで誰もわからない状態になる。
さらに問題なのは引き継ぎの構造です。伝える側は時間がないから端折りたい。受ける側は迷惑をかけたくないから深く聞けない。双方が抽象的なまま終わらせています。これが仕組み化失敗の根本原因です。
④ 設計の基準が間違っている
「できる人を前提に設計する」——これは間違いです。
「任せれば正しくやってくれるはず」「渡せば読むはず」「伝えればわかるはず」——この前提で設計すると、優秀な人が辞めた瞬間にすべてが止まります。
本来やるべきは逆です。属人化解消の設計基準は「新卒でもミスが起きない」状態にすることです。
新卒は業務の前提知識がない。全く知らない人でも動く状態が本当の設計です。人は必ずミスをします。意識や能力は信用できません。この前提で設計しない限り、その仕組みは再現できません。
職人気質の優秀な担当者ほど、ミスの原因を「その人のスキル不足」と断定する傾向があります。「私だったらすぐできる」「これは簡単なのに」——しかし問題は意識ではなく設計の不在です。
よくある誤解——すべて間違っています
「ツールを入れれば仕組み化できる」——できません。使い方が人ごとに違う時点で属人化です。
「フローを作れば回る」——回りません。イレギュラーで必ず詰まります。得意先とのイレギュラーは営業部と口頭調整。仕入先とのイレギュラーは調達部と口頭調整。決算のイレギュラーは税理士や社長と口頭調整。これらは記録されず、担当者の頭の中に蓄積されます。担当者が辞めた瞬間に消えます。
「優秀な人に任せればいい」——最も危険です。「○○さんの判断でやっている」状態は完全なブラックボックスです。ルールがないからこうなります。その人が辞めた瞬間に再現できません。
解決策｜仕組みは再現性で設計する
性弱説で設計することです。
人は弱い。ミスをする。面倒を避ける。この前提で、それでも回る仕組みを作る。これが持続可能な設計思想です。
① 業務を分解する：何を見るのか、どこを確認するのか、どのファイルを使うのか——ここまで明確にします。「今月分」「先月分」という相対表現は禁止です。「2026年4月分」など具体的な月を明示することで認識齟齬を防ぎます。
② 判断基準を固定する：「○○さんの判断でやる」は完全なブラックボックスです。判断は仕組みに移します。特に3ヶ月に1度しか発生しないイレギュラーこそ、具体的な月と内容を記録することが重要です。
③ チェックまで設計する：事前チェック→処理→事後チェック、ここまでで初めて「仕組み」が完成します。チェックを省略した仕組みは半製品です。ダブルチェックより推移によるチェック（前月・前年同月との比較）が有効です。
④ 複数人で回す：メイン＋サブの2名体制を基本にします。仕組みを考える人と作業する人も分ける。1人に二役をやらせない。設計と作業では求められる思考が根本的に異なります。
本質｜仕組み化とは人を前提にしない設計
仕組み化とは効率化ではありません。再現性です。
人に依存している時点で、それは仕組みではありません。属人化です。
仕組み化の完成基準は「新卒でもミスが起きない状態になっているか」です。優秀な人がいれば回る。マクロが動いていれば回る。担当者が頑張れば回る——この状態は仕組みではなく属人化の継続です。
最後に——強い会社は仕組みに依存する
多くの会社は人で回しています。しかし強い会社は違います。仕組みで回します。その結果として人が入れ替わっても維持できます。優秀な人がいれば業務がまわる、というものは仕組みではありません。
もし1つでも当てはまるなら、属人化はすでに進行しています。
問題は「あるかどうか」ではありません。いつ持続できなくなるかです。
問題は人ではありません。属人化です。そして属人化は設計でしか解決できません。
同じ問題を繰り返したくない方はフォローしてください。
関連記事
→ 第1回：公認会計士がバックオフィスBPO会社を作った理由
→ 第2回：なぜバックオフィス担当は突然辞めるのか
→ 第3回：強い会社は教育より仕組みを作る
→ 第4回：バックオフィスの属人化が起きる会社の特徴5選
→ 第5回：なぜバックオフィスの属人化防止のためにイレギュラーは設計しなければならないのか
→ 第6回：バックオフィスの属人化は採用では解決しない理由
→ 第7回：なぜバックオフィスの属人化は「ある日突然」崩壊するのか
→ 第8回：なぜ会社は「仕組みで回る組織」と「属人化で止まる組織」に分かれるのか
→ 第9回：バックオフィスの品質が安定しない理由｜原因は属人化にある
→ 第10回：マニュアルが機能しない会社の共通点｜原因は属人化です
筧 智家至 公認会計士・税理士 BackofficeForce株式会社 代表（12年・3500社以上支援）
