〜Open系（Java）への段階移行 × ハイブリッド開発 × AI活用の現実解〜
「基幹システムを刷新したい。でも止められない」
これは多くの企業が抱える共通課題です。
特に、小売・製造・物流・金融など、24時間365日止められない業務では、RPG／COBOLなどのレガシー基幹システムが今も中核を担っています。
しかし2026年現在、レガシー刷新は「いつかやる」ではなく、待ったなしの経営課題になっています。
本記事では、GICが支援した実際のプロジェクトをもとに、
RPG／COBOL基幹システムを止めずにモダナイゼーションする方法を分かりやすく解説します。
なぜ今、レガシー刷新が「待ったなし」なのか？
レガシー刷新が急務となっている背景は、単なる技術トレンドではありません。
現場では次の4つの課題が同時に進行しています。
1. 技術者の高齢化（Talent Cliff）
RPG／COBOL技術者は50代〜60代に集中しており、若手の担い手が不足しています。
技術の継承ができないまま、退職が進むことで、保守そのものが成立しなくなるリスクがあります。
2. ブラックボックス化（The Black Box）
長年の保守運用により「設計書がない」「仕様が分からない」状態になり、
結果として「変更できない」「改修が怖い」システムになります。
3. 変えたいのに止められない（The Dilemma）
刷新の必要性は理解していても、基幹システムを止めた瞬間に業務が止まり、会社の売上が止まります。
つまり、刷新は「技術の問題」ではなく「事業継続の問題」になっています。
4. 外部環境の圧力（External Pressure）
EC連携、BI、クラウド連携、セキュリティ強化、BCP対策など、外部要求は年々増加しています。
「ビッグバン刷新」は失敗しやすい。答えは「段階移行」にある
そこで現実解として採用されるのが、段階移行（Phased Migration）です。
Strangler Pattern（ストラングラーパターン）
段階移行では、既存システムをすぐに捨てず、
新システムを横に作りながら機能を少しずつ切り出し、段階的に置き換えていきます。
この方法のメリットは次の通りです。
- 既存業務を止めずに進められる
- リスクを管理しながら移行できる
- 小さな成功を積み上げられる
- 共存期間を設計できる
実例：年商1,000億円規模の小売企業のモダナイゼーション
今回ご紹介するのは、年商1,000億円以上の小売・リテール企業の実例です。
ゴールは、
RPG／COBOLからAzure（Java／Spring）への完全移行です。
課題は、長年の保守でブラックボックス化し、ベテラン社員への属人化が進んでいたことでした。
足掛け8年。「止めない」ための現実的ロードマップ
このプロジェクトは、いきなり基幹を置き換えたわけではありません。
8年かけて段階的に進めています。
Phase1：UIのオープン化（外堀から攻める）
GenesisやBizBrowserなどのLowCodeを活用し、
AS/400の画面インターフェースを先にオープン化しました。
この戦略の重要ポイントは、
いきなりDBや業務ロジックに触れず、外堀（UI）から着手したことです。
Phase2：転換点（バッチ処理のオープン化）
基幹刷新で最大の難所となるのが、バッチ処理です。
このフェーズでは、バッチ処理の移行を段階的に進めました。
Phase3：Java／Spring × Azureへ完全移行
最終的に、クラウドネイティブな基盤へ移行し、
DXやAI活用ができる状態へ進化しました。
仕様書がない問題への対抗策：「可視化」
多くのレガシー刷新では、次の壁にぶつかります。
「仕様書がない」
「どこに何が書かれているか分からない」
「ベテランしか理解できない」
そこで本プロジェクトでは、
Planet／Comet iなどの解析ツールを活用し、RPG／COBOL資産を可視化しました。
- 対象：プログラム1,600本
- 期間：数か月
- 成果：属人性排除、誰でも改修できる状態へ
可視化は、移行の第一歩であるだけでなく、
「保守できる状態を取り戻す」ための最重要工程でもあります。
Java（Spring）× Azureへの移行を実行できた理由
本プロジェクトでは、移行を机上の計画で終わらせませんでした。
実行面で成功した理由は次の通りです。
ターゲット技術を明確化
- Java（Spring Boot）
- SQL Database（Azure）
20名規模の開発体制
スピードを重視し、移行を加速できる体制を確保しました。
Fail Fast（早く失敗し、早く学ぶ）
移行プロジェクトでは、後半になって問題が発覚すると致命傷になります。
そこで、早い段階で移行の課題を洗い出し、対策を打つアプローチを採用しました。
東京・宮崎・ミャンマー：3拠点ハイブリッド体制の強み
本プロジェクトは、技術だけでなく体制設計も成功要因です。
Tokyo（High Context）
- 顧客折衝
- 要件定義
- 全体設計
- 意思決定支援
Miyazaki（Quality & Bridge）
- 中核開発
- 品質管理
- 技術移転
- 日本品質の担保
Myanmar（Scale & Cost）
- 実装
- テスト
- 移行作業などボリューム対応
これは単なる「安く作る」ではなく、
スピードと継続性を両立するためのサプライチェーン設計です。
若手がレガシーを学ぶ？逆転の人材戦略
ここはGICとして特に強調したいポイントです。
レガシー刷新の最大の壁は「技術」ではなく「人材」です。
顧客側のRPG／COBOL技術者は高齢化しており、
Javaしか知らない若手が不足しています。
そこでGICでは、20代〜30代のエンジニアに対し、
RPG／COBOL教育を実施しました。
そして目指すのは、
「レガシーが読める」
かつ
「モダンが書ける」
という希少価値の高い人材です。
これは若手エンジニアにとって、非常に大きなキャリアメリットになります。
「動く」ではなく「正しい」を保証する品質管理
モダナイゼーションで最も重要なのは、
「新システムが動くこと」ではありません。
旧システムと同じ結果を返すことが絶対条件です。
本プロジェクトでは、旧（IBM i）と新（Java）を並行稼働させ、
出力結果を比較エンジンで全量突合しました。
また、
- 単体テスト
- 結合テスト
- 回帰テスト／移行リハーサル
を段階的に実施し、
小さくリリースし、問題があれば即戻せるロールバック設計を採用しました。
AI活用の現実：「できること」と「できないこと」
最近は「AIで全部変換できるのでは？」という期待もあります。
しかし、AI活用には明確な境界があります。
AIができること（生産性向上）
- RPG／COBOLソース解析支援・要約
- テストケース案の自動生成
- Java／SQLコードのドラフト作成
AIができないこと（責任領域）
- 業務仕様の正しさの最終保証
- 複雑なバッチ処理の一括自動変換
- 移行結果に対する監査・説明責任
AIは武器ですが、最終判断は人（エンジニア）が不可欠です。
本プロジェクトで得られた3つの成果
本プロジェクトでは、次の3つの成果を実現しました。
1. Business Continuity（業務停止ゼロ）
移行中も業務停止（Unplanned Downtime）はゼロ。
止めない移行を実現しました。
2. Sustainability（属人性の排除）
ベテランの暗黙知がドキュメント化され、チームに継承されました。
3. Modern Foundation（DX・AI活用の土台）
Azure基盤への移行により、リアルタイムデータ活用やDX（AI連携）が可能になりました。
明日からできる「最初の一歩」
最後に、モダナイゼーションは何から始めるべきか。
ポイントは4つです。
- Inventory（棚卸し）
現行資産（機能・データ・バッチ）を全量把握する - Assessment（仕分け）
「増築」「廃棄」「移行」を分類する - Team Design（体制設計）
意思決定者（プロジェクトオーナー）を明確にする - Start Small（小さく始める）
PoCではなく、最も確実な「小さな実移行」から始める
まとめ：モダナイゼーションは技術ではなく「経営判断」と「体制設計」
レガシー刷新は、技術的には難しい。
しかし本質的には、次の2つが成功要因です。
- 経営としての意思決定
- 止めないための体制設計（人材・品質・移行戦略）
GICは、RPG／COBOL資産の可視化から、
段階移行、クラウド移行、ハイブリッド開発体制、AI活用まで一気通貫で支援しています。
ご相談はこちら
もし貴社でも、
- IBM i（AS/400）基幹の刷新を検討している
- 仕様書がなくブラックボックス化している
- 人材不足で移行が進まない
- 止めない移行ロードマップを作りたい
といった課題がありましたら、ぜひお気軽にご相談ください。
