T社様 メインフレームからの移行事例
2007年12月13日
NECソフト株式会社
PFシステム事業部

目次
１．はじめに
２．T社様

マイグレーションの概要

３．T社様

マイグレーションPJ成功のポイント

３．１ オープン化のメリット・デメリット
３．２ お客様参加型PJ
３．３ 棚卸の精度
３．４ パイロット変換・検証を重視
３．５ テストの効率化
４．T社様

マイグレーション技術面のポイント

５．まとめ© NEC Soft Corporation 20072

１．はじめにNECのメインフレームマイグレーションサポート体制
お客様
お客様
ソリューション提供

ＮＥＣ営業部門／ＳＥ部門
ＮＥＣ
マイグレーションサポート

ＡＣＯＳマイグレーションサポートセンタ（ＡＭＳＣ）
プロフェッショナル部門
ツール開発部門

方式設計部門

製品開発部門© NEC Soft Corporation 20073

© NEC Soft Corporation 2007

4

２．T社様マイグレーションの概要

２．マイグレーションの概要（１）○Ｔ社様 会社概要
・サービス業・従業員１，５００名○システムの特徴
・24時間365日運転 （オンラインは、夜間1時間程度のバックアップ中停止）
・オンライン端末数２００台○背景と経緯・メインフレーム要員の不足によりオープン化を検討（特定のメインフレーム要員に負荷集中）
・業務の仕組みは大きく変えたくない（現行の業務に不満はない）
・メインフレーム利用制限（ＤＢ二重管理、ＤＢアクセス性能の限界、ＤＢレコード拡張の困難性）
・メインフレーム維持費の負担○オープン化にあたっての要件
・トータルコストは抑えて、オープン化したい・システム課題の解決 （統合ＤＢ構築の１ｓｔｅｐ、ＤＢレスポンス向上、システム拡張性確保）
・業務ＡＰ開発言語の統一
・現行システムと同等の性能© NEC Soft Corporation 2007

5

２．マイグレーションの概要（２）○移行対象資産量
・COBOL
363本 155.0KL
・IDLⅡ
186本 123.5KL
・JCL
213本
・帳票
144帳票
・画面66画面・ファイル(RIQS) 114表
○ＰＪにおける主なお客様作業分担
・ツール変換後の手修正、ＮＥＣ側疎通テスト後のテスト（ＮＥＣはテスト支援）○スケジュール
・２００５年度 ：資産棚卸、パイロット変換/検証
・２００６年度 ：マイグレーション、評価・２００７年度～ 新システム稼動（順調に稼動中）
2005年度
資産棚卸
パイロット検証
移行設計

2006年度マイグレーション

2007年度評価

本番稼動© NEC Soft Corporation 20076

２．マイグレーションの概要（３）
移行形態とミドルウェア製品
ACOS-2
AP資産の移行IDLⅡ、COBOL(85,74)

APMS/SRC(*1)
APMS/SRC(*1)※VIS/JCL/DB/帳票の※VIS/JCL/DB/帳票のAPI変換含む
API変換含む

バッチ帳票（FORMEX)APMS/FORM(*1)

Windows2003
ＣＯＢＯＬ８５
らくらく
ふぉーむ

Spoolernet
Printview

データの移行オンライン画面（MFD）

OLTPPARTNER
OLTPPARTNER

VB

ＪＣＬ

APMS/JCL(*1)
APMS/JCL(*1)

バッチファイル

RIQS

Data Migration Toolset(*2）

Ｏｒａｃｌｅ

標準ファイル(SEQ)
共通AP
基盤

標準ファイル(SEQ)

VIS
VIS

TPBASETPBASE

JOB管理
JOB管理

JobCenter
JobCenter(*1)資産移行サービスの中で使用する内部ツール(*2)データ移行専用ツール© NEC Soft Corporation 2007

7

２．マイグレーションの概要（４）マイグレーション後のシステム構成
バックアップサーバ
APサーバ

開発環境
COBOL85 Pro
RemoteWorkbench

DBサーバ
オンライン

TPBASE
TPP（ｵﾝﾗｲﾝAP）

バッチ
バッチAP

クライアントrenetsiL
P
T

ORACLE
10g

OLTPPARTNER
DataEntry AP(VB)

JobCenter
ﾊﾞｯﾁﾌｧｲﾙSORTKIT

帳票データフォーム

らくらくふぉ～む
Printview for windows

帳票

電子帳票

Spoolernet for printview© NEC Soft Corporation 20078

３．Ｔ社様マイグレーションＰＪ
成功のポイント© NEC Soft Corporation 20079

３. マイグレーションＰＪ成功のポイント①オープン化のメリット/デメリットの明確化→メリット/デメリットをお客様に十分理解して頂けた②お客様参加型のＰＪ→業務ノウハウをお持ちのお客様とＮＥＣの技術者との協同ＰＪ体制が実現できた③棚卸の精度→十分な期間を持って業務システムの棚卸を実施し移行対象資産を削減した④パイロット変換/検証を重視→変換作業の効率化、変換後環境の確認、リスク対策⑤テストの効率化→テストパターン分類による効率化と、テスト体制の工夫© NEC Soft Corporation 200710

３．１ オープン化のメリット・デメリット

十分な理解の下でご決断して頂く！

オープン化によるリスクはゼロではありません
メリットだけでなくデメリットについて理解して頂く必要がありました○メリット①業務ＡＰの開発/保守の効率化（ベテランメインフレーム技術者から若手技術者を主体に）・業務ＡＰの開発言語の統一・若手が得意な技術（ＤＢ／ＳＱＬ、Ｗｉｎｄｏｗｓ、ＶＢ等）②システムのランニングコストの削減③製品の組み合わせによって、マイグレーション範囲内で電子帳票化を実現④オープン化のコスト削減
・再構築やＰＫＧ導入と比較し、低コストでオープン化を実現○デメリット①マシンの信頼性低下への懸念→高信頼性のメインフレームからＷｉｎｄｏｗｓサーバへの心配②システム運用の複雑化→１台のメインフレームで賄っていた業務を複数サーバ化することの弊害（バックアップ、障害時の復旧手順 等）© NEC Soft Corporation 200711

３．２ お客様参加型ＰＪ

お客様との信頼関係が大事
業務を熟知されているお客様の協力なしにＰＪは成功できません
お客様とＮＥＣの協同ＰＪ体制を築くことがＰＪ成功の第一歩
ＰＪ統括（お客様ＣＩＯ）＜＜お客様とＮＥＣの協同ＰＪ＞＞＜＜お客様とＮＥＣの協同ＰＪ＞＞
ＰＪメンバー内のコミュニケーション
ＰＪメンバー内のコミュニケーション
課題、進捗の共有
課題、進捗の共有

ＰＪリーダ
情報システム責任者

お客様ＰＪチーム
情報システム部メンバー

ＮＥＣ ＰＪマネージャー

コンバージョン

＜＜主な分担＞＞＜＜主な分担＞＞
・システムの棚卸・システムの棚卸・システム運用の見直し・システム運用の見直し→新システム要件定義→新システム要件定義
業務フロー作成
業務フロー作成・変換（手修正）・変換（手修正）・評価仕様作成、評価実行・評価仕様作成、評価実行

システム運用ＮＥＣ

基盤構築＜＜主な分担＞＞＜＜主な分担＞＞
・マイグレーション方式設計
・マイグレーション方式設計
・システム運用設計
・システム運用設計
・システム基盤構築
・システム基盤構築
・資産変換（コンバージョン）
・資産変換（コンバージョン）
・お客様作業支援
・お客様作業支援
・評価支援（問題解析）
・評価支援（問題解析）© NEC Soft Corporation 200712

３．３ 棚卸の精度
捨てる勇気も！
棚卸精度が悪いと、無駄な移行コストがかかる
棚卸期間を十分に取って、資産をスリム化①機械的な棚卸
棚卸ツールを利用し、ＪＣＬとＡＰ資産との関連を調査→宙に浮いたプログラムは不要②業務観点からの棚卸
業務メニューから紐付く資産を調査
メニュー（機能）の要/不要を棚卸し、必要資産を絞り込み
メニュー

ＪＣＬ

メインサブルーチン

業務メニュー１

ＪＣＬ１

ＡＰ１

ＡＰ３

ＡＰ４

ＡＰ６ＡＰ２
業務メニュー２
業務メニュー３

ＪＣＬ２
ＪＣＬ３

ＡＰ１
ＡＰ５

ＡＰ６

ＡＰ１０ＡＰ３

ディスク上にあったAP資産 約１，７００本から５４９本に削減© NEC Soft Corporation 200713

３．４ パイロット変換・検証を重視
急がば回れ！
お客様によっては、“無駄”と思われるかもしれませんが、ＰＪの成功（後戻り防止/効率化）の為には非常に重要①変換仕様の精度が低下 →移行コスト増②お客様に変換後の操作性等確認いただけない→後戻りの発生③ＰＪ全体にリスクが増大→方式や業務の“作り”によって思わぬ落とし穴が。。。
＜Ｔ社様では十分なパイロット変換/検証を実施＞①目的の明確化と共有・変換ツールの精度向上
・手修正内容の把握
・実際のオペレーションを想定し動作／操作確認②対象、アウトプット、スケジュールの明確化③お客様にマイグレーション作業を体感して頂く④課題の対処/検討© NEC Soft Corporation 200714

３．５ テストの効率化
業務テストはお客様主体で、移行対象全て実施

手を抜かない！

マイグレーションといえども、プラットフォームが変ることによって思わぬ運用面等の問題が露見するケースもあり、十分なテスト期間とテスト実施がプロジェクト成功の重要な鍵！
■効率良くテストを行う為に・テストのパターン化→単体でできるものと、できないものを洗い出し、類似パターンをグルーピング→業務フローを明確にし、テストデータ作成やテストの順番を効率良く計画
・テストチームの体制
業務を熟知されているお客様主体のテスターとＮＥＣ主体の解析チームでテストを分担
類似パターンで分類しテストを実施

テストデータ作成（お客様主体）問題点の修正は、全該当プログラムにフィードバックし、同一問題を実機テストで繰り返さないように実施
パターン分類している為、問題点の影響範囲が絞り込み易い

テスター（お客様主体）解析（ＮＥＣ主体）

問題修正（協同実施）© NEC Soft Corporation 200715

© NEC Soft Corporation 2007

16

４．Ｔ社様マイグレーション
技術面のポイント４．１ 技術面のポイント
Ｔ社様のシステムは、ＮＥＣ製メインフレームで動作する簡易言語「ＩＤＬⅡ」の資産があり、ＩＤＬⅡ資産を次期システムでどうするか？が課題＜選択肢＞■ＩＤＬⅡ言語のまま移行：×【理由】
お客様要件である、「開発言語の統一化」から外れる為オープン系技術者（若手技術者）へメインフレーム文化を持ち越すことになる為■他言語へ移行：○
移行先言語は、ＣＯＢＯＬ８５を選択【理由】
移行対象資産に、ＣＯＢＯＬ８５（一部７４）があり、ＣＯＢＯＬ８５で開発言語を統一
注：ＩDLⅡは、データフローを基本としたパターンによるプログラミングスタイル© NEC Soft Corporation 2007

17

４．２ AP変換（IDLⅡ変換）
ＩＤＬＩＩからCOBOLへの移行方式は２方式がある。
Ｔ社様では、保守性を考慮し、方式１を採用。
変換方式

方式の内容

特徴

方式１

ＩＤＬⅡソースからＣＯＢＯＬへの移行
・プログラムが構造化されているためアクション変換は処理パターン（雛形）を 可読性が良い
元に変換
・保守性が良い・非手続き型要素を手続き型処理に変換が必要
・完全にツール化が難しい面があり、若干の手修正がある

方式２

ＩＤＬⅡコンパイラが生成したＣＯＢＯＬソー ・コンパイラが生成したコードなので可スからの移行
読性が良くない
・保守性が悪い・手続き型なのでそのまま変換可能© NEC Soft Corporation 200718

４．２ AP変換（IDLⅡ変換）＜ＩＤＬⅡプログラムの構造＞②

アクション１

ＩＤＬ制御部④終了処理③

アクション２①

初期処理＜マイグレーション後のＣＯＢＯＬプログラム構造＞

初期処理
マルチアクションアクション１

アクション２

終了処理・構造化したＣＯＢＯＬプログラムロジックへ変換
・アクション間の繋がりも構造化したロジックで実現© NEC Soft Corporation 2007

19５． まとめ■Ｔ社様からのお言葉
・思っていたより大変だったが、予定通りサービスインでき、順調に稼動している
・マイグレーションＰＪでは、特にテスト時は問題がありそうなところをピンポイントで指摘してくれて、技術力（マイグレーション経験/ノウハウ）に感心した

メインフレームの業務システムはお客様が長年築き上げてこられた、かけがえのない財産です。
これを無駄にすることなく、将来へ活かして行くお手伝いを、今後もお客様と協力し合って、一丸となって行ってまいりたいと思います。

ご清聴ありがとうございました© NEC Soft Corporation 200720

© NEC Soft Corporation 200721