レガシーシステム移行のフルスクラッチ・オーダーメイド開発について

レガシーシステム移行のフルスクラッチ・オーダーメイド開発とは、COBOLやメインフレームなど老朽化した旧システムから新環境へデータと処理を移し替える「移行の実行フェーズ」において、データ移行そのものを担うツール・スクリプトを、既製のETLツールを使わずに自社の特殊なデータ形式に合わせてゼロから独自開発するという選択肢を指します。既存の「レガシーシステムのモダナイゼーション」「レガシーシステム刷新」「レガシーシステム更改」「レガシーシステムリニューアル」「レガシーシステムリアーキテクチャ」「レガシーシステムリプレイス」「レガシーシステム改修」の各記事群が、システム本体のビルド・バイ判断や独自性の追求を扱うのに対し、本記事が扱う「レガシーシステム移行」のフルスクラッチ・オーダーメイド開発は、EBCDIC文字コードやパック10進数、階層型データベースといった旧汎用機特有のデータ形式を、既製の移行ツールで標準対応できるか、それとも変換ロジックを独自に組む必要があるかという、移行実行プロセス固有の技術判断に焦点を当てます。

本記事では、移行ツール・スクリプト独自開発という選択肢の位置づけから、既製ETLツール活用とオーダーメイド開発の判断基準、開発体制と費用感・スケジュール、AIを活用した移行仕様解明・変換ロジック開発、そして開発を成功させる進め方・依頼先選定までを体系的に解説します。データ移行は移行プロジェクトの中でも最も問題が発生しやすい工程であり、既製ツールとオーダーメイド開発のどちらを選ぶかという判断そのものが、移行全体の成否とコストを大きく左右します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム移行の完全ガイド

レガシーシステム移行におけるフルスクラッチ・オーダーメイド開発とは

データ移行を担うツールには、市販のETLツール（データの抽出・変換・ロードを行うソフトウェア）を導入する方法と、自社のデータ形式に合わせて移行スクリプトをフルスクラッチでオーダーメイド開発する方法の2つの選択肢があります。IPAの資料でも「データの質と量、管理の精度によってデータ移行の難易度が大きく変わる」と指摘されているとおり、この選択は対象システムのデータ特性に強く依存します。メインフレーム特有の文字コードやデータ構造を扱うレガシーシステム移行では、既製ツールの標準機能だけでは対応しきれないケースが多く、フルスクラッチ・オーダーメイド開発が現実的な選択肢として浮上する場面が少なくありません。

メインフレームや汎用機では、EBCDIC文字コード、パック10進数、階層型データベース（非リレーショナルDB）といった、現在主流のリレーショナルデータベースとは根本的に異なる形式でデータが保管されています。これらを新しいシステムのモダンなRDBへ変換するには、単純なフォーマット変換だけでなく、業務的な意味を保ったままデータ型やコード体系を読み替える専門的な変換ロジックが必要です。既製のETLツールで標準対応できない独自のデータ型や特殊な制御コードが大量に含まれている場合、その部分だけでも独自の変換ロジックを開発したほうが、確実かつ結果的に早く仕上がるケースが多くあります。

通常のシステム開発とは異なり、データ移行ツールは基本的に本番切り替え時とそのリハーサル時にしか使わない「一過性」の成果物です。この性質は、既製ツールとオーダーメイド開発のどちらが有利かという判断に大きく影響します。高額なエンタープライズ向けETLツールのライセンスを短期利用のためだけに購入するよりも、使い捨ての移行スクリプトをオーダーメイドで開発したほうが、トータルコストを抑えられる場合がある一方、複数システムで継続的に使い回す前提であれば、標準化されたETLツールへの投資のほうが長期的に合理的になることもあります。

既製ETLツール活用とオーダーメイド開発の判断基準

実際の判断にあたっては、データ特性・クレンジングの複雑度・コスト構造という3つの軸を組み合わせて検討することが有効です。

移行対象のデータ構造が標準的なリレーショナルデータベースに近く、既製ツールがサポートする標準的な変換パターンでほとんどのマッピングをカバーできる場合や、今後も継続的に複数システム間でのデータ連携・移行が発生する見込みがある場合は、既製ETLツールの導入が合理的です。GUIベースで変換ルールを設定でき、標準機能としてデータ品質チェックやジョブスケジューリングが備わっているため、開発期間を短縮しやすく、属人化のリスクも抑えられます。

一方、対象データに複雑な条件分岐を伴うクレンジングが必要な場合や、イレギュラーな入力・表記揺れが大量に蓄積している場合は、ETLツールのGUI設定で無理に実現しようとするより、専用のスクリプトを記述したほうが保守性と処理速度の両面で優れることがあります。加えて、移行が一度きりのイベントであり、高額なライセンス費用に見合う継続利用の見込みがない場合も、オーダーメイド開発によって使い捨ての移行スクリプトを組んだほうがトータルコストを抑えられる合理的な選択になります。

開発体制と費用感・スケジュール

オーダーメイドで移行ツール・スクリプトを開発する場合、必要になる体制と費用感、スケジュールの目安を事前に把握しておくことが、現実的な予算計画につながります。

データの抽出、新データモデルへの変換ロジック設計（マッピング）、クレンジング処理の実装、そしてトライアル移行を含むテストという一連のデータパイプライン構築には、約3〜5ヶ月程度の期間を見込むのが実務上安全な目安です。費用感は対象テーブル数やデータ量に大きく依存しますが、小・中規模であれば数百万円、大規模で複雑なメインフレーム移行になると1,000万円〜数千万円規模の開発費用が追加で発生することが一般的です。この費用は移行本体のシステム開発費とは別枠で確保しておく必要があります。

レガシーデータ移行のスクリプト開発には、新旧システムの仕様を正確に橋渡しする特別な開発体制が必要です。IPAの調査でも、モダナイゼーションの障壁として既存システムの複雑さやデータ移行の技術的困難が挙げられ、それらを統括する「ビジネス/ITアーキテクト」が多くの企業で不足していると指摘されています。移行スクリプトの開発には、旧システムの仕様（COBOLやデータベース設計）を理解できる技術者と、新システムのデータモデルを設計できる技術者が密に連携する体制が不可欠であり、この人材確保が費用・期間双方に影響する最大の変数になります。

AIを活用した移行仕様解明・変換ロジック開発

旧システムの仕様書が存在せず、当時の担当者もすでに退職しているブラックボックス化した状態では、独自の変換ロジックを設計すること自体が大きな困難に直面します。この課題に対し、近年は生成AIを活用したアプローチが実用化されつつあります。

東京システムハウスが提供する「AIベテランエンジニア」は、Googleの生成AIであるGeminiを活用し、COBOLの古いソースコードから仕様書を作成し、システムに関する質疑応答まで支援するソリューションとして2025年4月より提供が開始されています。このように、生成AIを用いてCOBOLの古いソースコードから仕様を解明（リバースエンジニアリング）し、データ移行の要件定義そのものを支援するアプローチが実用段階に入っており、仕様書が存在しないレガシーシステムでも、移行の変換ロジック設計に着手しやすくなっています。

AIによる仕様解明や自動変換によって開発効率が上がっても、開発された移行スクリプトが業務的に正しくデータを変換できているか、データ欠損や丸め誤差が生じていないかを最終的に判断できるのは、現場の業務部門だけです。そのため、IT部門やベンダーだけで完結させず、業務担当者を巻き込んで移行リハーサルとデータ整合性チェック（UAT：ユーザー受け入れテスト）を複数回実施する体制を、開発計画の初期段階から組み込んでおく必要があります。

開発を成功させる進め方・依頼先選定

移行ツール・スクリプトのオーダーメイド開発を成功させるには、進め方の工夫と依頼先選定の両面からのアプローチが必要です。

既製ETLツールとオーダーメイド開発は、必ずしも二者択一ではありません。定型的なデータの抽出・ロード部分は既製ツールに任せ、メインフレーム特有の特殊なデータ型や複雑なクレンジングロジックの部分だけをオーダーメイドで開発するというハイブリッドな進め方が、多くの現場で現実的な選択肢になっています。まずサンプルデータでのPoCを通じて、既製ツールでカバーできる範囲とオーダーメイド開発が必要な範囲を切り分けることが、無駄のない開発投資につながります。

依頼先を選ぶ際は、対象言語・基盤（COBOL、メインフレーム特有の文字コードやデータ構造）の移行実績、AIを活用した仕様解明・変換ロジック開発の活用実績、類似規模のデータ移行プロジェクトでの費用・期間の実績を具体的な数値とともに確認することが、見積もりの妥当性を検証する近道です。レガシー領域に対応できる技術者は希少であるため、実績が乏しいパートナーに依頼すると、変換ロジックの設計段階からつまずき、期間・費用ともに想定以上に膨らむリスクが高まります。

まとめ

本記事では、レガシーシステム移行のフルスクラッチ・オーダーメイド開発について、移行ツール・スクリプト独自開発という選択肢の位置づけから、既製ETLツール活用とオーダーメイド開発の判断基準、開発体制と費用感・スケジュール、AIを活用した移行仕様解明・変換ロジック開発、そして開発を成功させる進め方・依頼先選定までを解説しました。EBCDIC文字コードやパック10進数、階層型データベースといったメインフレーム特有のデータ形式は、既製ツールの標準機能だけでは対応しきれないことが多く、移行という一過性のイベントである点も踏まえると、オーダーメイド開発が合理的な選択肢になる場面が少なくありません。期間は3〜5ヶ月、費用は規模に応じて数百万円から数千万円が目安であり、新旧両システムを橋渡しできる開発体制と、生成AIによる仕様解明支援の活用が、開発の確実性を高める鍵になります。既製ツールとオーダーメイドを組み合わせるハイブリッドな進め方を軸に、レガシー領域の実績が豊富なパートナーへ早めに相談することをお勧めします。

▼全体ガイドの記事
・レガシーシステム移行の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。