退職や異動のたびに「このマクロ、誰か分かる人いますか」という会話が起きていないでしょうか。Excelマクロの属人化は、コードが難しいから起きるのではなく、どこに何があり、なぜそう作ったかの記録が残っていないから起きます。この記事では、社内に散らばるVBAマクロを洗い出し、業務影響度と改修リスクで分類し、誰でも触れる状態に近づけるための棚卸し手順を5つのステップで整理します。
- 洗い出し 社内に存在するマクロを場所と使用者ごとに一覧化する
- 分類 業務影響度と改修リスクの2軸で着手順を決める
- 情報収集 6分類のフォーマットに沿って不足情報を埋める
- 版の固定 現行の仕様とコードを基準版として確定し確認記録を残す
- 運用 改修のたびに同じ場所へ追記し、引継ぎは案件単位で渡す
なぜExcelマクロは属人化するのか
多くの現場で、マクロは正式な開発案件としてではなく、担当者が自分の作業を楽にするために作り始めます。この成り立ちに属人化の原因が集まっています。
- 作った本人は仕様を覚えているため、仕様書を書く動機がない
- 「月末だけ処理を分ける」といった例外ルールが、依頼者との口頭のやり取りだけで決まっている
- ファイルが個人フォルダや共有ドライブの深い階層に置かれ、存在自体が共有されていない
- 修正のたびに「最終版」「最終版2」とコピーが増え、どれが本番か分からない
つまり、残っていないのはコードではなく、コードの外側にある情報です。コードはファイルを開けば読めますが、「なぜこの条件分岐があるのか」「どの部署の誰の依頼で入れた処理か」は、本人の頭の中にしかありません。棚卸しで集めるべきなのは、この外側の情報です。
属人化しているのはコードではなく、仕様・経緯・依頼のやり取りという周辺情報です。
手順1・2：洗い出しと、2軸での分類
全件を一覧にする
まず、存在するマクロを把握します。完璧を目指さず、次の聞き方で各部署から拾い上げるのが現実的です。
- 毎月・毎週決まって実行しているExcelファイルはあるか
- ボタンを押すと自動で処理が走るファイルはあるか
- 作った人がすでに異動・退職しているファイルはあるか
一覧には、ファイル名、保管場所、使用部署、使用頻度、作成者、現在の担当者を記録します。作成者が不明なら「不明」と書くこと自体が重要な情報です。
業務影響度と改修リスクで分ける
全件を同じ熱量で整備するのは現実的ではありません。次の2軸で分類し、着手順を決めます。
| 区分 | 業務影響度 | 改修リスク | 対応方針 |
|---|---|---|---|
| A | 高（止まると業務が滞る） | 高（作った人が不在・仕様不明） | 最優先で情報を復元する |
| B | 高 | 低（担当者が在籍し内容を説明できる） | 在籍中に仕様を書き起こす |
| C | 低 | 高 | 使用状況を確認し、廃止も検討する |
| D | 低 | 低 | 一覧に載せるだけで当面は保留 |
業務影響度は「止まったときに手作業で代替できるか」「何日で業務に支障が出るか」で判断します。改修リスクは「作成者が今も連絡を取れるか」「仕様に関する記録が残っているか」で判断します。
手順3：6分類で情報を集める
優先順位が決まったら、情報を集めます。何を集めるかを先に決めておかないと、人によって書く粒度がばらつきます。自動化案件の情報は、次の6分類に整理すると抜けが見えやすくなります。
| 分類 | 集める内容 | 確認の観点 |
|---|---|---|
| 基本情報 | 名称、用途、使用部署、実行タイミング、担当者 | 止まったとき誰に連絡するかが分かるか |
| 仕様 | 入力データ、処理内容、出力、例外ルール | 第三者が読んで同じ結果を再現できるか |
| 資料 | 画面イメージ、サンプルデータ、元の依頼書 | 実際の入力ファイルの形式が分かるか |
| コード | 現行のソースと配置場所 | 本番として動いているものと一致しているか |
| 会話 | 依頼者とのやり取り、仕様決定の経緯 | 「なぜそうしたか」が追えるか |
| 改修履歴 | いつ・誰が・何を・なぜ変えたか | 過去の変更理由が分かるか |
特に抜けやすいのが「会話」と「改修履歴」です。コードだけ渡されても、後任者は「この例外処理は消していいのか」が判断できません。判断できないから触れず、結果として誰も直せないマクロが残ります。
手順4・5：版を固定し、改修を同じ場所に積む
情報を集めたら、現時点の仕様とコードを「基準版」として確定します。ここを曖昧にしたままだと、せっかく書いた仕様書と実際の挙動が半年後にずれます。
確定の際は、依頼部署に内容を確認してもらい、その確認記録を残します。「この内容で合っている」と確認した事実が残っていれば、次に不整合が見つかったときに、いつ以降の変更で生じたかを絞り込めます。
その後の運用で守る点は3つです。
- 改修の依頼・検討・結論を、コードと同じ場所に残す
- 仕様を変えたら仕様の記述も同時に更新し、新しい版として固定する
- 引継ぎは「ファイルを渡す」ではなく「案件一式を渡す」形にする
この3点は、ExcelのVBAに限らず、PythonやGASで作った自動化処理でも同じです。社内の自動化資産がツールごとにばらばらの管理になっていると、棚卸しの効果が続きません。
基準版の確定と確認記録があれば、ずれが生じた時期を後から絞り込めます。
管理の受け皿をどう用意するか
6分類での整理は、共有フォルダとExcel台帳でも始められます。ただし、分類ごとにファイルが分散すると、結局どこを見ればよいか分からなくなり、更新が止まりやすくなります。
Poxiiは、VBA・Python・GASなどの自動化案件を、基本情報・仕様・資料・コード・会話・改修履歴の6分類で整理するサービスです。案件ごとにURLが割り当てられ、そのURLを渡すことで管理と引継ぎを行えます。仕様とコードの版を固定し、確認記録を残す機能があるため、本記事の手順4・5にあたる運用をそのまま置けます。
すぐ棚卸しに着手すべき状態
- 作成者がすでに退職・異動している
- 止まると月次業務が滞るマクロがある
- 「最終版」が複数あり本番が特定できない
一覧化から始めればよい状態
- 作成者が在籍し、仕様を説明できる
- 代替の手作業手順が明文化されている
- 使用頻度が低く、停止しても即座には困らない
よくある質問
Q: 作成者がすでに退職していて、仕様がまったく分かりません。どこから手を付けますか。
A: コードを読み解く前に、使っている人へのヒアリングから始めます。どのファイルを入れ、どの結果を何に使っているかという入出力の事実は、使用者が知っています。入出力が分かれば、コードの中で不明な箇所を絞り込めます。分からない部分は「理由不明」と記録に残したうえで基準版を固定し、改修時に判明した内容を履歴へ追記する進め方が現実的です。
Q: マクロをすべて他のツールに作り直すべきでしょうか。
A: 棚卸しと作り直しは分けて考えることをおすすめします。仕様が分からないまま作り直すと、拾えていない例外処理が抜け落ちます。まず6分類で情報を揃え、仕様が明確になった段階で、現行のまま維持するか別の形に移すかを判断する順序が安全です。
Q: 棚卸しの作業自体が負担になり、途中で止まりそうです。
A: 全件を同じ水準で整備しようとすると止まりやすくなります。業務影響度と改修リスクの両方が高いものに絞り、まず数件を完了させてフォーマットを固めてから広げる進め方が続けやすいです。完了の基準を「仕様書の完成」ではなく「基準版の確定と確認記録の作成」に置くと、区切りを付けやすくなります。
まとめ
Excelマクロの属人化は、コードの難易度ではなく記録の欠落が原因です。解消の手順は、全件の洗い出し、業務影響度と改修リスクによる分類、6分類での情報収集、基準版の固定、改修の継続的な記録という流れになります。
重要なのは、最初から完璧を目指さないことです。作成者が不在で業務が止まると困るものから着手し、1件ずつ「誰でも状況を把握できる状態」に変えていけば、組織としてのリスクは着実に下がります。社内に自動化の資産が増えているなら、ファイル単位ではなく案件単位で管理する仕組みを一度検討してみてください。
