ＩＴモダナイゼーション Summit

COBOLコンソーシアムセッション

マイグレーション時に考えなければならないこと・進め方（簡易版）
２０１５年４月２３日
ＮＥＣ
クラウドプラットフォーム事業部
シニアエキスパート 飯島 裕一

本説明の前提と内容▐ 「リホスト手法」によるマイグレーションを想定しています。
▐ 初めてマイグレーションを検討されている方を対象としています。
l ＣＯＢＯＬさえあれば、オープン化できる？
l リホストだから、設計・評価は不要？
l マイグレーション（リホスト）のリスクは何？

▐ マイグレーションを進める上での主要なポイントについて、Q&A形式にまとめています。
l Q1.マイグレーションを検討したいが、何からすべきか？
l Q2,効率の良いリホスト・プロジェクトの進め方は？
l Q3.効率のよい評価方法は？
l Q4.その他の懸案事項は？

Page 2© NEC Corporation 2015

Q1．マイグレーションを検討したいが何からすべきか？
Ａ．現行ＣＯＢＯＬ資産の棚卸から始めてください。
▐ どのマイグレーション手法を選択するにしても、現状のアプリケーション資産の量や種類を把握しておく必要があります。
▐ 資産はCOBOLプログラムだけではありません。帳票や画面などの各種定義体などの数量を把握します。
資産種別

対象資産

プログラム

COBOL、４GL(第四世代言語）、アセンブラ、業務簡易ツール、 ・・・※バッチ・オンラインそれぞれの規模の把握※DB・ファイルへのアクセス方式（READ/WRITE? SQL?)

ＪＣＬ／ＪＳ

ＪＣＬ、利用しているユーティリティ種別

帳票

フォーム定義体（バッチ帳票、オンライン帳票）

画面

画面定義体

ファイル／ＤＢ

表定義（リレーショナルDB)、スキーマ（ネットワーク型DB)、索引編成ファイル、相対編成
ファイル、・・・

仕様書

上記対象資産の仕様書、および仕様書のメンテナンス状態

Page 3© NEC Corporation 2015

（参考）資産棚卸の位置づけ■棚卸情報を活用し、メインフレーム・オフコン上の資産を整理→保守・運用コストの削減、オープン化に際してのコスト/リスクを低減■外部インターフェースやインフラ、運用を含めたシステム全体の移行性を整理→次期プラットフォームでどのように実現させるかを要件定義していく

資産棚卸情報効果

プログラム
構造・規模

資産の整理、関係の明確化

アプリケーション

ﾌﾟﾛｸﾞﾗﾑ
解析

COPY原文

JCL解析

プログラムとデータの関連

資産分析

各種マクロ
JCL
画面
帳票

システム分析
Page 4

画面定義
解析
帳票定義
解析

外字
ＤＢ（データ）

ＤＢ解析

プログラムの利用状況
プログラム
関係管理情報等
各種ドキュメント

資産の死活の明確化による不要資産撤廃
ｵｰﾌﾟﾝｼｽﾃﾑ移行に与える効果
変換、修正コストの削減
確実性、概算コストの精緻化
移行時の不確定要素の排除
ｵｰﾌﾟﾝｼｽﾃﾑ移行後に与える効果

現行ｼｽﾃﾑ情報

保守・運用コストの削減

HW、SW、端末、プリンタ、媒体運用（自動運転、オペレーション等）

EDI、EAI、EUC

稼働状況（負荷、レスポンス）© NEC Corporation 2015

システム、資産を分析

資産棚卸

現行ﾒｲﾝﾌﾚｰﾑの各種資産

スムーズなシステム運用

Q2．効率の良いリホスト・プロジェクトの進め方は？
Ａ．資産の一部をパイロット変換し、課題を把握・確認してから本格変換作業に入ります。
パイロット変換

お客様の固有機能部分を把握

一部を抽出

プログラム
(変換前)

ﾌﾟﾛｸﾞﾗﾑ(一部)

基本変換
ツール or 手動ﾌﾟﾛｸﾞﾗﾑ(一部)

変換ツールカスタマイズ

基本変換
ツール or 手動
お客様固有機能変換
ツール

Step1
基本変換
ツールor 手動

一部を抽出ﾌﾟﾛｸﾞﾗﾑ
(一部)

プログラム
(変換前)

カスタマイズしたツールの正常性を確認

Step2

ﾌﾟﾛｸﾞﾗﾑ(一部)

お客様固有機能変換ツール

本格変換・移行基本変換
ツール or 手動

プログラム
(変換前)

Page 5

お客様固有機能変換ツール© NEC Corporation 2015

プログラム
(変換後)

評価

▐ パイロット移行を実施しない場合のリスク
l 移行手順が確立されていないため、本格変換作業が非効率的（移行手順を決めながらの作業となる）。
l 修正作業の洗い出しが不完全なため、本来、ツールにより変換すべき作業が、結局手作業で実施される。
l 全体移行作業工数の見積り精度が低いまま。
l 動作検証未であり、基本的な変換仕様ミスが、評価段階になってはじめて発覚する（変換ツールのバグを含む）。
l プロダクトのバージョン間の矛盾などが評価段階になって発覚。

Page 6© NEC Corporation 2015

Q3．効率のよい評価方法は？
Ａ．現システムとの並行評価をするのが効率的です。
▐ テストデータ、テスト仕様に基づき、オンライン画面、画面レイアウト、バッチ帳票の出力結果のコンペアを行います。
メインフレーム・オフコン
出力

入力同じデータを入力

結果
ツール等で結果を比較、確認（コンペア評価）

並行評価例
オープンサーバ

入力

Page 7© NEC Corporation 2015

出力結果▐ 並行評価を行うために・・・
l テスト仕様、テストデータの準備作業は、基本的に業務をよく分かっている方（通常はお客様）の担当となります。
• 基本的にお客様側での準備が必要となります。
• コンペア結果でNGが出たとき、それが業務に影響するかどうかの判断も必要となります。

l 移行時に「機能追加・変更」はしないことを推奨します。
• 変更・追加すると、単純なコンペアが困難となります。
• コンペア結果でNGが出たとき、それが、機能追加・変更によるものなのか、マイグレーション作業のミスなのかの切り分けに時間がかかります。

Page 8© NEC Corporation 2015

Q4．その他の懸案事項は？
Ａ．リホストと言っても、システム的に変わる部分は多々あります。したがって、十分な事前設計が必要です。
OS▐ 独自のインターフェース、サブルーチン、ユーティリティ、お客様限定対応等への対応

言語の移行
オンライン運用

データ移行
外部接続
帳票・画面
外字
文字コード
Page 9▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐▐

ツールによる移行(手修正無しも可能だが、ツールのみでは移行後の保守に難)
アセンブラや移行対象外の言語の扱い(C、COBOLで再作成)
ソースプログラム消失の場合の対応(仕様書がなければ再作成困難)
トランザクションタイプの違い(AP分割や再作成の可能性もある)
トランザクション連携の実現(複数台のサーバ間連携など）
統合運用環境の構築検討(メインフレーム並の運用は作り込みが必須)
コンソール応答への対応
エンドユーザコンピューティング（EUC)の移行（エンドユーザの協力が必須）
MT、CGMT等の外部媒体の扱い(オープン環境ではあまり利用されない)
NDB(構造型)からRDB(リレーショナル型)へ移行
コード変換（ＥＢＣＤＩＣ→ＳＪＩＳ）
マルチレイアウトの対応
社内システムとの連携（EAI)検討(通信手順、媒体、ミドルウェア等)
社外システムとの接続（EDI）検討(通信手順、媒体、ミドルウェア等)
画面、フォームオーバレイの移行(全く同じは難しい)
大量印刷(どちらかといえばオープン系は苦手)、オンライン印刷
外字登録数(日本語EUC：X0208:940文字・X0212：1504文字、SJIS:3384文字)
フォント移行▐ コレーティングシーケンス(英数字、スペースのソート順変化)© NEC Corporation 2015

未来に向かい、人が生きる、豊かに生きるために欠かせないもの。
それは「安全」「安心」「効率」「公平」という価値が実現された社会です。
NECは、ネットワーク技術とコンピューティング技術をあわせ持つ類のないインテグレーターとしてリーダーシップを発揮し、卓越した技術とさまざまな知見やアイデアを融合することで、世界の国々や地域の人々と協奏しながら、明るく希望に満ちた暮らしと社会を実現し、未来につなげていきます。