先代のレガシーシステム、壊れる前にデータだけ救出する方法

レガシーシステムからデータだけ救出する方法

先代が使っていた販売管理ソフトが、いつのバージョンのWindowsで動いているのかも分からない。触ると壊れそうで、かといって業務は止められない。承継してから半年、一年と経つうちに「そろそろ何とかしないと」という焦りだけが積もっている——そんな状態の方に向けて、この記事を書いています。パソコンに詳しい社員は今の会社にはおらず、かといって外部の誰に相談すればいいのかも分からない。そんな孤独な状況の中で、今日から一人でも始められる具体的な手順をお伝えします。

結論から言うと、レガシーシステムの全面刷新をいきなり狙う必要はありません。まず着手すべきは「システムを動かし続けること」ではなく「中に入っているデータだけを、今のうちに安全な形で取り出しておくこと」です。ソフト自体が壊れても、データさえ手元にあれば業務は止まりません。逆にデータを救出しないままシステムが止まると、顧客名簿も取引履歴も一瞬で失われます。

株式や登記の引き継ぎには税理士や司法書士という相談先がいますが、「先代が20年前に導入した謎のシステムのデータをどう救い出すか」を相談できる専門家は、身近にはなかなかいません。会社を継いだ経営者の多くが、法務・税務の手続きには専門家の伴走を得られる一方で、システムの問題だけは自分一人で抱え込んでいます。この記事では、非IT出身の経営者でも一人で進められるレベルまで手順を分解して説明します。難しい専門用語は最小限にとどめ、今日から動ける形にしています。

なぜ「今」データ救出が急務なのか

EOL（サポート終了）を迎えたシステムは、壊れてから対処するのでは手遅れになります。実際に、Microsoft Access 2021の主流サポートは2026年10月13日に終了することが、Microsoft公式のライフサイクル情報で明記されています(Access 2016/2019はすでに2025年10月14日に終了済み)。サポート終了後は新しいWindows更新プログラムとの相性問題が起きても修正パッチが提供されず、ある日突然データベースファイルが開けなくなるリスクが高まります。

さらに経済産業省が2018年に公表した「DXレポート」では、21年以上稼働している基幹系システムが2025年には全体の約6割に達すると指摘されました。先代の代から使い続けている業務システムの多くが、まさにこの「レガシー」の年代に該当します。承継のタイミングというのは、皮肉なことに「システムが最も高齢化したタイミング」と重なりやすいものです。先代が10年、20年前に導入したシステムをそのまま引き継いだ二代目・三代目の社長であれば、なおさらこの節目に直面している可能性が高いといえます。

システムが古いこと自体が悪いのではなく、「壊れたときに誰も直せない」「壊れる前触れに誰も気づけない」状態こそが承継後の会社にとって最大のリスクです。

このリスクを避けるために必要なのは、システムの延命ではなく「データの避難」です。株式や登記の名義変更であれば、税理士や司法書士が手続きの道筋を示してくれます。ところが「先代の代のシステムに入っているデータをどう守るか」という問いに答えてくれる専門家は、身近な相談先の中には見当たらないことがほとんどです。結果として、多くの経営者はこの問題を「後回し」にしたまま、日々の業務に追われていきます。

しかし、後回しにできる猶予は思っているより短いかもしれません。ハードウェアの故障、OSの大型アップデートによる非対応、あるいは唯一の有識者だった古参社員の退職——これらはどれも予告なく起こります。逆にいえば、「まだ動いている」今この瞬間こそが、最も低コストでデータを救出できるタイミングです。壊れてから業者に泣きつくと、復旧費用も納期も足元を見られやすくなります。動いているうちに手を打つことの価値は、想像以上に大きいのです。

データ救出とシステム移行を混同しない

多くの経営者が最初につまずくのは、「データを救出する」ことと「新システムに全面移行する」ことを同じ話だと考えてしまう点です。この2つは目的も規模もまったく異なるプロジェクトとして切り分けるべきです。

Accessなどのデータベースソフトからの本格的な脱却プロジェクトは、標準的なロードマップとして6ヶ月程度を要するとされています。これは業務要件の整理や新ツールの選定、テスト運用まで含めた期間です。また移行先の規模によっては、シンプルな管理台帳程度なら数十万円から対応できる一方、複雑な業務フローを持つシステムでは数百万円規模の投資になることもあると言われています。こうした本格移行の話を最初から意識してしまうと、「予算がない」「時間がない」という理由で結局何も手を付けられずに終わってしまいます。しかし「データだけを救出する」作業に限れば、これほど大きな意思決定は不要です。まずは小さく、確実に着手できる範囲から始めましょう。全面移行は、データという最も大切な資産を守った後で、落ち着いて検討すればよいのです。

ステップ1: 何が「先代システム」の中に眠っているかを棚卸しする

データ救出の第一歩は、闇雲にエクスポートボタンを押すことではなく、「どこに何のデータがあるか」を可視化することです。承継直後の会社では、これが驚くほど整理されていません。先代は頭の中にすべてを把握していたかもしれませんが、その暗黙知は代替わりと同時に失われてしまいます。

典型的には、次のようなシステムやファイルが社内のあちこちに散らばっています。

• 販売管理ソフト(顧客・受注・請求データ)
• Access（データベースソフト）で作られた自社製の在庫管理表
• 経理担当者のPCにだけ入っている給与計算ソフト
• 総務担当が個人的に作ったVBAマクロ付きExcelの勤怠集計表
• 先代が個人的に契約していたクラウドサービスのアカウント
• 紙の台帳をスキャンしただけの請求書PDFフォルダ

これらを一覧化する作業こそ、システム管理台帳の第一歩です。台帳を作る目的は管理そのものではなく、「このデータが消えたら会社が困る」ものを漏らさず洗い出すことにあります。棚卸しの際は、次の3点をメモしておくと後工程がスムーズになります。

1. ソフト名・バージョン・導入時期(分かる範囲でよい)
2. 開発者や導入業者の連絡先が今も生きているか
3. そのデータを日常的に触っている担当者は誰か(多くの場合、古参社員が該当します)

棚卸しは机上で完結する作業ではありません。実際に各担当者のパソコンの画面を見せてもらい、「普段どの画面を開いて、何を入力しているか」を確認する必要があります。ここで経営者自身が現場に足を運ぶことには、単なる情報収集以上の意味があります。「社長が自分たちの仕事に関心を持ってくれている」というメッセージにもなり、後の協力を得やすくする土台になるからです。

古参社員に聞き取りをする際は「このシステムをやめる」ではなく「万一の時に困らないよう控えを取りたい」というトーンで伝えると、警戒されずに協力を得やすくなります。長年そのシステムを一人で運用してきた社員にとって、システムの話は自分の存在意義そのものに直結していることも少なくありません。急に「これは古いから変える」と言われれば、自分の仕事を否定されたと感じてしまう人もいます。まずは敬意を払いながら、「あなたが今まで守ってきたデータを、これからも会社の財産として残したい」というスタンスで臨むことが、円滑な棚卸しの鍵になります。

ステップ2: 壊れる前に「読み出せる状態」を確保する

棚卸しが終わったら、次はデータを実際に取り出す作業です。ここで意識すべきは、「システムを直す」のではなく「システムがまだ動いているうちに、中身をコピーする」という発想です。修理や刷新を先に考える必要はまったくありません。今動いているものを、動いているうちに写し取ることが最優先です。

Accessのようなデータベースソフトの場合、Microsoft公式のサポートページでも案内されている通り、ナビゲーションウィンドウでテーブルやクエリを右クリックし、「エクスポート」から「テキストファイル」を選ぶことでCSV形式に書き出せます。CSVへのエクスポートには件数上限がなく、他システムへの取り込みでも扱いやすい汎用フォーマットである点が実務上の大きなメリットです。ExcelやAccessだけでなく、ほとんどの業務ソフトはCSV形式でのデータ出力機能を備えています。手順の骨格は次のとおりです。

1. 元のファイル(.accdbや.mdbなど)をまるごとコピーして別の外付けドライブやクラウドストレージに保存する(最も確実な保険)
2. 主要なテーブルを一つずつCSV形式でエクスポートする
3. エクスポートしたCSVを開き、文字化けや欠落がないか目視確認する
4. 元データと突き合わせて件数が一致しているか確認する
5. 複数の場所(社内サーバー・クラウド・外付けドライブなど)に分散して保管する

「動いているうちにコピーを取る」だけで、単一障害点（SPOF）の状態(そのシステム1つが壊れたら全データが消える状態)から抜け出せます。これがデータ救出の本質です。

作業を進める際は、必ず「まずファイルごとバックアップを取ってから、コピーに対して作業する」という順序を守ってください。元のシステムに直接手を加えて何かを削除したり、設定を変更したりする必要は一切ありません。あくまで「複製を作る」だけの引き算のない作業です。この原則を守っていれば、仮に操作を間違えても、元のシステムには何の影響も及びません。

Excelで管理されたVBAマクロ付きの表も同様に、マクロ機能に依存しない「値だけのコピー」をCSVやシートのバックアップとして残しておくと安全です。マクロの中身は動作原理が分からないことも多いため、無理に解読しようとせず、まずは「出力結果のデータ」を確保することを優先してください。マクロがどう動いているかを理解するのは、データが安全になった後でも遅くありません。

データ量が非常に多い場合や、複数のテーブルが複雑に関連し合っている場合は、ODBC接続という仕組みを使って外部のデータベースに丸ごと接続・移行する方法もあります。ただしこれは専門知識を要する作業になりやすいため、非IT出身の経営者が一人で無理に挑戦するよりも、まずは範囲を絞ってCSVで確実に主要データを確保することを優先し、複雑な移行は外部の専門家に依頼する判断も選択肢に入れておくとよいでしょう。

ステップ3: 救出したデータの置き場所と引き継ぎ方を決める

データを取り出しただけでは安心できません。次に決めるべきは「誰が」「どこで」「どうやって」そのデータにアクセスできるようにするか、という保管ルールです。せっかく救出したデータも、置き場所が一人のパソコンの中だけでは、また同じ問題を先送りしているにすぎません。

• 属人的な個人のPCやローカルフォルダにだけ置かない(担当者の異動・退職で行方不明になる属人化の典型パターン)
• クラウドストレージなど、経営者自身もアクセス権を持つ場所に複製を置く
• ファイル名に日付を入れ、いつ時点のデータかが分かるようにする
• 誰がいつバックアップを取ったか、簡単な記録を残す
• 定期的に(たとえば月に一度)同じ手順で再度バックアップを取り、更新する

この段階で欲張って「新しいシステムに全部きれいに入れ直そう」とすると、プロジェクトが肥大化して止まってしまいがちです。まずは「壊れても困らない状態」を作ることをゴールにし、本格的な新システム選定は落ち着いてから別プロジェクトとして進める方が現実的です。実際、システム再構築のガイドラインでも、現行システムの仕様とデータ形式・運用実態をまず正確に把握することが移行成功の前提条件として位置づけられています。データの棚卸しと保全は、その最初の一歩そのものです。

たとえば、ある製造業の二代目社長のケースでは、先代が導入した受注管理ソフトのサポートがすでに終了していることに気づいたものの、日々の受注処理に追われて手を付けられずにいました。そこでまず休日の半日だけを使い、直近3年分の受注データだけをCSVでエクスポートし、クラウドストレージに保存するところから着手しました。全データの移行には至っていませんが、「最悪ソフトが動かなくなっても、直近の取引履歴だけは手元にある」という安心感は、それだけで経営上の大きな違いを生みます。データ救出は、こうした小さな一歩の積み重ねで十分に前進できる作業なのです。

セキュリティ更新プログラムが提供されなくなった環境にデータを置き続けることも、パッチマネジメントの観点でリスクになります。サポート終了後のOSやソフトウェアは、新たに見つかった脆弱性が修正されないまま放置される状態になります。救出したデータの保管先は、少なくとも定期的に更新プログラムが適用される環境を選びましょう。

また、保管ルールを決めたら、それを紙一枚でもよいのでメモに残し、経理担当や後継の役員など複数人で共有しておくことをおすすめします。経営者一人だけがバックアップの場所を知っている状態は、結局のところ「システムのブラックボックス化」を「経営者の頭の中のブラックボックス化」に置き換えているだけだからです。

承継直後だからこそ生まれる「特有の壁」

データ救出という作業そのものは、実はどの会社にとっても本質的には同じ手順です。しかし承継直後の経営者には、創業社長や生え抜きの後継者にはない、いくつか特有の壁が立ちはだかります。

一つ目は、「そのシステムがなぜ今の形になっているのか」という経緯を経営者自身が知らないという壁です。創業社長であれば、自分が導入を決めた経緯や、当時の業務課題を覚えています。しかし先代から引き継いだ社長にとっては、目の前のシステムは「気づいたらそこにあったもの」です。なぜこのExcelシートにこの列があるのか、なぜこの入力欄だけ手入力なのか——理由が分からないまま扱わなければならない不安は、創業者にはない独特の重さがあります。この不安を解消する近道はなく、地道に棚卸しをしながら一つずつ「なぜ」を担当者に聞いていくしかありません。

二つ目は、社内の人間関係における立場の違いです。創業社長であれば「自分がすべて決めた」という前提で堂々と方針転換ができます。しかし承継した社長、特に若い世代の二代目・三代目は、自分より社歴の長い古参社員に対して「これはこうしましょう」と言いにくい空気を抱えていることが少なくありません。データ救出の作業も、この人間関係の機微を無視して進めると、「急に何を言い出すんだ」という反発を招きかねません。前述の通り、目的を「システムを変える」ではなく「データを守る」というフレーミングに置き換えることが、この壁を越える実務的な工夫になります。

三つ目は、時間的な余裕のなさです。承継直後は、取引先への挨拶回り、金融機関との関係構築、社内での信頼獲得など、経営者としてやるべきことが山積みです。その中で「システムのデータ救出」という地味で目立たない作業に時間を割く優先順位は、どうしても後回しにされがちです。しかし、この記事で紹介した棚卸しとCSVエクスポートは、一度に何十時間もかかる作業ではありません。まずは最も重要な顧客データや受注データ一つに絞って、半日だけ時間を確保するところから始めても十分に意味があります。小さく始めて、少しずつ範囲を広げていくやり方の方が、承継直後の忙しい経営者には現実的です。

よくある失敗パターンと回避策

データ救出の現場では、いくつか典型的なつまずきが繰り返されています。あらかじめ知っておくことで、同じ轍を踏まずに済みます。

• バックアップを取らずに直接いじってしまう: 「エクスポートするだけだから大丈夫」と思っても、操作ミスで元データを破損させる事故は起こり得ます。必ず元ファイルの複製を先に取ってから作業してください。
• 文字化けに気づかず放置する: 古いシステムは文字コード(Shift-JISなど)が現在主流のUTF-8と異なることが多く、CSVエクスポート後に住所や氏名が文字化けするケースがあります。開いて目視確認する工程は省略しないでください。
• 開発した業者と連絡が取れない: 先代の代に導入した業者が廃業・世代交代しているケースは珍しくありません。連絡が取れるうちに、せめてデータ構造の説明だけでも聞いておくと後々の助けになります。
• 「そのうちやる」で先延ばしにする: サポート終了後のシステムは、ある日突然起動しなくなることがあります。着手のタイミングは「時間ができたら」ではなく「動いている今」です。
• 一部のデータだけ救出して満足してしまう: 目につきやすい顧客名簿だけ救出して、経理データや過去の取引履歴を後回しにしてしまうケースもあります。棚卸しの段階で洗い出した一覧と照らし合わせ、抜け漏れがないか必ず確認しましょう。

「データがどこにあるか分からない」状態のまま先代からシステムを引き継いでしまうと、いざという時に何を失ったのかすら分からなくなります。棚卸しの一覧表そのものが、承継後の会社にとって最初の防波堤になります。

これらの失敗の多くは、「急いで一気にやろうとする」ことから生まれます。データ救出は完璧を目指すよりも、まず主要な部分から確実に、段階的に進めることの方が結果的に安全です。

専門家に頼るべきタイミングの見極め方

ここまで紹介した棚卸しとCSVエクスポートは、非IT出身の経営者でも一人で進められる範囲の作業です。しかし、次のような状況に当てはまる場合は、無理をせず外部の専門家に相談することも検討してください。

• データベースのファイル自体がすでに開けない、エラーが出て起動しない
• テーブル同士の関連(どのデータとどのデータが紐づいているか)が複雑で、自分では構造が理解できない
• 数万件を超える大量データで、目視確認だけでは限界がある
• 個人情報や機密性の高いデータを扱っており、セキュリティ面での不安がある

このような場合、地域のIT支援機関や商工会議所のIT相談窓口、あるいはシステム開発を専門とする会社に相談する選択肢があります。開発した業者と連絡が取れない、担当者しか触れないブラックボックス状態のシステムを専門に調査・引き継ぐ会社（システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー）もあります。相談する際は、いきなり「システムを全部作り直したい」と伝えるのではなく、まず「棚卸しの一覧表」と「これまでに救出できたデータの範囲」を持参すると、話が具体的でスムーズに進みます。専門家側にとっても、経営者が事前に整理してくれている情報があるかないかで、見積もりの精度も提案のスピードも大きく変わってきます。

また、専門家に依頼する場合の費用感についても、あらかじめ相場観を持っておくと安心です。目安として、シンプルな管理台帳レベルのデータ移行であれば数十万円程度から対応できる場合がある一方、業務フローが複雑に絡み合った基幹システムでは数百万円規模の投資になることもあると言われています。金額に幅があるのは、データ量や構造の複雑さ、移行先に求める機能によって作業範囲が大きく変わるためです。だからこそ、依頼前の自社での棚卸しが、見積もりの精度を左右する重要な準備になります。何も整理されていない状態で相談すると、業者側も手探りで高めの見積もりを出さざるを得なくなることがある、という点も覚えておいて損はありません。

まとめにかえて

先代が築いたシステムを前にすると、「壊すのが怖い」「触ると何が起きるか分からない」という不安が先に立つのは自然なことです。しかし、データ救出はシステムを壊す作業ではなく、むしろシステムに何かあっても会社を守るための保険をかける作業です。株式や登記のように専門家が並走してくれる手続きとは違い、この作業は経営者自身が最初の一歩を踏み出すしかありません。しかしその一歩は、思っているよりずっと小さく、今日からでも始められるものです。

先代が長年守ってきたシステムとデータは、そのまま会社の歴史そのものでもあります。それを次の世代に安全な形で引き継ぐことは、決して後ろ向きな作業ではありません。むしろ、先代が築いてきたものを尊重しながら、これから先の会社を守るための、前向きな一歩です。まずは棚卸しから、できるところから着手してみてください。小さく始めた一歩が、数年後には「あの時やっておいてよかった」と思える備えに変わっていくはずです。

よくある質問

Q1. 先代が作ったシステムを「もう使わない」と伝えると、機嫌を損ねてしまいそうで心配です。どう切り出せばいいですか。 A. データ救出の段階では「システムをやめる」という話をする必要はありません。「大事なデータだから念のため控えを取っておきたい」という説明で十分です。先代の功績を否定するのではなく、これまで培ってきたデータを守るための作業だと伝えると角が立ちにくくなります。実際にシステムをどうするかという判断は、データが安全になった後でゆっくり考えても遅くありません。

Q2. 経理データを一人で握っている古参社員がいます。データ救出に協力してもらえるか不安です。 A. 古参社員にとっても「自分がいなくなったらどうなるのか」という不安を抱えているケースは少なくありません。属人化を解消する話ではなく、「もしもの時に業務が止まらないようにするための準備」という位置づけで依頼すると、協力を得やすくなります。棚卸しの聞き取りも、まずはその担当者の知見に敬意を払う姿勢で進めてください。長年一人でシステムを支えてきた労をねぎらう一言があるだけでも、協力の得やすさは大きく変わります。

Q3. データを取り出したら、元のシステムはすぐに使うのをやめるべきですか。 A. 必ずしもそうする必要はありません。データ救出はあくまで「保険」であり、日常業務に使っているシステムを即座に止める話とは別です。まずは安全な控えを確保した上で、本格的な移行や刷新は業務への影響を見極めながら計画的に進めるのが現実的です。焦って切り替えることで業務が混乱するリスクの方が、むしろ大きい場合もあります。

Q4. 会社を継いだときの契約書や登記には司法書士がいましたが、システムのデータ移行は誰に相談すればいいのでしょうか。 A. 現状、システムデータの引き継ぎに特化した公的な相談窓口は限られています。地域のIT支援機関や商工会議所のIT相談窓口、あるいはシステム開発会社に個別に相談するのが現実的な選択肢です。まずは自社でできる「棚卸し」と「バックアップ」を済ませておくと、専門家に相談する際の話がスムーズに進み、見積もりの精度も上がりやすくなります。法務・税務の手続きに比べて相談窓口が可視化されていない分野だからこそ、自分で動ける範囲を広げておくことが、結果的に会社を守ることにつながります。

この記事の次に読みたい記事

• VB6・Delphi製の先代システムはいつまで動くか。移行タイミングの見極め
• 先代のシステムを「延命するか、作り直すか」の判断基準
• Accessで動く先代の業務システムの限界と移行先の選び方