設計書が一部しか残っていない基幹システムでも、ソースコードから現在の業務仕様を取り出す工程からご一緒します。固定長レコード・PACKED十進数・JCLの扱いまで含めて、移行後に手を入れられる形を設計します。
ご相談をいただく案件で、実際にご一緒しながら整理することの多い四点です。
COBOLからJavaへの移行でつまずくのは、言語の置き換えそのものではありません。数十年のあいだに積み上がった業務ルールが、どこに、どういう形で置かれているかを取り出す工程です。ここを飛ばした移行計画は、テスト工程で差分が大量に出る形になりがちです。
COBOLのデータ定義はJavaの型と一対一で対応しません。PACKED十進数を単純にdoubleへ置き換えると、金額計算で丸め差が出ます。移行設計の段階で、業務上どの精度が必要かを資産ごとに決める必要があります。
バッチの起動順・条件分岐・異常時の扱いがJCL側に置かれている場合、COBOLのソースだけでは全体が再現できません。JCLを移行対象に含めるか、ジョブ管理製品へ置き換えるかを先に決めます。
同じ業務項目が複数のコピー句に別名で定義されている状態は珍しくありません。棚卸しの段階で名寄せしておかないと、新環境で同じデータを二重に持つ設計になります。
一覧に残っているが実際には呼ばれていないプログラムが混ざったまま見積もりに入ることがあります。棚卸しの段階で使用状況を確認し、移行対象から外せるものを切り分けます。
7Rフレームワークに沿って、資産ごとに方式を決めます。
資産全体に同じ方式を当てる必要はありません。業務上の重要度と改修予定に応じて、資産ごとに方式を分けるほうが、費用と期間の両面で無理がなくなります。
| 移行方式 | 内容 | 適する資産 |
|---|---|---|
| リホスト | 実行環境のみを移し、ソースは原則そのまま | 安定稼働しており、今後の改修予定が少ない資産。まず動く形を早く作りたい場合 |
| リライト | 業務ロジックを保持したままJavaへ書き換える | 継続的に改修が入る中核資産。移行後に手を入れる前提のもの |
| リビルド | 業務要件から作り直す | 現行の作りが業務の実態と合わなくなっている資産。移行ではなく新規開発として扱います |
| 現状維持 | 移行対象から外す | 使用されていない資産、近く廃止予定の資産 |
リライトの場合、単に構文を置き換えただけの状態（COBOLの構造をそのまま持ったJava）で終わらせないことが要点です。パッケージ構成・例外処理・トランザクション境界をどう設計するかを、移行設計の段階で決めておきます。
ご相談の初期段階でよく話題になる、実務上の注意点です。
| 見落とされやすい点 | 内容 |
|---|---|
| 数値精度を後で調整しようとすること | PACKED十進数の扱いは、移行設計の段階で業務側と決めておく項目です。実装後の調整は影響範囲が読めなくなります |
| コピー句の名寄せを省くこと | 同一項目の別名定義を残したまま設計すると、新環境で同じデータを二重に持つ構造になります |
| JCLを移行対象外にすること | バッチの流れがJCL側にある場合、COBOLだけ移してもジョブが動きません。対象範囲の判断は棚卸しの結果で行います |
| 突合をサンプリングで済ませること | 基幹システムでは移行前後の全件突合を前提にご計画ください。抽出検査では業務上重要な差分を取りこぼします |
掲載できる完了案件がそろうまでは、対応範囲と検証結果でご判断いただける形にしております。
| 項目 | 内容 |
|---|---|
| 現在ご一緒している内容 | COBOL資産の解析と移行方式の検討をご一緒している案件が進行中です。完了しお客様のご了解をいただいた段階で、規模・作業範囲・期間を掲載してまいります |
| 対応可能な作業範囲 | 現行資産の棚卸し／移行方式の設計／現行業務仕様の文書化／移行実装／データ移行と全件突合／総合テスト支援／稼働後の運用 |
| 解析基盤での検証 | デモ用コードベース「COBOL-AIRLINES」および AWS 公開の検証用アプリ「CardDemo」を用いた解析エンジンの動作検証が完了しております（技術検証事例） |
| 規模感のご説明 | ご相談の際に、現行資産の構成をお伺いしたうえで近い性質の案件をもとにご説明いたします |
移行の可否と範囲を決める工程は、お客様と直接お話ししながら進める必要があります。この部分は日本法人の責任者が担当いたします。
| 項目 | 内容 |
|---|---|
| 現行資産の解析 | 自社開発のAI解析基盤 BIZ ModAI を用い、ソースコードの該当行という根拠つきで現行仕様を可視化します（構成と設置場所は案件ごとに決定いたします） |
| 要件の確定・設計の承認 | 日本法人（株式会社DEHA SOLUTIONS）が担当します。窓口は日本側で一本化しており、仕様のやり取りで齟齬が出ない体制です |
| 実装・テスト | 要件が確定したあとの工程を、開発拠点 DEHA VIETNAM（ハノイ・200名以上）が担います。CMMI Development & Services レベル3の評定を受けたプロセスと三層QAのもとで進めます。開発拠点 DEHA VIETNAM は ISO/IEC 27001:2022 の認証を取得しています |
| 責任の所在 | 契約の当事者は当社（日本法人）です。請負契約では成果物の完成について、準委任契約では業務の適切な遂行について、当社が責任を負います |
移行をご判断いただく前の段階でも構いません。資産一覧をお送りいただくだけで、概算と移行リスクの見取り図をお返しします。ソースコードのご提供は不要です。その先の現行調査（As-Is分析）は、稼働中のシステムを変更しない読み取り専用の解析で、作業範囲とお見積りを着手前に確定いたします。
無料レガシー簡易診断を申し込む 現行調査（As-Is分析）についてそのような状態からのご相談も承っております。ソースコードから現在の業務仕様を取り出して文書化する工程からご一緒しますので、社内にCOBOLを読める方がいらっしゃらない前提で進められます。
言語を変えるだけでは構造はそのまま残ります。移行後に手を入れられる形にするには、パッケージ構成や例外処理をどう置き換えるかを移行設計の段階で決めておく必要があります。そこまで含めてご提案いたします。
はい。移行先は業務要件と社内の保守体制に合わせて選ぶ項目です。Javaが前提ではありません。移行先の選定からご相談いただけます。
費用の構成要素、品質保証の仕組み、そして刷新を任せる相手を選ぶ観点については、モダナイゼーションのページにまとめております。COBOLからJavaへの移行に限らず共通してご確認いただける内容です。
モダナイゼーション全体のご案内へレガシー刷新の進め方（全体） ／ 業務ロジック可視化・設計書復元 ／ 移行後の運用保守・AI活用 ／ レガシー刷新の導入事例
設計書が残っていない状態、社内に読める方がいらっしゃらない状態からでもご相談いただけます。まずは現行資産の構成をお聞かせください。
