既存システムの読み解きと改修下書き｜レガシーでできること

長年運用されてきた既存システム（レガシーシステム）は、企業の業務ロジックが凝縮された重要な資産です。しかし、ドキュメントの逸失、担当者の退職、技術の陳腐化により、安易な改修が困難な「ブラックボックス」となっているケースが少なくありません。

本記事では、IT実務担当者が直面する「既存システムの読み解き」から、安全に機能を拡張・改修するための「下書き」設計まで、現場で即応できる具体的な手法を詳しく解説します。フルリプレイスに多額の投資をする前に、現状のシステムをどう活かし、どうモダンな環境へ橋渡しすべきかを整理しましょう。

レガシーシステム改修の第一歩は「静的な解析」と「動的な観測」

仕様書が存在しない、あるいは現状と乖離しているシステムを扱う際、最初に行うべきは「ソースコードやDB構造の解析（静的解析）」と「実際の挙動の観測（動的観測）」の組み合わせです。

ドキュメント不在を前提としたシステム調査の5ステップ

1. インフラ構成の棚卸し：OS、ミドルウェア（DB、Webサーバ）、プログラミング言語のバージョンを確認します。
2. プロセス・ポートの特定：どのポートでどのサービスが待機し、外部とどのプロトコルで通信しているかを把握します。
3. データフローの可視化：手入力、ファイルインポート、他システムからのAPI呼び出しなど、データの「入り口」をすべて洗い出します。
4. ログの収集と分析：アプリケーションログやエラーログを時系列で追い、定例バッチや特定の操作に伴う処理の連鎖を確認します。
5. 依存関係のマップ化：ファイル共有サーバ、プリンタ、特定のクライアント端末など、システムが依存している外部リソースを特定します。

テーブル定義とER図を逆引きで作成する手法

DB定義書がない場合、SQL Server Management Studio (SSMS) や MySQL Workbench、A5:SQL Mk-2 などのツールを用いて、既存のスキーマからER図をリバースエンジニアリングします。ここで重要なのは、ツールで自動生成した後の「意味付け」です。

物理名（T_ORD_Dなど）から論理名（受注詳細テーブル）を推測し、外部キー制約が設定されていない場合でも、カラム名の一致（ORDER_IDなど）からテーブル間のリレーションを定義し直します。この作業が、後のデータ抽出や改修における影響範囲特定に直結します。

特に、古いオンプレミス環境からクラウド会計などへデータを移行する際、このデータ構造の把握が不十分だと、仕訳の不整合を引き起こします。例えば、PCA会計からfreee会計への移行ガイドで解説しているような、強固なコード体系をどう解体するかという視点も、既存システムの読み解きには不可欠です。

既存システムの「読み解き」で見るべき急所

改修の設計に入る前に、システムの「弱点」と「特性」を正しく把握する必要があります。以下の3点は、レガシーシステムにおいて特にトラブルの火種になりやすい箇所です。

データ整合性：ユニークキーとリレーションの現実

古いシステムでは、アプリケーション側で整合性を担保していることが多く、DB側には制約（Constraints）がほとんど設定されていないことがあります。主キーが重複していたり、親テーブルに存在しないIDが子テーブルに書き込まれていたりするケースです。改修時に新しいテーブルを追加して紐付ける場合、こうした「汚れ」を前提としたクレンジング処理を設計に含める必要があります。

バッチ処理の依存関係：タスクスケジューラとジョブ管理

「夜間バッチが終わらないと翌日の業務が開始できない」といった依存関係は、Windowsタスクスケジューラやcronに直接記述されていることが多々あります。これらの設定値（実行タイミング、引数、リトライ回数）を漏れなく抽出することが、改修後の運用設計において極めて重要です。

ハードコードされたビジネスロジックの抽出

消費税率、特定の取引先コード、会計年度の切り替わり日などが、プログラム内に直接記述（ハードコード）されていることがあります。これらは設定画面から変更できないため、改修時には「外出し（設定ファイル化やDB管理化）」することが望ましいですが、影響範囲が広すぎる場合は、あえてハードコードを維持し、修正手順をマニュアル化する現実的な判断も求められます。

レガシーを活かした「改修下書き」の設計パターン

既存システムを大きく壊さず、現代的なニーズ（SaaS連携、モバイル対応、データ分析）に応えるための設計パターンは主に3つあります。

パターンA：CSV/ファイル連携によるルーズ結合

最も安全かつ確実な方法です。既存システムの標準機能である「CSVエクスポート」を活用し、そのファイルを中間処理プログラム（PythonやiPaaS）で加工して、他システムに流し込みます。既存プログラムに1行も手を加えないため、本番環境を壊すリスクが最小限で済みます。

例えば、経理業務の自動化において、楽楽精算×freee会計のCSV手作業を自動化するアーキテクチャは、このルーズ結合の典型的な成功例です。APIが未整備なシステム間でも、処理を自動化することは十分に可能です。

パターンB：データベースビュー・レプリケーションによるデータ活用

既存システムのデータベースに対して「読み取り専用」のビューを作成するか、レプリケーション（複製）を作成して、外部のBIツールやデータ基盤から参照する方法です。既存システムのパフォーマンスに影響を与えず、最新のデータを用いた分析が可能になります。ただし、DBの直接参照はテーブル構造の変更に弱いため、間にdbtなどの変換レイヤーを挟むことが推奨されます。

パターンC：RPA/iPaaSによるUIレイヤーの自動化

APIもCSV出力もない、あるいはDBへのアクセス権限がない場合は、UI（画面）操作を自動化するRPAを選択します。ただし、画面の解像度やボタンの位置変更に弱いため、これは「最終手段」として考えるべきです。最近では、APIを持たないレガシーなWebシステムに対して、プロキシ的にAPIを提供するサービスも登場しています。

実務で選ぶ連携・抽出ツール比較

既存システムからデータを抜き出し、モダンな環境へ繋ぐための手法を比較表にまとめました。

適切な手法の選択は、コストだけでなく「将来的にそのシステムをどうしたいか」というロードマップに依存します。例えば、最終的にSaaSへ完全移行する予定であれば、一時的なCSV連携でしのぎつつ、移行の準備を進めるのが合理的です。オンプレミス負債の剥がし方でも触れている通り、現実的な「剥がし方」を設計に組み込むことが重要です。

改修作業のステップバイステップとトラブル回避

「読み解き」が終わったら、いよいよ実作業に入ります。レガシーシステムの改修で最も恐ろしいのは、予期せぬ副作用による「先祖返り」や「業務停止」です。

STEP 1：本番環境の完全クローンによる検証環境構築

レガシーシステムは、特定のライブラリやOSの設定に強く依存していることが多いため、簡易的なテスト環境では不十分です。可能であれば、P2V（Physical to Virtual）などの技術を使い、本番環境のイメージをそのまま仮想環境やクラウド上にコピーした「完全クローン」を作成します。ここで初めて、本番同様のデータ量での負荷試験や、連携プログラムの動作確認を行います。

STEP 2：差分データの整合性チェック自動化

改修前後でデータの出力結果が変わっていないかを検証するために、現行システムの出力と新システムの出力を比較（diff）する処理を自動化します。特に計算ロジック（消費税の端数処理や合計金額の算出）に手を加えた場合は、過去数年分の全データを流し込んで不一致が発生しないかを確認する「全件検証」が推奨されます。

STEP 3：段階的な切り替え（並行稼働期間の設計）

一斉に新システムへ切り替える（ビッグバン移行）のではなく、一部の機能や特定の事業所から順次切り替えていく「フェーズ移行」を検討してください。また、万が一致命的なバグが発覚した際に、即座に旧システムでの運用に戻せるよう、切り戻し（ロールバック）の手順を必ずドキュメント化し、リハーサルを行っておきます。

よくあるエラーと対処法

• 文字コードの不一致：既存システムがShift-JIS、新システムがUTF-8である場合、ファイル連携時に「ハシゴ高」や「環境依存文字」でエラーが発生します。連携基盤（Python等）で変換処理を挟むか、変換できない文字を代替文字に置換するロジックが必要です。
• タイムアウト：古いDBに重いクエリを投げると、ロックが発生して既存業務の画面がフリーズすることがあります。クエリの最適化に加え、実行時間を夜間に限定する、または前述のレプリケーション参照への切り替えを検討してください。
• 権限不足：古いOS上のフォルダにネットワーク越しにアクセスする場合、SMBのバージョンの違いやWindows認証の仕様変更により、接続できないことがあります。

まとめ：レガシーは「負債」ではなく「資産」に変えられるか

既存システムの読み解きは、過去のエンジニアや業務担当者が積み上げてきたロジックへの「敬意」を持って行う作業です。たとえコードが乱雑であっても、そこには長年の業務改善の歴史が刻まれています。

「古いからすべて捨てる」という極端な二元論ではなく、現状の強みを活かしながら、最新のIT基盤（Google Workspace、AppSheet、各種SaaSなど）を柔軟に組み合わせることで、最小コストで最大のDX効果を得ることができます。例えば、Google Workspace × AppSheetを活用したガイドにあるような、現場の使い勝手を損なわない「疎結合な改修」こそが、今求められている実務者のスキルと言えるでしょう。

まずはシステムのI/Oを可視化することから始めてみてください。それが、レガシーを負債から資産へと転換する第一歩となります。

3. **追記するHTMLだけ**（通常は `