「あの Excel マクロ、田中さんしか分からないんだよね」
一度は聞いたことがあるセリフだと思う。
田中さんが Excel VBA で作った経費精算マクロ。振込データの全銀フォーマット変換マクロ。売上集計マクロ。仕様書はない。コメントもほぼない。田中さんの頭の中にだけロジックがある。
田中さんが在籍している間は、何の問題もない。月末にマクロのボタンを押せば、いつも通り動く。
田中さんが異動した。退職した。引き継ぎは「このボタンを押してください」だけだった。
翌月、マクロがエラーを吐いた。画面に表示されたのは「実行時エラー ‘1004’」。誰も直せない。
なぜ Excel マクロは属人化するのか
理由はシンプルだ。VBA は「ちょっと便利にする」ために書かれることが多い。
最初は 10 行のマクロだった。コピー＆ペーストを自動化するだけの小さなコード。仕様書を書くほどの規模ではない。テストコードも書かない。動けば OK。
それが 3 年かけて 500 行に育つ。分岐が増え、例外処理が増え、他のマクロから呼ばれるようになる。もはや業務の基盤だ。でも、依然として仕様書はなく、テストコードもない。田中さんの頭の中にだけ全体像がある。
そして田中さんがいなくなったとき、500 行の VBA コードと向き合える人は社内にいない。
よくある対策と、その限界
ドキュメントを書く
「マクロの仕様書を書いてください」と言えば解決するように見える。でも、仕様書を書くのは田中さん自身だ。忙しい田中さんが、新機能を追加するたびに仕様書を更新するだろうか。大抵は初版を書いた時点で止まる。コードと仕様書が乖離し始めたら、仕様書はないのと同じだ。
引き継ぎを丁寧にやる
引き継ぎに 1 ヶ月かける。マクロの構造を説明して、修正方法を教える。新しい担当者に VBA の知識がなければ、そこから教育する。
引き継ぎが成功しても、新しい担当者がまた「自分だけ分かるコード」を足していく。属人化は人に紐づくのではなく、VBA という仕組み自体に紐づいている。
外注する
マクロの保守を外部に委託する。月額数万円から数十万円。壊れたときに直してくれる安心感はあるが、マクロの中身を理解しているのが自社ではなく外注先に移るだけだ。外注先を変えるときに、また同じ問題が起きる。
根本的な解法: マクロをなくす
属人化の原因はマクロだ。マクロをなくせばいい。
「でも、マクロがやっている仕事は必要なんだ」。その通り。必要なのはマクロではなく、マクロがやっている業務処理だ。
振込データの全銀フォーマット変換。受注データの請求書への転記。メールの添付ファイルからのデータ抽出。これらの処理を、VBA ではなく SaaS の機能として提供すれば、属人化は起きない。
SaaS なら仕様はサービス側が管理する。アップデートもサービス側がやる。担当者が辞めても、ログインするアカウントを引き継ぐだけだ。
Saturn の場合
Saturn は「Excel マクロがやっていたことを、テーブルの列としてやる SaaS」だ。
- 全銀フォーマット変換 → アクション列で 1 クリック
- メールからのデータ抽出 → Gmail ソース + AI エンリッチ列
- 受注データの転記 → COREC ソース + freee アクション列
VBA のコードは存在しない。だから属人化もしない。「ボタンを押す人」は誰でもいい。
マクロを引き継ぐのではなく、マクロが不要な環境に移る。それが属人化の根本的な解決だ。
Saturn — AI が動く Excel
14 日間無料トライアルあり。