先代が作ったVBAマクロを、今いる人だけで解読する方法

先代の代から使われている見積書や請求書のExcelファイルを開いたら、ボタンを押すと数字がずらりと並ぶ。だが「なぜこの数字が出るのか」を説明できる人が社内に誰もいない——事業承継の現場では、こうした場面に驚くほど頻繁に出くわします。この記事は、先代が独学かどこかの外注先に頼んで作ったVBAマクロが会社の基幹業務に組み込まれてしまっており、作った本人はもう相談できず、今いる社員も「触ると壊れそうで怖い」と手を出せない、という状態の経営者に向けて書いています。結論を先に言うと、VBAマクロは正しい手順を踏めば、プログラミング未経験の今いる人員だけでも8割方は解読可能です。必要なのは特別な才能ではなく、順番と道具立てです。この記事では、その具体的な手順を、承継直後の限られた時間とリソースの中でどう実行するかという視点でまとめます。

株式や登記には専門家がいるのに、システムには誰もいない

先代から会社を継いだ経営者の多くが口にする違和感があります。株式の名義変更には税理士がいる。登記の変更には司法書士がいる。事業承継計画そのものには商工会議所や地域の金融機関、事業承継・引継ぎ支援センターといった相談先が用意されている。ところが「先代が作ったこのExcelファイル、どうしたらいいですか」と尋ねる相手は、社内にも社外にもほとんど見つかりません。中小企業庁が公開している事業承継ガイドラインでも、経営状況や経営課題を「見える化」し、誰が経営者になっても回る組織体制を作ることが承継準備の重要な一歩と位置づけられていますが、そこで言う「経営資源の見える化」には、実は日々の業務を支えているExcelマクロやシステムの中身も含まれているはずです。ただ、この部分は税務や法務ほど制度化されておらず、相談窓口も整っていないため、経営者が一人で抱え込みやすい領域になっています。まずは「これは自分だけが困っているわけではない」という前提を持つことが、次の一歩を踏み出す助けになります。

先代のマクロが「解読不能」に見える3つの理由

先代が作ったマクロを開いて「意味がわからない」と感じるのには、はっきりした理由があります。原因を分解すると、対処のしかたも見えてきます。

まず1つ目は、変数名や処理の単位に日本語のコメントがほとんど残されていないことです。先代世代の担当者は「動けばいい」という発想で組んでいることが多く、後任者への説明を前提にしていません。2つ目は、マクロが複数のシートやファイルをまたいで動く「連鎖構造」になっていて、どこが処理の起点なのかが一見してわからないことです。3つ目は、そもそも先代がどこまで自分で書いたのか、外部の業者に一部だけ発注したのかという「出自」が不明なことです。この3つが重なると、社員は「怖くて触れない」という心理状態に陥り、結果としてマクロは動いているだけの「聖域」になってしまいます。

解読作業に着手する前に決めておくべき前提

コードを開く前に、経営者として決めておくべきことがあります。ここを飛ばすと、せっかく解読を始めても途中で頓挫します。

• 担当者を1人に絞らない: 属人化の再生産を避けるため、最低2人体制で進める
• 業務を止めずに並走させる: 旧マクロは動かしたまま、解読と検証を並行する
• 期限を決める: 「いつまでに全体像を把握するか」を先に区切る
• 先代への確認ルートを塞がない: 完全に引退していなければ、質問できる窓口を残しておく

このうち特に重要なのが最後の一点です。先代がまだ存命で、たまに会社に顔を出す関係であれば、「一言二言聞けば済むこと」を無理に自力解読で何日もかけるのは非効率です。ただし、承継後の関係性によっては、先代に頻繁に質問することが心理的にやりづらい場合もあるでしょう。その場合は、後述する解読手順で「まず自分たちで8割まで詰めて、残り2割だけを質問する」形にすると、先代への負担も自分たちの気まずさも最小化できます。

ステップ1: マクロの「入口」を特定する

VBAマクロの解読で最初にやるべきことは、そのマクロが「どこから始まって、どこで終わるか」を特定することです。多くの場合、マクロはボタンやショートカットキーに割り当てられていますが、その裏側にあるプロシージャ(処理のまとまり)が複数存在し、どれが最初に呼ばれるのかが不明瞭です。

Excelの「開発」タブからVisual Basic Editor(VBE)を開き、左側のプロジェクトエクスプローラーで、標準モジュール・シートモジュール・ThisWorkbookのどこにコードが書かれているかを一覧します。ボタンに割り当てられているマクロ名は、ボタンを右クリックして「マクロの登録」を選べば表示されるので、そこから逆算して該当するプロシージャ(Sub〜End Sub)を探します。この段階では処理の内容を理解する必要はありません。「どの箱に何が入っているか」の地図を作ることが目的です。

ステップ2: 一度も実行せず、まず「読む」

いきなり実行して結果を見るよりも先に、コードを声に出さずに一読することを勧めます。VBAは英語の予約語ベースの構文なので、For〜Next(繰り返し)、If〜Then(条件分岐)、Do While(条件付き繰り返し)といった基本構文のパターンさえ覚えれば、変数名がわからなくても「ここは繰り返し処理をしている」「ここは条件で分岐している」という骨格は見えてきます。

この段階でおすすめなのが、コード全体をコピーして印刷するか、別のテキストファイルに貼り付けて、行数の少ないプロシージャから手をつけることです。長大な一つの処理を最初から解読しようとすると挫折します。10行程度の小さな処理から手をつけて「読めた」という感覚を積み重ねるほうが、非IT出身の担当者には向いています。

ステップ3: F8キーでの逐次実行という最強の武器

VBAの解読において、今いる人だけで完結できる最大の武器が「ステップ実行」です。VBEの中でカーソルを実行したいプロシージャの中に置き、F8キーを押すと、コードが1行ずつ実行され、今どの行が動いているかが黄色くハイライトされます。もう一度F8を押せば次の行へ進みます。

これの何が強力かというと、処理を「読んで理解する」のではなく「動きを目で追って理解する」という、非エンジニアにとって圧倒的にハードルの低い学習方法に切り替えられる点です。マクロがどのセルを読み、どこに書き込み、どの条件で分岐したのかが、コードを読むよりもずっと直感的にわかります。

さらに、変数の値をその場で確認したいときは、Microsoft公式のドキュメントでも紹介されている「イミディエイトウィンドウ」が役立ちます。VBEの表示メニューからイミディエイトウィンドウ(Ctrl+G)を開き、ステップ実行で処理が止まっている状態で ? 変数名 と入力してEnterを押すと、その時点での変数の値が表示されます。コードにあらかじめ Debug.Print 変数名 を差し込んでおけば、実行を通して変数がどう変化していくかを一覧で確認することもできます。この2つの機能を使うだけで、「このマクロは何をしているのか」という問いのほとんどに、実行結果という具体的な答えで応えられるようになります。

「コードを読んで理解する」のではなく「F8キーで1行ずつ動かし、目で追って理解する」。この発想の転換が、非IT出身の担当者にとって最大の突破口になります。

ステップ4: 処理を機能ブロックで色分けする

ステップ実行である程度動きが見えてきたら、コード全体をいくつかの機能ブロックに分割してメモを残す作業に入ります。たとえば「A列からD列のデータを読み込む部分」「税率を掛けて計算する部分」「別シートに結果を転記する部分」「印刷用にレイアウトを整える部分」のように、意味のある単位で区切りをつけ、それぞれの先頭行にコメントとして書き加えていきます。

このとき役立つのが表形式の整理です。実際に手を動かした企業の担当者からは、次のような一覧表を作ってから作業が一気に進んだという声がよく聞かれます。

このように危険度を可視化しておくと、「どこは触っても安全か」「どこは慎重に扱うべきか」が今いる社員の間で共有され、次に何かトラブルが起きたときの初動対応も格段に早くなります。

ステップ5: 古参社員の「使い方の記憶」を掘り出す

コードの解読と並行して見落とされがちなのが、実際にこのマクロを長年使ってきた古参社員へのヒアリングです。古参社員はVBAのコードそのものは読めなくても、「このボタンを押すと月末の集計が出る」「このエラーが出たときは決まってこのセルを直せば直る」といった運用上の経験知を大量に持っています。

承継直後の経営者にとって、古参社員へのヒアリングは意外と気を使う場面かもしれません。先代の代からのやり方に口を出すようで気が引ける、あるいは「今更聞くのか」と思われないか不安になる、という声もよく聞きます。しかし、この場面でのヒアリングは「システムを壊さないために教えてほしい」という文脈であれば、むしろ古参社員の経験を尊重する姿勢として伝わりやすいものです。実際に聞くべき質問は次のようなものです。

1. このマクロを実行するのは月に何回か、どのタイミングか
2. 過去にエラーが出たことはあるか、その時どう対処したか
3. 入力する数値やファイル名に「決まりごと」はあるか
4. 先代以外にこのマクロを触ったことがある人はいるか
5. 「動かないと本当に困る」処理はどの部分か

この5つの質問への回答を得られれば、コードの解読と現場の運用実態を突き合わせることができ、「コード上はこう見えるが、実際の運用ではこう使われている」というギャップに気づけます。このギャップこそが、今後のトラブルの火種になりやすい部分です。

古参社員へのヒアリングでもう一つ気をつけたいのは、聞き方の順序です。いきなり「このマクロの中身を教えてください」と切り出すと、相手は「自分が知らないことを試されている」ように感じて構えてしまうことがあります。先に「いつもこの作業、助かってます」と日頃の労いを一言添えてから、「実はこのマクロ、先代が作った経緯を今のうちに残しておきたくて」という承継の文脈を共有すると、相手も「会社のために協力する」という前向きな姿勢で応じてくれやすくなります。承継直後は社内の空気そのものが不安定になりがちな時期なので、こうした小さな声かけの積み重ねが、古参社員との関係を保つうえでも効いてきます。

部署をまたぐマクロほど後回しにされやすい

社内で複数の部署が関わる業務、たとえば受注データを営業が入力し、経理が請求処理に使い、さらに製造部門が在庫の連携に使っているようなマクロは、解読の優先度が高いにもかかわらず、後回しにされがちです。理由は単純で、担当部署が一つに定まらず、「うちの部署だけの問題ではない」という意識が働いて、誰も手を挙げにくいからです。

このタイプのマクロを解読する際は、経営者自身が「どの部署がどの範囲を担当するか」を最初に割り振ることが欠かせません。部署間をまたぐデータの受け渡し部分は特にトラブルの火種になりやすいため、営業側の担当者と経理側の担当者が同席して、それぞれの立場から見た処理の意味を確認し合う場を設けると、単独で解読するよりも早く全体像が見えてきます。承継直後は組織図そのものが揺れている時期でもあるため、この機会に「このマクロは今後どの部署が責任を持つか」を明文化しておくと、次に同じ問題が起きた時の対応もスムーズになります。

名義とライセンスの問題にも目を向ける

VBAマクロ自体はExcelの標準機能なので、追加のライセンス費用は基本的にかかりません。しかし、注意が必要なのは「そのマクロが外部の業者に発注して作られたものかどうか」です。先代が個人的な知り合いのITベンダーや、退職した元社員に個人的に依頼して作ってもらったマクロの場合、著作権や利用許諾の扱いが曖昧なまま使われ続けているケースが少なくありません。

承継のタイミングで、次のことを確認しておくと後々のトラブルを避けられます。

• マクロの発注書や見積書、契約書が残っているか
• 保守契約が今も生きているか(先代個人と契約していた場合、承継後に無効になっていないか)
• 外部委託先が今も連絡可能な状態か

これは法律の専門知識が要る領域なので、税理士や弁護士に事業承継全体を相談している場合は、その場で「システムの契約関係も一緒に確認してほしい」と伝えておくのが効率的です。株式や不動産の名義変更ばかりに気を取られて、こうした小さな契約書の存在を見落としたまま、後になって「保守契約が切れていた」と気づくケースは実際にあります。

全部を解読しなくていい、という判断も必要

ここまで解読の手順を説明してきましたが、経営判断として重要なのは「マクロの全行を100%理解する必要はない」という点です。会社によっては数千行に及ぶマクロが動いていることもあり、それを今いる人員だけで完全に解読しようとすると、本業を圧迫してしまいます。

優先順位のつけかたとしては、次の3段階に分けて考えるとバランスが取れます。

• 必須で理解する: 毎日・毎週使う処理で、止まると即座に業務が止まるもの
• できれば理解する: 月次・年次で使う処理で、止まっても数日の余裕があるもの
• 理解を諦めてもいい: ほぼ使われていない過去の処理、あるいは代替手段がすでにあるもの

この優先順位づけをせずに全行解読を目指すと、多くの中小企業では途中で息切れして中断し、「結局よくわからないまま」という状態に戻ってしまいます。承継直後は本業の引き継ぎだけでも手一杯なはずなので、限られた時間は「止まったら困る部分」に集中投下するのが現実的な判断です。

エラーが出たときの応急処置マニュアルを先に作る

完全な解読が終わる前でも、エラーが出た際の応急処置マニュアルだけは先に作っておくことを強く勧めます。実際の実務では「マクロの仕組みを100%理解する」より「エラーが出たときに慌てず対処できる」ことのほうが緊急性が高いからです。

応急処置マニュアルには、次の内容を最低限含めておきます。

エラーメッセージの文言(スクリーンショットを残す)/エラーが出た直前にどの操作をしたか/エラー発生時にOKやキャンセルのどちらを押すべきか/デバッグボタンを押した場合にどこがハイライトされるか/最終手段としてマクロを使わず手作業で代替する方法

この最後の「手作業で代替する方法」は特に重要です。マクロが完全に止まってしまった場合でも、電卓とExcelの手入力だけで当日の業務を乗り切れる代替フローを一つ用意しておけば、解読作業中に多少のトラブルがあっても会社の業務は止まりません。承継直後は「システムが止まる=会社が止まる」という恐怖感を持ちやすいですが、手作業の代替ルートがあるとわかっているだけで、心理的な余裕がまったく違ってきます。

解読後にすぐ「作り直す」べきかは別の判断

マクロの中身が見えてくると、「こんな古い作り方をしているなら、いっそ全部作り直したほうがいいのでは」という発想が出てくることがあります。これは半分正しく、半分早計です。

正しい部分は、長年のパッチワークで複雑化したマクロは、いずれ限界を迎えるという点です。一方で早計な部分は、解読した直後の勢いだけで刷新に踏み切ると、現場が新しいやり方に馴染むまでの間、古参社員の抵抗や業務の一時的な停滞というコストが発生する点です。事業承継の直後は、経営権の移行そのものに社内の関心とエネルギーが集中している時期でもあります。システムの刷新は、経営の引き継ぎがある程度落ち着いてから、優先順位を持って進めるほうが、社内の心理的な負担を分散させられます。

刷新を検討する際の選択肢としては、VBAマクロの保守を続けながら部分的に手直しする方法、あるいはノーコード・ローコードのツールに段階的に置き換えていく方法などがあります。マクロを完全に捨てるのではなく、「今動いている部分は残しつつ、危険度の高い部分だけ先に手を入れる」というハイブリッドな進め方が、承継直後の会社には現実的な場合が多いです。移行先の候補としてkintoneを検討する際に整理しておきたいデータ項目は、kintoneに移行する前に整理しておきたい先代データの項目でまとめている。

解読作業を「今いる人」だけで完結させる意味

この記事のタイトルにもある「今いる人だけで解読する」という前提には、単なる予算の制約以上の意味があります。外部のITベンダーにマクロの解読を丸ごと依頼すれば早いかもしれませんが、それでは「先代が抜けたら誰も分からない」という属人化の構造を、「外部業者が抜けたら誰も分からない」という別の属人化に置き換えるだけになってしまいます。

今いる社員が自分たちの手でマクロの構造を掘り出す過程には、単に業務知識を引き継ぐという以上の効果があります。「このマクロは自分たちが理解している」という自信が生まれ、次に似たような業務改善が必要になったときに、また外部に頼らず自分たちで手を動かす土壌ができます。承継直後の会社にとって、この「自分たちで理解できた」という経験の蓄積は、目に見えない資産として長く効いてきます。

解読の過程で見つかる「隠れたデータの汚さ」

VBAマクロを解読していく過程で、多くの経営者が予想していなかった副産物に気づきます。それは、マクロが参照している元データそのものの品質の低さです。同じ取引先名が「株式会社」の有無や全角半角の違いで複数の表記として登録されていたり、日付の形式が統一されていなかったりすることが、マクロの中の条件分岐やIF文を読み解く過程で次々と発覚します。

こうしたデータの乱れは、マクロが本来意図した通りに動かない原因になっていることも多く、データクレンジングと呼ばれる整理作業を先に行っておくことで、マクロ自体の動作も安定しやすくなります。解読作業とデータクレンジングは別の作業に見えて、実際には表裏一体の工程だと理解しておくと、途中で「マクロがおかしいのか、データがおかしいのか」を混同せずに進められます。台帳が「重くて開けない」状態を放置した場合に何が起きるかは、先代の台帳が「重くて開けない」を放置するとどうなるかでも解説している。

承継のタイミングだからこそ得られる「聞ける」チャンス

先代がまだ経営に一部関与している、あるいは相談役として社内に残っているタイミングは、実は最後の「直接聞ける」機会でもあります。完全に引退してしまった後や、万一のことがあった後では、マクロの意図や作られた経緯を確認する手段が永久に失われます。

このため、解読作業を先延ばしにするのではなく、承継直後のこの時期にこそ着手する価値があります。「まだ時間があるから」と後回しにした結果、数年後に先代へ連絡が取れなくなり、当時の判断の経緯や「なぜこの計算式にしたのか」という背景が完全にわからなくなってしまった、という声は決して珍しくありません。事業承継ガイドラインが示す「見える化」の考え方は、財務や組織図だけでなく、日々の業務を支えるこうしたマクロにも当てはめて考えるべきものです。

解読を通じて社内の「次の担当者」を育てる

もう一つ、解読プロセスを通じて得られる大きな成果は、次にこのマクロを扱う担当者が自然と育つことです。属人化の本質的な問題は「1人しか知らない」ことにあるので、解読作業を最初から2人以上の体制で進め、双方が同じ資料とメモを共有する形にしておけば、たとえその2人のうち1人が退職しても、もう1人が残ります。

この「2人体制」を制度として定着させることが、実は今回の解読作業で得られる最大の恒久的効果です。マクロそのものの理解度以上に、「1人だけが業務を握る」という状態そのものを解消することが、次の世代への引き継ぎリスクを下げる本質的な対策になります。

解読の記録は必ず文書として残す

ステップ実行で追いかけた処理の流れ、機能ブロックごとの整理表、古参社員からのヒアリング内容、エラー時の応急処置マニュアル——これらはすべて、口頭のやり取りや個人のメモで終わらせず、社内で共有できる文書として残しておく必要があります。せっかく苦労して解読したのに、それが担当者個人のノートにしか残っていなければ、その担当者が異動や退職をした時点で、また同じ苦労を繰り返すことになります。

文書化する際には、WordやExcelの共有ファイルでも構いませんが、更新履歴が残る形式にしておくことが望ましいです。マクロは業務の変化に合わせて少しずつ改変されていくものなので、「いつ、誰が、何を、なぜ変えたか」を残しておけば、次に担当が変わったときにも過去の変更意図をたどれます。

今後の改修は小さく始める

解読が一段落したら、次に検討すべきは「今後どう保守していくか」です。ここでいきなり大規模な改修に踏み切るのではなく、小さな改修を積み重ねる方が、承継直後の組織には向いています。たとえば、エラーが頻発する箇所だけをまず直す、入力ミスが起きやすい欄にチェック機能を追加する、といった小さな改善から始めます。

小さな改修を繰り返すことで、解読した担当者自身のスキルも段階的に上がっていきます。最初は「読むだけ」だったところから、「1行変えてみる」「if文の条件を調整する」といった実際の修正作業に踏み出せるようになれば、それはもう「今いる人だけで完結できる」保守体制が実現したということです。逆に言えば、解読はゴールではなく、社内で保守できる体制を作るための出発点に過ぎません。

CSVやクラウドとの連携も視野に入れる

古いマクロの多くは、Excelファイル同士の受け渡しを前提に組まれていますが、最近の業務では取引先や金融機関とのデータ連携にCSV形式のファイルを使う場面も増えています。マクロを解読していく中で、「実はこの処理はCSVの読み込みと出力をしているだけだった」と判明することも多く、その場合は思い切ってクラウド上のツールに置き換えたほうが、今後の運用が楽になることもあります。

すべてを一度に変える必要はありませんが、「このマクロはCSV連携が中心だから、将来的にクラウドサービスに移行しやすい」「このマクロは複雑な条件分岐が多いから、当面は保守で乗り切る」といった仕分けを、解読作業の中で同時に進めておくと、後々のシステム刷新の計画が立てやすくなります。FAXや手書き台帳からの受発注をまず脱する第一歩を踏み出したい場合は、FAX・手書き台帳からの受発注、抜け出すための第一歩も参考になる。

解読を機に他のマクロも横並びで棚卸しする

一つのマクロの解読が終わると、多くの会社で「実はこのマクロも先代が作ったものだった」「これも動いているけど誰も触れない」という声が次々と出てきます。承継直後に見つかるマクロは、たいてい1つではありません。請求書用、在庫管理用、勤怠集計用など、業務の節目ごとに先代が少しずつ作り足してきた結果、社内には把握されていないマクロが複数存在していることが珍しくありません。

このため、1つのマクロの解読が終わった段階で、社内にある他のExcelファイルにもマクロが仕込まれていないかを一度棚卸ししておくことを勧めます。方法は単純で、業務で使っているExcelファイルを開き、リボンの「開発」タブからVBEを開いて、プロジェクトエクスプローラーに何らかのモジュールが存在するかを確認するだけです。ファイルの拡張子が.xlsmになっているものは、マクロが有効になっている可能性が高いので、まずそこから優先的に確認すると効率的です。この棚卸し作業を先にやっておけば、「次はどのマクロが火種になるか」を先回りして把握でき、後から慌てて対応する事態を減らせます。

解読作業にかかる社内コストを見積もっておく

経営者として気になるのは、この解読作業にどれだけの人件費、つまり社内コストがかかるのかという点です。担当者2人が本業と並行して進める場合、1つのマクロにつき、週に数時間ずつ着手して1〜2ヶ月というのが一つの目安になります。この時間を「本業を圧迫する負担」と捉えるか、「将来の属人化リスクを下げる投資」と捉えるかで、経営者としての意思決定の重みが変わってきます。

承継直後は目先の業務の引き継ぎで手一杯になりがちですが、ここであえて数十時間規模のコストを払ってでも解読を進めておくと、数年後に「担当者が突然退職してマクロが止まった」という最悪のシナリオを避けられます。逆にこのコストを払わずに放置した場合、いずれ発生するトラブル対応にかかるコストは、事前の解読作業よりもずっと大きくなるのが実情です。小さな投資で大きなリスクを避けられると考えれば、この作業の優先度は決して低くありません。

まとめると、解読は5つのステップで進む

ここまでの内容を、実際に手を動かす順番として整理すると次のようになります。

1. マクロの入口(ボタンやショートカット)から該当プロシージャを特定する
2. コード全体を一度読み、小さいプロシージャから手をつける
3. F8キーによるステップ実行とイミディエイトウィンドウで動きを目で追う
4. 機能ブロックごとに危険度を色分けし、表として整理する
5. 古参社員へのヒアリングで運用実態と突き合わせ、文書として残す

この順番を守れば、プログラミング経験のない社員だけでも、多くの業務マクロは十分に解読可能な範囲に収まります。特別なプログラミングスクールに通う必要も、高額な解析ツールを導入する必要もありません。必要なのは、正しい順番と、少しの根気だけです。

先代が積み上げてきた仕組みを、恐れる対象から「自分たちの資産」に変える作業は、決して楽ではありませんが、承継後の会社にとって大きな意味を持ちます。先代の工夫や試行錯誤の跡がコードの中に残っているということは、それだけ会社の歴史がそこに刻まれているということでもあります。焦らず一つずつ解き明かしていけば、その先には「もう先代がいなくても大丈夫」という、経営者としての確かな自信が待っています。