Accessを続けるか、スプレッドシート＋Pythonで逃がすか。小規模業務DBの現実解

小さなAccess、大きな負債

最初は、ただの小さな台帳だった。部門の中だけで使う、入力しやすい一覧。そのためにAccessを使い、現場で見やすいようにExcelを前面に置いた。

「これなら十分だろう」と思っていた。少なくとも、最初の数か月はそうだった。ところが、業務は静かに増える。担当者が増え、項目が増え、例外が増える。気づけばそのAccessは、誰も全体像を把握していないのに。毎日の業務を止められない位置に座っていた。

まず、Accessは、立ち上げるだけなら本当に早い。でも、早く始めたシステムほど、後から止めにくい。「小さいから安全」と思っていたものが。いつの間にか「小さいままでは済まないもの」に変わっていく。そこが一番やっかいです。

Access運用の見えない地雷

Accessのしんどさは、派手な故障ではなく。地味な不安が積み重なるところにある。同時編集でつまずく。バックアップの取り方が面倒になる。リンクテーブルが壊れる。修復しても、またどこかで同じ違和感が出る。

しかも厄介なのは、壊れる前はそれなりに回って見えることだ。誰も大騒ぎしていないから、改善も後回しになる。でも実際には、ファイルの肥大化、レコードロック、未整備の更新ルールが。静かに地雷として積み上がっている。

次に、小規模だから安全、ではない。むしろ小規模だからこそ、直せる人が1人しかいない。その1人が休んだら止まる。その1人が異動したら崩れる。それがAccess運用の、いちばん現実的で重いところです。

ここで見落としやすいのは、Accessが便利だった期間が長いほど。担当者の頭の中にしかない運用ルールが増えることだ。ファイル名の付け方、更新の順番、誰が触ってよいか。どこまでが手作業でどこから自動化か。これらが曲十りないまま増えると、表面上は動いていても。実際は毎回誰かが手で支えているだけになる。

Access見直し、役割分担で運用最適化

では、どうするか。答えは、Accessを無理に神格化しないことだ。全部を一気に作り直すのではなく、役割を分ける。現場が触る入口はスプレッドシートに寄せる。処理の本体はPythonに逃がす。

一方で、この分け方をすると、運用はかなり素直になる。スプレッドシートは説明しやすい。誰でも見やすい。更新のハードルが低い。一方Pythonは、整形、集計、検証、バックアップ。ログ保存のような定型処理に強い。人が毎回やるより、最初から機械に任せた方が事故が少ありません。

同時編集の不安を減らしつつ、処理の中身を固定できる。ここが一番大きい。Accessのような一体型の便利さは減るが、その代わり壊れ方が単純になる。壊れたときに、どこを見ればいいか分かる。それだけで、運用の怖さはかなり下がる。

Access移行：理想より分解、壊れ方の単純化

移行と聞くと大仕事に聞こえる。でも、実際にやることはかなり地味だ。まず、Accessの中に何が入っているかを整理する。次に、更新される項目と、参照だけの項目を分ける。そのうえで、CSV化できる形に整える。

そのため、ここで大事なのは、最初から理想のDBを狙わないことだ。きれいな設計を夢見ているうちに、また別の属人化が生まれる。だから、まずは壊れやすいところから外す。入力チェックを入れる。更新履歴を残す。バックアップの保存先を固定する。止まるのではなく、どこで止まったかが分かるようにする。

移行は、作り直しではなく分解だ。見えにくい結合をほどいて、壊れ方を単純にする。この発想を持てるだけで、作業の順番が変わる。

パネル/access-vs-python-decision-table.png

しかし、もちろん、Accessを悪者にする話ではない。小規模で、使う人数が固定されていて、更新頻度が低いなら。Accessのままでも十分に回る。むしろ、その方がシンプルで安いこともある。

道具選びは運用条件との相性

大事なのは、道具の好き嫌いではなく、運用条件だ。同時編集が必要か。バックアップを自動化したいか。今後も項目が増えるか。直せる人が社内にいるか。この4つで見ると、だいぶ判断しやすくなる。

道具の優劣ではなく、運用条件との相性で決める。これを外すと、移行してもまた別の地獄に入る。だから、残す判断も立派な判断です。

小規模業務DBの選定は運用と復旧で

さらに、小規模業務DBは、今日回るかどうかだけで決めると危ない。3か月後に人数が増えているか。担当者が変わっても説明できるか。バックアップが自動で残るか。トラブル時に、どこまで戻せるか。そこまで見て、AccessかPythonかを決めた方がいい。

Accessを続けるか、スプレッドシート＋Pythonで逃がすか。答えは、機能の多さではなく、壊れ方の素直さにある。そして、その選択は「今の人数」ではなく「これからの運用」で決めるべきです。

ここで大事なのは、機能の多さではない。迷ったら、復元手順を先に書ける方を選ぶ。

まず、迷ったときは、壊れたあとに誰が直せるかまで含めて選ぶ。デベロップの便利さより、復元までの道筋が素直かどうかを優先したい。

急がず、見える形で進める。

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

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