はじめに
業務システム選定で最も多い失敗は、
「今のデータ量」で判断してしまうこと です。
業務が続く限り、データはほぼ確実に増えます。
この回では データ量が増える前提 を置いたときに、
- Excelで持ち続けてよい業務
- Access（DB）に切り替えるべき業務
この分岐点を、ExcelとAccessの対比で整理します。
1. 判断基準は「今」ではなく「未来」
Excelが破綻する瞬間は、だいたい決まっています。
- 行数が一気に増えた
- 履歴を残し始めた
- 検索・集計条件が増えた
- ファイルを分け始めた
問題は「重い／遅い」ではありません。
増加に耐えられない構造 で運用していることです。
「今は数千行だから大丈夫」
これは判断材料になりません。
2. ExcelとAccessの本質的な違い（データ量視点）
| 観点 | Excel | Access |
|---|---|---|
| 想定用途 | 表計算・確認 | データ管理 |
| データ量 | 少量前提 | 増加前提 |
| 検索 | 行走査 | インデックス |
| 履歴管理 | 表が肥大化 | テーブル分離 |
| 同時利用 | 事故りやすい | ある程度耐える |
| 構造の寿命 | 短い | 長い |
Excelは「計算する器」、Accessは「増え続けるデータを収める器」です。
3. データ量の現実的な目安
Excelが成立しやすい範囲
- 数百〜数千行
- 増加が緩やか（年数千行以下）
- 履歴をほぼ持たない
- 単一ファイル・単一担当
危険信号が出始める領域
- 数万行規模
- 月次で増え続ける
- 検索・集計が体感で遅くなる
- ファイル分割を考え始めた
Accessに切り替えるべき領域
- 数万行以上で増加が止まらない
- 履歴を削除できない
- 検索・結合・集計が頻発
- 複数人が触る
「Excelが重い」ではなく、「Excel構造で増え続けること自体が限界」 です。
4. Excelがデータ量増加に弱い理由
Excelでよく起きる破綻パターンです。
- 1シート1テーブルで履歴を溜め込む
- 集計用の列を増やし続ける
- ファイル分割で軽量化しようとする
- マクロで無理に延命する
結果として、
- 処理が指数的に遅くなる
- 更新漏れ・二重管理が発生する
- 特定の人しか触れなくなる
- 壊れたときの復旧が困難
これは操作の問題ではなく、設計の限界 です。
5. Accessが「増える前提」に強い理由
Accessでは、
増えるデータと増えないデータを最初から分けて設計 します。
例として、次のような構造を考えます。
- 主テーブル（現在の状態だけを持つ。基本的に肥大化しない）
- 履歴テーブル（状態変更の履歴。ここだけが増え続ける）
設計イメージ：
--主テーブル：orders
order_id --注文ID（主キー）
customer_id -- 顧客ID
status -- 現在の注文ステータス
created_at -- 登録日時
--履歴テーブル：order_status_history
history_id -- 履歴ID（主キー）
order_id -- 注文ID（主テーブルと紐づく）
status -- 変更後の状態
changed_at -- 状態変更日時
主テーブルは軽いままで、履歴テーブルのみデータが増加、
結果として検索・集計が安定します。
6. Excel継続が危険かを見極めるチェックリスト
次に YES が多いほど、Access検討段階です。
- データは今後も増え続ける
- 履歴を削除できない
- 検索・集計条件が増える予定
- 月に数千行以上増える
- ファイルを分けたくなっている
- 「このマクロ触れるのは〇〇さんだけ」
3つ以上該当したら、
Excel継続はリスクが高い状態です。
7. よくある誤解
誤解1：Excelが重いからAccessにする
増える前提があるからAccessにする です。
誤解2：完成してからDB化すればいい
完成後の移行は、最もコストが高い選択です。
誤解3：Accessは難しい
壊れたExcelを保守する方が、よほど難しいです。
8. 結論
- データが増えない → Excelで成立する場合が多い
- データが増える → Accessを前提に考える
- 増え続けるのが確定 → 最初からAccessで設計する
判断軸はひとつ。
データ量増加を見越せるか
これを置けない仕組みは、遅かれ早かれ問題が発生します。