Excelマクロの属人化を解消する：VBA業務のシステム移行の進め方

作った人しか直せないExcelマクロを安全にシステムへ移すには、いきなり作り直すのではなく、まず「マクロが何をしているか」を業務の言葉で書き出すことから始めます。マクロのコードを一行ずつ読み解くことよりも、どのデータを受け取り、どんなルールで処理し、何を出力しているかを、入力と出力の具体例とともに整理することが大切です。この整理ができれば、移行先がシステム開発でも、既製のサービスでも、業務自動化のツールでも、安全に移せます。

属人化したマクロを放置すると、作った人の退職や異動、Excelや業務の変化をきっかけに、ある日突然業務が止まります。ただし、すべてのマクロをシステムに移す必要はありません。止まったときの影響が大きいもの、変更が頻繁に必要なもの、複数人で使うものから優先して手を付け、個人の作業を楽にするだけの小さなマクロは、手順を残したうえで当面そのまま使い続けるという判断もあります。

この記事は、業務の重要な部分がExcelマクロ（VBA）に依存していて、作った人以外が直せない状態に不安を感じている経営者、管理部門の責任者、情報システムの担当者に向けて、マクロの属人化のリスク、処理内容の洗い出し方、移行先の選び方、安全な移行の手順を具体的に解説します。

Excelマクロが属人化する理由

Excelマクロは、業務を効率化するために現場の誰かが作り始めることがほとんどです。最初は数行の便利な処理だったものが、要望に応えて機能を足し、例外に対応し、他のファイルとの連携を加えていくうちに、作った本人しか全体を把握できない大きな仕組みになっていきます。

属人化が進む理由は、作った人の能力や姿勢ではなく、仕組みにあります。

• 作る過程が記録に残らない：マクロは業務の合間に少しずつ作られることが多く、なぜその処理を加えたのかが記録されない。
• 業務のルールがコードの中にある：「この取引先だけ端数を切り上げる」といった業務のルールが、手順書ではなくコードの中にしか書かれていない。
• 確認する仕組みがない：作った人以外がコードを確認する機会がなく、他の人が理解できる形に整えられない。
• 便利だから頼られる：マクロがうまく動いているほど、周囲は中身を知らなくても困らず、作った人への依存が深まる。

マクロのもとになっているVBAの基本はVBA（Excelマクロ）、業務が特定の人に依存する状態の一般的な問題は属人化の用語ページでも解説しています。

属人化したマクロを放置するリスク

属人化したマクロは、うまく動いている間は問題が見えません。しかし、次のような出来事をきっかけに、突然業務が止まります。

• 作った人の退職・異動・長期休暇：マクロが動かなくなったとき、原因を調べて直せる人がいない。
• Excelや環境の更新：Excelの更新、パソコンの入れ替え、ファイルの保存場所の変更で、マクロが動かなくなる。
• 業務の変更：取引先の追加、税率や料金体系の変更、帳票の書式変更などに、マクロを合わせられない。
• 誤った結果に気づけない：マクロが一見正常に動いていても、条件によっては誤った計算をしていることに誰も気づかない。
• セキュリティの問題：マクロを含むファイルの扱いは、セキュリティの方針によって制限されることがあり、使えなくなる可能性がある。

特に注意したいのは、4つ目の「誤った結果に気づけない」ことです。請求額や給与、発注量の計算をマクロに任せている場合、誤りが長期間見過ごされると、影響は大きくなります。

こうしたリスクは、作った人が社内にいる間に手を打つほど小さく抑えられます。本人が在籍していれば、コードの意図や例外処理の理由をその場で確認でき、洗い出しにかかる時間も短くなるからです。異動や退職が決まってから慌てて引き継ぐのではなく、属人化に気づいた時点で、処理内容の記録だけでも始めておくことをおすすめします。記録が残っていれば、移行を急がない場合でも、いざというときの復旧の手がかりになります。

マクロの棚卸しと優先順位づけ

社内にあるマクロをすべて一度に移そうとすると、手が回りません。まず、どんなマクロがあるかを棚卸しし、優先順位をつけます。

棚卸しで確認すること

• ファイル名と保存場所
• 作った人と、今メンテナンスしている人
• 使っている人と、使う頻度（毎日、毎月、年に一度など）
• 何の業務に使っているか
• 止まったときに、手作業で代わりができるか、どのくらい時間がかかるか
• 他のファイルやシステムとデータをやり取りしているか

優先順位の付け方

棚卸しの結果を、止まったときの影響と、変更の必要性の2つの軸で整理します。

廃止候補が意外に多く見つかることもあります。使われていないマクロや、すでに不要になった業務のためのマクロは、整理するだけで管理の負担が減ります。

処理内容を洗い出す手順

移行の成否は、マクロが何をしているかを正しく把握できるかで決まります。コードを読むことだけに頼らず、次の手順で洗い出します。

1. 使っている人に操作を見せてもらう：マクロを実行する前に何を準備し、実行後に何を確認し、結果をどう使っているかを、実際の操作で見せてもらう。
2. 入力を特定する：マクロが読み込んでいるファイル、シート、セルの範囲、他のシステムから書き出したデータを特定する。
3. 出力を特定する：マクロが作るファイル、書き換えるセル、印刷する帳票、送るメールなどを特定する。
4. 処理のルールを書き出す：入力から出力までの間にどんな計算、並べ替え、条件分岐、集計をしているかを、業務の言葉で書き出す。
5. 例外を洗い出す：特定の取引先や商品、月末や年度末、データの欠けなど、条件によって処理が変わる箇所を洗い出す。
6. 入力と出力の具体例を保存する：典型的なケースと例外のケースについて、入力データと、マクロが出力した結果を保存しておく。移行後の確認に使う。
7. 手作業の補正を確認する：マクロの実行前後に、人が手で直している部分がないかを確認する。マクロだけでは完結していない業務は多い。

手順7は見落とされがちですが、非常に重要です。「マクロを実行した後、この列だけは毎回手で直している」といった補正は、マクロのコードには書かれていません。これを見落とすと、移行後に結果が合わなくなります。

コードを読むときのポイント

処理のルールを確かめるためにコードを読む場合は、次の点に注目します。

• 条件分岐（特定の値のときだけ処理を変えている箇所）
• 直接書き込まれた値（取引先名、税率、日付、ファイルの保存場所など）
• 他のファイルやシートを開いている箇所
• エラーが起きたときの処理

コードの中に直接書き込まれた取引先名や税率は、業務のルールがそこにしかない典型的な例です。これらを洗い出して一覧にすると、業務のルールが見えるようになります。

移行先の選び方

処理内容を洗い出したら、移行先を選びます。マクロの性質によって、適した移行先は異なります。

業務自動化のツールに移す場合は注意が必要です。ノーコードのツールやRPAに移しても、作った人しか中身が分からない状態になれば、属人化の問題は解決しません。管理されないまま増えたロボットの問題は野良RPAとも呼ばれます。どの移行先を選ぶ場合も、処理内容の記録と、複数人での管理を前提にします。

安全に移行する手順

移行先が決まったら、次の手順で移します。

1. 移行の範囲を決める：洗い出した処理のうち、新しい仕組みで実現するもの、やめるもの、手作業に残すものを分ける。
2. 業務のルールを見直す：マクロに書き込まれていたルールが今も必要かを確認する。不要な例外処理はこの機会にやめる。
3. 新しい仕組みを作る：洗い出した処理内容をもとに、新しい仕組みを作る。業務のルールは、コードに直接書くのではなく、設定や一覧として管理できるようにする。
4. 新旧の結果を照合する：保存しておいた入力と出力の具体例を使い、新しい仕組みの結果がマクロの結果と一致するかを確認する。差がある場合は、どちらが正しいかを業務の担当者が判断する。
5. 並行運用する：一定期間、マクロと新しい仕組みの両方で処理し、結果を照合する。
6. 切り替える：照合で問題がなくなったら、新しい仕組みに切り替え、マクロのファイルは読み取り専用で保管する。
7. 手順と記録を残す：新しい仕組みの使い方、業務のルール、問い合わせ先をまとめ、複数人が理解できるようにする。

手順4で差が見つかったとき、マクロの結果が正しいとは限りません。長年使われてきたマクロに誤りが含まれていて、移行をきっかけに初めて見つかることもあります。差が出たら、業務の担当者と一緒に、本来どうあるべきかを判断します。

属人化を繰り返さないための仕組み

新しい仕組みに移しても、管理の仕方が変わらなければ、数年後にまた同じ状態に戻ります。移行と同時に、次のような仕組みを整えておきます。

• 業務のルールを設定として持つ：取引先ごとの条件や税率、締め日などは、プログラムの中ではなく、管理画面や一覧表で担当者が確認・変更できるようにする。
• 変更の記録を残す：誰がいつどのルールを変えたかを記録し、理由も書けるようにする。
• 担当者を複数にする：日常の運用と、ルールの変更ができる人を少なくとも2人にし、片方が不在でも業務が止まらないようにする。
• 手順書を定期的に見直す：業務が変わったときに手順書も更新し、年に一度は内容が実態と合っているかを確認する。
• 小さな改善の依頼先を決める：帳票の書式変更など小さな改修を、誰にどう依頼するかを決めておく。依頼先がないと、現場がまた手元のExcelで補い始める。

Excel業務全体をシステム化する手順は、Excel業務をシステム化する手順でも詳しく解説しています。

具体的な場面で考える

架空の例として、社員50名ほどの卸売の会社を考えます。この会社では、経理の担当者が10年近く前に作ったマクロで、販売管理システムから書き出した売上データを取り込み、取引先ごとの請求書を作成していました。担当者が別の部署に異動することになり、マクロを直せる人がいなくなることが分かりました。

まず、異動前の担当者に、月末の請求書作成の操作を一通り見せてもらいました。その中で、マクロの実行後に、特定の取引先の請求書だけ手で金額を修正していることが分かりました。理由を聞くと、その取引先とは特別な値引きの約束があり、マクロに組み込む前に担当者が手で直す運用になっていたのでした。

コードを確認すると、取引先ごとの締め日、端数処理、請求書の送付先が、コードの中に直接書き込まれていました。これらを取引先ごとの一覧表に書き出し、手で直していた値引きのルールも加えました。

移行先は、販売管理システムと連携して請求データを作る小さなシステムにしました。取引先ごとのルールは一覧表として管理画面から変更できるようにし、経理の担当者なら誰でも更新できる形にしました。移行前の3か月分の売上データを新しい仕組みで処理し、マクロで作った請求書と照合したところ、端数処理の違いで数件の差が見つかりました。確認すると、マクロの処理のほうが取引先との約束と異なっていたことが分かり、新しい仕組みのルールを正としました。

切り替え後は、取引先の追加や条件の変更があったときに、経理の担当者が管理画面から一覧表を更新するだけで請求書に反映されるようになりました。異動した担当者に問い合わせが来ることもなくなり、請求業務は複数の担当者で回せる状態になりました。この例のように、移行の価値はマクロを置き換えることそのものより、業務のルールを誰でも見て直せる場所に出すことにあります。

よくある失敗と避け方

• コードだけを読んで移す：手作業の補正や、使っている人の確認作業を見落とし、移行後に結果が合わない。使っている人の操作を必ず見せてもらう。
• マクロをそのまま別の言語に置き換える：処理の意味を理解しないまま書き換えると、新しい仕組みも誰にも分からなくなる。業務の言葉で処理内容を書き出してから作る。
• 業務のルールをまたコードに埋め込む：取引先ごとの条件などを新しい仕組みのコードに直接書くと、変更のたびに開発が必要になる。設定や一覧として管理する。
• 照合をせずに切り替える：新旧の結果を比べずに切り替え、誤りに気づくのが遅れる。具体例を使って照合する。
• 作った人の異動直前に始める：処理内容を聞き取る時間が足りない。属人化に気づいた時点で、早めに洗い出しを始める。
• ツールに移して安心する：業務自動化のツールに移しても、管理する人が一人なら属人化は続く。記録と複数人での管理を前提にする。

移行を始める前のチェックリスト

• 社内のマクロを棚卸しし、影響と変更の必要性で優先順位をつけたか
• 使っている人に、実行前後の操作を見せてもらったか
• 入力と出力、処理のルール、例外を業務の言葉で書き出したか
• マクロの実行前後に行っている手作業の補正を確認したか
• コードに直接書き込まれた値（取引先、税率、保存場所など）を一覧にしたか
• 照合に使う入力と出力の具体例を保存したか
• 移行先と、業務のルールの管理方法を決めたか
• 並行運用の期間と、切り替えの判断基準を決めたか

よくある質問

Q. 作った人がすでに退職していても、移行できますか？

できます。ただし、処理内容の洗い出しに時間がかかります。今マクロを使っている人の操作を見せてもらい、入力と出力の具体例を集め、コードを読んで処理のルールを確かめる、という手順で進めます。コードの意図が分からない箇所は、入力と出力の具体例から推測し、業務の担当者に正しいかを確認します。

Q. マクロを最新のExcelで動くように直すだけではだめですか？

止まったときの影響が小さく、変更もほとんど必要ないマクロであれば、動くように直し、処理内容と手順を記録したうえで使い続けるのも一つの判断です。ただし、業務の中心を担い、変更が頻繁に必要なマクロは、直しても属人化の問題は残ります。棚卸しの優先順位に沿って判断します。

Q. マクロの処理をRPAに置き換えるのはどうですか？

画面操作の自動化が中心の処理であれば、RPAが向いている場合もあります。一方、計算や条件分岐が中心の処理は、RPAよりもシステムや業務自動化の仕組みで実現したほうが、保守しやすくなります。どちらの場合も、処理内容を記録し、複数人で管理できる体制にすることが前提です。

Q. 生成AIを使ってマクロのコードを解析できますか？

生成AIにコードを読ませて、処理の概要を説明させたり、条件分岐を一覧にさせたりすることは、洗い出しの助けになります。ただし、手作業の補正や、業務上の意図はコードからは分かりません。AIの説明は下書きとして使い、使っている人への聞き取りと、入力と出力の具体例による確認を必ず組み合わせます。また、社外のサービスにコードやデータを入力する場合は、社内の情報管理の方針を確認してください。

Otsumuに相談できること

マクロの棚卸しと優先順位づけ、使っている人への聞き取り、手順書の作成は、社内で進められる作業です。止まっても影響の小さいマクロや、請求書作成のように既製のクラウドサービスで置き換えられる処理であれば、自社で移行を進めるのが合理的です。まずはこの記事のチェックリストに沿って、社内のマクロを洗い出してみてください。

一方で、業務の中心を担うマクロに独自のルールが複雑に組み込まれている、作った人がすでにいない、販売管理や会計など他のシステムとのデータのやり取りを含めて作り直したい、といった場合は、処理内容を正しく読み解き、業務のルールを管理しやすい形で新しい仕組みに移す技術が必要になります。

Otsumuでは、マクロの処理内容の洗い出しから、業務のルールの整理、移行先の選定、新しい仕組みの開発、新旧の結果の照合までを一貫して支援します。業務のルールをコードに埋め込まず、現場の担当者が自分で更新できる形にすることで、二度と属人化しない仕組みを目指します。詳しくはExcel業務のシステム化のページをご覧ください。

どのマクロから手を付けるべきか迷っている段階でも構いません。30分の無料相談で、現在の状況を伺いながら、進め方を整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01