1 職務分掌の概念
1.1 定義と目的
1.1.1 説明（責任範囲の明確化）
職務分掌とは、組織内の業務を機能や役割単位に整理し、各担当者・各部門が担う責任範囲を定める考え方および実務上の仕組みである。責任範囲には、何を達成すべきかというアウトカム（結果責任）、どこまでを実施対象とするかという実務の範囲（作業責任）、判断・決裁・実行に必要な権限の範囲（意思決定権限）、ならびに期待される品質や期限といった成果の基準が含まれる。これにより、担当が不明な事項や、複数部門が同じ作業を重ねる状況を減らし、業務の追跡可能性を高める。
1.1.2 期待効果（重複・抜け漏れの低減）
職務分掌の導入は、業務の重複や抜け漏れを抑え、運営の安定性を高めることを狙いとする。たとえば、受け渡しに関わる決裁や確認工程が誰の責任か曖昧な場合、手戻りや遅延が生じやすい。分掌を明示すると、判断点が見えるため、実行側が迷いにくくなる。さらに、責任範囲が文章化されているほど、部門間の調整コストや説明コストが下がり、管理層による統制も実効性を持ちやすい。
1.2 関連する概念との違い
1.2.1 役割分担との関係
役割分担は、誰がどの仕事を担当するかを概説することが多いのに対し、職務分掌はそれを「責任・権限・成果基準」まで含めて体系化し、境界を管理する点に特徴がある。役割分担が割当のイメージに留まる場合、職務分掌では、承認の要否、実行権限の有無、評価指標の設定など、運用上の論点が明確に扱われる。
1.2.2 権限委譲との関係
権限委譲は、上位者から下位者へ意思決定の権限を移す行為や方針である。職務分掌は委譲そのものを目的とするだけでなく、権限の所在を責任範囲として配置し、実行と結果の整合を取る仕組みとして機能する。したがって、職務分掌を設計する際には、委譲の可否だけでなく、承認段階や越権防止の観点も同時に整理する必要がある。
1.2.3 業務フローとの関係
業務フローは工程の順序、入出力、判断点の位置を示すことが中心である。職務分掌は、その工程における担当者・部門の責任範囲を対応づける点で補完的である。フローが存在しても、分掌が定義されていなければ、同じ工程でも「誰が最終責任を持つか」が曖昧になりうる。逆に、分掌だけでも実務の連結が見えなければ、該当工程の接続不良が起こり得る。
1.3 対象範囲の考え方
1.3.1 部門別
部門別の分掌では、機能単位（例：営業、調達、製造、品質保証、情報システムなど）に責任を割り当てる。部門が管理する資源や専門領域に合わせやすい一方で、顧客対応のように複数部門が同じ案件に関与する領域では、境界設定の精度が重要となる。部門を単位にする場合でも、部門横断の責任点（例：最終承認、対外回答の窓口）を別途明確化する設計が求められる。
1.3.2 職位別
職位別の分掌では、役職や職階に基づいて責任と権限を整理する。意思決定の階層が明確になりやすく、決裁の段取りを標準化しやすい。反面、職位が同じでも部門や担当領域が異なる場合、業務実態との乖離が生まれる可能性がある。よって、職位別の定義を行う場合は、職位が扱う範囲の条件（業務種別、金額やリスクの閾値など）を併せて定めると運用しやすい。
1.3.3 プロセス別
プロセス別の分掌は、調達から受領、検収から支払い、問い合わせ対応から解決までのような業務連鎖を単位として設計する。工程のつながりを前提にするため、部門間の調整点が見えやすい利点がある。ただし、プロセスに登場する部門が複数ある場合、各工程の最終責任とサポート責任を階層的に整理しないと、会計・品質・法務などの観点が重なって混乱しやすい。したがって、プロセス単位で進める場合には、責任の最終地点を強く意識して設計することが望ましい。
2 設計の進め方
2.1 分析と整理
2.1.1 現状業務の棚卸し
2.1.1.1 業務の流れ・入出力の把握
設計は、現状の業務を工程単位で分解し、流れを可視化することから始まる。入力となる情報や資源（申請書、発注情報、顧客要求、システムデータなど）と、出力となる成果物（承認済み書類、検査結果、回答内容、更新データなど）を特定する。あわせて、判断点（承認、却下、条件付許可、例外処理の分岐）と、成果の確認者を把握することで、後の分掌設定の土台ができる。
2.1.2 課題（重複・停滞・不明確点）の特定
棚卸しの結果から、重複（複数部署が同じ確認を行う、同一データを別経路で更新するなど）、停滞（待ち状態が長引く、承認待ちが解消されないなど）、不明確点（最終責任者が定まらない、判断基準が共有されないなど）を抽出する。課題は「なぜそうなっているか」まで因果に近づけると設計に直結する。たとえば、承認が遅い原因が権限の所在ではなく、必要情報の標準化不足にある場合もあるため、観察だけで終えず整理することが重要となる。
2.2 担当範囲の定義
2.2.1 責任（アウトカム）と実務（インプット）
担当範囲を定義する際は、結果に結びつくアウトカムと、実施に要するインプットを分けて考える。アウトカムは、案件が達した状態（品質要件の充足、期限内の提出、問い合わせの解決など）として記述する。インプットは、作業に投入されるデータや資料、前提条件である。両者が対応づく形で記述されると、担当者が「何を受け取って何を出すべきか」を理解しやすくなる。
2.2.2 権限（承認・決裁・実行）
職務分掌における権限は、承認・決裁・実行の各段階で整理する。承認は確認の性格を持つ場合があり、決裁は方針や最終可否に関わる場合が多い。実行は、実務作業や外部手続きの遂行を指すことが一般的である。分掌表に権限の種類を併記すると、同じ担当でも判断点の深さが揃い、越権や放任の両方を抑制しやすい。
2.2.3 成果基準（KPI・品質・期限）
成果基準は、測定可能な指標（KPI）、品質基準、期限の三点から設けると設計が安定する。KPIは量や効率に寄りやすく、品質は正確性や不具合率などの観点で示される。期限は、いつまでに完了すべきかの時間軸を与える。基準がない場合、作業の質が主観に寄りやすく、評価の納得性が低下しやすい。逆に、基準が過剰に詳細だと運用負荷も高まるため、実務の現場が参照しやすい粒度で設計する。
2.3 RACI等の活用
2.3.1 役割整理のフレーム
RACIは、各業務に対して「Responsible（実行責任）」「Accountable（最終責任）」「Consulted（相談）」「Informed（周知）」を対応づけることで役割を整理する。職務分掌の設計段階では、分掌表を作成する前に、重要工程の責任点をRACIで仮置きする方法が用いられることがある。こうしたフレームを用いると、最終責任が複数に分散していないか、相談者が過剰になって意思決定が遅れていないかを点検しやすい。
2.3.2 誤用しないための注意
フレームの誤用として、RやAが曖昧なまま複数付与される、相談や周知の指定が形式化して実際の連絡が整理されない、といった問題が起こりうる。特に「最終責任」を一つに固定できない案件では、判断基準（どの条件なら誰がAになるか）を別途定義しておく必要がある。また、現場が参照しない図表になると形骸化するため、分掌表や手順書へ反映し、運用で使える記載に落とし込むことが重要である。
2.4 文書化の設計
2.4.1 職務分掌表
職務分掌表は、部門または職位と業務領域を軸にして、担当・責任・権限・成果基準の概要を整理する文書である。読者が業務の境界を理解できるように、担当範囲の始点と終点、引き継ぎ条件、例外の扱いの所在を簡潔に記載する。表形式に加えて、注記欄で補足を整理すると、誤読や解釈のばらつきを抑えられる。
2.4.2 職務記述書
職務記述書は、個々の職務について、役割、求められる能力・経験、主要業務、評価に関する情報を整理する文書である。職務分掌表が「組織の割当」を示すのに対し、職務記述書は「その職に就く人が何を期待されているか」を具体化する。分掌と記述書を連動させることで、採用、配置、育成、評価の観点が同じ責任構造を共有しやすくなる。
2.4.3 権限規程・手順書との整合
職務分掌の設計では、権限規程や手順書と矛盾がないかを確認する必要がある。分掌表で「承認不要」としている工程が、手順書では「必ず決裁者のサインが必要」となっている場合、現場はどちらを優先すべきか判断できず、実務が停止する。したがって、文書間の整合をチェックする作業を設計プロセスに組み込み、改訂時にも参照関係を追跡できるようにすることが望ましい。
3 運用とガバナンス
3.1 周知と教育
3.1.1 初期導入の手順
初期導入では、分掌の内容を配布するだけでなく、業務への当てはめを理解させる段取りが必要になる。まず管理層に対して、責任点と権限の位置づけ、運用上の判断原則を共有する。次に現場に対して、担当工程の具体例、引き継ぎの条件、例外時の連絡先を中心に説明する。最後に、問い合わせが発生しやすい箇所を事前に洗い出し、質疑応答を準備することで定着までの摩擦を低減できる。
3.1.2 配属・異動時の引き継ぎ
配属や異動では、分掌そのものの最新版を確認させたうえで、当該人員が担当する範囲を短時間で把握できるようにする。引き継ぎでは、単なる作業手順だけでなく、判断の根拠となる規程や、過去の例外対応の傾向、関連する連絡ルートを共有すると効果が高い。さらに、担当の境界にある案件（境界工程）を優先的に扱い、抜け漏れが起こりやすい局面を可視化する。
3.2 例外対応とエスカレーション
3.2.1 例外ルールの設計
業務は例外が発生する前提で設計する必要がある。例外ルールの設計では、「通常時は誰が何を判断するか」をまず確認し、その後に「通常から外れたときに誰へ連絡し、どの観点で決めるか」を規定する。例外を無制限に拡大すると管理コストが上がるため、発生頻度や影響度に応じた閾値（リスク、金額、品質逸脱の程度など）で分類する運用が現実的である。
3.2.2 エスカレーション経路
エスカレーション経路は、連絡の順序、連絡に必要な情報、判断を受ける側の責任範囲を明確にする。経路が曖昧だと、担当者が誰に相談すべきか迷い、判断が遅れる。経路設計では、緊急度に応じた優先順位も含めて定めると、突発案件での対応力が上がる。加えて、相談から決定までの時間目標を置くと、意思決定の停滞を抑えやすい。
3.3 改訂プロセス
3.3.1 改訂トリガー（組織変更・業務変更）
改訂は「いつ、何をきっかけに」行うかが重要である。トリガーとして、組織改編、業務プロセスの変更、システム導入・変更、規制対応の変更、重大インシデントや監査指摘などが想定される。トリガーの種類ごとに、必要な確認範囲（関係部門、影響調査の粒度、反映期限）を定めておくと、改訂の遅れや手戻りを減らせる。
3.3.2 改訂の承認と反映
改訂は、責任者の承認プロセスを伴う。承認では、責任範囲の変更が評価制度や手順書、権限規程に波及する点を確認する。反映では、周知媒体の更新、教育資料の改訂、運用開始日、旧版の参照可否を整理し、現場が混乱しないようにする。特に移行期間の扱い（いつまで旧手順で処理できるか）を明確にすることで、過渡期の運用事故を抑えられる。
3.4 監査・点検
3.4.1 定期レビュー
定期レビューでは、分掌が実際の運用と整合しているかを確認する。視点としては、実務で発生した照会や手戻りの傾向、停滞が起きる境界工程、例外の増減、処理時間の変化などがある。文書として整っていても、実態とズレることは起こりうるため、記録や実績データに基づく点検が望ましい。
3.4.2 逸脱の是正（再発防止）
逸脱が見つかった場合は、単に注意喚起するのではなく、是正と再発防止をセットで行う。是正では、影響を受けた案件の処理を整理し、判断の整合性を確保する。再発防止では、分掌の不明確さ、権限が届いていない構造、手順が現場の実態に合っていない点など、原因を分解して文書・教育・運用設計へ反映する。これにより、同様の逸脱が繰り返されるリスクを下げられる。
4 評価・改善への接続
4.1 個人評価・組織評価との整合
4.1.1 成果指標の反映
分掌が定める成果基準は、評価制度の設計にも接続させると有効である。個人評価では担当領域に関するKPIや品質、期限の達成度を反映し、組織評価では部門横断の成果指標（処理完了率、再発率、顧客満足の一部など）を用いることがある。指標は分掌と同じ時間軸・定義で運用しないと、現場が「評価のための数字」と捉えて行動が歪むため、定義の統一が重要となる。
4.1.2 責任範囲と評価の一致
評価が責任範囲と一致していないと、成果が出ても評価されず、逆に評価されるために無理な手配が生じる。たとえば、入力情報の品質が別部門に依存する工程で、アウトカムだけを個人に割り当てると不公平感が強まる。したがって、評価対象と責任範囲の一致を点検し、必要に応じて協働責任や影響度の扱いを調整することが望ましい。
4.2 業務改善サイクル
4.2.1 ボトルネックの特定
業務改善では、滞留が起きる箇所や判断待ちが増える工程をボトルネックとして特定する。分掌の観点では、権限がないために止まっているのか、相談が多すぎて判断が遅いのか、責任点が複数に分散しているのかを見立てる。工程データと分掌表を突き合わせることで、問題が手順の改善か、責任配置の見直しかを切り分けやすくなる。
4.2.2 権限と手順の見直し
ボトルネックが責任や権限の配置に由来する場合、分掌の調整と手順の改訂を行う。たとえば、一定条件下では現場側の承認範囲を広げ、例外時のみ上位決裁にするなどの整理が考えられる。見直しでは、権限拡大の妥当性と、逸脱時の抑止策（記録、監査ログ、事後レビュー）を同時に設計することが重要である。
4.3 よくある失敗と対策
4.3.1 役割が曖昧なまま放置される
役割が曖昧なまま運用が続くと、判断のたびに確認が増え、結果として遅延が慢性化する。対策として、境界工程を重点的に洗い出し、最終責任の所在と判断基準を文書化する。さらに、現場からの照会ログを集計し、誤解が繰り返される箇所を改訂優先度として扱うと改善が進む。
4.3.2 形式化して形骸化する
分掌が紙の上では整っていても、現場が参照しない状況は形骸化と呼べる。対策として、分掌表を手順書や運用ツールに直接リンクさせ、実務の場で確認できる導線を作る。また、例外処理やエスカレーションの運用が回っているかを観察し、運用実態に合わせた簡略版（要点表）を併設することが有効である。
4.3.3 部門間の境界で詰まる
境界では、情報の受け渡し条件が曖昧だったり、再確認の要否が揃っていなかったりして詰まりが発生する。対策として、引き継ぎの必要情報を標準化し、「次工程が使える状態」を成果物として定義する。加えて、境界工程の最終責任点を明確にして、遅延時の意思決定者をあらかじめ定めると、停滞を短縮できる。
4.4 事例から学ぶ実践知
4.4.1 受発注・品質・問い合わせの切り分け
実務では、受発注の段取り、品質確認、問い合わせ対応が混ざりやすい。分掌の設計では、受発注は「契約・注文の成立」に関わる責任、品質は「仕様適合の判断と是正」に関わる責任、問い合わせは「事実確認と回答方針」に関わる責任として分離するのが一つの整理方法である。これにより、品質不具合が見つかった場合に、誰が是正を主導し、誰が顧客への説明を担うかが定まり、混線を減らせる。
4.4.2 緊急対応（突発案件）の分掌設計
突発案件では、通常手順をそのまま適用すると時間を失いやすい。緊急対応の分掌設計では、緊急度の判定者、暫定判断の権限上限、関係部署への通知の順序をあらかじめ定める。事後にはレビューと記録を行い、どの判断が例外として扱われたかを追跡可能にしておく。こうした設計により、迅速性と統制の両立が図られる。