「その業務、担当の方が長期で休んだら止まりますか？」——この問いに苦い顔で「はい」と答える会社は少なくありません。また、そのような会社に限って担当の方が長期で休んだり退職することをリスクとして想定できていません。そして想定できている会社でも、多くの場合解決策として最初に挙がるのが「マニュアルを整備する」「もう一人採用する」の2つです。
しかし、1,500社以上のバックオフィスの現場に携わってきた当社の経験から言えば、この2つでは属人化は根本的には解決しません。マニュアルは作った瞬間から現場とずれ始め、新しく採用した人も、いずれ「その人にしかできない業務」を抱えていくからです。
必要なのは、個人の努力を積み増すことではなく、業務そのものを設計し直すことです。本記事では、属人化を根本から解消する「業務設計」とは何か、そして誰が担当しても同じ品質で回る仕組みをどうつくるのかを、体系的に解説します。
業務設計とは何か——定義と本質
業務設計は、マニュアル整備や増員とは異なるアプローチです。まずは定義と、手順書との決定的な違いから整理します。
業務設計の定義
業務設計とは、特定の担当者に依存せず、誰が担当しても同じ品質で業務が回るように、業務の「手順」「判断基準」「責任範囲」をあらかじめ組み立てておくことです。
手順書との最大の違いは、「判断基準まで含めて設計する」点にあります。作業の順番を並べるだけなら手順書ですが、業務設計は「なぜその処理をするのか」「例外が起きたらどう判断するのか」までを言語化します。この一点が、属人化を解消できるかどうかの分かれ目になります。
業務設計を構成する3つの要素
定義に出てきた3要素は、それぞれ役割が異なります。どれか一つが欠けても業務は止まるため、順に見ていきましょう。
手順は「何を、どの順番で」を定めます。ここだけを整えたものが、いわゆるマニュアルです。多くの会社が着手し、そして多くの会社がここで止まります。
判断基準は「迷ったときに、何を基準に決めるか」を定めます。業務設計の中核はここです。たとえば経費精算なら、手順は「申請を受け取り、内容を確認し、承認する」で終わりますが、実務で時間を溶かすのは「この支出は会議費か、接待費か」「この金額は資産計上か、費用処理か」といった判断です。判断基準が言語化されていない業務は、手順書がどれだけ分厚くても、結局その人にしか回せません。
責任範囲は「どこまでが自分の責任で、どこからが誰の役割か」を定めます。ここが曖昧だと、例外が起きるたびに担当者が判断を抱え込むか、逆に全員が様子見をして業務が滞ります。「入力する人とチェックする人を分ける」といった設計は、ミス防止のためだけでなく、責任範囲を構造として固定するために行います。
「マニュアルがある」ことと「業務が設計されている」ことは違う
多くの会社で「マニュアルはあります。」と伺います。しかしその多くは棚やフォルダにしまわれ、実際の業務は結局「担当者の頭の中」で動いています。
大切なのは、マニュアルが存在することは、業務が仕組みで回っていることを意味しないという点です。マニュアルは、整備に「取り組んだ証拠」ではあっても、業務が「整った証拠」ではありません。本当に設計された業務は、マニュアルを逐一読まなくても回ります。手順と判断が業務フローそのものに埋め込まれ、迷う場面が構造的に減っているからです。
逆に言えば、「マニュアルを見てください」と言わなければ回らない業務は、まだ設計されていません。人は基本的に、マニュアルを網羅的には読まないからです。読まれる前提で分厚い文書を作るのではなく、読まなくても迷わない業務フローに組み替えること。それが業務設計とマニュアル整備の決定的な違いです。
業務設計が解消する「属人化の3つの共通点」
属人化した業務には、部門を問わず、次の3つの共通点があります。
- 説明できない——担当者本人が「なんとなく」で進めているため、手順を言葉にできない
- 再現できない——他の人が同じ手順をなぞっても、同じ結果にならない
- 判断基準が曖昧——「この場合はこうする」という基準が明文化されていない
業務設計とは、この3点を一つずつ潰していく作業にほかなりません。この3つは、そのまま診断のチェックリストとしても使えます。気になる業務を一つ思い浮かべて、担当者に「この業務の手順を、5分で口頭で説明できますか」と聞いてみてください。詰まるようであれば、その業務はすでに属人化しています。（属人化そのものの原因やリスクについては、第2章「属人化とは」で詳しく解説しています）
業務設計と混同されやすい4つの言葉
業務設計を語るとき、必ず出てくる言葉があります。「仕組み化」「標準化」「見える化」「集約」の4つです。これらは正しく行えば業務設計の構成要素になりますが、形だけ真似ると、かえって「◆◆の形をした属人化」に陥ります。よくある4つの失敗パターンを整理します。
「仕組み化」したのに回らない
ツールを導入し、フローを決めた。それでも特定の人に業務が集中する——これは「仕組み化の形をした属人化」です。仕組みが結局は人の判断に依存している限り、仕組み化は完成しません。
「標準化」したのに品質がばらつく
書式やテンプレートを統一しても、埋め方の判断が人によって違えば、標準化は表面的なものにとどまります。標準化とは、書式ではなく判断をそろえることです。
「見える化」したのに誰も動かない
ダッシュボードやレポートを整えても、「その数字を見て何を判断するのか」が設計されていなければ、見える化は装飾に終わります。
「集約」したのに一人に集まっただけ
シェアードサービスやアウトソースで業務を集約しても、集約先がまた一人依存であれば、属人化の場所が移っただけです。
これら4つは、いずれも「手段」であって「目的」ではありません。業務設計は、この4つを『誰がやっても同じ品質で回る』という一点に向けて統合する上位概念です。それぞれの落とし穴の詳細は、専門記事で解説しています。
どこから始めるか——業務設計の優先順位のつけ方
すべての業務を一度に設計し直そうとすると、ほぼ確実に頓挫します。バックオフィスの業務は数が多く、しかも日常業務を止められないからです。着手順を決める軸は2つで足ります。
一つ目は「その人が抜けたら止まるか」。二つ目は「止まったとき、事業にどれだけ影響するか」です。この2軸で業務を4つに分けると、優先順位は自動的に決まります。
- 止まる × 影響大——最優先。請求・支払・給与・月次決算がここに入る会社がほとんどです
- 止まる × 影響小——次点。緊急性は低いものの、放置すると担当者の負荷として蓄積します
- 止まらない × 影響大——すでに複数人で回せている業務。設計の完成度を上げる対象
- 止まらない × 影響小——当面は手をつけない
重要なのは、最初の対象を1つか2つに絞ることです。範囲を欲張るほど、設計が終わる前に日常業務に押し戻されます。まず1業務を最後までやり切り、「設計すると本当に回るようになる」という実感を社内に作ったほうが、結果的に全体は速く進みます。
BOF式・業務設計の3ステップ
BackofficeForceは、現場で繰り返し確立してきた業務設計の型を、「課題発見 → ナレッジ型化 → 運用の安定化」の3ステップに整理しています。順番に意味があり、飛ばすと必ず後戻りが発生します。
ステップ1：課題発見——「止まる業務」を特定する
まず業務を棚卸しし、「その人が抜けたら止まる業務」を洗い出します。すべての業務を一度に設計し直す必要はありません。止まると事業に影響が出る業務——請求・支払・月次決算・給与——から着手するのが定石です。ここで先ほどの「属人化の3共通点」が診断の物差しになります。
進め方は、担当者へのヒアリングではなく、実際の業務の並べ直しから始めます。過去3ヶ月の業務を「毎日／毎週／毎月／年次」の4分類で書き出し、期日のあるものに印をつける。これだけで、その部門が何回のサイクルで回っているかが見えます。年次の業務は忘れられやすいため、必ず12ヶ月分をさかのぼって拾います。
つまずきどころは、担当者本人に「どんな業務をしていますか」と尋ねて終わりにすることです。属人化した業務ほど、本人は無意識に処理しているため、聞いても出てきません。出てこなかった業務こそが、引き継ぎの時に事故になります。実際の仕訳履歴、承認履歴、送信済みメールといった「記録」から拾い直すほうが確実です。
このステップの完了条件は、業務の一覧に「担当者以外の誰かが、期日と目的を説明できる」状態になっていることです。網羅性ではなく、説明可能性で判定します。
ステップ2：ナレッジ型化——判断基準まで言語化する
ここが業務設計の核心です。手順だけでなく、「なぜそうするのか」「例外時にどう判断するか」を言語化し、担当者の頭の中にある暗黙知を、誰でも参照できる形（ナレッジ）に変換します。
判断の目安はシンプルです。「この業務、あなたが横で説明しないと回りませんか？」——横での説明が必要な時点で、その業務はまだ仕組みで動いていません。説明がなくても後任が進められる状態になって、初めてナレッジ型化は完成します。
進め方として有効なのは、手順書を書き起こす前に、まず「迷った場面」を集めることです。担当者に1〜2週間ほど、判断に迷った瞬間をその都度メモしてもらう。出てきたメモが、そのまま言語化すべき判断基準のリストになります。手順は後から書けますが、判断は実際に迷った瞬間でないと言葉になりません。
あわせて、作業画面の録画を残す方法も効果的です。文章に起こすと膨大になる操作も、数分の録画なら負荷なく残せます。文書化のハードルが下がるぶん、更新も続きます。
つまずきどころは、完璧な文書を目指してしまうことです。ナレッジ型化のゴールは「読めば分かる文書」ではなく、「後任が迷わず進められる状態」です。例外の8割を拾えていれば、残りは運用しながら足していけば構いません。むしろ、完成度を上げようとして公開が遅れるほうが損失になります。
このステップの完了条件は明確です。担当者が横にいない状態で、別の人がその業務を一度通せること。「引き継いだ」ではなく「引き継げた」で判定します。
ステップ3：運用の安定化——回り続ける状態をつくる
設計した業務を運用に乗せ、改善しながら安定させます。ここで「安定度を測る指標」を一つ持つと効果的です。たとえば月次決算なら「翌月10営業日以内に締まるか」。この基準を継続的に満たせるなら、その業務は設計され、仕組みで回っている確かな証拠です。
指標は業務ごとに一つで足ります。請求業務なら「請求書の発行漏れがゼロか」、支払業務なら「支払期日の超過がゼロか」、給与なら「支給日から逆算した確定タイミングを守れているか」。数を増やすと計測自体が新しい負担になり、続きません。
進め方は、設計した直後の1〜2サイクルを「設計者が横で見る期間」と決めておくことです。この期間に出た詰まりは、担当者の習熟不足ではなく設計の穴と考えて、その場で設計に戻します。運用に乗せてから直すほうが、机上で完璧を目指すより早く安定します。
つまずきどころは、指標が悪化したときに「担当者の頑張り」で埋めてしまうことです。締まらない月が続いているのに残業で吸収していると、設計の問題が見えなくなり、属人化が静かに戻ります。指標は、人を評価するためではなく、設計の劣化を早期に検知するために置きます。
このステップの完了条件は、担当者が交代しても指標が維持されることです。ここまで来て、業務設計は完了したと言えます。
「引き継ぎ」で業務設計を失敗させないために
退職や異動のたびに引き継ぎ資料を作る会社は多いですが、その多くが機能しません。理由は、「引き継いだ」と「引き継げた」を混同しているからです。
資料を渡すことは、引き継ぎの完了ではありません。後任が、その資料だけで同じ品質を再現できて、初めて「引き継げた」と言えます。業務設計ができていれば、引き継ぎは「特別なイベント」ではなくなります。業務がもともと誰でも回る形で設計されているため、担当者が代わっても品質が落ちないからです。逆に言えば、引き継ぎのたびに現場が混乱する会社は、業務が設計されていないサインです。
引き継ぎが失敗する構造には、共通のパターンがあります。前任者の「この業務は簡単ですよ」という一言の裏に、月に一度しか発生しない例外が隠れているのです。産休中社員の社会保険、途中入退社の日割り計算、遡及計算、特定社員の手当判定——いずれも頻度は低いのに、間違えると影響が大きいものばかりです。手順は渡せても、判断は渡せない。これが引き継ぎ失敗の正体です。
したがって、引き継ぎを成功させたいなら、引き継ぎの場で頑張るのではなく、引き継ぎを日常に埋め込むほうが確実です。退職が決まってから資料を作るのではなく、判断基準の文書化と画面録画を日常業務の一部にしておく。そうすれば、引き継ぎは「すでにある状態を共有する」だけの作業になります。
引き継ぎが成立したかどうかは、次の一点で判定してください。前任者が不在の状態で、後任が翌月のサイクルを二〜三度回せたか。資料の分量でも、引き継ぎ期間の長さでもありません。
部門別・業務設計の勘所
業務設計の原則はどの部門にも共通しますが、着手のポイントは部門によって異なります。
経理
月次決算・請求・支払など「締め」のある業務から着手します。期日という明確な基準があるため、設計の成否を測りやすい領域です。
判断基準として言語化すべき代表例は、勘定科目の使い分け（会議費と接待費など）、資産計上と費用処理の金額基準、計上時期の考え方の3つです。いずれも「その会社なりの決め方」が存在するのに、明文化されていないことがほとんどです。
よくある失敗は、会計ソフトを新しくすれば解決すると考えることです。ツールは手順を効率化しますが、判断基準を代わりに決めてはくれません。判断が言語化されていないまま入れ替えると、操作の属人化がデータの属人化に変わるだけです。
労務
給与計算・社会保険手続きなど、法改正の影響を受ける業務が中心です。判断基準そのものが更新される前提で設計する、という点が他部門と異なります。
具体的には、判断基準の文書に「いつ時点の制度に基づくか」を必ず併記し、改正情報を確認するタイミングを年次イベントとしてカレンダーに載せておきます。労働保険の年度更新、算定基礎届、年末調整といった山は毎年同じ時期に来るため、先回りで組み込めます。
よくある失敗は、イレギュラーを設計対象から外すことです。産休・育休、途中入退社、遡及計算といった例外は、頻度が低いために「その都度考える」運用になりがちですが、まさにそこが属人化の温床になります。
総務
契約・押印・請求書処理など、担当が点在しやすい業務が中心です。集約と設計をセットで行うのが有効な領域です。
ただし、集約だけを先に行うと「一人に集まっただけ」の状態になります。集約する前に、受付から承認までの責任範囲を定義しておくこと。誰が受け、誰が確認し、誰が最終判断するかを先に決めてから集約すると、窓口を一本化しても特定の人に判断が滞留しません。
よくある失敗は、依頼の入口が複数あるまま運用を始めることです。メール・チャット・口頭が混在していると、記録が残らず、設計した手順が実態と乖離していきます。入口を一つに絞ることは、それ自体が業務設計の一部です。
業務設計がもたらす3つの変化
業務設計は、単に「業務が楽になる」だけの取り組みではありません。会社の体質を変える3つの変化を生みます。
- 止まらない——担当者の休職・退職で業務が止まるリスクが構造的に下がる
- 育てやすい——判断基準が明文化されているため、新しい人が早く戦力になる
- 人に依存しない経営に近づく——採用できても、できなくても回る体制に近づく
2つ目は、採用の観点でも効いてきます。判断基準が言語化されていれば、経験者でなくても任せられる範囲が広がり、求人要件を下げられるからです。逆に属人化したままだと、「即戦力の経験者」しか候補にできず、採用の難易度と単価が上がり続けます。
3つ目は、そのまま第1章「採用に依存しない高収益経営（BackofficeEnablement）」につながります。業務設計は、その中核となる実践手法です。
まとめ——仕組みは、才能に依存しない
属人化は、優秀な個人がいるから起きるのではなく、業務が設計されていないから起きます。マニュアルを増やすことでも、人を増やすことでもなく、業務そのものを「誰がやっても同じ品質で回る」形に設計し直すこと——それが業務設計です。
そして業務設計は、一度やって終わる取り組みではありません。「課題発見 → ナレッジ型化 → 運用の安定化」を、対象を変えながら回し続けることで、会社は少しずつ人に依存しない状態へ近づいていきます。まずは1業務から始めてみてください。
BackofficeForceは、積み重ねてきた実務で培った業務設計の型で、貴社のバックオフィスが「人に依存しない」状態になるまで伴走します。
強い業務は、才能ではなく設計で回るのです。
よくある質問（FAQ）
Q1. 業務設計とは何ですか？
業務設計とは、特定の担当者に依存せず、誰が担当しても同じ品質で業務が回るように、手順・判断基準・責任範囲をあらかじめ組み立てておくことです。手順書との違いは「判断基準まで含める」点にあります。
Q2. マニュアル作成と業務設計はどう違いますか？
マニュアルは手順を記録したものですが、業務設計は「なぜそうするのか」「例外時にどう判断するか」まで含めて、業務そのものを組み立て直します。マニュアルがあっても属人化するのは、判断基準が設計されていないためです。
Q3. 業務設計はどこから始めればよいですか？
すべてを一度に見直す必要はありません。「担当者が抜けたら止まる」かつ「止まると事業に影響する」業務——請求・支払・月次決算・給与——から着手するのが定石です。最初の対象は1つか2つに絞ってください。
Q4. 属人化とは何ですか？
属人化とは、業務が特定の人に依存し、その人がいないと回らない状態を指します。原因・リスク・解消法は第2章「属人化とは」で詳しく解説しています。業務設計は、その属人化を解消する具体的な方法論です。
Q5. 中小企業でも業務設計はできますか？
できます。むしろ、担当者が少なく一人あたりの業務範囲が広い中小企業ほど、属人化のリスクが高く、業務設計の効果が大きく表れます。人を増やす前に、いまある業務を設計し直すことが、採用に依存しない経営への第一歩です。
Q6. 業務設計にはどのくらいの期間がかかりますか？
対象業務の数と例外の多さによりますが、1業務であれば、課題発見からナレッジ型化までが数週間、運用が安定するまでに1〜2サイクルというのが一つの目安です。全部門を一度に進めるより、1業務ずつ完了させるほうが結果的に速く進みます。
