予算ゼロ・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などのモダンなツールに移るかどうか。これは、単なる道具選びの問題ではありません。システムの「壊れ方」をどう素直にするか。属人化を防ぎ、他人へ手渡せる状態にするか。これは運用設計の本質への問いなのです。便利なツールに隠された複雑さを直視する必要があります。いつか必ず来る破綻の前に、自らの手で退路を構築しなければなりません。

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

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