現場のExcel・Accessバッチはどうする — 「野良ETL」の移行戦略

サーバ一覧には載っていないのに業務を支えているもの——部門のExcelマクロとAccessです。ファイルサーバ移行やPC更改のタイミングで突然表面化し、「これが動かないと月次が締まらない」と判明する。全社移行で必ず出土するこの「野良ETL」への現実的な向き合い方を書きます。

01まず出土させる：棚卸しの仕方

野良ETLは申告されません。ファイルサーバのアクセスログから更新頻度の高い.xlsm/.accdbを機械的に洗い出し、所有部門にヒアリングするのが確実です。「そのファイルが1週間使えないと何が困るか」を聞くと、業務重要度が浮かび上がります。移行プロジェクトの序盤にこれをやっておくと、切替直前の「動かない」事故が激減します。

023分類する：廃止・延命・作り直し

• 廃止 — 作った人が異動して誰も中身を知らない・実は後継システムがある。棚卸しすると1〜2割はこれです。堂々と消しましょう
• 延命 — 業務は回っているが作り直す価値まではない。大多数がここ
• 作り直し — 全社業務に昇格している・属人化リスクが高い・データ量が限界。投資判断の対象

03延命の現実解：実行環境ごとAWSへ

延命組は「Excelのまま動く環境」をAWS側に用意します。ファイル置き場はFSx for Windowsへ、実行環境はWorkSpaces（仮想デスクトップ）へ。ファイルサーバとPCの距離が近くなるので、むしろ今より快適に動くことすらあります。マクロの中のパス直書き（\\旧サーバ名\共有）だけは一斉置換が必要——ここを漏らすと移行当日に一斉に沈黙します。

04作り直しの前に：データの正本化

作り直し組をいきなりGlueやLambdaで再実装するのは、順番が違います。野良ETLが乱立した根本原因は、正本データが配布されず、各部門が手元でコピー・加工するしかなかったことです。まず正本をS3／DWHに定め、部門が直接参照できる形（Athena・BIツール・共有データセット）を作る。それだけで「加工のためのマクロ」の大半は存在理由を失います。

05移行計画への織り込み方

野良ETLは「サーバ移行の後で考える」と後回しにされがちですが、ファイルサーバ移行・PC環境更改と依存しているため、切替日程は本体の移行と同期させる必要があります。棚卸し→3分類→延命組のパス置換計画までを、移行計画書の1章として最初から持っておくのが、事故らない唯一の方法です。