20年以上前から稼働している基幹システム（販売管理・生産管理・会計システム等）には、企業の重要なデータが蓄積されています。なお本記事でいう「移行なし」とは、基幹システムそのものを新システムに置き換えないという意味です。データを別の分析基盤へ連携するための抽出処理や接続設定は必要になります。システムが老朽化しており、データ構造が複雑でブラックボックス化していたり、外部連携のAPIがなかったりすることで、BI・AI活用に使いたくても使えない状態になっているケースがあります。本記事では、「基幹システムを移行せずに」データを活用するアプローチを解説します。
レガシー基幹システムのデータ活用が難しい3つの理由
- ①データ構造の複雑さ・ブラックボックス化：テーブル構造・フィールド定義が文書化されておらず、「このデータが何を意味するか」を知っている人がいない状態。特に旧来のシステムはコード値（例：001=A商品、002=B商品）が外部に公開されていないケースがあります
- ②外部連携手段の欠如：レガシーシステムでは外部連携用のAPIが整備されていないことがあり、データを取り出すにはバッチファイル・CSVエクスポート・直接DBアクセスなど手間のかかる方法を組み合わせる必要があります
- ③データ品質の問題：長年の運用で入力ルールが変わったり、過去のデータが現在の業務定義と合わなくなっていたりすることがあります。特に20年前のデータと現在のデータでは意味が変わっている可能性があります
既存システムを残したままデータを活用する
システムの完全な移行・リプレイスを待たずに、現行のレガシーシステムのデータを「現地で活用できる」状態に整備するアプローチです。
- テーブル定義・コード値の文書化：まずデータ構造・フィールド定義・コード値（マスタコードと業務上の意味の対応）を調査・文書化します。知っている担当者へのヒアリング・SQL分析・旧来マニュアルの読み解きを組み合わせます。この作業は時間がかかりますが、活用の基盤になります
- DBビュー・抽出ETLの設計：「BI・AI活用で必要なデータ」をレガシーシステムのDBから抽出するビュー（SQL view）またはETLスクリプトを設計します。業務担当者と連携して「どのテーブルのどのデータが必要か」を定義します
- 中間データマートの構築：レガシーシステムから定期的にデータを抽出し、BI・AI活用に適した形に変換した「中間データマート」をクラウドDB（BigQuery・Snowflake等）に構築します。これによりレガシーシステムの業務機能を変更せずに、モダンなBIとの連携を実現できます。ただし抽出のための読み取り権限や接続設定は別途必要です
刷新を待たずに進める3ステップ
※ 刷新を待つあいだの時間が、刷新そのものの準備にもなります
データ品質の優先的な整備
レガシーシステムのデータ活用では、「すべてのデータを完璧に整備してから使う」のではなく「使いたいデータから優先的に整備する」アプローチが現実的です。
- 使用頻度・活用インパクトで優先度を決める：「この分析ができればビジネスに最大のインパクトがある」データから整備します。全データの整備を待つと活用開始が遅くなります
- 「過去データ」と「最新データ」の定義が違う場合は分けて扱う：コード体系や会計基準が途中で変わっているなど、過去データを現在のルールで解釈できない場合は、無理に同じ扱いにせず別管理にして最新データから活用を始める方法があります。現在の体系に対応付けて統合する設計もあり、どちらが適切かは変更の大きさによります
- 定期的なデータ抽出・整合性チェックの自動化：レガシーシステムからのデータ抽出を自動化し、抽出のたびに整合性チェック（件数確認・必須項目確認）を実行することで、品質問題を継続的に検知します
この進め方で陥りやすい落とし穴と対策
レガシーシステムからデータを抽出して中間データマートを作る進め方で注意すべきなのは、「レガシーシステム側の仕様変更への追従」です。バッチ処理の変更・テーブルの列追加・コード体系の追加——こうした変更がレガシーシステム側で起きると、中間データマートへの抽出ETLが壊れることがあります。レガシーシステムのベンダー・内部担当者と「変更前の事前通知フロー」を取り決めておくことが、安定した活用の前提になります。
もう一つ、設計段階で必ず確認したいのが基幹システム側への負荷です。長年稼働しているデータベースに対してBI用の重い集計を直接かけると、受発注や出荷といった本業の処理が遅くなることがあります。抽出は業務時間外のバッチで行う、参照用の複製（レプリカ）から読む、全件ではなく前回からの差分だけを取る、といった方法で本番への影響を抑えます。どの方法が取れるかは基幹システムの構成によるため、着手前にシステム担当者と確認しておきます。
もう一つの落とし穴は「テーブル定義の文書化が属人化すること」です。ヒアリングと調査でテーブル定義を解読した担当者が異動・退職すると、再び「このデータが何を意味するか分からない」状態に戻ります。文書化した内容はWiki・共有ドライブ・データカタログツールなどチームで参照・更新できる場所に保管し、変更があった際に更新する運用ルールを設けることが重要です。
レガシー活用から将来の移行を見据えた設計
既存システムを残したまま活用するこの進め方は、将来の基幹システムリプレイスへの布石にもなります。中間データマートで「BI・AI活用に必要なデータの定義」が明確になると、新システムのデータ要件（何のデータが必要か・どの精度で・どの頻度で）を具体化する材料になります。移行要件には機能・性能・セキュリティ・業務プロセスなども含まれるため、これだけで要件がそろうわけではありません。この整備の過程で得た知見——テーブル構造・業務ロジック・品質課題——は、新システム設計時の重要なインプットになります。レガシー活用の整備とシステム刷新の計画を並行して進めることで、移行対象や要件を事前に具体化でき、移行プロジェクトの手戻りを減らせる可能性があります。また、ここで構築した中間データマートは、新システム稼働後も「旧データの歴史的参照先」として存続させることができます。過去データの連続性を保ちながら新システムに移行できることは、経営分析や、過去データの参照・証跡確認が必要な場面で役立ちます。監査で使う場合は、保持期間やアクセス制御など監査側の要件を満たす設計が別途必要です。
よくある質問
テーブル定義を知っている人がもう社内にいない場合、どう進めればよいですか？
実データから逆算する方法があります。コード値であれば、実際に入っている値を集計して出現頻度の高い順に並べ、業務担当者に「この値が付いているのはどういう取引か」を確認していきます。日付や金額の項目は、既存の帳票や月次報告の数字と突き合わせると意味を特定できます。すべてを解読する必要はなく、BI・AIで使う予定の項目に絞れば現実的な作業量になります。
中間データマートを作ると、二重管理になりませんか？
更新の向きを一方向に限定すれば、二重管理にはなりません。レガシー側を正とし、データマートは抽出した結果だけを持つ読み取り専用の場所として扱います。データマート側で値を直接修正しないことが条件で、修正が必要ならレガシー側を直して再抽出します。この原則を崩すと、どちらが正しいか分からなくなります。
まとめ
レガシー基幹システムのデータを活用するには「テーブル定義の文書化→抽出するデータの設計→中間データマートの構築」という、既存システムを残したまま進めるアプローチが有効です。すべての整備を完了してから始めるのではなく、最もインパクトの大きいデータから優先的に整備・活用を始めることで、早期に成果を出せます。ここで構築した中間データマートは、将来のシステム移行時にも過去データの継続性を保つ資産として機能します。レガシーシステムとモダンなBI・AI基盤の橋渡しを設計する際には、一時的な整備にとどまらず「どう維持・発展させるか」まで含めた計画を立てることをお勧めします。長年の運用で蓄積されたレガシーシステムのデータは、整備すればBI・AIの入力として使えます。「使えない」と判断する前に、既存システムを残したまま連携する方法が取れないかを検討する価値があります。その際は、レガシーシステム固有の構造や業務ロジックを理解したうえで、データ抽出・品質確認・運用までを設計することが重要になります。BFT Insightでは、レガシー基幹システムのデータ活用・連携に関する支援を行っています。設計から実装・運用までご相談いただけます。レガシーシステムのデータ活用・整備支援についてはBFT Insightにご相談ください。