中間データ設計論

～Excelマクロ開発と業務設計における橋渡し～

第1章　はじめに

1.1 本レポートの目的と背景

本レポートは、Excel VBAを用いた業務システム開発や業務マクロ設計における「中間データ」の意義とその設計方法について、体系的に論じるものである。中間データは、単なる一時ファイルや作業用シートとして軽視されがちであるが、実際には再現性・保守性・透明性といった品質属性を根本から支える設計上の重要構成要素である。

プログラムの計算過程において生成される中間結果を、明示的かつ構造的に「中間データ」として定義・管理することで、以下のような利点が得られる：

複雑なロジックの段階的可視化
不具合のトレースや原因分析の容易化
テストケース設計の基盤強化
非エンジニアとの業務的整合性の担保

中間データは、単なる出力ではなく、「プロセスの節点（ノード）」として、関数や業務手順のあいだに論理的構造を与える役割を果たす。こうした観点をもとに、中間データを「設計対象」として明示的に扱い、正しい構造と運用のあり方を検討するのが本レポートの目的である。

1.2 対象読者と適用領域

本レポートの対象読者は以下のとおりである：

Excel VBAで業務マクロを構築する開発者
入力・出力の検証と業務処理の整合を求められる業務SE
単体テストや工程内レビューを重視する開発リーダー
設計書と実装の乖離を減らしたい設計者・文書管理者

また、適用領域はExcelマクロ開発にとどまらず、CSVファイルによるデータ加工、スクリプト系バッチ処理、データフロー設計一般に及ぶ。

1.3 中間データの再定義

本レポートで扱う「中間データ」は、単なる一時変数やログファイルとは異なる。明示的に加工・出力され、次の工程の入力として再利用可能であることが前提である。つまり「中間データ」とは、計算プロセスの透明性を高め、かつ後続処理に対して汎用的なインターフェースを提供するものである。

たとえば、A関数 → B関数 → C関数という階層的構造を持つ処理において、B関数が中間データを出力し、それを後続のC関数だけでなく、別系統のX関数・Y関数も参照できるとすれば、B関数の出力は単なる中継点ではなく、「共通の整形済みデータ」としての役割を果たす。これは「パイプライン構造」や「関数木構造」の実装上の中核を成す。

よって、中間データの設計は単なる手続きの中間生成物ではなく、構造設計そのものであり、業務ロジック、関数構造、DFD、そして業務フロー設計すらつなぐ「構造的ハブ」として位置づけるべきである。

第2章　中間データとは何か

2.1 中間データの定義と役割

中間データとは、処理の途中で生成されるデータであり、最終出力を目的とせずとも、次の処理段階への橋渡しとなる情報である。それは計算ロジックの過程であり、結果の積み重ねでもある。Excel VBAにおいては、シートに書き出される加工済みデータが中間データとして機能し、再計算・検証・可視化に用いられる。

役割としては以下が挙げられる：

各処理段階の状態を「保存」するログ的役割
後続処理への入力としての橋渡し（インターフェース）
複数出力系処理での共有ベース
ユーザ・開発者間のコミュニケーションの媒介

2.2 中間データの分類：キャッシュ／ログ／構造変換／検証点

中間データはその機能・目的により、次のように分類される：

キャッシュ型：時間のかかる処理を一度実行して保持するための一時保存用。再利用性と効率向上が主目的。
ログ型：処理ステップの履歴を保持し、後からトラブルの原因分析や監査に活用する。
構造変換型：入力データの列構造や型を業務処理向けに変換したもの。データクレンジングや整形もここに含まれる。
検証点型：テストの際に比較対象として使われる基準値や中間結果の記録。ユニットテストや差分チェックに重要。

これらは混在することも多く、適切な目的意識と命名・管理が重要である。

2.3 データ流と処理構造の関係性

中間データは「データの流れ」を明示することにより、「処理構造」を自然に設計する手がかりとなる。たとえばDFD（データフロー図）におけるノード同士の矢印が中間データを意味しているように、各処理は「何を受け取り、何を出すか」で設計される。マクロ設計においても、

中間データがなければ関数同士の直接呼び出しが密結合になる
中間データを介在させることで、関数が疎結合になり、独立性・テスト性・再利用性が向上する

また、業務設計者が処理のステップ間でどのようなデータが必要なのかを理解し、プログラマに伝えるうえでも、中間データはコミュニケーションの可視化手段となる。

第3章　中間データがもたらす価値

3.1 可視化とトレーサビリティ

中間データは、システム内部の処理過程を可視化する最も有効な手段である。通常、最終出力からは処理の途中段階や条件分岐の履歴は見えないが、中間データを記録することで、「なぜこの結果になったのか」が明らかになる。トレーサビリティの確保は、業務監査、障害解析、改善活動にとって不可欠であり、中間データはその基盤として機能する。

例えば、入力ミスにより集計結果が異常値を示した場合、入力→変換→集計の各段階の中間結果が残っていれば、どこで問題が発生したのかを迅速に特定できる。

3.2 保守性・再実行性の向上

中間データを設計的に分離・記録しておくことは、ソフトウェアの保守性を大きく高める。特にExcelマクロにおいては、実行時の一過性の処理が多く、再現が困難になることが少なくない。中間データを活用することで、処理途中の状態を保持でき、部分的な再実行や再テストが可能となる。

また、処理全体をやり直すことなく、途中の中間データから再処理を行える設計は、システムの耐障害性と作業効率の両立にも寄与する。

3.3 非エンジニアとの共有性

中間データがシートやCSVといった人間可読な形式で出力されることで、非エンジニア（業務担当者、品質管理者など）との情報共有が可能となる。処理の「ブラックボックス化」を避け、処理の段階的な挙動を共有・検証できるため、開発と業務の間の断絶を埋める手段となる。

たとえば、処理前後のデータを比較することで、業務担当者が業務ロジックに適合しているかを自ら確認できるようになる。

3.4 処理ロジックの“物的証拠”としての中間データ

システムが「何をしたか」を証明する唯一の手段が中間データである場合も多い。特に、外部監査や説明責任を求められる場面においては、ログファイルや中間シートが“物的証拠”としての役割を果たす。

マクロなどのスクリプト系処理はログ出力を標準で持たないことも多いため、中間データを明示的に出力する設計は、品質保証や監査対応の観点からも極めて有効である。

第4章　中間データ設計の基本原則

4.1 入力データの非破壊原則

中間データを設計に取り入れるうえでまず守るべき原則が、元データの非破壊性である。入力されたデータを直接上書き・削除してしまうと、誤操作やバグ発生時のリカバリが困難になる。中間データは、この非破壊性を維持しながら処理を進めるための“バッファ”として機能する。

元データは常に読み取り専用とし、すべての加工・集計処理は中間シートや別ファイル上で実施する。これにより、万が一不具合が発生しても、初期状態への復元が容易になる。

4.2 処理段階の分割と明示的なデータ遷移

複雑な業務処理を一括で実装することは、バグの温床となり、また再利用性や保守性も損なう。中間データを使って処理を「段階的に切る」ことで、各段階の責任が明確化され、設計も洗練される。

例えば、「元データ → 整形 → フィルタリング → 集計 → 出力」という5段階の処理を、それぞれ中間シートに出力しながら実施することで、どこでミスが起きているのかを逐一確認できる。また、各ステップの処理単体を再実行・再利用することも容易になる。

4.3 ファイル構造とシート設計：名前規則とスナップショット設計

中間データを用いる場合、シートやファイルの構成設計は極めて重要である。まず、シート名・ファイル名には処理段階や日付・バージョン番号などを明示し、処理内容や作成日時が一目でわかるようにする。例：「tmp_整形_20240506」「snap_集計_v2.xlsx」など。

また、スナップショット設計とは、ある処理段階での出力結果を履歴として保存しておく設計思想である。上書き保存ではなく、「保存してから次へ進む」という運用を取り入れることで、原因追跡・監査証跡・デバッグの各観点で優れた利便性を確保できる。

4.4 再実行性（Idempotency）を支える中間構造

再実行性（idempotency）とは、同じ処理を何度実行しても結果が変わらない性質を指す。これを担保するためには、途中の中間データが正確かつ安定して存在していることが前提となる。

一連の処理のうち、どこかで失敗しても、直前の中間データから再実行可能であれば、システム全体の堅牢性が大きく向上する。また、処理単位でのテストや再検証も容易になる。

中間データを「再実行の起点」として位置づける設計は、業務運用の信頼性と効率を大きく高める鍵となる。

第5章　Excelマクロにおける中間データの実装戦略

5.1 中間シートを活用した段階処理モデル

Excel VBAにおける中間データの代表例が「中間シート」である。処理の各ステップごとにシートを分けて出力し、段階的にデータを確認・加工・検証していく構造は、マクロ開発におけるトレーサビリティと再現性を高める基本手法である。

例：

「Raw_Import」シート：取り込み元の生データ
「Step1_Cleansed」シート：整形・補正済データ
「Step2_Filtered」シート：フィルタリング後のデータ
「Final_Output」シート：最終出力対象

このような段階的構造により、どこで何が起きたかを人間が目視確認できる。

5.2 関数設計の分離原則：入出力と処理の三分割

関数の設計においては、「入力取得」「処理実行」「出力書き込み」を別々の役割として分けることが望ましい。この三分割原則により、ロジック部分は常に入力と出力を渡される前提で構成され、テストや再利用がしやすくなる。

Sub 実行例()

   Dim inputData As Variant

inputData = 読み込み関数(Sheet1)

    Dim resultData As Variant

resultData = 処理関数(inputData)

出力関数 Sheet2, resultData

End Sub

このように、処理の本体はデータに依存し、シート操作から切り離されていることが重要である。

5.3 データレイアウトと属性の標準化

中間シートの構造は、行列の使い方、列見出しの命名、データ型（数値・文字列・日付）などを標準化する必要がある。これにより、後続の関数が安定的に入力を読み取ることが可能になり、全体の処理連鎖の堅牢性が向上する。

例：列順・列名を固定、「YYYY-MM-DD」形式の日付表記、「null」や空白の扱いルールなど。事前定義されたスキーマに従うことで、設計ミスを予防できる。

5.4 文字コード・構造標準化・ロギング設計の基本

外部CSVなどの入出力を扱う場合、文字コード（Shift_JIS, UTF-8）、改行コード（CRLF, LF）の標準化も重要である。また、処理中に発生するエラーや異常値のログを中間シートに記録することで、動作確認や障害分析が飛躍的にしやすくなる。

' ログ出力例：処理中のエラー記録

LogSheet.Cells(nextRow, 1).Value = Now

LogSheet.Cells(nextRow, 2).Value = recordId

LogSheet.Cells(nextRow, 3).Value = "金額異常: " & 金額

このように、ログもまた中間データの一形態である。

5.5 ステップ間の責任分離とデータインターフェース化

各処理ステップの責任範囲を明確にし、入力と出力を“契約”として定義することで、処理の分担や外注、後続工程との連携がスムーズになる。中間データは、この契約のインターフェースとして機能する。

また、異なるモジュール間で中間データをやり取りすることで、モジュール同士の結合度を下げ、保守性・拡張性の高い設計が実現できる。

第6章　中間データが関数構造にもたらす構造変化

6.1 関数の入れ子構造から段階的構造へ

従来の関数設計では、関数の中にさらに関数を呼び出す「入れ子構造」が多く見られる。しかし、これはロジックの把握や保守を難しくし、バグの原因にもなる。中間データを導入することで、各関数の処理結果をシート等に出力し、それを次の処理が明示的に受け取る段階的構造へと転換できる。

これにより、関数ごとの責任範囲が明確になり、処理の流れを逐次確認できるようになる。ネストを排除した「フラットな呼び出し構造」は、シンプルで可読性の高い設計を可能にする。

6.2 ステージごとのシート出力による再利用と単体テスト性

各処理ステージで中間シートに出力することで、その時点のデータを使って次の処理を個別にテストできるようになる。これにより、関数単体でのテストが容易になり、不具合の切り分けが迅速に行える。

また、中間データが保存されていれば、後から別の用途で再利用することも可能になる。たとえば、「整形済みデータ」を他の分析ツールに投入するなどの活用が考えられる。

6.3 中間データによるパイプライン構造の実現

関数を直列に結合するのではなく、「中間データによるステージ制御」を行うことで、処理をパイプライン化できる。各関数は、決められた形式の中間データを入力として受け取り、決められた形式で出力を返す。この構造は、UNIXのパイプ処理やETLツールの設計思想にも通じる。

パイプライン構造により、各処理の独立性が保たれ、部分的な差し替えや並列処理の可能性も生まれる。

6.4 複数出力系関数にとっての「整ったデータ」としての中間点

1つの中間データを、複数の出力系関数で共通利用できる構造は、メンテナンス性と再利用性の観点で極めて重要である。たとえば、「商品別売上集計」という中間データを、帳票出力・グラフ描画・異常検知など複数の機能が参照することができる。

中間データが「整った形」であればあるほど、下流処理が自由に展開できるため、上流処理の品質がシステム全体の柔軟性に直結する。

6.5 副作用を持たない関数の設計とシート入出力の分離

関数が「実行と同時にシートを直接書き換える」ような副作用を持つと、テスト性や再現性が損なわれる。これを防ぐため、関数内部ではシート操作を行わず、データの計算・変換ロジックのみに集中させるべきである。

シート入出力は別のレイヤーで処理し、関数には純粋関数的な性質（入力に対して常に同じ出力を返す）を持たせることが、信頼性の高いシステム設計に繋がる。

第7章　中間データによる業務フロー・DFD・関数木の統合

7.1 中間データがつなぐ三つの構造（業務→DFD→関数）

中間データは、実装レベルのコード構造だけでなく、より高次の「業務フロー」や「データフロー図（DFD）」との接点も持つ。業務フローは処理の目的と順序、DFDはデータの流れ、関数木は具体的な実装単位を表すが、それぞれの間に中間データという“共通物理実体”があることで、階層を超えた設計連携が可能になる。

中間データは、業務からコードへの「橋渡し情報」として、設計者・開発者・レビューアの視点を統合する鍵を握る。

7.2 各階層における中間点の設計と意味

業務フローでは、部門間や処理単位ごとの「引き継ぎ点」として中間帳票やCSVが出現する。DFDでは、データストアやデータフローとして中間成果物が登場し、関数木では各関数の出力が次の入力となる構造を取る。

これらの中間点に対し、形式、命名、責任者、タイミングなどを設計段階で明確にすることで、フロー全体の透明性と変更耐性が著しく向上する。

7.3 マクロ内データフロー図の描き方と対応付け

Excelマクロで作成された処理フローをDFDとして視覚化する場合、各中間シートを「データストア」、各処理サブプロシージャを「プロセス」として定義する。シート間の関係を矢印で表せば、自然なDFD図となり、マクロの構造を視覚的に把握できる。

この図解によって、開発者以外の関係者（業務担当者や品質管理者）との合意形成が容易になる。設計資料としても説得力を持つ。

7.4 ドキュメント化された中間データがもたらす説明力

中間データが明示的に設計・記録されていることにより、「このデータはどこから来たのか」「なぜこうなっているのか」といった問いに文書で答えられるようになる。これはドキュメントとしての信頼性を確保するうえで非常に重要である。

また、開発時の内部レビューや外部監査、引継ぎ時の資料としても、中間データは“説明可能性”を担保する根拠となる。単に「出力が正しい」だけでなく、「正しく導かれた」ことを証明する設計思想として位置づけられる。

第8章　落とし穴とアンチパターン

8.1 中間データが肥大・複雑化するリスク

中間データは便利な半面、管理が甘ければ容易に肥大化し、逆に処理全体を複雑化させてしまうリスクを孕んでいる。特に、あらゆる処理ステップで詳細なデータを保持しようとすると、シート数やファイル数が過剰になり、メンテナンスが困難になる。

中間データは目的に応じて「何を残すべきか」「いつ破棄すべきか」を明確にする必要がある。不要な中間シートが残り続けることは、開発者だけでなく運用担当者にも混乱を与える。

8.2 保存ルールや命名規則が曖昧な設計

中間データに一貫性のないファイル名やシート名が付けられていると、バージョンの把握、更新の追跡、差し替えの判断が極めて困難になる。特に、チーム開発や長期運用を見据えた場合、命名規則や保存ルールの不備は致命的な設計ミスとなる。

適切な命名規則（例：「Step2_Filter_yyyymmdd」「temp_整形済_20250506」）を設定し、作業ごとのスナップショット管理と組み合わせることで、この問題を予防できる。

8.3 中間データが業務混乱やセキュリティ事故を招く例

中間データに個人情報や機密データが含まれている場合、それを適切に管理しなければ情報漏洩のリスクが生じる。例えば、メール添付やクラウド共有の際に誤って中間ファイルが送付されてしまうなど、想定外の二次的影響が発生することがある。

また、業務担当者が中間ファイルを「最終成果物」と誤認し、誤った判断をしてしまうこともある。このような混乱を防ぐためには、中間データの性質を明示的に区別し、設計・運用の段階でリスクを低減する仕組みを整える必要がある。

8.4 「とりあえず書き出す」中間シートの弊害

中間データは設計的に意味づけされ、管理されて初めて価値を持つ。にもかかわらず、「とりあえずデバッグ用に出しておこう」といった短期的思考で作られた中間シートが、最終的に放置・混在・誤利用されるケースは少なくない。

このような“行き当たりばったり”のデータは、後続処理の障害となり、設計の信頼性を損なう。中間シートを作る際は、目的・保持期間・責任者・命名規則を事前に定め、設計意図に基づいて制御された形で生成・保存・削除されるべきである。

第9章　発展的応用と他技術との接続

9.1 テスト駆動開発と中間データの一致性確認

テスト駆動開発（TDD）において、中間データは「処理の正しさを検証するための比較対象」として不可欠な役割を担う。期待される中間結果と実際の中間出力を比較することで、処理ロジックの一貫性を確保できる。特に、単体テストの粒度で中間データを活用することで、不具合の早期検出と修正が可能になる。

また、中間データをテストベンチと連携させれば、回帰テストやリグレッションチェックも自動化しやすくなり、長期的な品質維持につながる。

9.2 ETL／Power Queryとのアーキテクチャ的親和性

中間データを設計的に活用するアプローチは、ETL（Extract, Transform, Load）処理やPower Queryのようなデータ統合ツールとも高い親和性を持つ。これらのツールは、各変換ステップでの出力を中間段階として保持し、それぞれが疎結合な処理ブロックとして独立している。

Excelマクロにおいても、中間シートを用いた処理段階の明示と分離は、ETL的なアーキテクチャに自然と接続できる構造であり、将来的なシステム移行や他ツールとの統合を見据えた柔軟な設計を実現する。

9.3 差分データ・監査ログ・BI分析への応用可能性

中間データは、差分検出・監査証跡・分析基盤といった派生的な応用にも活用可能である。処理の前後で中間シートを比較すれば、データ更新や異常値の有無を検出する差分分析が可能になる。

また、全処理ログを中間データとして蓄積することで、後からの追跡・再検証が可能な「監査ログ」としての機能を果たす。さらに、整形済の中間出力はBI（Business Intelligence）ツールに取り込むための「クレンジング済みソース」として最適である。

9.4 中間データを通じた開発ドキュメント連携と自動生成

中間データの設計・命名・構造が明確であれば、それをもとに自動的に処理フローやDFD、関数仕様書などのドキュメントを生成することも可能となる。たとえば、シート名や列名を解析して処理ステップの図式化を行うツールや、ログ出力からエラーパターンの頻度を抽出するスクリプトなどが考えられる。

このように、中間データを「実装とドキュメントの共通言語」として扱えば、文書化作業の負荷軽減と品質一貫性の維持が同時に実現される。コードとドキュメントを並行設計する思想への発展形である。

第10章　結論：中間データという設計資産

10.1 「構造物」としての中間データ

中間データは単なる一時ファイルや検証用出力ではなく、「設計された構造物」であるべきである。その構造には、入力と出力の形式、責任の所在、再実行の起点といった設計要素が内包されている。中間データを持つこと自体が、処理の節目を明確にし、ロジックの区切りを可視化する役割を果たす。

したがって、中間データは「残すべきもの」でもあり「使われるべきもの」でもある。これを適切に設計・記録・管理することが、持続可能なシステムの基盤となる。

10.2 業務と技術を接続する役割

中間データは、業務フローと実装コードの間にあるギャップを埋める「翻訳装置」として機能する。業務担当者が理解しやすい形で処理内容を提示し、同時に開発者には形式的に整った入力・出力の制約を与える。そのため、設計レビュー・開発引継ぎ・品質保証など、様々なフェーズで中間データが橋渡しのメディアとなる。

これは技術文書でも業務説明でも同様であり、「中間にあるもの」に焦点を当てることで、コミュニケーションの軸を確立できるのである。

10.3 設計思想としての中間性：変わるものと変わらないもの

業務要件や出力仕様が将来的に変化したとしても、ステップ間の中間データ設計がしっかりしていれば、上流や下流の変更影響を局所化できる。これは、システム設計において「中間構造が安定性をもたらす」という原則を示している。

変化しやすい業務の中で、あえて中間を“固定する”という発想は、柔軟性と安定性を両立させる戦略でもある。中間データを中心とした設計は、設計思想としても優れている。

10.4 中間データが照らす設計の未来

データ駆動型の設計、分業・再利用・説明可能性を重視する開発、可視化されたプロセス指向設計。中間データという考え方は、これら新しい設計観のいずれとも親和性が高い。マクロやExcelといった一見レガシーな技術であっても、思想としての「中間点の設計」はモダンなソフトウェア工学にも十分通用する。

将来、AIによる処理生成や自動化が進むなかで、「どの段階で何が起きているか」を明示できる中間データの設計は、設計透明性の最後の拠り所となるだろう。