予算ゼロ・IT部門なし。ファイルサーバーにAccessを置いてExcelをフロント端末にした「野良DB」の作り方と末路

ファイルサーバーの奥底に、ひっそりと置かれた拡張子「.accdb」のファイル。最初は部門内のささやかな備品管理や。社員の交通費精算の履歴を残す程度の用途だったはずである。予算はないが、とりあえずデータを一箇所にまとめたい。IT部門に頼むと要件定義だけで半年待たされる。それなら手元のOfficeでなんとかしようと、誰かが善意で生み出した産物。これが「野良DB」の誕生の瞬間です。

便利さの罠、Excel連携の悪夢

最初は劇的に業務が楽になる。Excelから裏側のAccessにデータを飛ばす仕組みを作ると。これまで乱立していた各自のExcelファイルが一つのデータベースに統合されるからだ。現場の誰もが使い慣れたExcelをフロント端末として置き。裏側の保存領域としてファイルサーバーのAccessを使う。ユーザーはAccessの複雑な画面を見ずに済み、入力も早い。

まず、前任者が残した「管理台帳V2_最新版.xlsm」の保存ボタンを押すと。一瞬砂時計のアイコンが出て完了メッセージが出る。裏で何が起きているか全く知らなかった当時の私は「Excelって魔法みたいだな」と能天気に感動していた。だが半年後。そのファイルが突如「データベースの形式を認識できません」というエラーを吐き。部署全体の業務が完全にストップした時。初めて自分の足元の氷がどれほど薄いかを知って絶望した。胃が鉛のように重くなり、冷や汗が止まらなかった。

便利さは恐ろしい。最初は1日数回の更新だったものが。いつの間にか経理の支払い処理から総務の契約管理まで。部門の心臓部のような役割を担い始める。誰も全体像を把握していないシステムに、日々の重要な業務が完全に依存してしまう。抜け出したくても、すでに後戻りできない状態に陥っているのです。

Access同時編集：データ破損と業務停止の代償

システムが拡大すると、すぐに限界の壁にぶつかる。最大の敵は「同時編集の衝突」である。ファイルサーバーに置かれた一つのAccessファイルに対して。複数のExcel端末が同時に接続を試みる。Accessの仕様上、複数人での同時アクセスは可能とされているが。現実は甘くありません。

次に、誰かがExcelから重い検索処理を走らせている最中に。別の担当者がデータを登録しようとすると、容赦なくロックアウトされる。あるいは処理途中でネットワークが一瞬でも瞬断すれば。データベースファイル全体が破損（Corrupt）するリスクがある。ファイルの排他制御という概念が曖昧なまま運用を続けたツケが。ある日突然エラー画面として襲いかかってくるのです。

脆いシステム、業務停止と損失コスト

月末の請求処理のピーク時、派遣社員のAさんがExcelで入力中にフリーズし。無理やりタスクマネージャーで終了させた。その直後から他の全員がシステムにアクセスできなくなった。「もしかして私が壊しましたか…？」と震える声で聞かれた時。本当の原因は脆いシステムにあるのに彼女を安心させる言葉が出てこなかった。修復ツールを回すまでの3時間。部署全体が息を殺して私の背中を見つめていたあの重圧は今でも夢に出る。

さらに厄介なのがバックアップの取りにくさだ。誰かがファイルを開きっぱなしにして帰宅すると。夜間の自動バックアップ処理がファイルのコピーに失敗する。翌朝、昨日までのデータが消えていないか祈るような気持ちでファイルを開く。小規模だから安全というわけではない。むしろ、小規模だからこそ専用の保守担当がおらず。一度壊れたときに修復する逃げ道がどこにも用意されていありません。

一方で、数値：Accessファイル破損時の復旧作業にかかる平均時間（約4時間）と。その間の部署全体の業務停止による見えない損失コスト（数万円規模）。

Excel入力統一のVBA地獄

利用者の負担を減らすため。入力インターフェースをExcelに統一するアプローチは一見正解に思える。ExcelのVBAから裏のAccessを操作すれば。ユーザーは面倒なAccessの使い方を覚えなくて済む。しかし、この構成は見た目がすっきりする分。裏側のメンテナンス性を著しく低下させる。

まず直面するのが「VBAの配布」という地獄だ。入力フォームを少し修正しただけで。全員のパソコンに入っているExcelファイルを最新版に差し替えてもらう必要がある。「新しいのを使ってください」と何度アナウンスしても。必ずデスクトップに保存した古いバージョンを使い続ける人が現れる。その結果、古い仕様のデータが無理やりAccessに流し込まれ。データ不整合が引き起こされる。

Excelの親切さが招く開発者の不毛な作業

そのため、Excel特有の「親切さ」が引き起こすエラーも運用を狂わせる。日付を入れるべきセルに「未定」という文字列を入れても。Excel上ではそのまま入力できてしまう。それをAccessの日付型フィールドに書き込もうとした瞬間に「型が一致しません」という冷酷なエラーが返る。Excelのセル書式の揺れ、コピー＆ペーストによる見えない空白文字の混入など。想定外のデータに対するバリデーション（入力値検証）をすべてVBAで書き込まなければならありません。

「なんで保存できないのよ！」と怒り心頭のベテラン社員の席へ行くと。全角スペースと半角スペースが混ざった顧客コードが入力されていた。それを防ぐためだけにTrim関数やStrConv関数を何重にも噛ませるコードを夜遅くまで書き足した。誰の役にも立たない不毛な作業をしている虚無感で、目の奥がジンジンと痛んです。

見た目を簡単にすればするほど。裏側で泥臭いエラーハンドリングを延々と実装する羽目になる。Excelの親切さは、開発者にとってそのまま運用負荷に直結してしまうのです。

ADOエラーの闇、精神を削るデバッグ

しかし、ExcelからAccessへの橋渡しを担うのが。ADO（ActiveX Data Objects）という接続技術である。これを使えば外部データベースと自由にやり取りができるが。一度つまずくと底なし沼のようにデバッグが終わらなくなる。

動かない理由は無数にある。接続文字列（ConnectionString）のたった一文字のスペルミス。参照設定で「Microsoft ActiveX Data Objects Library」にチェックを入れ忘れたことによるコンパイルエラー。近年特に多いのが。WindowsやOfficeの32bit/64bitのアーキテクチャ違いによるプロバイダのエラーだ。自分のパソコンでは完璧に動くのに。隣の席のパソコンでは「プロバイダが見つかりません」と怒られる。

ログなきADOトラブル解決の闇

なぜADOのトラブルはこれほどまでに解決が難しいのか。原因は「エラーの内容が抽象的すぎる」という点に尽きる。ファイルパスが間違っていても、権限がなくても、ネットワークが切れていても。返ってくるのは似たような実行時エラーだけだ。しかも野良DBのVBAには。まともなエラーログをテキストに出力する仕組みなど実装されていない。「何かよくわからないけれど動かない」というユーザーからのフワッとした報告だけを頼りに。コードのあちこちにブレークポイントを置いて推測ゲームを繰り返すしかありません。

さらに、数時間にわたるデバッグの末。原因が「共有フォルダのアクセス権限が外れていた」というシステム外の要因だったと判明した時。疲労は怒りを超えて虚無に変わる。ログを残す仕組みがないシステムは、保守する人間の精神を静かに削り取っていく。

野良DBの現実解：Pythonで処理分割

限界を迎えた野良DBをどうすべきか。「クラウドの最新SaaSに一新しよう」というのは簡単だが。予算ゼロ・IT部門なしの現実では絵に描いた餅である。現実的なアプローチは、残す領域と切り出す領域を分けて考えることです。

人が手で入力するインターフェース部分はExcelに残しても構わない。現場の反発を最小限に抑えるためだ。データの集計や検証、夜間のバックアップ。そしてエラーログの保存といった「裏側の重い処理」は。Pythonに逃がすという選択肢が非常に有効になる。

まず、Pythonのpandasなどのライブラリを使えば。Accessへの負荷を劇的に下げられる。Excelから直接Accessに重いSQLを投げるのをやめ。一旦CSVに吐き出したものをPythonで夜中に一括処理する。これだけで同時アクセスの衝突は激減する。

数値：ExcelからAccessへの直接クエリ実行によるシステムフリーズ回数（月平均15回）が。Pythonによるバッチ処理移行後にゼロになるまでの期間（約2週間）。

Access利用判断と野良DB脱却の境界線

Accessを完全に否定する必要はない。利用者が数人で、単なる名簿管理程度であればそのまま使い続ける方が合理的だ。更新頻度が1日に数十回を超え。誰もVBAのコードを解読できない属人化の極致にあるなら。処理の分割を始める合図である。壊れ方を単純にし、「ここまではExcel。ここからはPython」という境界線を引くことが。野良DBの呪縛から抜け出す第一歩となる。

属人化システムの危険、負の遺産からの脱却

次に、現状のシステムが「今。なんとか回っているから大丈夫」という考えは極めて危険である。野良DBの延命判断は、現在の利用人数やデータ量で決めてはならありません。

本当の判断基準は「3か月後に担当者が増えても。このシステムを自信を持って説明できるか」である。新しいメンバーが入ってきた時。「このボタンはエラーが出やすいから2回押して」「たまにフリーズするけど気にしないで」といったローカルルールを教えなければならないなら。そのシステムはすでに破綻している。

明確なバックアップ方針があり。万が一ファイルが完全に飛んでも翌日には業務を再開できる算段はあるだろうか。これが無いまま運用を続けるのは、目隠しで綱渡りをしているのと同じです。

一方で、異動の際、私が作ったAccessツールを後任に引き継ごうとした。「ここが壊れたらこのコードを直して」と説明する私に対し。後任の顔がどんどん青ざめていくのを見た。自分が会社を救っているつもりで。実はとんでもない負の遺産を他人に押し付けているだけだと気づき。激しい自己嫌悪に陥った。

Access脱却、運用設計の本質と退路

Accessを捨ててPythonなどのモダンなツールに移るかどうかは。単なる道具選びの問題ではない。システムの「壊れ方」をどう素直にし。属人化を防いで他人へ手渡せる状態にするかという、運用設計の本質への問いである。便利なツールに隠された複雑さを直視し、いつか必ず来る破綻の前に。自らの手で退路を構築しなければならありません。

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

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