マクロ解析の実践手順書

～マクロ解析の手順化を目指して～

Copyright © 2025 LWP 山中 一弘 本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

第1章　マクロ解析の意義と全体像

1.1　なぜマクロを解析するのか

業務で使用されるExcelマクロは、しばしば属人的に開発され、仕様書もなくブラックボックス化していることが多い。そのため、保守・改修のたびに新たに理解し直す必要が生じ、作業効率や品質に影響を与える。マクロを解析することで、構造・機能を可視化し、再利用性や保守性を高めるとともに、属人化を防ぎ、組織的な知見の蓄積へとつながる。

1.2　設計と解析の違い

設計とは、目的に沿ってゼロから構造を考え出す「創造的な行為」である。一方で解析は、既に存在する構造を理解する「解読的な行為」である。設計が将来に向けた構築であるのに対し、解析は過去の構築物を読み解く作業である。設計者と同じ発想を持つことは不可能でも、データと処理の流れを整理することで、全体像を的確に把握することができる。

1.3　本手順書の目的と活用シーン

本手順書は、既存マクロの解析を体系化し、実務担当者が効率的かつ正確にマクロを理解するための手順を示すものである。特に、以下のようなシーンを想定している：他人が作ったマクロの改修前に構造を把握したい場合、属人化されたツールをチームで共有したい場合、新しい担当者が引き継ぐ場合など。手作業を重視しつつ、AIを効果的に組み合わせて学習効果を高める構成になっている。

1.4　全体構造から理解するという原則

マクロ解析において、まず個別のコードから読み始めるのは避けるべきである。コードは「手段」であり、「目的」を達成するための構造を理解することが先決である。そこで重要なのが、全体のオブジェクト（ブック、シート、テーブルなど）とその相互関係を図に落とし込む作業である。これにより、関数がどのようにそれらの構造を変形・操作しているかが自然に見えてくる。構造を可視化することで、複雑な処理も理解可能になる。

第2章　解析に必要な環境と道具

2.1　手作業による可視化の重要性

マクロ解析においては、視覚的な整理が極めて重要である。人間の脳は、文章よりも図や構造化された情報のほうを早く、正確に把握できる特性を持っている。ノートに手書きでオブジェクトや関数の関係を描くことで、抽象的な処理の流れが具体的な図として定着する。頭の中だけでコードの構造を把握しようとするのではなく、視覚に頼って構造を可視化することが、解析の第一歩となる。

2.2　準備物一覧：ノート、定規、3色ペン、2色マーカ

解析作業には、最小限かつ効果的な道具が必要である。ノートは自由に図を書き込める罫線なしのものが理想的。定規は、データの流れや関数の階層構造をまっすぐに書き込むために用いる。ボールペンは赤・青・黒の3色を揃え、役割ごとに使い分けることで情報が整理される。蛍光マーカは最低でも2色を使用し、関数名やオブジェクト名などの重要箇所に視覚的なアクセントを与えるために使う。

2.3　印刷：行番号付き、1ページ100行の原則

マクロコードは、印刷して目視で確認するのが基本である。行番号付きで印刷することで、関数木やコメントで参照する際に正確な位置が特定できる。1ページに100行程度に収めることで、紙ベースでの階層把握がしやすくなり、ページ番号と行番号を使った効率的な参照が可能となる。数百行程度であれば全ページを印刷し、紙面上でマーキングとメモを書き込むことを推奨する。

2.4　解析の作業環境と集中時間の確保

複雑なマクロの構造を解読するためには、集中できる時間と場所が必要である。おすすめは、カフェや図書館など、適度な雑音がありながら集中できる環境である。一般的には、まとまった時間を取って一気に進めるほうが理解が深まりやすい。たとえば、スターバックスで5時間程度こもって取り組むことで、大まかな構造把握とメモ書きが完了する。日常業務と切り離した時間の確保が解析成功の鍵となる(言うまでもなく、お店に迷惑をかけないことが前提)。

第3章　全体概要図を描く

3.1　入力ファイル・出力ファイル・シート・テーブルのリストアップ

マクロ解析の出発点は、「何を入力として受け取り、何を出力として生成しているのか」を明確にすることである。これにより、コードを読まずとも処理の全体像を想定できる。具体的には、CSVやExcelファイルなどの外部ファイル、対象となるブックやシート、Excelのテーブル（ListObject）などの構造を洗い出す。名前定義や設定用のシートもこの段階でリストアップする。これらの「モノ」がすべての処理の前提である。

3.2　グローバルオブジェクトを中心に構成する

解析において重要なのは、局所的な処理ではなく、グローバルに参照されるオブジェクトの把握である。ここでいうグローバルオブジェクトとは、上記に加えてマクロ内の複数の関数で使用される共通のデータ構造やシート、配列などを指す。これらは処理の中核をなすため、優先的に図に配置し、後から関数の解析を進める際の参照軸となる。処理の流れは変わっても、オブジェクトは変わらないことが多いため、軸として非常に有効である。

3.3　オブジェクト間の関係を図で整理する

リストアップされたオブジェクトをノート上に配置し、変換の流れを実線でつなぐ。たとえば「CSVファイル → 配列 → 加工済み配列 → シート出力」といった具合に、処理の道筋を視覚的に描写する。この図は「データの変形の地図」となり、どの処理が何を変形しているかを俯瞰する助けとなる。必要があれば、制御フロー（フラグ設定やループ制御など）を点線で書き込んでもよい。

3.4　業務フローや運用画面の情報を加味する

もし業務フロー図や操作マニュアル、実際の運用画面が存在する場合は、それを元に「なぜこのマクロが存在するのか」「どこで呼び出されているのか」といった背景情報を補完する。業務の目的とデータの変化をつなげることで、コードの意図や前提が見えてくる。マクロは業務の反映であり、処理単体ではなく業務との接点を意識することで、より深い理解と意味づけが可能になる。

第4章　データの流れを書き込む

4.1　データフローと制御フローの違い

マクロ解析においては、処理の「流れ」を把握することが鍵となる。ただし、「流れ」には大きく2種類ある。1つはデータがどのように形を変えて流れていくかを表すデータフロー、もう1つは条件分岐やループなどによって制御が移動する制御フローである。多くのマクロにおいて本質的なのは、どのようにデータが入力され、加工され、出力されるかというデータの変形過程であり、制御の流れはその補助にすぎない。よって、まずはデータフローを中心に図示するべきである。

4.2　矢印・点線・補助記号の使い方

データの流れは実線の矢印で表す。例えば、「CSV → 配列 → 加工配列 → 出力シート」というように、一方向に流れる変形過程を矢印でつなぐ。制御フローについては、たとえば処理の分岐条件やフラグの制御などを点線の矢印で示すと、見分けがつきやすくなる。補助的な注記（例えば「ここでフィルタ処理」「ここで集計」など）は、吹き出しや枠付きコメントとして記載すると、図全体の可読性が高まる。

4.3　関数が変換に使われている箇所を追記する

各データ変形の矢印の上には、それに関与する関数名を追記する。たとえば「配列 → 加工配列」の矢印に「TransformArray」などの関数名を書き込むことで、その関数の役割が一目でわかるようになる。関数の解析が完全でなくても、わかる範囲で仮の名称でも構わない。後で訂正できるように鉛筆やフリクションボールなどを使って柔軟に記述する。この段階で関数の責務が明確になり、不要な処理や重複処理の発見にもつながる。

4.4　関数の責務をラベリングして整理

関数名に加え、その関数が何をしているかを簡単なラベルで書き添えると、理解が格段に進む。例えば「集計」「変換」「結合」「抽出」「書き込み」などの単語で十分である。これにより、同じような処理を行う関数がどこにどのように配置されているかが可視化され、構造的な偏りや設計思想を読み取るヒントになる。関数を通じて、どのデータがどのように扱われているかを言語化し、責務の一貫性や分離性も確認することができる。

第5章　関数木を構築する

5.1　関数の呼び出し構造を調べる方法

関数木とは、関数がどの関数を呼び出しているかを階層的に表現した図である。これを構築することで、マクロ全体の構造や処理の流れが視覚的に把握しやすくなる。まずは、マクロ内で最も外側（起点）となるプロシージャや関数を探す。SubまたはFunctionの中で、他のプロシージャを呼び出している箇所を探し、呼び出し元・呼び出し先の関係を線でつないでいく。VBEの検索機能や、AIを用いた関数抽出も有効であるが、初学者はまず手作業で全体感を掴むのが望ましい。

5.2　トップ関数からの分解

マクロ全体を統括する「トップ関数」から処理がどのように分割されていくかをたどる。このとき重要なのは、一段下の関数が何を担当しているかを明確にすること。トップ関数の中で「初期化」「データ読込」「加工」「出力」といった責務が順に呼び出されていれば、それぞれの中身をさらに掘り下げていく。階層が深くなっていく場合は、関数の再利用や分離がうまく行われている可能性があり、設計の良し悪しを見極める視点にもつながる。

5.3　手書きでの階層構造の記録と補足

関数木の作成はノートへの手書きが推奨される。関数名をノードとして記述し、呼び出し関係を線でつなぎ、上から下へ処理の流れを視覚化する。わからない関数名や、実装されていない関数については「？」などの補助記号を用いて保留しておく。関数ごとに簡単なラベル（例：「読込」「加工」）を付記すると、後から全体を見返したときに理解が早まる。必要に応じてページをまたいで展開する構造もよい。

5.4　関数木と全体概要図の連携

関数木と第3章で作成した全体概要図を対応づけることで、マクロの「データ」と「処理」の関係が明確になる。たとえば、「CSV読込 → 配列変換 → 加工 → シート出力」という流れが、関数木とデータフローの両方に現れていれば、理解が統合される。関数木に現れる関数を、概要図の矢印や変換点に書き加えることで、二つの図がリンクし、解析の正確性と網羅性が大きく向上する。これにより、処理の重複や見落としの検出も容易になる。

第6章　関数木と概要図の照合

6.1　関数木をもとに全体概要図を補強する

第5章で構築した関数木は、全体概要図をさらに豊かにする材料となる。関数木に登場する関数を再度確認し、それぞれがどのオブジェクトに関与しているかを全体概要図に書き込んでいく。関数木と概要図の情報を相互参照することで、関数がどのようなデータを扱い、どの段階で処理されているかが明確になる。特に、関数が複数のデータオブジェクトにまたがって作用している場合、それを図に反映させることで、処理の全体的な見通しがよくなる。

6.2　データ変換の中心となる関数を明示

データの変換点、すなわち配列やシートの加工・変形を担っている関数は、処理の中核を担っている。これらの関数を全体概要図上に明確に記述することで、「この関数が何をしているか」が視覚的に一目で把握できるようになる。例えば「LoadCsvData」「TransformArray」「OutputToSheet」などの名前が図上に登場すれば、コードを読まずとも処理の流れが把握できる。こうした中心的な関数は、解析において特に注意深く取り扱うべき対象である。

6.3　機能単位ごとの構成要素の再整理

関数木と概要図を照らし合わせることで、機能のまとまりが浮かび上がる。たとえば「初期化」「読込」「変換」「出力」「集計」といった処理ブロックごとに関数を再整理し、構成要素を分類してみる。これは、既存マクロの設計意図を読み取る手がかりになると同時に、後のリファクタリングや再設計にも役立つ。分類にあたっては、関数の命名や位置関係、引数の性質などからヒントを得るとよい。

6.4　見落としがちな処理ルートの発見

関数木と概要図を照合することで、コード中で扱われているが図に現れていない処理ルートが浮かび上がることがある。例えば、一部の関数がデバッグ用途でのみ呼ばれている、特定条件下でのみ実行される分岐処理が存在するなど、通常の処理フローでは把握しづらい構造が明らかになる。これらの“見えないルート”は不具合や仕様漏れの原因となりうるため、特に注意して拾い上げ、図に反映させることが大切である。

第7章　個別関数の詳細解析

7.1　関数単位にコードをGPTで説明させる

関数の構造や処理内容を詳細に理解するためには、関数単位でコードを切り出し、GPTなどのAIに解説を求めることが有効である。特に初見のマクロや複雑なロジックに対しては、処理の目的や引数の役割、返り値の意味などを明確に説明してもらうことで、理解のスピードと正確性が大きく向上する。入力の際は関数名・引数・戻り値を含めて関数全体をコードから抜き出し、「この関数の説明書を作ってください」と依頼すればよい。

7.2　REMコメント形式の関数IFの作成

AIから得られた説明をそのまま終わらせず、VBA標準のREMコメント形式に変換し、関数の冒頭に貼り付けておくと、将来的な保守や共有時に非常に役立つ。具体的には、関数の概要、引数の説明、戻り値の型と意味、副作用の有無などを整理して書く。例：

このようなスタイルで統一することで、関数単位での理解が深まると同時に、チーム共有にも強くなる。

7.3　複雑なロジックの可視化（蛍光ペン＋定規）

ループが多重になっている関数や、条件分岐が深い関数については、紙に印刷したコードに蛍光マーカと定規を使って解析するのが有効である。条件式の流れを色分けしたり、関数内の処理ブロックに枠を引いたりすることで、視覚的に構造が見えてくる。特にFor〜NextやDo〜Loop、If〜ElseIf〜End Ifの構造は、手書きで整理することで頭に入りやすくなる。必要であればフローチャートに落とし込んでもよい。

7.4　関数の責務と抽象度の見直し

関数の内容が把握できたら、その関数が適切な粒度で責務を持っているかを評価する。1つの関数で複数の役割を果たしている場合は、責務が分割されていない可能性が高く、再設計の余地がある。逆に、汎用的すぎて実体のない関数になっている場合は、抽象度が高すぎて理解や再利用が困難になる。適切な抽象度とは、他の関数と連携して機能を果たしつつ、内部の処理が1つのまとまりとして説明できる状態である。責務と抽象度のバランスを見直すことで、マクロ全体の品質が向上する。

第8章　関数名・変数名・引数名のリテラシー

8.1　関数名から機能を読み取る技法

関数名はその関数の責務を表す最も直接的な手がかりである。良い関数名は、何をする処理かをひと目で想起させる。例えば「LoadCsv」や「ExportResultToSheet」は、処理対象と方向性を明示している。命名が曖昧である場合は、その関数が適切に責務分離されていない可能性がある。マクロ解析においては、関数名を見ただけで「何をする」「何を使う」「何を返す」が推測できるかを確認し、機能を読み解く第一歩とする。

8.2　引数の具象性・抽象性と命名規則

引数には、呼び出し元から渡す「実引数」と、関数側が受け取る「仮引数」がある。実引数は具体的な値やオブジェクトを持ち、仮引数はそれを抽象的に受け取るという違いがある。命名においてもこの区別を意識することが望ましい。たとえば売り上げ日付から入金日を求める関数では、実引数は「FruitSalesData」、仮引数では「pSalesDate」や「aSaleseData」のように、スコープの違いを接頭辞や命名パターンで表現することにより、関数の入出力の役割が明確になる(実引数は呼び出し側で使用される具象的な変数、仮引数は様々な実引数を代表する抽象的な変数なので、実質的なグローバル変数を受け渡す場合を除き同じ名前にはできないし、するべきでもない)。

8.3　仮引数にa_やp_をつける意味

仮引数の変数名に「a_」（argument）や「p_」（parameter）といった接頭辞をつけることは、コードの可読性を高めるうえで非常に効果的である。特にVBAでは引数の型が動的になりがちなため、命名規則によって「これは関数の引数である」という役割を明示するのが有効である。これは義務ではないが、チームでの運用や将来の保守性を考えると、習慣化することを推奨したい。なお、他人のコードではこの命名が省略されていることも多く、その場合は注意深く読み取る必要がある。

8.4　命名規則から逆算する開発者の意図

関数名、変数名、引数名には、開発者がその処理に対して持っていた設計意図が滲み出る。命名は「何を大事にしているか」「何に着目して処理を書いているか」を読み取る鍵である。たとえば「CleanUpTempData」という関数名には、「一時データを消去する」という処理目的だけでなく、「これは処理の最後に呼ばれるべき補助関数である」という暗黙の前提が含まれているかもしれない。マクロ解析においては、命名から開発者の思考の流れを逆算し、コードの意図を掘り起こす姿勢が重要となる。

第9章　巨大マクロの抽象化と分割思考

9.1　1万行超のマクロの分割単位

実務では、1万行を超えるような大規模マクロに出会うこともある。こうしたコードは1つの関数やモジュールで構成されていることもあり、全体を一望することが難しい。まずは構造の見通しを得るために、大まかな処理ブロック単位で分割を試みる。たとえば「初期化処理」「読込処理」「変換処理」「出力処理」といった単位でコードを物理的に分け、各セクションに見出しや仮ラベルをつける。分割は仮で構わないので、まず“分けてみる”ことが重要である。

9.2　機能のまとまりに名前をつける

処理を読みながら「この一連の流れは何をしているのか？」を自問し、それにふさわしい名前を与えることで、意味的な塊として再編成できる。これは小さな設計行為であり、マクロの抽象化に不可欠なステップである。名前をつける際は、「集計処理」「エラー補正」「書式設定」など、業務寄りかつ機能的な表現が望ましい。名前をつけた処理は、将来的に独立した関数として切り出すことも視野に入れるとよい。

9.3　「これは○○である」と断言する技術

マクロ解析においては、ある処理が「これは○○である」と明確に言い切れるかどうかが理解の深度を測る指標になる。「たぶん○○っぽい」ではなく、「これはCSVを読み込んで配列に変換する処理である」と断言できるようになれば、そこに関数名を与え、再利用・再設計への第一歩が踏み出せる。断言するためには、処理の目的、入出力、前提条件を意識して読み解く必要がある。この技術は構造把握の核となる。

9.4　関数のグルーピングと意味的再編成

複数の関数や処理が同一目的のために連携している場合、それらを「グループ」として捉え、意味的なまとまりとして整理する。たとえば、「データの読み込み」に関する関数、「レポートの書式整形」に関する関数などをカテゴリ化することで、コード全体の構造が見やすくなり、理解や改修の単位も明確になる。マクロの後半でよく見られる「補助的な関数の寄せ集め」も、再整理することで意味のある構造として再構築できるようになる。

第10章　AI支援と人間の作業の分担

10.1　AIで行うべきこと／避けるべきこと

AI、とくにGPTのような生成系AIは、マクロ解析における補助役として極めて強力である。たとえば、関数の要約、処理の説明、命名規則の推察、コードの整形など、局所的で形式的な作業において高いパフォーマンスを発揮する。一方で、全体構造の判断、業務上の前提条件の理解、ドメイン固有の知識の適用など、文脈依存性の高い判断や設計的解釈は、依然として人間の領域である。AIの得意・不得意を見極めて役割分担を明確にすることが、成功のカギとなる。

10.2　GPTへの入力例とプロンプト設計

AIを活用するうえで重要なのが、適切なプロンプト設計である。たとえば関数の説明が欲しい場合は、「以下のVBA関数について、引数と戻り値を含めた関数の説明書をREMコメント形式で出力してください」と具体的に依頼する。プロンプトに「目的」「形式」「対象」を明示することで、出力結果の精度が大きく向上する。曖昧な指示では抽象的な説明しか得られないため、プロンプトは設計の一種と心得るべきである。

10.3　AIが得意な説明と不得意な判断

AIは構文レベルでの読み取りと文法的な説明を得意とする。たとえば、「この関数はCSVを読み込んで、配列に変換する処理です」といった機械的な構文理解は極めて正確である。一方で、「この関数がなぜこの位置で呼ばれているのか」「処理の目的に照らして適切かどうか」といったコンテキストに根ざした判断は不得手である。また、間違っていても流暢に語るため、誤った説明をそのまま信じないリテラシーも求められる。

10.4　AIを活かすための人間の構造化作業

AIを効果的に活用するには、人間が構造を把握し、指示を設計できる状態にあることが前提となる。コードのどの部分を切り出すか、どのような順序で説明を求めるか、何を理解したいのかを明確にすることで、AIの出力が価値ある情報となる。逆に、構造が曖昧なままAIに頼ると、断片的で一貫性のない出力に振り回されることになる。AIは「賢い助手」であり、道筋を決めるのはあくまで人間である。構造化こそが、AIを使いこなすための鍵となる。

第11章　成果物のまとめとドキュメント化（参考、通常は行わない）

11.1　関数IF、関数木、全体概要図の清書

マクロ解析の成果物は、ラフな作業記録にとどまらず、他者に伝えるためのドキュメントとして整える必要がある。特に、関数ごとのIF（仕様書）、関数木（処理の構造図）、全体概要図（オブジェクトとフローの関係図）は、三位一体で全体像を伝える中核資料となる。手書きのものでもよいが、可能であればデジタル化し、簡潔で明確な体裁に整えることで、後から参照しやすくなる。

11.2　解析ノートの整形とPDF化

解析作業で用いたノートは、内容が正しくても読みづらければ意味が半減する。ノートの情報は、章立てや分類を見直しながら再構成し、清書することが望ましい。紙で残してもよいが、推奨されるのはPDF化して保管・共有する方法である。スキャンや写真のPDF化、あるいはWordなどで再作成してもよい。特に手書きの全体図・関数木・コメントなどは画像として添付しておくと、文脈の把握に役立つ。

11.3　開発者／保守者への引き継ぎ資料の構成

解析結果は、**実際に使う人（後任者、別チームの保守担当者など）**にとって意味が通る形で構成しなければならない。推奨される構成は以下の通り：

• 全体概要図（処理対象と変換関係の可視化）

• 関数木（機能構造の階層表示）

• 関数IF（主要関数の仕様・引数・戻り値など）

• 説明コメントの一覧（特記事項や例外処理の説明）

• 処理ブロック単位のサマリ（初期化／出力／集計など）

ドキュメント化においては、「このマクロは何をしているのか」「どの関数を触ればどこに影響するか」が読み取れることを最優先する。

11.4　再利用・拡張のための文書化の工夫

マクロは「読み捨て」のツールではなく、再利用や拡張を前提とすることで、資産化されていく。そのためには、解析結果を単なる報告書にとどめず、「この関数は他の案件でも使える」「この部分はモジュール化できる」といった視点で文書を補足するとよい。再利用しやすいコードは、解析ドキュメントと併せて再構成しておくと、次のプロジェクトでも価値を発揮する。これは解析を超えた“育てる設計”である。

第12章　まとめと今後の展望

12.1　マクロ解析で身につく実践的設計力

本書で紹介したマクロ解析のプロセスを通じて得られる最大の成果は、実践的な設計力である。既存のコードを「読む」だけでなく、「構造として理解し、再構成し、説明できる」ことは、そのままシステム設計力に直結する。特に、構造化、責務分離、抽象化といった考え方は、マクロに限らずあらゆるプログラミング・業務設計に応用可能な普遍的な技術である。解析経験は、設計能力の裏付けとして強力な武器となる。

12.2　データ設計／フロー設計の視点獲得

マクロ解析では、「何が入って、何が出るのか」「どこでどのように変換されるのか」を明らかにする。その過程で培われるのが、データ設計とフロー設計の視点である。これは、単なるコーディングスキルとは異なり、業務の本質に迫るための重要な力である。実際、企業内ではコードの整合性よりも、出力結果の正しさと手順の透明性が求められる場面が多い。この視点を身につけることで、業務要件と技術の橋渡しができる人材となれる。

12.3　ノーコード時代への応用可能性

ノーコード／ローコード開発が普及する中で、VBAやExcelマクロのようなスクリプト型ツールの役割は変化しつつある。しかし、ノーコードであっても本質は「構造」と「流れ」であり、マクロ解析で得られたスキルはそのまま応用できる。たとえばPower AutomateやAirtable、AppSheetなどを扱う際にも、「全体構造を図解する」「処理の流れを見通す」「処理単位を意味で分割する」といった思考は変わらず必要である。マクロ解析の訓練は、将来のノーコード時代を生き抜くための基盤になる。

12.4　教育・研修での活用方法と展望

本手順書は、単なる自己学習のためだけでなく、新人教育や業務引き継ぎ、社内研修の教材としても有効である。属人化されたマクロを可視化し、共有可能な形式に落とし込むことは、組織全体のスキル平準化に貢献する。今後は、本書の内容をベースにしたワークショップや、実案件に即した演習形式の研修も展開可能である。また、GPTなどのAIと組み合わせることで、実践とテクノロジーを融合した次世代の教育カリキュラムにも応用できるだろう。