「この業務システムは15年以上使っている。そろそろ入れ替えた方がよいのだろうか」。長年利用しているAccessやExcel VBA、社内向け業務システムを持つ中小企業では、このような悩みが生じます。
一方で、「今も問題なく動いている」「現場が使い慣れている」「新しいシステムへ移行すると費用も混乱も大きい」という事情もあります。
業務システムの入れ替えは、「古いから刷新する」「まだ動いているから使い続ける」という二択で決める必要はありません。
重要なのは、現在のシステムを使い続けるリスクと、新しいシステムへ移行するリスクの双方を確認し、現状維持、部分改善、段階移行、全面刷新などの選択肢を比較することです。
本記事では、15年間利用しているMicrosoft Access製の業務システムを架空例として、経営者が刷新要否を判断するときに確認したいポイントを整理します。
古い業務システムは「年数」だけで入れ替えない
10年、15年、20年と利用していることは、システムを見直すきっかけにはなります。しかし、「15年以上使ったら刷新」といった一律の基準があるわけではありません。
経済産業省も、稼働年数や利用技術が古い場合であっても、必ずしもレガシーシステムではないと整理しています。問題になるのは、システムが老朽化・複雑化し、必要な機能追加・変更や維持を適切なスピードや経済性で実施できなくなっている状態です（経済産業省, 2024）。
これはAccessについても同じです。Microsoft Access自体は現在もMicrosoft 365等で提供されており、Access 2024もサポートされています。したがって、「Accessで作られている」という理由だけで刷新対象と判断するのは適切ではありません。
確認すべきなのは、実際に使用しているAccess・Office・Windows・データベース・ドライバ等のバージョン、アプリケーションの構造、保守体制、データ量、利用方法です。
「今動いている」と「今後も維持できる」は違う
長期間、大きな障害なく動いていることは重要な情報です。しかし、現在正常に動作していることと、障害発生後に復旧できること、今後も変更しながら利用できることは別です。
例えば、毎日バックアップを取得していても、復元手順が分からなかったり、復元試験を長期間実施していなかったりすれば、障害時に業務を再開できるとは限りません。
また、システムの作成者が退職し、VBAやデータベース構造を理解している社員が一人しかいない場合、普段の稼働には問題がなくても、その社員の退職や長期不在によって保守できなくなる可能性があります。
業務システムを見直す7つの視点
| 確認視点 | 主な確認事項 |
|---|---|
| 1. 業務上の重要性 | 停止した場合に受注、出荷、請求、顧客対応等へどの程度影響するか |
| 2. 障害・復旧 | バックアップだけでなく復元手順、代替運用、復旧可能性を確認できるか |
| 3. 保守可能性 | 修正できる人、ソース、仕様書、管理者情報、外部ベンダーが存在するか |
| 4. サポート・セキュリティ | OS、Office、Access、DB等がサポート対象か。必要な更新・アクセス制御が可能か |
| 5. 現在の業務適合性 | 二重入力、CSV転記、手作業、処理遅延等が業務負荷になっていないか |
| 6. 将来の業務適合性 | 拠点追加、利用者増加、制度変更、他システム連携等へ対応できるか |
| 7. 移行リスク・コスト | データ移行、業務ルール再現、教育、切替、費用等を把握しているか |
15年使っているAccessシステムの架空例
説明用の架空例として、ある中小企業が約15年前に構築したMicrosoft Access製の受発注管理システムを現在も利用しているとします。
- 利用者は約10名
- 日々の受発注業務に利用
- 現在は大きな障害なく稼働
- 初期開発者はすでに退職
- VBAを理解できる社員は1名
- 仕様書は一部のみ残っている
- バックアップは毎日取得しているが、復元試験は長期間未実施
- 会計・販売システムとはCSVで手動連携
- 新しい機能の追加には時間がかかる
- ベンダーからクラウド型システムへの移行を提案されている
この企業について、「15年間利用しているから全面刷新」と結論を出すことはできません。
現行システムには、安定稼働している、利用者が操作に慣れている、現在必要な業務を処理できている、新規投資を抑えられる、といった利点があります。
一方で、保守知識の集中、復元未検証、仕様書不足、手動連携、将来変更への対応力といった確認事項があります。
クラウドシステムへ移行すればこれらがすべて解決するとも限りません。過去データの移行、Access内部に埋め込まれた業務ルールの再現、利用者教育、切替時のトラブル、新しいベンダーへの依存など、新たなリスクも発生します。
現行システムを使い続けるリスクを整理する
現行維持を検討する場合、保守契約費やライセンス費だけでなく、表面に見えにくい負担も確認します。
例えば、会計システムへ毎日CSVを出力して転記している場合、その作業時間、入力ミス、確認作業も現行システムを使い続けるためのコストです。
機能追加を行うたびに特定社員へ依頼しなければならない、PC交換のたびに設定確認が必要になる、障害時の復旧方法を誰も説明できない、といった状態も維持リスクに含まれます。
また、実際に利用している製品のサポート状況を確認します。例えばMicrosoft Accessは現在も提供されていますが、バージョンによってサポート期間は異なります。Access 2021は2026年10月にサポート終了予定である一方、Access 2024は2029年10月までサポート予定です（Microsoft, 2026）。
Accessだけでなく、Windows、Office、データベース、ODBCドライバ、外部コンポーネントなど、システムを構成する依存関係をまとめて確認することが重要です。
新しいシステムへ移行するリスクも確認する
現行システムの問題を列挙すると、新しいシステムへの刷新が常に有利に見えてしまいます。しかし、移行自体にもリスクがあります。
- マスタ・取引履歴・添付ファイル等を正しく移行できるか
- 長年の運用で追加された業務ルールを再現できるか
- 現在の例外処理を要件として把握できているか
- 新システムの操作を利用者が習得できるか
- 旧システムと新システムを並行利用する必要があるか
- 切替日に問題が起きた場合、元へ戻せるか
- 新しいベンダーやサービスへの依存が増えないか
特に仕様書が十分に残っていないシステムでは、プログラムの中に長年の業務ルールが埋め込まれている場合があります。画面上では単純に見える処理でも、例外条件や計算ルールが多数存在することがあります。
したがって、刷新前には「現在何ができているか」を調べるだけでなく、「新しいシステムへ移したときに何を失う可能性があるか」も確認します。
「維持・部分改善・段階移行・全面刷新」を比較する
| 選択肢 | 考え方 | 確認したい点 |
|---|---|---|
| 現状維持＋リスク低減 | 現在のシステムを継続しつつ、保守・復旧面を強化する | サポート継続性、保守担当、バックアップ・復元 |
| 部分改善 | 問題となっている部分だけを改修・置換する | 改修可能性、既存構造への影響 |
| 段階移行 | データ基盤や一部機能から順次新環境へ移す | 新旧連携、移行順序、二重運用 |
| 全面刷新 | 業務・システムを整理し、新システムへ置換する | 要件、データ移行、教育、切替、TCO |
どの選択肢が適切かは、企業の状況によって変わります。
現在の業務を十分に満たし、保守・復旧体制も確保できているなら、今すぐ全面刷新しない判断も考えられます。一方、障害時に復旧できない、保守できる人がいない、事業変更へ対応できないなどの問題が重なっている場合は、移行準備を進める必要性が高まります。
「古いから入れ替えるべきか」で迷っている場合は、まず対象システムについて、「止まったときの影響」「復旧できるか」「誰が修正できるか」「現在困っている業務」「今後必要になる変更」「移行時に失うもの」の6項目を書き出してみてください。
年数だけでは見えなかった判断材料を整理できます。
今すぐ刷新しない場合にやっておきたいこと
「当面は現在のシステムを使う」と判断することと、「何もしない」ことは同じではありません。
特にデータを取り出せる状態にしておくことは重要です。現在のシステムをあと数年使う場合でも、将来の移行可能性を確保しておけば、障害や担当者退職をきっかけに慌てて刷新するリスクを抑えやすくなります。
ベンダーから刷新を提案されたときの確認ポイント
ITベンダーから「古いのでクラウド化しましょう」「新しいシステムへ入れ替えましょう」と提案された場合も、提案自体を刷新理由にはしません。
まず、自社側で次の点を確認します。
- 現在どの問題を解決するための刷新なのか
- 現行システムを継続する場合のリスクは何か
- 部分改修では解決できない理由は何か
- 移行するデータの範囲はどこまでか
- 現行の業務ルールをどう再現するか
- 移行後の運用費・保守費はどの程度の構造になるか
- 契約終了時にデータを取り出せるか
- 障害・切替失敗時の対応方法はどうなっているか
「クラウドだから新しい」「SaaSだから保守不要」といった言葉だけではなく、自社の業務課題と技術上の制約に照らして判断します。
業務システム刷新判断チェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 対象業務 | どの業務を支えるシステムか説明できるか |
| 停止時影響 | 停止すると何の業務がどの程度困るか |
| 復旧 | バックアップから実際に復元できるか |
| 保守担当 | 障害・改修に対応できる人や会社がいるか |
| 仕様 | 主要な業務ルール・画面・帳票・連携を把握しているか |
| サポート | OS、Office、Access、DB等のサポート状況を把握しているか |
| セキュリティ | 認証、権限、更新、ログ、バックアップ等を確認したか |
| 現在の負荷 | 手入力、二重入力、CSV転記等の業務負荷を把握しているか |
| 将来要件 | 今後数年で必要になる機能・連携を整理したか |
| データ | データを汎用形式等で取り出せるか |
| 現行維持リスク | 使い続ける場合の問題を整理したか |
| 移行リスク | データ・業務・教育・切替のリスクを整理したか |
| 選択肢 | 全面刷新以外の部分改善・段階移行も検討したか |
| 次回見直し | 継続利用する場合の次回評価時期を決めたか |
まとめ
業務システムの入れ替え時期は、構築から何年経過したかだけでは決まりません。
現在の業務への影響、障害時の復旧可能性、保守体制、サポート・セキュリティ、機能不足、将来必要になる変更、現行維持コストを確認し、それらを新システムへの移行リスクと比較します。
15年前に作られたAccessシステムでも、安定して運用され、保守・復旧でき、現在と将来の業務要件を満たしているなら、年数だけを理由に全面刷新する必要があるとは限りません。
一方、現在動いていても、保守できる人がいない、復元できるか分からない、仕様がブラックボックス化している、業務変更へ対応できないのであれば、将来の移行を見据えた準備が必要です。
結論を「刷新する・しない」の二択にせず、現状維持＋リスク低減、部分改善、段階移行、全面刷新を比較し、自社にとって次に確認すべきことを明確にするところから始めるとよいでしょう。
SCI総合研究所株式会社のKAMUSHIRUBEでは、古い業務システムについて「今すぐ刷新すべきか」「当面使い続けられるか」「ベンダーの刷新提案は妥当か」といった判断段階から相談できます。
Access・Excel等で構築された既存システムについても、年数や製品名だけで結論を出さず、業務影響、保守性、技術上の制約、移行リスクを整理し、次に確認すべき事項を検討します。
参考文献
- 経済産業省. 2024. デジタルガバナンス・コードの策定に向けた検討 参考資料3. https://www.meti.go.jp/shingikai/mono_info_service/dgs5/pdf/001_s03_00.pdf
- 独立行政法人情報処理推進機構（IPA）. 2025. ITシステムのモダン化とは？ レガシーシステムモダン化委員会総括レポートのポイント解説. https://dx.ipa.go.jp/modernization
- Microsoft. 2026. Access 2021 – Microsoft Lifecycle. Microsoft Learn. https://learn.microsoft.com/en-us/lifecycle/products/access-2021
- Microsoft. 2026. Access 2024 – Microsoft Lifecycle. Microsoft Learn. https://learn.microsoft.com/en-us/lifecycle/products/access-2024
- Microsoft. 2026. Access included as part of Microsoft 365 and Office 365 subscriptions. Microsoft Support. https://support.microsoft.com/en-us/access/access-included-as-part-of-microsoft-365-and-office-365-subscriptions