「自分でやった方が早い」。この一言を口にするたび、あなたのチームは少しずつ動かなくなっている。経理マネージャーがプレイングマネージャーから抜けられないのは、本人の意志が弱いからではない。決算という業務が、属人化（その人がいないと回らない状態）を生みやすい構造を持っているからだ。本稿では、その構造を解きほぐし、締め業務を「言語化→標準化→委譲」の順で剥がしていく具体的な移行設計を示す。
なぜ経理の管理職は手を動かし続けてしまうのか
問題の正体は、能力でも気合でもない。役割設計の曖昧さ、個人成果に寄った評価、権限委譲の仕組みの不在という組織構造にある（アルー）。経理マネージャーの場合、ここに業務固有の事情が三つ重なる。
ひとつ、決算は会計基準の理解を前提とするため専門性が高く、担当者の頭の中でブラックボックス化しやすい（ベルシステム24）。仕訳一本の判断根拠が、本人にとっては当たり前すぎて言葉になっていない。
ふたつ、締めには期日がある。月次5営業日、四半期、本決算。「育てている時間で締まらなくなる」恐怖が、毎月確実にやってくる。プレイングマネージャーが抱える「現場の数字を作る」と「部下を育てる」の矛盾（bayiii）が、経理では期日というかたちで毎月牙を剥く。
みっつ、間違えれば監査で指摘され、開示が遅れ、最悪は決算訂正になる。「任せて失敗されたら結局自分が尻拭い」という不安（bayiii）が、他のどの職種よりも具体的でリアルだ。
だから手放せない。そして手放さないから、知識は本人の頭に溜まり続け、ますます手放せなくなる。この自己強化ループこそが構造の本体だ。意志で断ち切ろうとしても無理がある。仕組みで剥がすしかない。
順番を間違えると委譲は必ず失敗する
多くの管理職が、いきなり委譲から始めて失敗する。「来月からこの工程やっといて」と渡す。部下は手順書もない状態で手探りし、判断に詰まり、結局マネージャーに聞きに来る。聞かれるたびに「自分でやった方が早い」が証明され、また巻き取る。委譲したつもりが、確認作業という名の二度手間が増えただけだ。
正しい順番は、言語化→標準化→委譲。この三段を飛ばしてはいけない。
言語化は、頭の中にある暗黙知を文章にする工程だ。経理の属人化解消では、担当者しか知らない知識を文書化することが業務代行の前提になる（パーソルビジネスプロセスデザイン）。ここで肝心なのは、手順だけでなく「なぜそうするのか」「どこで間違えやすいか」「判断が分かれるのはどの仕訳か」を書くこと。手順書は誰でも書けるが、判断の根拠を言葉にできるのはあなたしかいない。ここがマネージャー本人にしかできない最初の仕事だ。
標準化は、言語化したものを「誰がやっても同じ結果になる」形に整える工程。チェックリスト、入力フォーマット、判断フローチャートに落とす。定型的な転記や集計はRPAやシステムに寄せられる部分を切り分ける（ベルシステム24）。標準化されて初めて、委譲は「丸投げ」ではなく「引き渡し」になる。
委譲は最後だ。標準化されたものを渡し、最初の数回は伴走し、徐々に手を離す。ここまで積み上げて初めて、聞かれる回数が減っていく。
締め業務の何から手放すか――難易度×影響度で並べる
すべてを一度に手放そうとすると挫折する。締め業務を「習得の難易度」と「ミスったときの影響度」の二軸で四象限に分け、優先順位をつける。
第一に手放すべきは、難易度が低く、影響度も低い工程。 経費精算の入力、定型仕訳の起票、補助科目の消し込み、月次の数値集計といったルーティン。判断要素が薄く、間違えても発見・修正が容易だ。ここはマニュアル一枚と数回の伴走で渡しきれる。最初の成功体験を作る場所であり、ここを渡せると「任せても回る」という事実があなた自身の不安を溶かしていく。委譲は部下のためであると同時に、マネージャー自身の恐怖を上書きする訓練でもある。
第二は、難易度は高いが影響度が低い工程。 複雑だが、間違えても致命傷にならないもの。たとえば一部の経過勘定の見積りや、影響範囲の限られた調整仕訳。ここは判断の根拠を丁寧に言語化し、最初の数期はあなたがレビューに入る前提で渡す。育成の本丸であり、ここを渡せると部下が一段上がる。
第三は、難易度が低いが影響度が高い工程。 手順自体は単純でも、間違えると開示に響くもの。たとえば主要勘定の残高確定や、外部報告に直結する数値の確定。ここはダブルチェックの仕組みを標準化に組み込んでから渡す。人ではなく仕組みで品質を担保する設計に切り替える。
最後まで手元に残すのは、難易度も影響度も高い工程。 重要な会計上の見積り、減損や税効果の判断、監査法人との論点折衝。ここは管理職が判断者として関与し続けるべき領域であり、無理に手放す必要はない。むしろ、ここに自分の時間を集中させるために、下の三象限を剥がしていくのだ。
移行は一度きりのイベントではなく毎月の運用
言語化・標準化した手順書は、作って終わりではない。会計基準の改正、システム更新、取引の変化で、手順はすぐ古びる。属人化を本当に解くなら、手順書を毎月の締めのなかで更新し続ける運用に組み込む必要がある。締め後の振り返りで「今月詰まった工程」「手順書と実態がズレた箇所」を一つずつ直す。これを習慣にできれば、知識は個人ではなくチームに蓄積されていく。
- 今月詰まった工程を書き出す
- 手順書と実態がズレた箇所を特定する
- ズレを一つずつ手順書に反映する
- 知識を個人ではなくチームに蓄積する
急ぐ理由もある。中堅社員の退職は企業にとって最も痛手の大きい人材流出で、退職企業の8割超で勤続5年以上の中堅が抜けており、不足の本質は「人数」ではなく「経験・スキルの質」に移っている（帝国データバンク）。経理の中核知識があなた一人の頭にある状態は、組織にとって単なる非効率ではなく、明確な事業リスクだ。あなたが倒れたら締まらない会社を、放置してはいけない。
さらに、SAP ERP 6.0（ECC6.0）のメインストリーム保守が2027年末に終了する、いわゆる「2027年問題」が控える（OBC、NECソリューションイノベータ）。延長保守を契約しても最長2030年末までが目安だ。基幹システムの移行は、決算プロセスを根本から見直す数年に一度の好機でもある。属人化したまま新システムへ乗せ替えれば、ブラックボックスがそのまま温存される。逆に、言語化・標準化を済ませてから移行に臨めば、システム更新そのものが委譲を加速させる。
手を動かし続ける限り、あなたは上流に行けない。「自分でやった方が早い」を一度だけ我慢して、言語化に時間を投じる。その一回の投資が、毎月繰り返していた巻き取りを終わらせる。移行設計とは、結局のところ「いま少し遅くなる」を引き受けて「来年も再来年も速い」を手に入れる取引だ。経理マネージャーが本当に守るべきは、今月の締めではなく、あなたがいなくても締まる組織である。
