前任者が作ったExcelマクロ、誰も直せないまま使っていませんか?|壊れる前に残したい4つの情報

前任者が作ったExcelマクロ、誰も直せないまま使っていませんか?|壊れる前に残したい4つの情報

記事
IT・テクノロジー
Excelマクロって、動いている間は本当に便利です。

ボタンを押せば集計される。
帳票ができる。
CSVが出る。
別ファイルへ転記される。

誰も中身を気にしません。

そして作った人がいなくなった瞬間、

「これ、誰も触れないんだけど……」

になります。

はい。

個人的には、動いているExcelほど少し怖いです。

エラーが出ているなら直そうとなります。
でも毎日普通に動いていると、誰も中身を確認しません。

そのまま数年。

PCを入れ替えた。
保存場所が変わった。
Officeを更新した。
参照していたファイル名が変わった。

そこで初めて止まります。

この記事では、マクロのコードを全部ドキュメント化しましょう、という重たい話はしません。

最低限これだけ残しておくと、次に直す人がクッッッソ助かる。

そんな4つの情報を整理します。

■ コードより先に残す「役割」


1つ目は、そのExcelが何をしているかです。

意外とここが残っていません。

マクロ名が、

Main
実行
Button1_Click
Macro1

だけ。

これでは何も分かりません。

コードを読めば処理は追えます。

でも、

「なぜこの処理が必要なのか」
「誰がいつ使うのか」
「最終的に何ができれば成功なのか」

はコードだけでは分からないことがあります。

だから最低限、

・何のためのファイルか
・誰が使うか
・いつ使うか
・どのボタンをどの順番で押すか
・最終的に何が出力されるか

これを残します。

READMEを20ページ作る必要はありません。

Excelの先頭シートに「使い方」を1枚置くだけでも違います。

未来の担当者からすると宝です。

■ 入力と出力の「依存関係」


2つ目は、どこからデータを取って、どこへ出しているか。

ここはかなり重要です。

例えばマクロの中で、

Cドライブの特定フォルダを参照している。
ネットワークドライブのファイルを開いている。
決まった名前のCSVを探している。
別のExcelブックからマスタを読み込んでいる。

こういう依存関係があります。

利用者から見ると、

「このExcelを開いてボタンを押しているだけ」

なんですよね。

でも実際は、裏でいくつものファイルを触っていることがあります。

それを知らずにフォルダを整理すると止まります。

「不要そうだから移動しました」

はい、終了。

これは担当者が悪いという話ではありません。

見えない依存関係のまま運用していることが問題です。

残しておきたいのは、

・入力ファイル
・出力ファイル
・参照フォルダ
・参照シート
・外部データ
・必要なファイル名

このあたり。

図にするともっと分かりやすいです。

入力Excel
マクロ
集計
CSV出力

これだけでも十分。

コード1000行より、この4行の図のほうが先に役立つことがあります。

■ エラー時の「確認場所」


3つ目は、止まったときに最初に見る場所です。

マクロは、いろいろな理由で動かなくなります。

入力データがおかしい。
ファイルがない。
フォルダパスが変わった。
シート名が変わった。
権限が違う。
マクロが無効になっている。

Microsoftも現在、Excelでマクロの実行をセキュリティ設定によって制御しており、すべてのマクロを無条件で有効にする設定は推奨していません。

つまり、

「昨日まで動いていたのに、PCを変えたら動かない」

というとき、コードの不具合とは限りません。

ここで何も情報がないと、

担当者A「Excel壊れた?」
担当者B「知らない」
担当者C「作った人、もういない」

という美しい三段活用が完成します。

いや、笑えないです。

最低限、

・エラー画面のスクリーンショット
・エラーが出た操作
・最後に正常だった日
・直前に変えたもの
・確認するフォルダやファイル

を残せるようにしておく。

これだけでも原因調査がかなり楽になります。

さらに可能なら、マクロ側でエラーログを出すようにします。

「エラーになりました」だけではなく、

どの処理で。
どのファイルを触って。
何が見つからなかったのか。

まで残せると強いです。

■ 次の人へ渡す「引き継ぎメモ」


4つ目は、作った人しか知らない判断です。

これが一番消えやすいです。

「この列は空欄でもOK」
「このシート名だけは変えない」
「月初だけ処理順が違う」
「このファイルは削除しない」
「このボタンは押さなくていい」

こういう情報。

コードにコメントがあっても、運用上の理由までは書かれていないことがあります。

引き継ぎメモというと大げさですが、

「触っていいところ」
「触ると危ないところ」
「よくあるエラー」
「変更したいときの注意」

この4つくらいで十分です。

むしろ全部を完璧に書こうとすると続きません。

僕は、運用資料は「次の人が困る順」で残せばいいと思っています。

■ ChatGPTがあってもブラックボックスは消えない


今はChatGPTにVBAコードを貼れば、

「この処理は何をしていますか?」

とかなり詳しく説明してくれます。

これは便利です。

昔より既存コードを読むハードルは下がりました。

ただし、ChatGPTでも分からないものがあります。

なぜこのフォルダ構成なのか。
なぜこの列だけ除外するのか。
なぜ毎月3営業日に実行するのか。
なぜこのファイル名を変えてはいけないのか。

それはコードではなく、会社側の運用ルールだからです。

つまり、コードを説明できるツールが進化しても、

「このExcelが業務の中で何をしているか」

は人が残しておいたほうがいい。

ここは変わりません。

■ VBAを全部捨てる必要はない


「属人化しているならWebシステムにしましょう」

とすぐ言う人もいます。

僕はそうは思いません。

Excelで十分な業務は普通にあります。

利用者が数人。
データ量も大きくない。
入力も出力もExcel。
複雑な権限管理もいらない。

それなら、今のVBAを整理して使い続けるほうが安いこともあります。

逆に、

複数部署で使う。
同時編集したい。
履歴を残したい。
データベースで一元管理したい。
スマホから使いたい。

このあたりが増えてきたら、Web化を考える。

大事なのは、

「VBAは古い」
「Webが新しい」

ではなく、今の業務に合っているかです。

■ 壊れる前が一番安い


Excelマクロの保守で一番大変なのは、完全に止まってから初めて中身を見ることです。

しかも、

作った人はいない。
仕様書もない。
入力ファイルも分からない。
エラーの再現条件も分からない。

この状態から原因を探すと、どうしても調査時間が増えます。

逆に、まだ動いているうちなら確認できます。

このボタンを押す。
このファイルを読む。
このシートへ書く。
ここまでできれば正常。

たったそれだけでも違います。

前任者が作ったExcelマクロを、誰も直せないまま使っているなら、

まずコードを全部理解しようとしなくて大丈夫です。

1. 何をしているか
2. 何を入れて何を出すか
3. 止まったときにどこを見るか
4. 次の人に伝えたい注意点

この4つだけ残してください。

それだけで「壊れた瞬間に詰むExcel」から一歩抜けられます。

もし既存マクロがブラックボックス化していて、

「今は動いているけど、このままで大丈夫か見てほしい」
「エラーが出たので原因だけ切り分けたい」
「VBAのまま直すか、別の方法へ変えるか迷っている」

という段階なら、ファイルの役割と困っている点だけでも相談できます。

止まってから全部調べるより、動いている今のほうがずっと整理しやすいです。


サービス数40万件のスキルマーケット、あなたにぴったりのサービスを探す