メインフレーム・マイグレーションによる最新基幹システム移行事例

東京システムハウス株式会社
マイグレーションコンサルティング部
コンサルティング＆サービス課
リーダー 三浦 喬
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

1目次
1. 事例概要
1. お客様のご紹介
2. システム概要
3. プロジェクトの背景と目的

2. プロジェクト詳細
1. マイグレーション方針
2. システム構成
3. プロジェクト体制と役割分担
4. スケジュール計画と実績
5. 課題と対応策

3. まとめ1. お客様の評価
2. 今後の課題
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

2１．事例概要

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

3

１ー１．お客様のご紹介

商号
本社所在地
設立年月日
資本金
売上高
社員数
市場名

オリジン電気株式会社
http://www.origin.co.jp/
東京都豊島区高田1丁目18番1号
1938年（昭和13年）5月1日
61億円
252億1,500万円(平成21年度実績：連結)1188名(平成22年3月末：連結)
東証一部(証券コード：6513)

 事業内容以下の“3事業の連携・シナジー効果”を発揮し『提案型の製品開発』を進めています。
– エレクトロニクス• 電源機器、半導体デバイス– メカトロニクス• システム機器、精密機構部品– ケミトロニクス• 合成樹脂塗料
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

4

１ー１．お客様のご紹介
 基幹システム歴史‒ オリジン電気様の沿革および基幹システムの歴史は以下の通りです。

飛躍期（1990〜）

20
10年5月 新オープン環境へ
2010年5月
新オープン環境へ
2002年2月 リプレース ACOS-ACOS

1998年 埼玉オリジン株式会社を設立
1996年2月 リプレース ACOS-ACOS
1988年 結城オリジン株式会社を設立

1988年2月 リプレース ACOS-ACOS
1980年 NEC製汎用機導入

1972年 瑞穂工場を新設
1969年 東証第１部に上場
1961年 東証第２部に上場
1952年 社名をオリジン電気に変更

1938年 設立
1938年
設立
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

激動期（1970〜1989）1970年 富士通製汎用機導入

発展期（1950〜1969）
創業期（1938〜1949）5

１−２．システム概要
 システム種別

基幹システム（販売管理、生産管理、購買管理
原価管理、出荷管理、部品在庫管理）

 システム情報/規模
OS

ACOS4

COBOL

1365本

JCL

1107本

コマンドプロシージャ

100本

簡易言語（NL2）

105本

画面定義体（MFDL）

391本

帳票定義体（MFDL）

169本

オーバレイ（FDL）

100本

RDB（RIQS）

150テーブル

VSAS

50本

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

6１−３．プロジェクトの背景と目的
 オープン化検討の理由‒ ２０００年問題の対応をきっかけに社内システムに対し注目されはじめる‒ 汎用機上で稼動している基幹システムに課題が顕在化

課題1：ITコストの増大
・ TCOが高止まり
・ 保守メンテナンスに掛かる工数大

課題3：処理性能の劣化
・ オンラインのレスポンスが悪化
・ 夜間バッチの処理時間が延伸

課題4：拡張性に乏しい

課題2：ブラックボックス化
・ 現社員による保守メンテナンスが困難
・ 開発作業を外部委託できない・ 制限・制約が多い

汎用機のリースアップを機にシステムのオープン化を計画
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

7１−３．プロジェクトの背景と目的
 検討したオープン化手法、及び選定理由‒ オープン化手法の比較/評価
既存資産
有効活用

コスト

期間移行
リスク

システム
機能

保守
メンテナンス

拡張性

再構築

×××△

◎◎

◎

パッケージ×△△○○△△マイグレーション

◎◎

◎

○○○○

‒ オープン化手法の選定
COBOL資産・開発スキルが継承できる
ユーザインターフェースに変更無く、業務変更も無い

マイグレーション

納期厳守で安定的なオープン化を実現できる

上記理由より、オープン化手法はマイグレーションに決定！
その後、SIベンダーの提案をうけ、マイグレーションの製品/サービスを検討。
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

8

１−３．プロジェクトの背景と目的
 オープンCOBOL、ベンダー選考のポイント‒ マイグレーションにおけるオープンCOBOL、ベンダー選考のポイントは以下の通り。

【ポイント①】
オープンCOBOL製品の選定においては、グローバル・スタンダードなものをという強い意向
マイクロフォーカス社製オープンCOBOLを選定！
【ポイント②】
国内での汎用機マイグレーション実績が豊富なサービスを検討
100件以上の国内汎用機マイグレーション実績を評価！

東京システムハウスの『MMS』を選定していただく！
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

9１−３．プロジェクトの背景と目的
 プロジェクトの要件/目的

既存システムの運用を踏襲したまま、拡張性の向上および、現行システムの課題を解決する！
現行システムが抱える課題を解決する為の要件
現行システムが抱える課題を解決する為の要件
・・ 低価格なIAサーバを使用する事で、ITコストを削減する
低価格なIAサーバを使用する事で、ITコストを削減する
・・ 汎用機資産の棚卸を行い、システムの現状を再確認･把握･整理する汎用機資産の棚卸を行い、システムの現状を再確認･把握･整理する
・・ オープン系の技術を取り入れることで、システムに拡張性を持たせる
オープン系の技術を取り入れることで、システムに拡張性を持たせる
・・ 処理性能を向上させる
処理性能を向上させる
・・ 開発系を構築し、本番系と２つの環境をもつ開発系を構築し、本番系と２つの環境をもつ・・ HA構成とし、高い可用性を保つ
HA構成とし、高い可用性を保つ
・・ 帳票の電子ファイル（ＰＤＦ）出力を実現し、紙の印刷を削減させる
帳票の電子ファイル（ＰＤＦ）出力を実現し、紙の印刷を削減させる

現行システムを踏襲したまま、システムのオープン化を実現する為の要件
現行システムを踏襲したまま、システムのオープン化を実現する為の要件
・・ ユーザインターフェースは出来る限り変えない
ユーザインターフェースは出来る限り変えない・・ 業務内容の変更、機能の見直しは不要
業務内容の変更、機能の見直しは不要
・・ システム切替時のユーザー部門への負荷を最小限に留める
システム切替時のユーザー部門への負荷を最小限に留める
・・ 既存資産の継承（開発スキル、プログラム、ノウハウ）
既存資産の継承（開発スキル、プログラム、ノウハウ）
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.
10１−３．プロジェクトの背景と目的
 実施前の課題/懸念事項と対応策
課題とその対応策は以下の通り。
《課題①》新システム環境への適応が不安《課題①》新システム環境への適応が不安
オープン系COBOL及び、ORACLEやSVF等のオーオープン系COBOL及び、ORACLEやSVF等のオープン系製品の経験技術者もいなく、新環境へ適応プン系製品の経験技術者もいなく、新環境へ適応が出来るか不安。
が出来るか不安。

《課題②》《課題②》汎用機に開発環境が無い
汎用機に開発環境が無い
開発環境がない為、照合テストデータの取得、動開発環境がない為、照合テストデータの取得、動作検証が困難であると想定。
作検証が困難であると想定。

《課題③》日常業務をこなしながら出来るか《課題③》日常業務をこなしながら出来るか限られた人数での日常業務をこなしながら、マイグ限られた人数での日常業務をこなしながら、マイグレーション作業を予定通り行えるのかが心配。
レーション作業を予定通り行えるのかが心配。
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

《対応策》照合テストの実施方法を工夫《対応策》照合テストの実施方法を工夫
・通常ベンダーが請負う照合テストをオリジン電・通常ベンダーが請負う照合テストをオリジン電
気様に実施して頂き、プロジェクトの早い時気様に実施して頂き、プロジェクトの早い時期からオープン系へ慣れて頂く事で、稼動後期からオープン系へ慣れて頂く事で、稼動後の技術力不安を取り除いた。の技術力不安を取り除いた。
・開発環境が無い為、テストケース取得が困・開発環境が無い為、テストケース取得が困難である為、通常のマイグレーションプロジェク難である為、通常のマイグレーションプロジェク
トと比べ、照合テスト期間を長く予定。その為、トと比べ、照合テスト期間を長く予定。その為、照合テスト実施までの期間を5ヶ月間という照合テスト実施までの期間を5ヶ月間という短納期で予定した。
短納期で予定した。
・常駐テスト支援を実施し、テスト実施ノウハ
・常駐テスト支援を実施し、テスト実施ノウハ
ウ及び簡易ツールの提供、オープン系製品のウ及び簡易ツールの提供、オープン系製品の使用方法の教授を実施した。
使用方法の教授を実施した。
11

２．プロジェクト詳細

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

12２−１．マイグレーション方針
 マイグレーション方針‒ 簡易言語（NL2）は、汎用機上で一旦COBOL化し、その後オープンCOBOLに変換
汎用機
汎用機

マイグレーション後
マイグレーション後

既存資産
既存資産

マイグレーション後の資産
マイグレーション後の資産

汎用機
汎用機 COBOL,COBOL, COPY句
COPY句

オープン
オープン COBOL,COBOL, COPY句
COPY句

JCL、コマンドプロシージャ
JCL、コマンドプロシージャ

AJTOOLAJTOOL JCL
JCL スクリプト
スクリプト (AJ̲JCL)(AJ̲JCL)

画面定義（MFDL）
画面定義（MFDL）
帳票定義（MFDL）
帳票定義（MFDL）

変換サービスによる変換サービスによるコンバージョン
コンバージョン

オープン
オープン COBOL
COBOL
SVFオーバレイ
SVFオーバレイ

オーバレイ（FDL）
オーバレイ（FDL）
簡易言語
簡易言語 (NL2)
(NL2)

オープン
オープン COBOL
COBOL

SEQ,
SEQ, VSAM,
VSAM, RDB（RIQS）
RDB（RIQS）

コード変換とデータ移行
コード変換とデータ移行

SEQ,
SEQ, VSAM,
VSAM, ORACLEORACLE

汎用機のユーティリティ
汎用機のユーティリティ

代替ユーティリティ
代替ユーティリティ

AJTOOL,AJTOOL, オープン系代替ツール
オープン系代替ツール

帳票出力
帳票出力
運用管理
運用管理
汎用機OS（ACOS4）
汎用機OS（ACOS4）

帳票ツール（SVF）
帳票ツール（SVF）

オープン系ミドルウェア
オープン系ミドルウェア

運用ツール（千手）運用ツール（千手）WindowsWindows

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

13

２−２．システム構成
 移行前のシステム構成図
オフコン

サーバ

マイグレーション対象範囲

ECO-GP
PD部 サブシステム
生産管理

メインフレーム

i-PX7600

Nis
Mail

受注データ
製作指示データ

製品構成データ
部品データ

サーバ
出荷データ
在庫データ
検収データ
出庫データ
振替データ
製品在庫データ
在庫単価データ
原価データ
部品デ タ

部品EDIシステム

Nis
Mail

Nis
Mail

発注データ
納期回答デー
タ

専用端末
オフコン
Nis
Mail

MT部 サブシステム
生産管理
受注データ
製作指示データ

部品倉庫システム
出庫データ

NisMail

NisMail

NisMail

NisMail

サーバ
出荷データ
製品在庫データ
検収データ
出庫データ
振替データ

サーバ
人事給与システム
人事データ
仕訳データ

サーバ
経理システム(経理部)仕訳データ

直接経費
データ

受注データ
売上データ
受注残データT部 ERP
販売管理
生産管理
売上データ
検収データ
出庫データ
振替データ

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

14

２−２．システム構成
 移行後のシステム構成図
CPU:2CPU
ﾒﾓﾘ:16GB
ﾃﾞｨｽｸ:
73.2GB×2ﾐﾗｰ
300GB×4ｱﾚｲ

DBサーバ
120Ri-2

Open COBOL
千手エージェント
Oracle Client

CPU:2CPU
ﾒﾓﾘ:4GB
ﾃﾞｨｽｸ:
36.3GB×3ｱﾚｲ

千手センサー

管理者サーバ
120Ri-2

ロードバランサ

CPU:2CPU
ﾒﾓﾘ:4GB
ﾃﾞｨｽｸ:
36.3GB×3ｱﾚｲ

Oracle Database

帳票サーバ
120Rg-1

千手マネージャークライアントWindows XP

Open COBOL
CPU:2CPU
ﾒﾓﾘ:4GB
ﾃﾞｨｽｸ:
36.3GB×3ｱﾚｲ

RDE
UC/X
千手センサー

CPU:1CPU
ﾒﾓﾘ:4GB
ﾃﾞｨｽｸ:
73.2GB×2ﾐﾗｰ
300GB×3ｱﾚｲ

バッチサーバ
120Rg-1

APサーバ
120Rg-1 × ３
CPU:1CPU
ﾒﾓﾘ:4GB
ﾃﾞｨｽｸ:
73.2GB×3ｱﾚｲ

プリンタ

バックアップサーバ
NS460

千手エージェントF*TRAN
ftpサーバーRD Utility

ﾃｰﾌﾟｵｰﾄﾛｰﾀ装置
LTO3:16巻ﾓﾃﾞﾙ
T16A

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

15

２−３．プロジェクト体制と役割分担
 プロジェクト体制図および役割分担

オリジン電気株式会社様テスト（照合・結合・総合）

SIベンダー A社
プロジェクト統括、ハード/インフラ製品の提供・構築

東京システムハウス株式会社（略称：TSH）
マイグレーションコンサルティング部

移行設計、プロトタイプ、コンバージョン、テスト支援

マイクロフォーカス

野村総合研究所(Open COBOL)

(千手)
千手)

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

ウイングアーク テクノロジーズ(SVF：帳票ツール(SVF：帳票ツール))16

２−３．プロジェクト体制と役割分担
 プロジェクト運営での注意点‒ ３社間でのプロジェクト遂行の為、品質保証範囲・判定基準を予め明文化。
‒ 問い合わせは原則全て問い合わせ票にて管理。
‒ 連絡は全てメーリングリストにて連絡。
‒ メールのロストを防ぐ為、件名のルール化。
• 【マイグレ（進捗）】yyyymmdd（会社名）• 【マイグレ（ＱＡ）】ＱＡ票のファイル名• 【マイグレ（連絡）】内容要旨‒ テストにおける修正は全て修正管理を行い、他リソースへ横展開の徹底。
※マイグレーションはツール変換の為、１つの課題から複数の修正が可能。

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

17２−４．スケジュール計画と実績
 スケジュール計画と実績
2008年

2009年

2010年

8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月

1月 2月 3月 4月 5月

調査・分析

実績
移行設計

実績
プロトタイプ実績
コンバージョン

開発環境が無い為、本番環境での取得データ待ちテストケースの実施。及び、再照合テスト実施の為。完了済ジョブより結合テスト実施。

実績
照合テスト
本稼働

実績
結合テスト

実績総合テスト

実績
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

18

２−５．課題と対応策
 移行対象資産における課題‒ 現行資産を調査して移行対象とするか否かを決定し、無駄な資産は工数・期間の無駄使いとなりますので移行対象外とします。
‒ 資産調査方法は以下の通りです。
• 現行汎用機実行ログ調査、ユーザへのヒアリング
リソース

汎用機資産本数

移行対象本数

減少率

COBOL

約1400本約1000本

３９％ダウン！

JCL

約1100本

約500本

５５％ダウン！

画面定義（MFDL）

約400本

約300本

２５％ダウン！

【課題】
但し、テスト工程以降に移行対象外リソースから移行対象リソースとした場合、調査を実施していなく、また、変換が正しく出来ない可能性もあり、余計に工数・期間を無駄使いしてしまう事も。

本プロジェクトでは、移行対象外のリソースについても、予め変換作業のみは実施し、御客様作業において後戻り工数が発生しない様に対応！
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

CLEAR
CLEAR

19

２−５．課題と対応策
 COBOL非互換対応‒ 汎用機COBOLとオープンCOBOLの非互換は複数あり、それらの大部分は規則性を持っている為、変換ツールで対応する事が可能です。しかし、【課題】
ファイルアクセスCOBOL命令“Currency”については、対応する命令が、オープンCOBOLに無い為、単純なツール変換が出来ない！

‒ ある程度の機械変換は実施出来るものの、ロジックの判断を行い、最終的には手修正を実施しなければならない。

本プロジェクトでは、プロトタイプを実施し、特定のパターンの分析・移行設計を行い、ツール変換を実施。
照合テストにて他のパターンが出た場合には、そのパターンの分析・移行設計を行い、パッチ対応及び手修正による横展開を実施。
CLEAR
CLEAR

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

20２−５．課題と対応策
 照合テスト効率化‒ 照合テストにおいては、汎用機と同様のインプットデータを使用し、同じアウトプットが出力されるかの確認を行います。
【課題】
汎用機に開発環境が無いと本番環境データを使用する為、照合テストにおいて、トランザクションなども入ってしまい、正しくデータを取得するのが困難。

オンラインの照合テストについては、オリジン電気様環境でテストを実施し、汎用機上の実データを確認しながら、テスト作業を実施。
CLEAR
CLEAR

バッチの照合テストについては、部分的レコードの抜粋による照合テストを行い、複数回の処理を実施する事で、品質を向上した。
CLEAR
CLEAR

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

21

２−５．課題と対応策
 ミドルウェア不具合【課題】
本番稼動直後にミドルウェアの不具合発生。
‒ 製造元への問い合わせを実施するが初ケース（レアケース）との事。
‒ 情報の提供からでは、製造元での検証で再現せず。
‒ 製造元へ再現環境を送付したいが、本番環境でのデータのみの再現の為、データマスキングの必要有。また、最小構成で再現する様、加工。。。
‒ ようやく、製造元で、障害現象再現。。。
‒ パッチの改修まで待っていられない。。。

本番稼動直後のミドルウェア不具合は、既知の問題以外は、製造元での早急な対応は困難。
割り切って、アプリケーションの修正で逃げるのがベター！
CLEAR

CLEAR

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

22２−５．課題と対応策
 本番切替に関する課題と対策【課題】
本番切替に関し、システム単位での順次移行は、システム性質上出来ないため本番移行は、ワンポイント切替で行う必要がある。
‒ データ移行シミュレーションを十分に実施• 移行テスト計画を本番切り替え1年前から実施。
• 移行リハーサルを4回実施。

‒ データ転送時間の短縮化（データ転送の見直し、簡易ツールの作成）‒ 蓄積データの事前移行• CGMTの蓄積データは、１ヶ月前に移行を実施• 本番切り替え時は差分を更新

本番切り替え時、及び本番切り替え後、大きな問題や、データ変換ミスなど無く、移行成功！
CLEAR
CLEARCopyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

23

３．まとめCopyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

24３−１．お客様の評価
 御客様の評価
処理性能向上
処理性能向上・処理時間4時間程度のジョブが、20分に短縮！
・処理時間4時間程度のジョブが、20分に短縮！
・汎用機では、デイリーのバックアップは主要ディスクのみであったが、フルバックアップに変更！
・汎用機では、デイリーのバックアップは主要ディスクのみであったが、フルバックアップに変更！
・バッチ処理数を拡大（翌日対応となっていた個別処理を当日対応に）！
・バッチ処理数を拡大（翌日対応となっていた個別処理を当日対応に）！

コスト削減
コスト削減
・汎用機完全撤去によるITコスト削減！
・汎用機完全撤去によるITコスト削減！
・PDF化によるTCO削減！
・PDF化によるTCO削減！

安定稼動
安定稼動
・本番稼動後ノーダウン！
・本番稼動後ノーダウン！
・アプリケーションサーバは、HA構成に出来た為、可用性を確保。
・アプリケーションサーバは、HA構成に出来た為、可用性を確保。

拡張性向上
拡張性向上
・外部との連携がとり易い、拡張性のあるシステム基盤が構築出来た！
・外部との連携がとり易い、拡張性のあるシステム基盤が構築出来た！

保守・メンテナンス性向上
保守・メンテナンス性向上
・ブラックボックス化されていたシステムの一部が紐解かれた！
・ブラックボックス化されていたシステムの一部が紐解かれた！
・スキルトランスファーを行いながらのプロジェクトになった為、新環境の適用も問題無し！
・スキルトランスファーを行いながらのプロジェクトになった為、新環境の適用も問題無し！
・汎用機では無かった開発系が構築できた事により保守性が向上！
・汎用機では無かった開発系が構築できた事により保守性が向上！
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.
・ORACLE、SVF化、GUI化を行った事で、ユーザーからの機能要望が増加。
・ORACLE、SVF化、GUI化を行った事で、ユーザーからの機能要望が増加。

25

３−２．今後の課題
 今後の課題および方向性

バックログ対応
仕様凍結による改修作業
仕様凍結による改修作業
・一定期間仕様凍結を行っていた事による、改修作業の宿題が・・・・一定期間仕様凍結を行っていた事による、改修作業の宿題が・・・

新サービスの展開
帳票出力
帳票出力
・今回PDF化を実施した事がきっかけとなり、社内でペーパレス化の促進が活発に。
・今回PDF化を実施した事がきっかけとなり、社内でペーパレス化の促進が活発に。
・専用帳票をオーバレイを作成することで、汎用紙出力に変更。
・専用帳票をオーバレイを作成することで、汎用紙出力に変更。

RDB
活用
RDB活用
・インデックスファイルもRDB化を検討中。
・インデックスファイルもRDB化を検討中。
・DBをユーザにWeb公開
・DBをユーザにWeb公開

今後の方向性
オフコンのオープン化
オフコンのオープン化
・当初より汎用機マイグレーション後に予定していたオフコンのオープン化について検討中。
・当初より汎用機マイグレーション後に予定していたオフコンのオープン化について検討中。

Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

26

ご静聴有難うございました。

サービスを通じ、ユーザーに愛され信用･信頼を得ることが最大の目的である。
Copyright © 2010, Tokyo System House Co., Ltd. All Rights Reserved.

27