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

「このシステムは廃止する」。経営会議でそう決まった瞬間、担当者の頭によぎるのはシステムの解約手続きよりも先に、もっと切実な不安ではないでしょうか。「あのデータ、ちゃんと取り出せるのか」という不安です。10年、15年と使い込んできたシステムには、取引先の履歴、顧客とのやり取り、過去の見積もりや契約条件など、業務の記憶そのものが蓄積されています。システム自体は古くなっても、そこに詰まったデータの価値は失われていません。むしろ、作り直しや別システムへの移行を機に、これまでのデータを整理して活かせるかどうかが、次のシステムの使い勝手を左右すると言っても過言ではありません。

ところが実際には、「システムを止める」ことと「データを守る」ことが同時進行になり、気づいたときには契約が切れてサーバーにアクセスできなくなっていた、担当者が退職してログイン情報が分からなくなっていた、といった事態が起こります。作り直すか延命するかという判断がついた後でも、データ救出という作業は独立して計画しなければ、取り返しのつかない形で抜け落ちてしまうのです。

この記事では、「システム自体は作り直す、あるいは廃止すると決めた」という前提のもとで、その前に長年蓄積したデータだけは確実に救出するための考え方と手順を解説します。どんなシステムにも当てはまる万能の手順書ではなく、判断のための地図として読んでください。

この記事で分かること

システムの刷新・移行・廃止に先立って行う「データ救出」を、行き当たりばったりの作業ではなく計画的なプロジェクトとして進めるための考え方を解説します。具体的には、何を残すべきかの絞り込み方、エクスポート手法の選択肢とそれぞれの限界、救出したデータの検証方法、保存と引き渡しの形式、そしてベンダーとの調整という5つの観点を扱います。

先に要点を示すと、データ救出は次の順序で進めることが望ましい進め方です。

• 棚卸し: 何のデータが、どこに、どんな形式で存在するかを洗い出す
• 選別: 全データを残すのではなく、業務上・法令上必要なものを絞り込む
• 抽出: システムが提供する手段でデータを取り出す(エクスポート機能・DB直接アクセス・API・画面操作)
• 検証: 取り出したデータが欠損・文字化けなく正しいかを確認する
• 保管: 誰が見ても使える形式で、複数箇所に保存する

特に強調しておきたいのは、「システムが動いているうちにしかできない作業がある」という点です。稼働中のシステムからのデータ抽出は、契約が切れたり開発会社と連絡が取れなくなったりした後では、著しく困難になるか、不可能になります。作り直しの意思決定が済んだら、データ救出の着手は先延ばしにしないことが最大の防御策です。

なぜ「作り直す前提」でもデータ救出を独立させて考えるべきか

結論から言うと、システム刷新プロジェクトの中に「データ移行」という工程は存在しても、それは「新システムに合わせてデータを整形する」作業であり、「今あるデータを漏れなく安全に取り出す」作業とは目的が異なります。この違いを理解しておかないと、新システムの要件定義に合わせて必要なデータだけを抜き出した結果、新システムでは使わないが業務記録として重要な過去データが、旧システムの廃棄とともに消えてしまうことがあります。

たとえば、次のような性質を持つデータは、新システムの機能要件には直接関係しないため、通常のデータ移行計画からは見落とされがちです。

• 過去に解約・失注した取引先とのやり取りの履歴
• 監査や税務調査のために一定期間保管する義務がある帳票類
• すでに販売終了した商品・サービスに関する記録
• トラブル対応や苦情処理の経緯を示すログ

新システムの要件定義書には「今後使う機能」は書かれていても、「過去のデータをどこまで、どんな形で保持するか」は明記されていないことが少なくありません。データ救出は、新システムの要件定義とは別立てで、旧システム側の担当者が主導して計画する必要があります。

「作り直すかどうか」の判断軸については、TCOや技術的負債の観点から評価する方法を別記事で詳しく解説しています。作り直しの意思決定がすでに済んでいる方は、その判断を前提に、この記事で救出計画を具体化してください。

ステップ1: 何を残すか決める(全データを救出しようとしない)

データ救出と聞くと、「システムの中にあるものを全部コピーすればいい」と考えがちですが、これは多くの場合、非現実的です。長年運用されたシステムには、テスト用のダミーデータ、重複した入力、すでに意味を失った設定値なども大量に混在しています。全部を後生大事に持ち出そうとすると、作業量が膨れ上がるだけでなく、肝心の重要データの検証がおろそかになるという本末転倒が起こります。

まず着手すべきは、「残すべきデータ」と「残さなくてよいデータ」を仕分ける基準づくりです。

• 法令・契約上の保存義務があるデータ: 帳簿書類、契約書、一定の医療・労務関連記録など。保存年数は業種・書類の種類によって異なるため、顧問税理士や社労士に確認するのが確実です。
• 将来の業務で参照する可能性が高いデータ: 顧客の取引履歴、価格交渉の経緯、過去の見積もり条件など。
• トラブル対応の根拠となるデータ: クレーム対応履歴、契約不適合が疑われた際のやり取りなど。契約不適合責任が問題になった場合、当時の記録が自社を守る材料になります。
• もう参照する見込みがないデータ: テストデータ、重複レコード、すでに退職・廃業した取引先の初期問い合わせなど。

この仕分けを担当者一人の感覚だけで行うと、後になって「あのデータも必要だった」と発覚するリスクがあります。可能であれば、経理・営業・現場の関係者に「過去のデータで、これだけは残してほしいものはあるか」を短時間でもヒアリングしてから、保存範囲を確定させてください。

ステップ2: エクスポート手法の選択肢と、それぞれの限界

「何を残すか」が決まったら、次はどうやって取り出すかです。取り出し方はシステムの作りによっていくつかの選択肢があり、それぞれに一長一短があります。ここで重要なのは、「このやり方をすれば必ずうまくいく」という万能の正解はなく、システムの状態に応じて手段を組み合わせる必要があるという点です。

標準のエクスポート機能を使う

多くの業務システムには、画面上に「CSV出力」「Excel出力」といったエクスポート機能が用意されています。これが使える場合は最も手軽で、専門知識がなくても実行できます。ただし、次のような制約があることが多いため、事前に確認してください。

• 一度に出力できる件数に上限があり、大量データは分割出力が必要になる場合がある
• エクスポート項目があらかじめ固定されており、必要な項目が含まれていないことがある
• 文字コードの扱いがシステムによって異なり、CSVで出力した際に文字化けが起きることがある
• 関連するテーブル同士の紐づき(たとえば「注文」と「注文明細」の対応関係)が、1つのファイルにまとめて出力されると崩れる場合がある

データベースに直接アクセスする

システムの裏側で動いているデータベース(Access、SQL Server、MySQLなど)に、管理者権限で直接アクセスし、テーブルごとにデータを抽出する方法です。標準のエクスポート機能よりも網羅性が高く、隠れたデータまで拾える可能性がありますが、次の条件が揃っていることが前提になります。

• データベースの管理者アカウントとパスワードが分かっていること
• テーブルの構造(どのテーブルに何が入っているか)がある程度分かっていること、または調査する時間があること
• 社内、または依頼できる技術者にデータベース操作の知識があること

この方法は技術的な難易度が上がるため、社内に詳しい人がいない場合は、無理に自力で行おうとせず、スポットでの技術支援を外部に依頼することも検討してください。データベースの構造が分からない状態での調査手順は、別記事「仕様書がないシステムを引き継いだときの調査手順」で扱っています。

APIやツールを使った自動抽出

比較的新しいクラウドサービスであれば、外部連携用のAPIが用意されている場合があります。API経由での抽出は、標準エクスポートよりも柔軟にデータを取得できる一方、API仕様の理解とある程度のプログラミング、あるいはノーコードの連携ツールの知識が必要になります。ノーコード・ローコードツールで対応できるケースもありますが、データ量が多い場合や、頻繁な仕様変更があるシステムでは、単純作業の繰り返しにならざるを得ないこともあります。

最後の手段としての画面操作による手動転記

エクスポート機能もデータベースへのアクセス手段もない、非常に古いシステムでは、画面に表示された内容を目視で確認しながら手作業で転記する、という原始的な方法しか残されていない場合があります。これは時間もコストもかかる方法ですが、「他に手段がない」場合の最終手段として認識しておいてください。

どの手法を選ぶ場合でも共通して言えるのは、一つの手法だけに頼らず、可能であれば複数の手法でデータを取得し、後で突き合わせて整合性を確認するという姿勢です。特に業務上重要なデータについては、標準エクスポートとデータベース直接確認の両方で件数を突き合わせるなど、二重チェックの発想を持つことをおすすめします。

システムの種類ごとに事情が異なる点にも注意する

一口に「業務システム」と言っても、その実態は会社によってさまざまです。市販のパッケージソフトを使っている場合、オンプレミスで自社サーバー上に構築された独自システムの場合、クラウド上のSaaSを利用している場合とでは、データ救出のしやすさが大きく異なります。

パッケージソフトやSaaSであれば、提供元が一定のエクスポート機能を用意していることが多く、比較的取り組みやすい傾向があります。一方、開発会社に個別発注して作られたフルスクラッチ開発のシステムは、エクスポート機能自体が最初から用意されていない場合もあり、その場合はデータベースへの直接アクセスや、開発会社への個別依頼が前提になります。まず自社のシステムがどちらのタイプに近いかを整理してから、取れる手段を検討してください。

データ救出にかかる時間と体制を見積もる

データ救出は「思い立ったらすぐ終わる」作業ではありません。特に、複数のシステムが連携している場合や、データベースへの直接アクセスが必要な場合は、想定より多くの時間がかかることを前提に計画してください。

見積もりの際に考慮すべき要素は次のとおりです。

• データ量: 件数が多いほど、エクスポートにも検証にも時間がかかります。特に画像や添付ファイルを含む場合は、テキストデータだけの救出よりも大幅に時間が伸びます。
• システムの数: 一つの業務が複数のシステムにまたがっている場合(たとえば販売管理と会計が別システムなど)、それぞれで個別に救出計画を立てる必要があります。
• 担当者の技術レベル: データベースへの直接アクセスが必要な場合、社内に対応できる人がいなければ、外部への依頼を含めたスケジュールを組む必要があります。
• ベンダーの協力度: 開発会社が協力的であれば作業は早く進みますが、契約範囲外の作業として追加費用や日数がかかる場合もあります。

小規模なシステムであっても、「棚卸し→選別→抽出→検証→保管」の一連の流れを踏むと、実務上は数週間単位の作業になることが珍しくありません。「システム廃止までまだ余裕がある」と感じている段階から、並行してデータ救出の計画に着手することをおすすめします。

誰が主導するかを決めておく

データ救出は情報システム担当者だけの仕事に見えて、実際には経理・営業・現場それぞれの協力が必要になる場面が多くあります。「どのデータが本当に必要か」を判断できるのは、日常的にそのデータを使っている現場の担当者だからです。プロジェクトの旗振り役は情シス・総務担当者が担うとしても、各部門から一人ずつ「このデータについては聞けば分かる人」を確保しておくと、選別や検証の精度が上がります。

体制を組む際は、次のような役割分担を意識すると進めやすくなります。

• 全体の進行管理: スケジュールとタスクの進捗を管理する人(多くの場合、情シス・総務担当者)
• 技術的な抽出作業: エクスポート機能の操作やデータベースへのアクセスを担当する人(社内にいない場合は外部委託)
• データ内容の確認: 抽出されたデータが業務的に正しいかを見る、各部門の担当者
• 保管ルールの管理: 救出後のデータをどこに、どう保管するかを決め、管理する人

ステップ3: 救出したデータの検証(取り出して終わりにしない)

データを取り出せたら、そこで安心してしまいがちですが、実はここからが本番です。取り出したファイルが本当に正しいデータを含んでいるかを検証しないまま保管してしまうと、いざ必要になったときに「開けない」「文字化けしている」「件数が合わない」といった問題が発覚し、手遅れになることがあります。

検証で確認すべき代表的なポイントは次のとおりです。

1. 件数の突き合わせ: 元のシステム上で表示される件数と、エクスポートしたファイルの行数が一致しているか
2. 文字化けの確認: 日本語の氏名・住所・商品名などが正しく表示されているか。特に古いシステムでは文字コードの違いによる文字化けが起きやすい
3. 日付・数値の形式: 日付が意図しない形式に変換されていないか(たとえば「2020/4/1」が別の日付として解釈されるなど)、数値が文字列として扱われて計算に使えなくなっていないか
4. 関連データの紐づき: 複数のテーブル・ファイルに分かれたデータを組み合わせたとき、注文と注文明細のように、本来対応すべき情報が正しく紐づいているか
5. 重複・欠損の有無: 同じデータが二重に出力されていないか、逆に一部の期間や条件のデータが漏れていないか

これらの確認作業は、データクレンジングと呼ばれる工程の一部です。件数や整合性のチェックを一つひとつ手作業で行うのは負担が大きいため、Excelの関数やピボットテーブルを使って集計値を突き合わせる、といった簡易的な検証方法から始めるのが現実的です。

検証を軽視した結果、「データはあるはずなのに、いざ検索すると出てこない」という状態に陥るケースは少なくありません。取り出した直後の検証は、データ救出プロジェクト全体の中でも最も見落とされやすい工程だからこそ、意識的に時間を確保してください。

ステップ4: 保存形式と保管ルールを決める

検証を終えたデータは、次に「誰が」「いつ」「どうやって」使えるようにしておくかを決めて保管します。ここで重要なのは、救出したデータが特定の担当者のパソコンの中だけに存在する状態を避けることです。せっかく苦労して救出したデータが、その担当者の異動や退職と同時に所在不明になっては意味がありません。

保管方法を検討する際の基本的な考え方として、バックアップの世界でよく知られる3-2-1ルール（バックアップ）の発想が参考になります。データを1箇所だけに置かず、複数の媒体・複数の場所に分散して保管することで、単一の障害やヒューマンエラーでデータが失われるリスクを下げられます。

具体的な保管先の例としては、次のような組み合わせが考えられます。

• 社内のファイルサーバーやクラウドストレージ(Google Drive、OneDriveなど)への保存
• 外付けハードディスクやUSBメモリなど、物理的に切り離せる媒体へのコピー
• 新システム移行後は、データの一部を新システム内に取り込んで日常的にアクセスできる状態にする

保存形式についても、専用ソフトでしか開けない独自形式ではなく、CSVやExcel形式など、将来的にも開きやすい汎用的な形式を選ぶことが望ましいです。これはデータポータビリティの考え方にも通じます。将来、別のシステムに乗り換える際にも、汎用形式で保管しておいたデータであれば移行の負担が小さくなります。

あわせて、保管したデータに関する簡単なメモを残しておくことも重要です。

• いつ、誰が、どのシステムから救出したデータか
• どの範囲のデータが含まれているか(期間、対象など)
• ファイルの保存場所(複数箇所ある場合はすべて)
• 検証時に見つかった既知の問題点(あれば)

このメモは、後任者への引き継ぎ資料としても機能します。システム管理台帳の一部として管理しておくと、システム全体の管理状況の中に位置づけられ、存在を忘れられるリスクも下がります。

ステップ5: ベンダー・開発会社との調整

自社だけで完結できるデータ救出であれば話は早いのですが、システムの開発・保守を外部のベンダーに委託していた場合は、ベンダーとの調整が避けて通れません。ここで注意すべき点をいくつか挙げます。

契約内容を確認する

まず確認すべきは、現在の契約(あるいは過去に交わした契約)の中に、データの取り扱いに関する条項があるかどうかです。保守契約の内容によっては、契約終了時のデータ引き渡しについて取り決めがある場合とない場合があります。契約書が手元にあれば、解約・契約終了に関する条項とあわせて確認してください。

契約が生きているうちに依頼する

保守契約が有効な間であれば、ベンダーにデータエクスポートの作業を正式に依頼できる可能性があります。逆に、契約が切れてから依頼すると、有償の個別対応になったり、対応自体を断られたりすることもあります。「作り直す」と決まった時点で、契約終了予定日までにデータ救出を完了させるスケジュールを立てることが重要です。

ベンダーロックインの状態を把握する

長年同じベンダーに委託していると、データが独自形式で保存されていたり、ベンダー固有のツールでしか開けなかったりする、いわゆるベンダーロックインの状態に陥っていることがあります。この場合、データの取り出し自体をベンダーに依存せざるを得ないため、早めに「データを汎用形式で引き渡してもらえるか」を確認しておく必要があります。

連絡が取れない場合の対処

すでに開発会社が廃業していたり、担当者と連絡が取れなくなっていたりする場合は、データ救出の難易度が大きく上がります。このようなケースへの具体的な対処法は、別記事「開発会社と完全に連絡が取れなくなった。廃業・音信不通時の放置システム対処法」で詳しく解説していますので、該当する方はあわせて確認してください。

セキュリティ面で気をつけるべきこと

データ救出の過程では、大量の業務データが一時的に外付けハードディスクやUSBメモリ、個人のクラウドストレージなどに置かれることになります。この作業自体が新たなセキュリティリスクを生まないよう、次の点に注意してください。

• 個人情報を含むデータを、私物のパソコンやUSBメモリに安易にコピーしない
• やむを得ず外部媒体を使う場合は、パスワード保護や暗号化を行う
• 保管先のクラウドストレージやフォルダには、アクセスできる人を最小限に絞る
• 作業が完了し、正式な保管先への移動が終わったら、一時的に作成したコピーは削除する

特に、取引先や顧客の個人情報が含まれるデータを扱う場合は、多要素認証（MFA）が設定されたアカウントでのみアクセスできるようにするなど、通常の業務データ以上に慎重な扱いを心がけてください。データ救出という「特殊作業」だからこそ、通常のルールが緩みがちになる点には注意が必要です。

よくある失敗パターン

データ救出のプロジェクトでは、いくつかの典型的な失敗パターンが繰り返し起こります。事前に知っておくことで、同じ轍を踏まずに済みます。

失敗パターン1: システム廃止の直前に着手する

「もうすぐ止めるから」と後回しにした結果、契約解除の当日になって初めてデータ救出に着手し、時間切れで一部のデータを取りこぼす、というのは最も多い失敗です。データ救出には、想定より時間がかかることを前提に、余裕を持ったスケジュールを組んでください。

失敗パターン2: 取り出したデータの中身を誰も確認しない

エクスポート作業自体は完了したものの、ファイルの中身を誰も開いて確認しないまま「救出完了」として扱ってしまうケースです。前述のとおり、検証を怠ると、いざ使おうとしたときに使い物にならないデータだった、という事態になりかねません。

失敗パターン3: 個人のパソコンやメールに保存して終わりにする

担当者個人の環境にだけデータを保存し、組織としての保管ルールを作らないまま放置するケースです。担当者の異動・退職とともに、データの所在が分からなくなります。

失敗パターン4: 新システムに必要な項目だけを移行し、それ以外を破棄する

前述したとおり、新システムの要件定義に沿ったデータ移行と、旧システムの全体的なデータ救出は目的が異なります。新システムへの移行作業だけで満足し、それ以外の過去データを安易に破棄してしまうと、後になって「あの記録が必要になった」と気づいても手遅れです。

まとめ:今日からできる最初の一歩

システムを作り直す、あるいは廃止すると決めたときこそ、データ救出を独立したタスクとして計画に組み込む必要があります。システムが稼働しているうちにしかできない作業だからこそ、決定から着手までの間隔を空けないことが何よりも重要です。

• まず、旧システムに保存されているデータの種類をざっと洗い出し、残すべきものと残さなくてよいものを仕分ける基準を決める
• システムが提供するエクスポート手段を確認し、標準機能で足りない部分をどう補うか検討する
• 取り出したデータは、件数・文字化け・日付形式などを必ず検証してから保管する
• 保存先は一箇所に頼らず、汎用的な形式で複数箇所に残す
• 開発会社との契約が有効なうちに、データ引き渡しについて相談する

完璧な救出計画をいきなり作る必要はありません。まずは「今のシステムから、何を、いつまでに取り出す必要があるか」をリストアップすることから始めてください。それが、大切な業務データを未来に引き継ぐための最初の一歩になります。

次に読むべき記事

「そもそも作り直すべきか、延命すべきか」の判断がまだついていない方は、先に『老朽化した社内システムの「延命 vs 作り直し」判断基準』を読み、TCO・技術的負債・機会損失の3つの視点から方向性を固めることをおすすめします。

また、救出対象のシステムがAccessで作られている場合は、『Accessで動く業務システムの限界と移行先の選び方』で、Access特有のデータ移行の注意点を解説していますので、あわせてご覧ください。仕様書がなく、システムの中身の把握自体に苦労している方は、『仕様書がないシステムを引き継いだときの調査手順』から着手することをおすすめします。