中小企業のデジタル化は、紙や口頭が中心の段階から、Excelなどのツールを使う段階、データを効率化して活用する段階、そして事業のかたちを変える段階へと進むと整理されます。多くの会社は「Excelで一通り回る」段階に長くとどまり、その効率化のために、いつしかマクロやVBAで処理を自動化していきます。転記や集計を自動化するマクロは、たしかに現場を楽にしてくれます。
問題は、その便利さがある日、限界に変わることです。しかもその限界は、処理が重いとか件数が多いといった性能の話として来るとは限りません。もっと多いのは「これを作った人が異動・退職して、中身が誰にも分からなくなった」という形で訪れます。この記事では、マクロVBAの限界がどこにあるのかを整理したうえで、作った人がいなくなっても事業が止まらないための、現実的な進め方まで示します。
VBAの限界は「機能」ではなく「作った人しか直せない」ことにある
結論から言えば、マクロVBAの限界の多くは、機能の限界ではありません。保守の限界です。処理速度や件数の上限に達して困る会社もありますが、より多くの現場でつまずくのは、「動いているのに、中身を誰も説明できない」という状態のほうです。
マクロは、書いた本人にとっては便利な近道になります。しかしその近道は、本人の頭の中にある前提とセットで成り立っています。どのセルに何が入る想定か、どのファイルと連携しているか、なぜこの順で処理しているか。それらがコードの外に書き出されていないまま、担当者の記憶だけで運用が続きます。エラーが出ても直せるのは本人だけ、仕様を変えたくても触れるのは本人だけ、という状態が固定化していきます。作った人がいなくなる問題とは、担当者が一人抜けるという人事の話ではありません。その一人と一緒に、業務の仕様そのものが会社から消える、という設計の話なのです。
マクロVBAが属人化する3つの理由
なぜ、マクロは決まって属人化するのでしょうか。理由は担当者の怠慢ではなく、Excelとマクロの性質そのものにあります。代表的な3つを挙げます。
手軽さと専門性のあいだにギャップがある
Excelは誰でも触れます。しかしVBAでマクロを組むには、一定のプログラミングの知識が要ります。使う人の裾野は広いのに、中身を書き直せる人はごく一部、という構造的なギャップがあります。だから一度組まれたマクロは、書いた本人に依存しやすいです。
担当者に合わせて個別最適化されていく
現場のマクロは、その担当者のやり方に合わせて少しずつ育ちます。本人しか使わない前提で、近道や例外処理が積み重なっていきます。結果として、他人が見ると筋を追えない、その人専用の道具になります。便利になるほど、他人には引き継ぎにくくなります。
仕様を説明するドキュメントがない
多くのマクロには、仕様書もコメントもありません。何を、なぜ、どう処理しているかがコードの外に残っていないから、中身を知るには本人に聞くしかありません。この「聞くしかない」状態こそが、属人化の正体です。
本当のリスクは「壊れて止まる」ことではなく「動いているのに直せない」こと
属人化のリスクというと、多くの記事は「担当者が辞めたら業務が止まる」と説明します。それは正しいです。ですが本当に厄介なのは、止まる前の段階にあります。VBAの本当のリスクは壊れて止まることではありません。動いているのに誰も直せないことです。
動いているからかえって手を出せない
現場でいちばん多いのは、マクロが今日も問題なく動いている、という状態です。動いているから、わざわざ中身を確認する動機がありません。誰も読まず、誰も直さず、そのまま何年も回り続けます。そして「動いているものには触るな」という空気が、属人化を温存する最大の温床になります。手を出せないまま、いざ変更が必要になったときには、もう中身を知る人が社内にいません。
中身がブラックボックスで間違いに気づけない
読めないコードは、正しく動いているかどうかも検証できません。内部で計算の誤りやデータの取りこぼしが起きても、誰も気づかないまま結果だけが出てきます。その数字が請求や在庫や経営判断に使われていれば、間違いは静かに下流へ流れていきます。止まってくれるエラーより、止まらない誤りのほうが怖いです。
退職と同時に仕様が会社から消える
そして担当者の異動や退職が重なると、Excelファイルと本人の頭の中で成り立っていた一つの仕組みが、片方を失って一気に事業リスクへ変わります。パスワードでロックされていれば、中を開くことすらできません。残されるのは、動くけれど誰も触れない、変更もできない資産です。これは我慢やコストの問題ではなく、いつ止まるか分からない時限的なリスクとして積み上がっていきます。
作り直す前に「仕様の可視化」から始める
では、どう手をつけるか。ここで多くの人が「新しいシステムに作り替えよう」と考えますが、いきなり移行に走るのは順序が逆です。中身が分からないものは、正しく作り直すこともできません。最初にやるべきは、移行ではなく、仕様の可視化です。
まずは棚卸しをします。どのマクロが、どのファイルに、いくつ存在し、どの業務を担っているのかを一覧にします。動いていて見えていないものほど、まず数え上げます。次に、その中身を解読して文書化します。何を入力に、どんな処理をして、何を出しているのか。かつては専門家が読み解くしかなかったこの作業も、近年は生成AIを使って解読の下書きを作れるようになってきました。そして書き起こした仕様書は、移行の前提になるだけでなく、それ自体が会社の資産として残ります。担当者の頭の中にしかなかった前提が、はじめて社内で共有できる形になります。
この「可視化してから動く」という一手は、地味に見えて効きます。作り直すにせよ、Excelのまま整えるにせよ、仕様が見えていれば、手戻りなく次の判断に進めます。急いで作り替えて後から要件のズレに気づく、という一番高くつく失敗を避けられます。
全部を作り直さない 優先順位と移行先の選び方
可視化ができたら、すべてを一度に作り替えようとしないことが肝心です。マクロには、毎日回る重要なものもあれば、年に一度しか使わないものもあります。全部を平等に移行しようとすると、費用も手間も膨らみ、かえって頓挫します。
優先順位は、3つの軸で見るとつけやすいです。ひとつは使用頻度、どれだけ頻繁に回っているか。ふたつめは壊れたときの影響、止まると事業に直結するか。みっつめは改修のしにくさ、中身がどれだけブラックボックスか。この3つが重なるマクロほど、先に手を打つ価値が高いです。
移行先も一つではありません。業務を新しいWebツールや社内アプリに作り替える道、画面を持たないスクリプトとして自動処理に置き換える道、そしてあえてExcelは残し、中のコードだけを健全化して延命する「活Excel」の道があります。全廃か存続かの二択ではなく、マクロごとに向く手段を選び分けます。この選び分けこそが、現実的な脱却の中身になります。
よくある質問（FAQ）
動いているマクロは無理に作り替えなくてもいいですか
はい。動いていること自体は問題ではありません。ただし中身が誰にも分からない状態は別で、まず仕様を文書化して「読める」状態にしておきます。作り替えるかどうかは、その後に頻度と影響で判断すればよいでしょう。
作った人が退職していて中身が分かりません
まずは現物のマクロを棚卸しし、解読・文書化から始めます。パスワードで保護されている場合も含め、外部の専門家や生成AIの支援で仕様を書き起こせることが多いです。可視化ができてから、延命か作り替えかを選びます。
VBAはもう古いのですべてやめるべきですか
一概には言えません。頻度が低く影響も小さいマクロは、コードを健全化して残すほうが合理的なこともあります。全廃を前提にせず、業務ごとに残す・作り替えるを線引きするのが現実的です。
属人化したマクロは作り直さず外付けに逃がせる
マクロVBAの限界への向き合い方は会社ごとに違い、向く手段も作り替え・スクリプト化・Excelを残す活Excelと分かれます。マクロによっては、Excelファイルは残したまま、属人化した処理だけを外付けに逃がして健全化すれば足ります。何を残し何を外付けにするかはExcelを活かして補う進め方で全体像を確認できます。
自社のマクロがどの手段に近いか、次にどのマクロから可視化に着手すべきかは、3分の無料業務診断で見当がつきます。
