ACCESSを再構築するという選択― 延命か、再設計か

前回、原価計算システム刷新の選択肢を整理しました。

  • ACCESS再構築
  • Excel(PowerQuery)
  • クラウド基盤(Kintoneなど)
  • ERP統合

その中でも、最も現実的で、実際に多くの企業が検討するのが「今のACCESSを作り直す」という選択です。

これは妥当な判断なのか。それとも将来に禍根を残すのか。今回はその論点を整理します。

ACCESSは本当に“時代遅れ”なのか?

まず前提として整理しておきたいのは、

ACCESS=時代遅れ、ではないということです。年商数十億円規模の中小製造業であれば、次のような条件下では、ACCESSは十分に実用的です。

  • 製品点数が数百〜数千程度
  • 月間製番数が数百レベル
  • 工数データが月数万行程度
  • 同時利用者が5名以内

この規模感であれば、設計が適切なら大きな問題は起きません。実際、安定稼働している企業は数多くあります。問題は「ACCESSだからダメ」なのではなく、
設計が今の実態に合っているかどうかです。

それでも再構築が必要になる理由

では、なぜ再構築が議論に上がるのでしょうか。よくあるきっかけは次のようなものです。

  • 処理が遅くなってきた
  • 修正できる人がいない
  • 64bit対応で不具合が出た
  • Excelでの手修正が増えている
  • 生産形態が変わっている

特に最後の点。多品種少量化、外注比率の増加、複数拠点化など、生産の実態が変わっているにもかかわらず、原価計算ロジックは20年前の前提のままというケースは少なくありません。ここにズレが生じます。

ACCESS再構築には2種類ある

ACCESS再構築といっても、中身は大きく2つに分かれます。

① 延命型再構築

  • 不具合修正
  • 速度改善
  • 64bit対応
  • 帳票修正

いわば「リフォーム」です。短期的には合理的で、コストも抑えられます。ただし、原価計算の設計思想そのものは変わりません。生産実態とのズレがある場合、それは残ります。

② 設計見直し型再構築

もう一つは、

  • 間接費配賦の再設計
  • 製番単位の再定義
  • 標準原価の考え方の整理
  • データ構造の抜本的見直し

を行ったうえで、ACCESSで作り直す方法です。これは単なるシステム修正ではありません。原価計算の再設計です。同じACCESSでも、意味はまったく異なります。

ACCESSの現実的な限界ライン

ここで、データ量の目安も整理しておきます。ACCESSの制約はよく語られますが、実務上問題になるのは次のようなケースです。

  • 月間製番が数千件規模
  • 実績データが月数十万行を超える
  • 同時利用者が10名以上
  • 拠点間リアルタイム共有が必要
  • 海外拠点を含む統合管理

このレベルになると、

  • 処理速度低下
  • データ破損リスク
  • バックアップ運用の複雑化

といった問題が出やすくなります。つまり、問題は売上規模ではなく、データ量と同時利用環境です。年商30億円でもデータがシンプルなら問題は起きません。年商10億円でも製番が極端に多ければ厳しくなります。

最大のリスクは再び属人化すること

再構築で最も多い失敗はこれです。

  • ロジックを文書化しない
  • 配賦根拠を整理しない
  • データ構造を共有しない

結果として、数年後に再びブラックボックス化する。ACCESSの問題というより、
設計統制の問題です。再構築するなら、最低限、

  • 原価フロー図の作成
  • 配賦ロジックの明文化
  • マスタ設計書の整備

はセットで行う必要があります。

どんな会社にACCESS再構築は向いているか

ACCESS再構築が合理的なのは、次のような企業です。

  • 単一拠点である
  • 生産構造が比較的シンプル
  • 将来5年で大きな拡大予定がない
  • 上場予定がない
  • 原価設計を一度整理したい

この場合、ACCESSは十分に選択肢になります。無理にERPへ飛びつく必要はありません。

延命か、再出発か

結局のところ、判断の分かれ目はここです。

  • 今の原価は経営判断に使えているか
  • 生産の実態を正しく表しているか
  • 5年後も通用する設計か

もしここが曖昧であれば、単なる延命ではなく、設計からの見直しが必要です。ACCESSを使うかどうかよりも、どの思想で原価を設計するかの方がはるかに重要です。

次回は、「Excel × PowerQueryで原価計算を再設計する」というアプローチを取り上げます。大規模投資をせずに、原価ロジックを一度“分解”する方法です。

システム刷新の第一歩は、ツール選定ではなく、構造の可視化かもしれません。