決算マニュアルは、作った瞬間がいちばん価値が高く、そこから劣化していく。これは断言できる。手順書のほとんどは、3か月後には誰も開かないファイルになり、半年後には「最新版がどれか分からない」状態になり、1年後には「あの人しか正しいやり方を知らない」属人化に逆戻りする。手間をかけて作ったのに、だ。
ではなぜ死蔵されるのか。多くの記事は「更新しないから」と書く。だが本当の原因はもっと手前にある。そもそも更新できない構造で書かれているから、更新されないのだ。この記事では、使われる手順書と死蔵される手順書を分ける根本の差と、判断基準・例外処理・更新責任を最初から組み込んだ「生きる手順書」のフォーマットを、現場でどう動かすかまで踏み込んで書く。
死蔵される手順書の正体は「作業ログ」、生きる手順書は「判断ガイド」
死蔵されるマニュアルには共通の特徴がある。「何をやったか」しか書いていないことだ。
「経過勘定の振替仕訳を起票する」「前月比較表を作成し、増減を確認する」——こういう記述は、書いた本人には完璧に見える。だが、新しく入った担当者がこれを読んでも手は動かない。なぜ振り替えるのか、いくら以上の増減を「異常」と見るのか、確認した結果おかしかったらどうするのか、が一切書かれていないからだ。これは手順書ではなく、**作業の足跡（作業ログ）**でしかない。
ベテランは手順書を見ない。頭の中に判断基準が入っているからだ。新人は手順書を見ても動けない。判断基準が書かれていないからだ。つまり、作業ログ型の手順書は、必要としている人の役に立たず、必要としていない人だけが「正しい」と感じる。この非対称が、死蔵の出発点になる。
生きる手順書は逆だ。作業そのものより、その作業に埋め込まれた判断を言語化する。「経過勘定を振り替える」ではなく、「翌月以降に費用化される前払費用は、1件10万円以上を資産計上の対象とする（10万円未満は当月費用、重要性の判断による）。判断に迷う科目は◯◯（担当者名・役職）に確認」と書く。ここまで書いて初めて、手順書は人の代わりに考え始める。決算業務の標準化が「属人化の解消」だと言われる本質はここにある。手を標準化するのではなく、判断を標準化することが目的なのだ(TKC)。
例外処理を「欄外」ではなく「本体」に書く
手順書が現場で捨てられる、二番目にして最大の瞬間がある。書いてある通りにやろうとしたら、書いてない事態にぶつかったときだ。
決算は8割が定型作業で、残り2割が例外だ。そして実際に時間と神経をすり減らすのは、その2割のほうである。月次で発生しなかった臨時の引当、システム連携が落ちて手作業に切り替えた仕訳、子会社から数字が来ない中での見込み計上。手順書がこの2割に沈黙していると、担当者は「結局、手順書は使えない」と学習する。一度そう学習されたら、定型の8割すら開かれなくなる。手順書全体が信用を失うのだ。
だから例外処理は、付録や欄外に追いやってはいけない。各手順のすぐ隣に、本体として書く。実務で効くフォーマットはシンプルだ。一つの作業ステップを、必ず三つの要素で記述する。
特に三つ目の「誰に確認するか」を実名や役職で書ききることが、手順書を生かすか殺すかを分ける。例外にぶつかった担当者がいちばん欲しいのは正解そのものではなく、「ここから先は自分で抱えなくていい」という逃げ道だ。エスカレーション先が明記された手順書は、担当者を孤立させない。だから開かれ続ける。
「更新責任者」と「最終確認日」を一行目に刻む
ここからが、この記事のいちばんの肝だ。手順書が古くなって死ぬのは、更新を「みんなの仕事」にしているからである。みんなの仕事は、誰の仕事でもない。
制度は動く。インボイス制度、電子帳簿保存法、そして経理現場に直接効いてくるシステムの保守期限——SAP ERP（ECC 6.0）は標準保守が2027年末、追加料金を払っても延長保守は2030年末で終了する見込みで、多くの企業が後継のS/4HANAへ移行する(テックタッチ、SAP公式)。
システムが変われば、画面も連携も仕訳の起こし方も変わる。そのたびに手順書は陳腐化する。にもかかわらず、更新の責任者が決まっていなければ、誰も直さない。属人化の解消は一度作って終わりではなく、定期的な見直しが不可欠だと言われるのは、まさにこのためだ(Gluegent)。
生きる手順書は、本文の前——いちばん上の一行に、これを刻む。
- 更新責任者：直す義務を負う人（個人名／「みんな」は禁止）
- 最終確認日：現実と合っているか最後にチェックした日付
- 次回確認期限：いつ見直すか（決算サイクルに紐づける）
なぜ日付か。「いつ確認されたか」が分からない手順書は、正しくても信用されないからだ。最終確認日が半年前なら、読む側は「制度改正を反映していないかも」と疑い、結局ベテランに口頭で聞きに行く。手順書が一周回って無視される。逆に「先月確認済み」と書いてあれば、人はその通りに動く。日付は、内容の鮮度を担保する署名なのだ。
そして次回確認期限は、必ず決算スケジュールに埋め込む。
「毎年4月に見直す」ではなく、「本決算の引継ぎ会の議題に手順書レビューを含める」「四半期決算の締め後チェックリストに手順書の更新有無を1項目入れる」。更新を独立したタスクにすると後回しにされて死ぬ。既にある業務の中に更新の動作を寄生させるのが、続く仕組みの正体だ。
「使われ方」から逆算してフォーマットを決める
最後に、形式そのものの設計に触れたい。手順書が分厚いWord文書1本だと、使われない。決算の修羅場で、目次から該当ページを探している暇はないからだ。
実際に使われる手順書は、使う瞬間の動作から逆算した形をしている。締め作業中に「次は何をするんだっけ」を確認するためのものなら、それはマニュアルではなくチェックリストであるべきだ。一行一作業、チェックボックス付き、判断基準は各行の右に短く添える。一方、新人が一から学ぶための背景や「なぜ」を語るものは、別ファイルの解説書に分ける。この二つを一緒くたにすると、急いでいる人には冗長すぎ、学びたい人には説明不足という、誰も満足しない文書ができあがる。
実務で機能している形は、おおむねこの三層構造だ。
そして全体を、検索できる場所に一つだけ置く。「最新版がどれか分からない」が起きるのは、同じ手順書のコピーが個人フォルダに散らばるからだ。共有ドライブに正本を一つ、編集は更新責任者だけ、という運用ルールを敷く。スプレッドシートが属人化しやすいのと同じで、ファイルの置き場と編集権限を絞ることが、地味だが効く(TOKIUM)。
生きる手順書とは、結局のところ、書いた人がいなくなっても判断が再現できる文書のことだ。手順を写すのは誰でもできる。難しいのは、ベテランの頭の中にある「ここはこう見て、こう分ける」という暗黙の判断を、言葉にして、日付と責任者をつけて、業務の流れに埋め込むことだ。そこまでやって初めて、手順書は引き出しの中で死なず、現場で生き続ける。決算マニュアルを作ったのに誰も見ない、と感じているなら、見直すべきは中身の正確さより、判断・例外・更新責任が組み込まれているかである。
- 作業ログでなく判断ガイドを書く：「何をやったか」でなく「何を見てどう分けるか」を言語化する。
- 例外処理は本体に書く：各ステップを〈通常手順／判断分岐／例外時の動き〉の3要素で。誰に確認するかは実名・役職で。
- 更新責任を一行目に刻む：更新責任者・最終確認日・次回確認期限。日付は鮮度を担保する署名。
- 更新は既存業務に寄生させる：引継ぎ会や締め後チェックリストに組み込み、独立タスクにしない。
- 用途で三層に割り、正本はひとつ：チェックリスト／判断ガイド／解説書を分け、検索できる場所に正本だけを置く。
