結論の要約： Access の属人化は、担当者の怠慢でも Access の欠陥でもなく、「個人の道具として作られたものが、部門の基幹になってしまう」という構造から必然的に生まれます。解消の順序は決まっています。いきなり作り替えるのではなく、まず中身を可視化し、業務上の役割を仕分けてから、移行や再構築を設計する——この順番を守るかどうかで、コストも成功率も大きく変わります。

属人化は「Accessの欠陥」ではない——役割が変わっただけ

Access は本来、現場の担当者が自分の業務を効率化するための道具です。プログラマーでなくても、テーブルを作り、クエリを組み、フォームと帳票まで仕上げられる。この「現場で完結する力」こそが Access の価値で、EUC（End User Computing：利用部門による自力開発）の代表格として、長年にわたり現場の生産性を支えてきました。

問題は、道具がよくできていたことの副作用として起きます。便利だから周りも使い始める。データが集まる。気づけば部門の業務が、そのファイルなしでは回らない。「個人の道具」が、誰も任命していないのに「部門の基幹」へ昇格してしまう——これが属人化の正体です。作った人を責めても、Access を責めても解決しないのは、このためです。

属人化はこうして進む——4つの段階

進行には典型的な段階があります。自社の Access がいまどこにいるか、照らしてみてください。

第1段階： 作った本人が、自分の業務のために使っている。中身は本人の頭の中にあり、問題は表面化しない。

第2段階： 部門の複数人が使い始める。「あのファイルに入れておいて」が業務手順になる。仕様書はないが、本人がいるので誰も困らない。

第3段階： 作った本人が異動・退職する。引き継がれるのはファイルの場所と操作方法だけで、「なぜそう作られているか」を知る人がいなくなる。不具合が出ても直せないため、「触らない」が暗黙のルールになる。

第4段階： 触れないまま、業務だけが依存を深める。データは肥大化し、処理は遅くなり、エラーの回避手順だけが口伝で増えていく。準基幹業務が「開けられない箱」の上に載っている状態。

第3段階を過ぎると、時間が経つほど解消のコストは上がります。中身を知る人の記憶が薄れ、関連資料が散逸していくからです。

なぜ「いきなり作り替え」は失敗するのか

属人化に気づいた組織がまず考えるのは「新しいシステムに作り替えよう」です。方向は正しいのですが、順序を飛ばすと高い確率でつまずきます。

理由は単純で、中身が分からないものの要件は書けないからです。画面と帳票を見れば「何をしているか」は分かります。しかし「なぜそうしているか」——どの集計に手作業の補正が挟まっているか、どの数字が別のファイルから来ているか——は、構造を読み解かないと分かりません。ここを飛ばして要件定義をすると、移行後に「前と数字が合わない」「あの帳票が出ない」が噴出します。その結果、旧ファイルが温存され、新旧のシステムが二重に動き続けることになります。

解消の順序——可視化、仕分け、それから設計

遠回りに見えて確実なのは、次の順序です。

（1）可視化： テーブル・クエリ・マクロ／VBA・外部連携の構造を洗い出し、「このファイルが実際に何をしているか」を地図にする。

（2）仕分け： 業務上の重要度とリスクで分類する。役目を終えたもの、個人用途で十分なもの、部門で共有すべきもの、基幹に近いもの。

（3）設計： 仕分けに応じて、残す・統合する・作り替えるを判断し、移行先（クラウド化・社内Webアプリ化・基幹統合など）を選ぶ。

ポイントは、（1）と（2）だけでも独立した価値があることです。全体像の地図があるだけで、「どこから手を付けるか」の議論を、感覚ではなく事実の上でできるようになります。

可視化の壁と、構造解析という選択肢

（1）の可視化は、手作業でやろうとすると壁に当たります。オブジェクトの数は数百にのぼり、クエリがクエリを呼び、VBA がその両方を書き換える——人手で追い切るには相応の工数が必要で、「うちには無理」と棚上げされてきたのが実情です。

REGAZE では、この最初の壁を取り除くために、Access ファイル1本から受け付ける0円の構造診断を提供しています。構造の簡素な解析と可視化、そして仕分け・移行パスの提示まで。属人化の解消は、まず「開けられない箱」の中身を知ることから始まります。