誰も管理していないAccessファイルが基幹システムになっていた話（野良Accessの収拾）

Access魔宮の引き継ぎ

引き継ぎの共有フォルダを開いた瞬間、嫌な汗が背中を伝った。そこにあったのは「売上管理_最新版_絶対消すな.accdb」という。たった一つのファイルである。操作手順が書かれたWordファイルもなければ。システムの全体像を記した構成図も見当たらない。頼みの綱である前任者は、すでに先月末で退職してしまっている。

異動初日。担当部署のリーダーから「毎朝このAccessのボタンを押して売上を更新してね」とだけ言われた。言われた通りにボタンを押すと。マウスポインタが砂時計アイコンに変わったまま30分間フリーズした。タスクマネージャーから強制終了すべきか、それとも待つべきか激しく葛藤する。冷や汗でマウスが滑り、胃がキリキリと痛む中。ようやく「処理が完了しました」というそっけないメッセージが出た時の疲労感は。今でも忘れられありません。

便利ツールから魔宮へ：会社の命運を握る野良DB

まず、ファイルの中身を覗くと、数万件のデータが詰まったテーブルがいくつも転がっていた。これが会社の屋台骨である売上集計を根底から支えているという事実に、目眩を覚える。もしこのファイルが壊れたら、明日の朝から営業部への報告が止まり。経理の請求書発行も完全にストップする。たった一つの野良データベースが、会社の首根っこを完全に掴んでいた。なぜこんな危険な状態になるまで誰も止めなかったのか。原因は極めてシンプルだ。最初はただの「便利なツール」として生み出され。周囲がそれに甘え続けた結果にすぎない。情報システム部門の管轄外でひっそりと育ったこのツールは。もはや誰も全容を把握できない巨大な魔宮と化していた。

野良DBの発生パターンとブラックボックス化

野良DBが誕生する背景には、決まったパターンが存在する。最初はExcelの延長線上にすぎなかったのだ。現場の担当者が。ExcelのVLOOKUP関数やマクロでは処理しきれなくなった膨大なデータを扱うために。手元のPCにインストールされていたAccessに目をつけたのです。

Excelのシートが約50万行を超えたあたりで頻繁にフリーズするようになり。前任者はAccessが持つ理論上の最大容量である2GBという上限に希望を見出したのだろう。Accessは確かに強力なツールだ。テーブルをリレーションシップで繋ぎ、クエリを組めば。Excelの何倍もの速度で集計が終わる。フォーム機能を使えば、それらしい入力画面も簡単に作れてしまう。前任者は善意でこの仕組みを作り上げ。周囲の同僚たちも「ボタン一つで終わるなんて魔法みたいだ」と称賛したに違いありません。

属人化が招くブラックボックス

しかし、ここに大きな落とし穴があった。システム構築の専門知識を持たない人間が作ると。設計図という概念が完全に抜け落ちる。要件定義も設計書もないまま、その場しのぎの機能追加が延々と繰り返されていくのだ。データベース設計の基本である正規化は無視され。同じような顧客データが複数のテーブルに散在する。動作が遅くなれば、根本的なインデックスの最適化を行うのではなく。結果を一時テーブルに書き出す強引なマクロで解決を図ろうとする。こうして、作った本人にしか分からない複雑怪奇な依存関係が形成されていく。そして本人が退職した瞬間。会社に残されるのは中身の見えない巨大なブラックボックスだけになる。

泥沼クエリとVBA、謎解きの考古学者

絶望していても明日の業務はやってくる。腹を括って解読作業を始めるしかなかった。ナビゲーションウィンドウを開くと。そこには100個以上のクエリがずらりと並んでいた。どれが本番で使われているのか全く分からない。さらに悪いことに。処理の核心部分が書かれているはずのVBAにはパスワードがかけられており。中身を見ることすらできなかった。

クエリ群を一つずつ開いて解読しようとしたが。「Q_集計_旧」「Q_集計_最終_2022」「Q_集計_決定版_コピー」などの無秩序な命名規則に心が折れかけた。どのクエリがどのテーブルを参照しているのか、手作業で紐解くのは狂気の沙汰である。仕方なく、クエリをSQLビューに切り替え。そのテキストをエディタに貼り付けてテーブル名を正規表現で検索するという泥臭い作業を繰り返した。依存関係を一つずつ紙に書き出していく過程で。半分以上のクエリが数年間一度も使われていない「ゴミ」であることが判明した時の徒労感は筆舌に尽くしがたい。

VBAパスワード回避、ログと監視でシステムの深層解明

次に、VBAのパスワードについては、非公式なツールでこじ開けるリスクは取れなかった。代わりに取ったアプローチは。テーブルの更新ログとクエリの実行結果から「裏で何が起きているか」を推測することだった。フォームのボタンを押した瞬間にどのテーブルのタイムスタンプが更新されるかを監視し。データの流れを外側から観察する。まるで未知の古代遺跡を調査する考古学者のような日々が続いた。

野良DB管理の初動

全体像がぼんやりと見えてきたら。システムが完全に崩壊する前に手を打たなければならない。最初に行うべきは、何よりも確実なバックアップの確保である。ファイルサーバー上で単にファイルをコピーするだけだが。これがないと何も始まらない。かつて、バックアップを取らずに不要なテーブルを削除した直後。メインの集計フォームが「参照エラー」を吐いて全く動かなくなり。血の気が引いた経験がある。あの冷や汗を二度とかかないためにも、毎日の自動バックアップは必須です。

次に、解読作業で見つけた「使われていないオブジェクト」を隔離する。削除するのはまだ怖いので。オブジェクト名の上に「z_」というプレフィックスをつけてナビゲーションウィンドウの下部に追いやる。これだけでも視界が劇的にクリアになる。

Access DB分割で管理と安定

一方で、そして、実務上で最も効果が大きかったのが、テーブルとフォームの分割である。Access特有の脆さは、データと画面が同じファイルに同居している点にある。複数のユーザーが同時にファイルを開くと。ロックファイル（.laccdb）が生成される。この状態でネットワークが瞬断すると。ロックファイルが残ったまま本隊のファイルが破損するという致命的な弱点があるのだ。これを防ぐために、データだけを持つ「バックエンドファイル」と。画面やクエリだけを持つ「フロントエンドファイル」に分割し。リンクテーブルで接続する。この分割処理を行った結果。共有フォルダ上を飛び交うネットワークトラフィックが体感で約40%削減され。複数人での同時操作時のフリーズも劇的に減少した。

最後に、これまでの解読結果をExcelやWikiにドキュメントとして残す。これでようやく、野良DBは最低限の「管理下」に置かれたことになる。

Accessの限界、…

【スクショ：VS Codeの画面。PythonのPandasを使ってAccessのデータをSQL Serverに移行するスクリプトが書かれている。dark theme UI mockup style】

そのため、応急処置が終わった後、冷静に未来を考える必要がある。このままAccessを延命し続けるのか、それとも別のモダンな技術へ移行するのか。Accessは手軽だが、やはりファイル共有型データベースの限界は避けられない。データ量が増え続ければ、いずれ2GBの壁に再び激突する。

根本的な解決を目指すなら、データと処理の完全な分離が不可欠だ。データの保存先をAccessからSQL Serverやクラウド上のデータベース（PostgreSQLなど）に移行する。そして。データの集計や加工といったロジックの部分をPythonのスクリプトに置き換えるのだ。PythonのPandasライブラリを使えば。Accessの複雑なクエリで行っていたデータ結合や集計を。数行のコードで遥かに高速に処理できる。

移行投資、計り知れない価値

移行には当然コストがかかる。既存の100個のクエリとマクロのロジックをPythonとSQLで書き直すのに。専任の担当者が付きっきりで約150時間の工数を要すると試算された。しかし、毎朝30分間フリーズするAccessを祈りながら見つめる時間と。ファイル破損時の復旧作業にかかる見えないコストを考えれば。この投資は確実に回収できる。何より。コードとして処理を記述することでGitなどのバージョン管理システムが使えるようになり。「誰がいつ何を変更したか」が完全に追跡可能になるメリットは計り知れありません。

システム負債の解体と整理

しかし、【スクショ：整理整頓されたクリーンなデスクトップ画面。不要なショートカットが消え、新しいシステムのダッシュボードが開かれている。realistic photo style】

誰も管理していないブラックボックス化したシステムは、会社にとって時限爆弾である。前任者を責めても何も解決しない。彼らもまた、その時の最善を尽くして業務を回そうとした結果。技術的負債を抱え込んでしまっただけなのだ。肝心なのは、その負債から目を背けず、正面から解体していく勇気を持つことです。

業務改善に魔法のツールは存在しない。泥臭い解読作業と、地道な整理整頓の積み重ねだけが。属人化という重い鎖を断ち切る唯一の手段である。マニュアルなし、前任者不在という絶望的な状況からでも。順序立ててアプローチすれば必ず道は開ける。未来の担当者に、自分が味わったあの胃の痛むような思いを二度とさせないために。今こそ、野良データベースに立ち向かう時です。

関連リンクとチェックリスト

学習サービスとアンケート