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

レガシーシステム移行のフルスクラッチ・オーダーメイド開発とは、データ移行に使うツールやスクリプトを、既製のETLツールを使わずに自社のデータ形式に合わせてゼロから開発する方法です。

  • レガシーシステム移行におけるフルスクラッチ・オーダーメイド開発の位置づけ
  • 既製ETLツール活用とオーダーメイド開発の判断基準
  • 開発体制と費用感・スケジュール
  • AIを活用した移行仕様解明
  • 進め方・依頼先選定

データ移行は最も問題が起きやすい工程で、既製ツールとオーダーメイドのどちらを選ぶかが、移行全体の成否とコストを左右します。

本テーマの全体像は、以下の全体ガイドをご覧ください。

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

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

データ移行を担うツールは、大きく2つの方法から選べます。1つは市販のETLツール(データの抽出・変換・ロードを行うソフトウェア)を導入する方法で、もう1つは自社のデータ形式に合わせて移行スクリプトをフルスクラッチで開発する方法です。

IPAの資料でも「データの質と量、管理の精度によってデータ移行の難易度が大きく変わる」と指摘されています。このため、どちらの方法が合うかは、対象システムのデータ特性に強く左右されます。

メインフレーム特有の文字コードやデータ構造を扱う移行では、既製ツールの標準機能で対応しきれないことが多くあります。そのため、フルスクラッチ・オーダーメイド開発が現実的な選択肢として浮かび上がる場面も少なくありません。

メインフレーム特有のデータ形式が独自開発を必要とする理由

メインフレームや汎用機では、EBCDIC文字コード、パック10進数、階層型データベース(非リレーショナルDB)といった形式でデータが保管されています。これらは、現在主流のリレーショナルデータベースとは根本的に異なります。

これを新しいシステムのモダンなRDBへ移すには、業務的な意味を保ったまま、データ型やコード体系を読み替える専門的な変換ロジックが必要です。単純なフォーマット変換より一段踏み込んだ作業になります。

既製のETLツールで標準対応できない独自のデータ型や特殊な制御コードが大量に含まれる場合は、その部分だけでも独自の変換ロジックを組むほうが、確実で結果的に早く仕上がることが多くあります。

移行の「一過性」という特殊な性質

通常のシステム開発と違い、データ移行ツールは本番切り替えとそのリハーサルの時にしか使わない「一過性」のものです。この性質は、既製ツールとオーダーメイド開発のどちらが有利かという判断に大きく影響します。

高額なエンタープライズ向けETLツールを短期利用のためだけに購入するより、使い捨ての移行スクリプトをオーダーメイドで開発したほうが、トータルコストを抑えられる場合があります。一方で、複数のシステムで継続的に使い回す前提であれば、標準化されたETLツールへの投資のほうが長期的に合理的になることもあります。

ポイント

判断の目安は、旧システム特有のデータ形式を既製ツールで標準対応できるかどうかです。対応できない部分が多いほど、オーダーメイド開発を検討する理由が強まります。

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

データ特性、クレンジングの複雑度、コスト構造を並べた移行方法の判断軸の図
3つの観点をそろえると、移行方法の検討を整理できます。

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

既製ETLツールが適するケース

移行対象のデータ構造が標準的なリレーショナルデータベースに近く、既製ツールの標準的な変換パターンでほとんどのマッピングをカバーできる場合は、既製ETLツールの導入が合理的です。今後も複数のシステム間でデータ連携や移行が発生する見込みがあるなら、標準化されたETLツールへの投資が役立ちます。

GUIで変換ルールを設定でき、データ品質チェックやジョブスケジューリングも標準機能として備わっています。そのため、開発期間を短縮しやすく、属人化のリスクも抑えられます。

オーダーメイド開発が適するケース

対象データに複雑な条件分岐を伴うクレンジングが必要な場合や、イレギュラーな入力・表記揺れが大量に蓄積している場合は、専用のスクリプトを書いたほうが合うことがあります。その場合は専用スクリプトのほうが、ETLツールのGUI設定で無理に実現するより、保守性と処理速度の両面で優れることがあります。

移行が一度きりのイベントで、高額なライセンス費用に見合う継続利用の見込みがない場合も、使い捨ての移行スクリプトをオーダーメイドで組んだほうがトータルコストを抑えられます。

ポイント

既製ツールとオーダーメイドのどちらを選ぶかは、データ特性・クレンジングの複雑度・コスト構造を合わせて見て決めます。移行が一度きりか、複数のシステムで使い回すかも、判断を左右する大きな点です。

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

移行スクリプト開発の期間、規模別の費用、必要な技術者を4つのパネルに分けた図
期間の目安と規模別の費用帯を分けて確認できます。

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

期間3〜5ヶ月・費用は規模に応じて数百万〜数千万円

データの抽出から、変換ロジックの設計(マッピング)、クレンジング処理の実装、トライアル移行を含むテストまでを一連のデータパイプラインとして組み上げます。その構築には、約3〜5ヶ月程度の期間を見込むのが実務上安全な目安です。

費用は対象テーブル数やデータ量に大きく左右されます。小・中規模であれば数百万円、大規模で複雑なメインフレーム移行になると1,000万円〜数千万円規模の開発費用が追加で発生することが一般的です。なお、この費用は移行本体のシステム開発費とは別枠で確保しておく必要があります。

新旧両システムの仕様を扱える開発体制

レガシーデータ移行のスクリプト開発には、新旧両システムの仕様を正確に扱える特別な開発体制が必要です。

IPAの調査でも、モダナイゼーションの障壁として既存システムの複雑さやデータ移行の技術的な困難が挙げられています。さらに、それらを統括する「ビジネス/ITアーキテクト」が、多くの企業で不足していると指摘されています。

移行スクリプトの開発では、旧システムの仕様(COBOLやデータベース設計)を理解できる技術者と、新システムのデータモデルを設計できる技術者が密に連携する体制が欠かせません。この人材をどれだけ確保できるかが、費用と期間の双方に最も大きく影響します。

ポイント

予算は移行本体の開発費とは別枠で確保し、対象テーブル数やデータ量から費用の幅を見ておくのが目安です。新旧両方の仕様を扱える人材を確保できるかが、費用と期間を左右します。

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

COBOLの古いソースコードから生成AIによる仕様解明を経て、業務部門がデータ検証する流れの図
仕様の手がかりとデータの業務的な正しさは、異なる役割が担います。

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

COBOLソースコードからのAIによる仕様解明

東京システムハウスが提供する「AIベテランエンジニア」は、Googleの生成AIであるGeminiを活用するソリューションです。具体的には、COBOLの古いソースコードから仕様書を作成し、システムに関する質疑応答まで支援します。2025年4月から提供が開始されています。

このように、生成AIを使ってCOBOLの古いソースコードから仕様を解明(リバースエンジニアリング)し、データ移行の要件定義そのものを支援するアプローチが実用段階に入っています。仕様書がないレガシーシステムでも、移行の変換ロジック設計に着手しやすくなっています。

業務部門を巻き込んだデータ検証体制の構築

AIによる仕様解明や自動変換で開発効率が上がっても、開発された移行スクリプトが業務的に正しくデータを変換できているか、データ欠損や丸め誤差が生じていないかを最終的に判断できるのは、現場の業務部門だけです。

そのため、IT部門やベンダーだけで完結させず、業務担当者を巻き込む必要があります。移行リハーサルとデータ整合性チェック(UAT:ユーザー受け入れテスト)を複数回実施する体制を、開発計画の初期段階から組み込んでおかなければなりません。

ポイント

仕様書がない場合は、生成AIで旧ソースから仕様を解明できるかが分かれ目です。ただし、データが業務的に正しいかは、AIを使っても業務部門が最終的に判断します。

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

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

ハイブリッド活用という現実的な進め方

既製ETLツールとオーダーメイド開発は、組み合わせて使えます。定型的なデータの抽出・ロード部分は既製ツールに任せ、メインフレーム特有の特殊なデータ型や複雑なクレンジングロジックの部分だけをオーダーメイドで開発します。このハイブリッドな進め方は、多くの現場で現実的な選択肢になっています。

まずサンプルデータでPoCを行い、既製ツールでカバーできる範囲とオーダーメイド開発が必要な範囲を切り分けておくと、無駄のない開発投資につながります。

依頼先選定で確認すべき実績

依頼先を選ぶ際は、対象言語・基盤(COBOL、メインフレーム特有の文字コードやデータ構造)の移行実績、AIを活用した仕様解明・変換ロジック開発の活用実績、類似規模のデータ移行での費用・期間の実績を確認します。具体的な数値とともに示してもらうと、見積もりの妥当性を検証する近道になります。

レガシー領域に対応できる技術者は希少です。そのため、実績の乏しいパートナーに依頼すると、変換ロジックの設計段階からつまずき、期間と費用が想定以上に膨らむリスクが高まります。

ポイント

依頼先は、レガシー領域の移行実績と、AIを使った仕様解明の実績を具体的な数値で示せるかで選びます。実績が乏しい相手だと、設計段階でつまずき、期間と費用が想定以上に膨らむおそれがあります。

まとめ

フルスクラッチ・オーダーメイド開発は、移行ツール・スクリプトを自社のデータ形式に合わせて独自に作る選択肢です。既製ETLツールとの判断基準、開発体制と費用感・スケジュール、AIを活用した仕様解明、そして進め方・依頼先選定まで含めて検討することが大切です。

EBCDIC文字コードやパック10進数、階層型データベースといったメインフレーム特有のデータ形式は、既製ツールの標準機能で対応しきれないことが多くあります。さらに、移行が一過性のイベントである点も踏まえると、オーダーメイド開発が合理的な選択肢になる場面が少なくありません。

期間は3〜5ヶ月、費用は規模に応じて数百万円から数千万円が目安です。新旧両システムの仕様を扱える開発体制と、生成AIによる仕様解明支援の活用が、開発の確実性を高めるうえで欠かせません。

既製ツールとオーダーメイドを組み合わせるハイブリッドな進め方を基本に、レガシー領域の実績が豊富なパートナーへ早めに相談することをお勧めします。

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

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。