Accessで動く先代の業務システムの限界と移行先の選び方

先代が20年前に作った、あるいは取引先の詳しい人に頼んで組んでもらった「あの見積システム」。起動するとグレーの画面にボタンがずらりと並び、クリックすると帳票が印刷される。マウスを動かすたびにわずかにもたつくが、経理も営業事務も、これがないと仕事が回らない。多くの場合、その正体はMicrosoft Accessで作られた自社専用システムだ。

結論から言えば、Access製の業務システムは「今すぐ壊れる」ものではないが、「いつまでも使える」ものでもない。サポート期限という明確なタイムリミットがあり、しかも先代の退任や高齢化とタイミングが重なりやすい。だからこそ、承継したばかりの社長がまず把握すべきなのは「壊れる日」ではなく「詳しい人がいなくなる日」の方だ。この記事では、Accessシステムの技術的な限界、なぜ中小企業でここまで普及したのか、そして移行先をどう選ぶべきかを、承継の当事者目線で整理する。

こんな状態に心当たりがあるなら、続きを読んでほしい。先代の代からある受発注管理や在庫管理、顧客台帳がAccessで動いている。保守を頼んでいたベテラン社員がそろそろ定年で、その人しかマクロの中身がわからない。パソコンを新しいものに替えたら急に動かなくなった経験がある、あるいはそれを怖くて試せずにいる。株式の引き継ぎや登記の変更には税理士や司法書士という相談先がいたのに、この「謎のシステム」については誰に聞けばいいのか見当がつかない――。こうした感覚を抱えている経営者は、決して少数派ではない。

Accessとは何か、なぜ先代の時代に選ばれたのか

Microsoft Accessは、Microsoft Officeに含まれるデータベースソフトの一つで、専門のプログラマーでなくても比較的簡単に「顧客一覧」「受注管理」「在庫管理」といった業務アプリケーションを組み立てられる点が特徴だった。Access（データベースソフト）という位置づけを理解しておくと見通しが良くなる。表計算ソフトのExcelと違い、Accessはデータを正規化されたテーブルとして保存し、検索・抽出・集計を得意とする。1990年代後半から2000年代にかけて、外部のシステム会社に高額な発注をせずとも、社内の詳しい人やちょっとした知り合いのSEに頼めば「それなりに使える」業務システムが作れたため、資金力に限りがある中小企業で急速に広まった。

先代がAccessを選んだ背景には、悪意も怠慢もない。むしろ当時としては合理的な判断だった。パッケージソフトは業種にフィットせず、フルスクラッチのシステム開発は数百万円から数千万円かかる。Accessなら数十万円、場合によっては社内の人件費だけで「うちの会社専用」のシステムが手に入った。先代にとっては、限られた予算の中で現場の実情に合わせて磨き上げてきた、いわば手塩にかけた道具なのだ。承継した側がこれを頭ごなしに「古い」「時代遅れ」と切り捨てると、先代や長年使ってきた古参社員の心情を逆なでしかねない。まずは「なぜこの形になったのか」を理解する姿勢が、後の移行プロジェクトを円滑にする土台になる。

「動いているから大丈夫」の裏にある3つの限界

Accessシステムが抱える限界は、大きく分けて技術面・組織面・制度面の3つに整理できる。

• 技術面: ファイルサイズの上限（1つのAccessデータベースファイルは2GBまで）、同時アクセス数が増えると極端に遅くなる、スマートフォンやタブレットからの利用を想定していない
• 組織面: 開発した本人しか改修できない、退職や引退で保守できる人がいなくなる、マニュアルやドキュメントがほぼ残っていない
• 制度面: Microsoft側が定める製品ライフサイクルに沿ってサポートが順次終了していく、新しいOSやOffice製品との互換性が保証されなくなる

このうち経営者が最も見落としやすいのが組織面のリスクだ。技術的には「まだ動く」としても、それを直せる人が社内に一人もいなくなった瞬間、システムは事実上のブラックボックスと化す。

サポート終了というタイムリミットは実在する

「Accessはずっと使ってきたから、これからも大丈夫」という感覚は、半分正しく半分間違っている。ファイル自体は開き続けられることが多いが、Microsoft社が定める製品ライフサイクルに基づき、バージョンごとに明確なサポート終了日が設定されている。Microsoft公式のライフサイクル情報によれば、Access 2019のサポートは2025年10月14日に終了し、Access 2021のサポートは2026年10月13日に終了予定である。買い切り版の最新であるAccess 2024（Office LTSC 2024に含まれる）も、2029年10月9日にはサポートが切れる予定だ（参照: Microsoft Learn 製品ライフサイクル情報）。

つまり、先代の代に導入されたAccessのバージョンによっては、EOL（サポート終了）（サポート終了）がすでに到来しているか、1〜2年以内に到来する。サポートが切れるとセキュリティ更新プログラムが提供されなくなり、脆弱性が発見されても放置されたままになる。これは会社のシステムだけでなく、そこに保存された顧客情報・取引先情報の安全性にも直結する問題だ。取引先から情報セキュリティに関するチェックシートへの回答を求められる機会が増えている今、「サポート切れのソフトで基幹データを管理している」という事実そのものが、取引継続の障害になりかねない。

サポート終了日は「システムが止まる日」ではなく「守ってもらえなくなる日」である。この違いを理解しないまま先送りすると、実際に問題が表面化してから対応するしかなくなる。

Accessが「先代の遺産」になりやすい構造的な理由

承継した会社のAccessシステムがなぜここまで属人化しやすいのか。それには構造的な理由がある。

第一に、Accessのアプリケーションは「フォーム」「クエリ」「マクロ」「VBA（Visual Basic for Applications）」という複数の要素が複雑に絡み合って動く。VBAはExcelマクロと同じ言語体系で書かれることが多く、条件分岐や外部ファイルの読み書きまで踏み込んだ処理が組まれているケースも珍しくない。こうしたコードは作った本人以外には解読が難しいことが多く、コメントや設計書が残っていないケースがほとんどだ。担当者に「このボタンを押すと何が起きているのか」を聞いても、「昔からこうなっている」としか答えが返ってこないことすらある。第二に、Accessは基本的に一人〜数人の担当者が「自分のために」あるいは「自部署のために」作り育てたものであり、全社的なIT資産として一覧管理する発想自体がなかった時代に生まれている。第三に、改修のたびに機能が継ぎ足され、当初の設計思想からどんどん離れていく。10年、20年という時間をかけて、誰も全体像を把握していない状態に育ってしまうのだ。

これはまさに属人化の典型例と言える。中小機構が運営する情報発信サイトでも、事業承継の場面でITやデジタル化への対応が重要テーマとして取り上げられている。経営権や資産の承継には税理士・司法書士・弁護士といった専門家が同席するのが当たり前になっているのに、業務システムの承継については「引き継ぎ資料」すら存在しないことが珍しくない。株式の名義や不動産の登記であれば法務局や公証役場という明確な相談窓口があるが、社内のAccessシステムについては、経営者自身がその存在意義とリスクを正確に把握し、自分で動かない限り誰も手を付けてくれない。

放置した場合に起きる典型的なトラブル

現場で実際によく起きるトラブルのパターンを挙げる。

1. パソコンの入れ替えやOSアップデートをきっかけに、突然エラーが出て起動しなくなる
2. 保守担当だった社員が退職し、軽微な修正すら誰もできなくなる
3. データ量が増え続けて動作が極端に遅くなり、月末の締め作業だけで半日かかるようになる
4. 複数人が同時に開くと「排他的に開かれています」といったエラーが頻発する
5. 取引先や監査法人からセキュリティ体制を問われた際に、答えに窮する

これらは決して大げさな想定ではない。特に1と2は、多くの支援機関やシステム会社のコラムでも繰り返し指摘されている典型パターンであり、Accessシステムを提供するベンダー各社も、老朽化したAccessシステムの保守性・安全性の観点からの見直しを共通して呼びかけている。承継直後の社長がここで焦って「今すぐ全部作り直す」と決断してしまうと、業務を止めるリスクと投資額の両面で無理が生じやすい。まずは現状を正しく棚卸しすることが先決だ。延命するか作り直すかという判断そのものの軸は、先代のシステムを「延命するか、作り直すか」の判断基準で整理している。

移行を考える前にやるべき「棚卸し」

いきなり移行先を探し始める前に、次の3点を確認しておきたい。

• 何がAccessで動いているか: 受発注、在庫、顧客管理、勤怠、見積・請求など、社内に存在するAccessファイルとその用途を洗い出す
• 誰が触れるか: 改修や軽微な修正ができる人が今も社内にいるか、退職予定はないか
• 何と連携しているか: Excelマクロ、会計ソフト、他システムとのデータのやり取りがあるか

この棚卸しの結果は、口頭やその場限りのメモではなく、一覧表のような形で文書として残すことを強く勧める。ファイル名、格納場所、主な用途、利用部署、保守できる人の氏名、最終改修時期といった項目を、Excelでもよいので一枚の表にまとめておくだけで、承継後の意思決定において「何を、いつまでに、どう移行するか」を判断する土台になる。株式の承継であれば株主名簿という台帳があるように、システムの承継にも一覧表が必要だ、と捉えるとイメージしやすいだろう。この一覧表そのものが、次にこの会社を引き継ぐ人への最良の贈り物にもなる。

移行先の選び方：3つの方向性

Accessからの移行先は、大きく3つの方向性に分けて考えると整理しやすい。

方向性1: 業務パッケージ・SaaSへの乗り換え

在庫管理、販売管理、会計、勤怠管理など、Accessで自作していた業務が一般的なものであれば、すでに世の中に存在するクラウド型の業務パッケージ（SaaS）に乗り換えるのが最も現実的な選択肢になることが多い。メリットは、ベンダーが継続的に保守・アップデートしてくれるため、サポート終了の心配から根本的に解放される点だ。一方で、Accessで作り込んでいた「うちの会社特有のルール」（特殊な値引き体系、独自の帳票フォーマットなど）がパッケージの標準機能でカバーしきれず、業務のやり方自体を変える必要が出てくる場合がある。

方向性2: ノーコード・ローコードツールでの再構築

Accessと同様に「現場の担当者が業務に合わせて組み立てる」という自由度を維持したい場合は、ノーコード・ローコードのクラウドツールに置き換える方向性がある。中小機構の「ここからアプリ」のような公的なポータルサイトでは、業種・目的別にIT導入事例やツールを検索できる仕組みが用意されており、パッケージ選定の参考情報として活用できる。ただし、ノーコードツールも運営会社のサービス継続に依存する点は変わらないため、乗り換え先が突然サービス終了するリスクがゼロではないことは念頭に置く必要がある。

方向性3: フルスクラッチでのWebシステム化

取引先との複雑な連携や、業界特有の商習慣に強く根ざした業務プロセスがあり、パッケージやノーコードでは対応しきれない場合は、Webシステムとしてゼロから作り直す選択肢もある。初期投資は他の2方向より高くなりやすいが、自社の業務にフィットした形で、かつクラウド上で複数人が同時にアクセスできる環境を構築できる。この場合は、Accessのフロントエンド部分をできるだけ薄くし、データと処理のロジックをサーバー側（Web・API側）に持たせる設計にすることで、特定のPCやOSのバージョンに依存しない仕組みに作り替えられる。このような業務を止めずに段階的にシステムを作り変える進め方は、システムリプレース（運営会社ゼットリンカーの受託メニュー）として専門に扱われている領域でもある。

移行先を選ぶ際に確認すべきチェックリスト

どの方向性を選ぶにせよ、次の観点は共通して確認しておきたい。

このチェックリストを、税理士に相談する感覚で、システム会社や身近なIT支援機関に持ち込んでみるとよい。中小機構の「デジwith」やここからアプリのような公的な相談窓口、あるいは各地の商工会議所のIT経営相談も入口として活用できる。

「一気に全部」ではなく「重要度順」で移行する

Accessシステムが複数の業務にまたがっている会社ほど、移行は一度に全部やろうとすると失敗しやすい。優先順位をつける際の目安は次の3点だ。

• 事業の継続に直結する業務（受発注・在庫・請求など）を最優先にする
• 使っている人数が多く、属人化リスクが高いものを次点にする
• 単純にExcelの延長で使っているだけの軽微なものは後回しでよい

先代が長年かけて磨き上げたAccessシステムをすべて一気に置き換えようとすると、現場の反発や業務停止のリスクが跳ね上がる。ある程度の期間をかけて段階的に移行し、並行稼働期間を設けてデータの整合性を確認しながら進める方が、結果的に失敗が少ない。

単一障害点になっていないかを最初に確認する

移行の優先順位を決める上で、もう一つ重要な視点がある。それは、そのAccessシステムが会社の業務における単一障害点（SPOF）になっていないかという点だ。特定のパソコン1台でしか動かない、特定の担当者しか操作方法を知らない、バックアップが取られていない――こうした状態は、そのパソコンが壊れる、あるいはその担当者が突然出社できなくなるだけで、会社の業務そのものが止まってしまうリスクを意味する。株式の分散や後継者不在が事業承継の大きなリスクとされるのと同じように、システムにおいてもリスクの集中は経営課題として扱うべきだ。まずはこの単一障害点を解消することを、移行プロジェクト全体の第一目標に据えるとよい。

先代・古参社員との向き合い方

技術的な移行計画と同じくらい重要なのが、人との向き合い方だ。先代がまだ会社に関わっている場合、そのAccessシステムには先代自身の思い入れがあることが多い。「昔、外注する予算がなかったから知り合いに頼んで作ってもらった」「現場の声を聞きながら少しずつ改良してきた」という経緯を、承継した社長がまず理解し、否定せずに聞く姿勢を持つことが、その後の協力を得るうえで欠かせない。

同様に、そのシステムを長年使い続けてきた古参社員にとっては、使い慣れた画面が変わること自体が心理的な負担になる。移行の目的を「システムが古いから」ではなく、「今のやり方を将来も安心して続けられるようにするため」という言葉で伝えると、現場の理解を得やすい。実際の移行作業では、現場担当者にヒアリングを重ね、彼らが日々の業務でどう使っているかを具体的に洗い出すプロセスが、要件定義の質を大きく左右する。「動いているから触るな」と言われるシステムに実際に手を入れる安全な手順は、「動いているから触るな」と古参社員に言われるシステムの安全な改修手順にまとめている。

移行にかかる期間の目安

Accessシステムの移行にかかる期間は、システムの規模によって大きく異なる。小規模なシステムであれば3〜6ヶ月程度、中規模のシステムでは半年から1年程度を見込むという整理が、システム移行を専門とする事業者からも示されている。自社の繁忙期を避け、決算期や大型商談のタイミングと重ならないようにスケジュールを組むことが、現実的な進め方になる。

移行期間中は、旧システム（Access）と新システムを並行稼働させ、一定期間データの突き合わせを行うことをお勧めする。特に金額や在庫数といった数値項目は、集計方法の違いによって微妙にズレが出ることがあるため、月次の締め作業を1〜2回並行して回し、差異がないことを確認してから完全移行する流れが安全だ。

費用感をどう捉えるか

移行にかかる費用は、選ぶ方向性によって大きく幅がある。既存のクラウド型業務パッケージへの乗り換えであれば、初期費用を抑えつつ月額の利用料で運用するモデルが一般的で、比較的小さな投資で始められる。一方、フルスクラッチでのWebシステム化は、初期投資として数百万円規模になることもあるが、自社の業務にぴったり合わせられるという利点がある。ノーコード・ローコードツールでの再構築は、その中間に位置づけられることが多い。

ここで重要なのは、金額の大小だけで判断しないことだ。安価な選択肢であっても、自社の業務に合わずに結局使われなくなれば投資は無駄になる。逆に高額な投資であっても、長期間にわたって安定して使い続けられ、属人化のリスクを根本的に解消できるのであれば、経営判断としては合理的だ。先代の代に数十万円で作られたシステムが、実は20年間ノントラブルで会社を支えてきたという事実を踏まえれば、初期費用だけでなく「何年使えるか」「誰が保守できるか」まで含めたトータルコストで比較検討する視点が欠かせない。

セキュリティ・パッチ対応という論点

先代の代のAccessシステムでもう一つ見落とされがちなのが、OSやOfficeそのものの更新プログラム適用状況だ。Accessアプリケーション自体だけでなく、それが動いているWindowsやOffice全体について、セキュリティ更新プログラムがきちんと適用されているかを確認する必要がある。難しく考えなくても、要は「セキュリティの穴をふさぐ作業が継続的に行われているか」という点だと捉えれば理解しやすい。サポートが終了したバージョンのAccessやOfficeを使い続けている場合、この更新プログラムの提供自体が止まるため、脆弱性が発見されても放置されることになる。移行を検討する際は、現行システムのOS・Officeのバージョンと、それぞれのサポート期限も合わせて確認しておきたい。特に、社内で「このパソコンは動作確認済みだから」という理由だけで長年OSのアップデートを止めている端末がある場合は要注意だ。古いOSのまま固定運用しているパソコンほど、セキュリティ更新の空白期間が長く、ウイルス感染や不正アクセスの温床になりやすい。

移行を先延ばしにするコストも見積もる

「移行にはお金も時間もかかるから、まだ動いているうちは先送りしよう」という判断は理解できる。しかし、先送りにも見えないコストが積み重なっている。保守できる人がいなくなるリスクは時間とともに高まる一方であり、退職や高齢化は待ってくれない。サポート切れの期間が長くなればなるほど、セキュリティ上の脆弱性を抱えたまま業務データを扱う期間も長くなる。さらに、システムが古いままだと、新しい取引先や金融機関からの信用力評価においても不利に働く可能性がある。

移行の意思決定を先延ばしにするのではなく、「いつまでに、何を、どこまでやるか」というロードマップだけでも先に決めておくことを勧める。予算や体制が整うタイミングを見極めつつ、少なくとも棚卸しと優先順位づけだけは今すぐ着手できる。

なぜ経営者自身が動かないと誰も気づかないのか

株式の名義変更や登記の書き換えであれば、税理士や司法書士が「これをやっておかないと後で問題になりますよ」と教えてくれる。しかし、社内のAccessシステムについては、そもそも「問題になり得るもの」だと認識している専門家が周囲にいないことが多い。顧問税理士は税務のプロであってシステムのプロではないし、取引先の担当者も自社のAccessの中身までは把握していない。結果として、経営者自身がリスクの存在に気づき、自分から声を上げない限り、誰もこの問題を持ち出してくれないという構造になっている。

これは事業承継全体に共通する構図でもある。中小企業庁が公表している事業承継ガイドラインでも、後継者が経営権や資産の承継だけでなく、業務プロセスや暗黙知の承継にも目を向ける必要性が繰り返し指摘されている。Accessシステムは、まさにこの「暗黙知の承継」が最も抜け落ちやすい領域の一つだ。決算書や契約書のようにファイルとして目に見える資産ではなく、画面の裏側にあるロジックやデータ構造という、外からは見えにくい形で存在しているからこそ、承継のチェックリストから漏れやすい。

経営者が最初に聞くべき質問リスト

先代や古参社員、あるいはAccessシステムを作った外部の協力者がまだ連絡の取れる状態にあるなら、承継のタイミングで一度、次のような質問を投げかけておくとよい。

• このシステムは誰が、いつ頃、どんな経緯で作ったのか
• これまでに大きな改修をしたことはあるか、あるとすれば何がきっかけだったか
• 今、修正や追加ができる人は社内外に何人いるか
• バックアップは取っているか、取っているとすれば頻度と保存場所はどこか
• このシステムが止まったら、業務にどれくらいの影響が出るか

これらの質問への回答が「わからない」「昔からそうなっている」ばかりであれば、それ自体が重大なリスクシグナルだと受け止めるべきだ。逆に、多少なりとも明確な答えが返ってくるなら、その内容を書き留めておくだけで、将来の移行プロジェクトの初期調査にかかる時間を大きく短縮できる。

承継のタイミングこそシステム刷新の好機である理由

「せっかく先代が作ったものを、承継してすぐに壊すのは気が引ける」という心理は自然なものだ。しかし、視点を変えれば、経営交代のタイミングは、実はシステム刷新に最も適したタイミングでもある。

第一に、新しい体制のもとで業務フローそのものを見直す機会になる。先代の時代に確立されたやり方を無条件に踏襲するのではなく、「本当に今のやり方が最適か」を検討し直すきっかけとして、システム移行のプロジェクトを位置づけることができる。第二に、経営者交代は社内外に「変化のタイミング」として自然に受け止められやすい。数年間安定稼働している状況でいきなりシステムを変えるよりも、社長交代という大きな変化の一部として説明する方が、現場の心理的な抵抗が小さくなる傾向がある。第三に、先代がまだ会長や相談役として関わっている場合は、旧システムの背景を直接ヒアリングできる最後のチャンスでもある。この機会を逃すと、先代が完全に引退したあとでは、システムの経緯を知る手がかりが失われてしまう。

移行を機に業務フローそのものを見直す視点

Accessシステムの移行は、単に「同じ機能を新しい入れ物に移す」作業ではない。むしろ、20年前に確立された業務フローそのものを、今の会社の規模や取引先の数、従業員構成に合わせて見直す絶好の機会だと捉えるべきだ。

例えば、先代の時代には従業員が5人だったために「担当者が全部を把握している前提」で設計されていた業務が、今は30人規模になって分業が進んでいる、というようなケースは多い。この場合、単純にAccessの機能をそのままパッケージやWebシステムに置き換えるのではなく、承認フローや権限管理といった要素を新たに組み込む必要が出てくる。逆に、Accessの時代には手作業で行っていた確認作業を、システム側で自動化できる部分も見えてくるはずだ。移行プロジェクトの要件定義の段階で、「今のAccessと同じことができればいい」という発想に留まらず、「今の会社の実態に合わせるとどうあるべきか」を問い直すことで、単なる置き換え以上の価値を得られる。

相談先の探し方：システムにも「顧問」を持つという発想

株式や登記には税理士・司法書士という顧問がいるのに、システムには相談先がいない――この孤独感を解消する第一歩は、「システムにも顧問を持つ」という発想を持つことだ。

具体的な相談先としては、次のような選択肢がある。

1. 地元の商工会議所・商工会: IT経営相談の窓口を設けている場合があり、無料または低額で初期相談ができる
2. 中小企業基盤整備機構が運営する公的ポータルサイト: 業種・目的別にIT導入事例やツールを検索でき、中立的な立場からの情報収集に向いている
3. 地域のシステム開発会社: Accessからの移行実績を持つ会社であれば、具体的な見積もりと進め方の提案を受けられる
4. 同業種・同規模の経営者ネットワーク: 実際に似たようなシステムを移行した経験を持つ経営者仲間からの生の情報は、公的機関の情報より実践的なことが多い

いきなり1社に絞って発注するのではなく、複数の相談先から話を聞き、提案内容や見積もりを比較検討する姿勢が重要だ。株式の評価を複数の専門家に見てもらうのと同じ感覚で、システムの現状診断についても複数の視点を集めることをお勧めする。

移行にまつわる「よくある誤解」を解いておく

Accessからの移行を検討する経営者の間で、しばしば誤解されている点をいくつか整理しておきたい。

• 誤解1: 「Accessを使い続けても、壊れるまでは無料だから安い」 — 見えるコストは低くても、属人化によるトラブル対応の遅延、セキュリティリスクの放置、取引先からの信用低下といった見えないコストが積み重なっている
• 誤解2: 「移行すれば全ての問題が一気に解決する」 — 移行そのものはあくまで手段であり、業務フローの整理や運用ルールの明文化を伴わなければ、新しいシステムでも属人化が再発する
• 誤解3: 「クラウド化すればセキュリティは自動的に安全になる」 — クラウドサービスもID・パスワード管理やアクセス権限の設定次第でリスクが残る。移行先を選ぶ段階でセキュリティ設定の柔軟性も確認すべき
• 誤解4: 「先代に相談すると角が立つから黙って進めた方がいい」 — 先代の理解を得ずに水面下で進めると、後になって「なぜ勝手に変えたのか」という不信感を招きやすい。早い段階で背景を共有し、協力を仰ぐ方が結果的にスムーズに進む

まとめ：承継社長が今日からできる3つのこと

最後に、この記事の内容を承継社長がすぐに行動に移せる形でまとめる。

1. 社内にあるAccessシステムを全て洗い出し、それぞれの用途・利用者・保守できる人を書き出す（システム管理台帳の第一歩）
2. 使っているAccessのバージョンを確認し、Microsoft公式のライフサイクル情報でサポート終了日をチェックする
3. 単一障害点になっているシステムを特定し、そこから優先的に移行の検討を始める

先代が築いた仕組みには、その時代なりの合理性があった。承継した社長の役目は、それを否定することではなく、次の10年、20年も会社が安心して事業を続けられる形に作り替えていくことだ。株式や登記の手続きに専門家がいるのと同じように、システムの承継にも相談できる専門家がいる。まずは現状を正確に把握するところから、着実に一歩を踏み出してほしい。VB6・Delphiで組まれたシステムなど、他の言語・技術で作られた先代システムの移行タイミングについては、VB6・Delphi製の先代システムはいつまで動くか。移行タイミングの見極めも参考になる。オフコンや汎用機で動く基幹システムの場合はオフコンで動く先代の基幹システム、いつまで使い続けられるかを参照してほしい。

よくある質問

Q1. Accessで動くシステムは、サポートが終了したらすぐに使えなくなりますか？

いいえ、サポートが終了しても、ファイル自体がすぐに開けなくなったり、システムが即座に停止したりするわけではありません。しかし、セキュリティ更新プログラムの提供が止まり、脆弱性が発見されても修正されない状態が続きます。また、新しいOSやOfficeとの互換性が保証されなくなるため、パソコンの入れ替えなどをきっかけに動作しなくなるリスクが高まります。

Q2. Accessを保守できる人が社内にいません。今すぐ移行すべきでしょうか？

保守できる人が不在の状態は、単一障害点として早めに対応すべきリスクです。ただし「今すぐ全部作り直す」必要はありません。まずは現状のAccessシステムがどの業務を支えているかを棚卸しし、事業継続への影響が大きい業務から優先順位をつけて移行を検討する進め方をお勧めします。

Q3. 移行先はパッケージソフトとフルスクラッチ開発、どちらを選ぶべきですか？

自社の業務が一般的な流れに沿っているならパッケージ・SaaSへの乗り換えが低コストで済みやすく、業界特有の商習慣や複雑な取引先連携があるならフルスクラッチでのWeb化が適しています。判断に迷う場合は、まず自社の業務フローとAccessでの独自ルールを整理したうえで、複数のシステム会社や公的なIT相談窓口に相談し、比較検討することを勧めます。

Q4. 先代が作ったシステムを変えることに、社内から抵抗があります。どう進めればよいですか？

移行の目的を「古いから捨てる」ではなく「今のやり方を将来も安心して続けるため」と伝えることが有効です。先代や長年使ってきた古参社員には、システムが作られた経緯や工夫を丁寧にヒアリングし、その知見を新システムの要件定義に反映させる姿勢を見せることで、協力を得やすくなります。