第１６回 COBOLコンソーシアムセミナー
COBOLコンソーシアムセミナー
時代を超えて基幹システムを支え続けるCOBOL
時代を超えて基幹システムを支え続けるCOBOL

マイグレーションにより実現できたオープン環境での業務ＳＥの有効活用

株式会社大和ソフトウェアリサーチ
保険・共済ビジネス事業本部 保険・共済ソリューション部
平成２１年２月２５日

松原 清Ｃｏｎｔｅｎｔｓ
１．ＤＳＲのご紹介
1.1 ＤＳＲの概要
1.2 ＤＳＲの保険共済ビジネス事業内容
1.3 ＤＳＲにおけるＣＯＢＯＬ技術者の位置づけ
２．今回のマイグレーションの背景
2.1 対象システムの概要
2.2 意思決定のプロセス
2.3 今回のマイグレーションに関する課題及び対応策
３．マイグレーション方針について
3.1 マイグレーションの技術的対応方針
４．マイグレーション実作業
4.1 対応スケジュール
4.2 マイグレーション作業におけるポイント
4.3 成功の要因
５．マイグレーション後
5.1 評価できる点
5.2 今後の課題
６．まとめ

12356810111213141617

DSR Confidential

1１．ＤＳＲのご紹介
1.1 ＤＳＲの概要
【会社名】
【所在地】

株式会社大和ソフトウェアリサーチ①本社：東京都千代田区麹町1丁目5番2号
TEL：03-3262-8558（代表） FAX：03-3262-8867②システムサービスセンター：千葉県茂原市緑ヶ丘3丁目17番1号
TEL：0475-25-8111（代表） FAX：0475-25-8130③東京センター（ＩＤＣ）：東京都江東区

【設立日】
【資本金】
【業 績】
【従業員数】

1969年 7月 3日
4億450万円
売上高：30億7900万円（2007年度）
140名（2008年4月1日）【認定資格】

・情報セキュリティマネジメントシステム：ISO/IEC27001：2005認証（対象事業所：システムサービスセンター）・プライバシーマーク・システムインテグレータ
・システムオペレーション【U R L】③東京ｾﾝﾀｰ★
★
①本社②ｼｽﾃﾑｻｰﾋﾞｽｾﾝﾀｰ★

http://www.dsr.co.jp
1DSR Confidential

１．ＤＳＲのご紹介
1.2 ＤＳＲの保険共済ビジネス事業内容
設立当初より、大手共済団体のシステム開発・運用を主要事業として営んでおりました。共済団体向けシステム開発・運用のノウハウを基に共済団体の新規顧客を獲得し、業務が類似している保険業界へと事業を拡大して参りました。現在では長年の上流工程からの経験を通して習得した保険共済業務ノウハウ、また保険数理業務に強いＳＥを多数抱えた強みを活かして事務設計やシステム化検討といったコンサルティング業務にも力を発揮しています。

④約10%
④約10%

売上構成比率
売上構成比率

平成19年度全社売上中約67％が保険共済団体向け案件①約44％：共済団体向け案件②約23％：保険会社向け案件

③約23%
③約23%

②約23%
②約23%

①約44%
①約44%

共済
共済
保険
保険
大和証券グループ
大和証券グループその他
その他

平成19年度売上上位10顧客中6顧客が保険共済団体（4：共済団体、2：保険会社）
上記の他、大手ベンダー2社を通じて保険共済団体向け案件に従事

日本共済協会会員14団体中6団体と直契約取引
生命保険会社5社、損害保険会社3社
少額短期保険会社1社
DSRの保険共済ビジネス事業はの保険共済ビジネス事業は
DSR
DSRの保険共済ビジネス事業は設立以来約40年のノウハウが蓄積された中核事業多数の顧客から信頼と評価をいただいております。
2
DSR Confidential

2１．ＤＳＲのご紹介
1.3 ＤＳＲにおけるＣＯＢＯＬ技術者の位置づけ
保険・共済システムの概略図
基 幹 シ ス テ ム

ＣＯＢＯＬによるバッチ処理主体

営 業 支 援 系（対 消 費 者）

ＪＡＶＡ・ＨＴＭＬ等による対話型処理主体

・新契約

消費者

・契約管理（保全）・問い合わせ・資料請求・請求/・請求/収納・各種手続・決算/・決算/配当

Ｗｅｂサーバ・数理計算

営 業 支 援 系（対 契 約 者）

・支払審査/・支払審査/支払・挙績/・挙績/精算

メインフレーム

ＪＡＶＡ、ＶＢ、Ｃ言語等による対話型処理主体
営業職員

・会計･保障設計書･提案書 等

大量データを管理し、一括処理・顧客対応
・新規提案

拠点サーバ

・保険・共済システムの「肝」とも言える部分です。

経 営 支 援 系（分 析・収 支 予 測 等）・４０年に渡るノウハウは数多くの基幹システム構

データマイニングツールによるＥＵＣ築により蓄積されてきました。その為経営企画部門「ＤＳＲの保険共済業務ＳＥ＝ＣＯＢＯＬ」という傾向が非常に強くなっています。
※近年ではオープン系による営業支援系や経営支援系にも分野を拡大しています。

・経営分析
・収支予測
・各種統計

ＤＢサーバ（ＤＷＨ）

3
DSR Confidential

１．ＤＳＲのご紹介
1.3 ＤＳＲにおけるＣＯＢＯＬ技術者の位置づけ
ＣＯＢＯＬを習得しているＳＥ数

６５名

ＤＳＲの技術職

９７名

ＳＥ数

６７．０％
平成２１年２月現在

ＤＳＲの経営理念「人を創り、人を育て、人で勝負する企業を目指す」
業務ノウハウを有した業務ＳＥを如何に活用できるかが、企業としての成長力のカギとなる↓

高付加価値ＳＥの育成および活用が必須
・業務コンサルティング（顧客業務要件を分析し、事務の効率化を目指した新業務フローの作成ができる）
ができる上流ＳＥはほとんど上記６５名に含まれます。
・新人社員研修については、基本的にＣＯＢＯＬ以外のオープン系言語のため、若年層社員におけるＣＯＢＯＬ比
率は上記比率よりも下がりますが、配属現場により、一年目の新人からＣＯＢＯＬを習得させる場合もあります。
なお、来年度新卒採用社員からＣＯＢＯＬ及びＪＣＬのメインフレーム研修カリキュラムを設けました。
4DSR Confidential3２．今回のマイグレーションの背景
2.1 対象システムの概要【システムの種別】

団体内役職員向け共済システム（福利厚生の一環）【対象となる制度】①役職員向共済（生命共済・医療共済） ②パートタイマー向共済③拠出型企業年金保険 ④退職者向共済 ⑤長期休業補償【システムの規模】

移行元

メインフレームOS

COBOL

約340本（うち新規作成60本）

JCL

約130本

MFDL（MFDL（画面定義）

約50本

ALPS（ALPS（簡易言語）（ＪＣＬ内の約180箇所に記述）

COBOL/SマクロCOBOL/Sマクロ

約130本

データベースRIQS 約80テーブル【システムの特徴】①契約件数は比較的少ない（約１０万件程度）②機能的には、新契約、保全、支払、請求/収納、精算（営業支援系や数理系は無）③自家共済制度と他社商品の組合せのため、規模の割に把握すべき業務が多い④商品の特性上、商品改定があまり実施されないため、システムが陳腐化しにくい⑤業務から見直し、２００３年に稼動開始したシステムのため、まだ余命が長い⑥福利厚生の一環のため、メイン業務の基幹システムほど予算が潤沢でない
5
DSR Confidential

２．今回のマイグレーションの背景
2.2 意思決定のプロセス
メインフレームのリースアップに伴う撤去（２００８年９月末を予定）
メインフレームのリースアップに伴う撤去（２００８年９月末を予定）
継続使用の問題点 → ランニングコストが高額（機器費用、ファシリティ含む運用費用）→ 役職員向け共済システムのみを稼動させるにはオーバースペック
導き出される移行要件【移行要件①】

２００８年９月末までに、現行メインフレームの撤去を可能とする
２００８年９月末までに、現行メインフレームの撤去を可能とする【移行要件②】

ランニングコストも含めたトータルコストの低減

上記の要件から最終的に検討された選択肢は以下の３つ《選択肢①》
メインフレームの導入＆システム資源の移植の導入＆システム資源の移植 スケジュール重視かつオーバースペック解消
下位機種
スケジュール重視かつオーバースペック解消《選択肢①》 下位機種メインフレーム
下位機種メインフレームの導入＆システム資源の移植【メリット】【メリット】 ・スケジュール及び技術面のリスクが小・スケジュール及び技術面のリスクが小 ・ユーザの使い勝手が全く変わらない・ユーザの使い勝手が全く変わらない【デメリット】(場合によっては逆効果ともなり得る)・トータルコストの削減効果は低場合によっては逆効果ともなり得る)【デメリット】 ・トータルコストの削減効果は低(・トータルコストの削減効果は低(場合によっては逆効果ともなり得る)《選択肢②》《選択肢②》 サーバ上でのシステム再構築
サーバ上でのシステム再構築 トータルコスト削減重視
トータルコスト削減重視

リプレース
リエンジニアリング【メリット】・システム化対象範囲の見直しにより規模縮小可能
可能 ・技術基盤の選択肢が広がる
基盤の選択肢が広がる【メリット】・システム化対象範囲の見直しにより規模縮小
・技術【メリット】・システム化対象範囲の見直しにより規模縮小可能
・技術基盤の選択肢が広がる【デメリット】・要件定義から始める為、工期が長期に渡る・大幅な業務の再構築無しではコスト高ともなり得る【デメリット】・要件定義から始める為、工期が長期に渡る・大幅な業務の再構築無しではコスト高ともなり得る《選択肢③》《選択肢③》 サーバ上へのシステム資源の移植
サーバ上へのシステム資源の移植 スケジュール重視かつトータルコスト削減を狙う
スケジュール重視かつトータルコスト削減を狙う

リホスト【メリット】・スケジュール及び技術面のリスクが小【メリット】・スケジュール及び技術面のリスクが小 ・ランニングコストも含めて考慮するとコスト削減が可能
・ランニングコストも含めて考慮するとコスト削減が可能【デメリット】・システム規模のスリム化は図れない
コンバージョンツールに依存したシステムとなる【デメリット】・システム規模のスリム化は図れない ・・コンバージョンツールに依存したシステムとなる
6
DSR Confidential4

２．今回のマイグレーションの背景
さらに３つの選択肢を、それぞれのメリット＆デメリットから判断すると・・・《選択肢①》《選択肢①》 スケジュール重視かつオーバースペック解消を狙う
スケジュール重視かつオーバースペック解消を狙う
下位機種メインフレーム
メインフレームの導入＆システム資源の移植の導入＆システム資源の移植
下位機種
下位機種メインフレームの導入＆システム資源の移植【メリット】【メリット】
リプレース
・スケジュール及び技術面のリスクが小・スケジュール及び技術面のリスクが小・ユーザの使い勝手が全く変わらない・ユーザの使い勝手が全く変わらない【デメリット】【デメリット】
・トータルコストの削減効果は低((場合によっては逆効果ともな・トータルコストの削減効果は低・トータルコストの削減効果は低(場合によっては逆効果ともなり得る))
り得るり得る)《選択肢②》《選択肢②》 トータルコスト削減重視
トータルコスト削減重視
サーバ上でのシステム再構築
サーバ上でのシステム再構築【メリット】【メリット】
・システム化対象範囲の見直しにより規模縮小可能
可能
・システム化対象範囲の見直しにより規模縮小
・システム化対象範囲の見直しにより規模縮小可能
・技術基盤の選択肢が広がる
基盤の選択肢が広がる・技術・技術基盤の選択肢が広がる
リエンジニアリング【デメリット】【デメリット】
・要件定義から始める為、工期が長期に渡る・要件定義から始める為、工期が長期に渡る・大幅な業務の再構築無しではコスト高ともなり得る・大幅な業務の再構築無しではコスト高ともなり得る《選択肢③》《選択肢③》 スケジュール重視かつトータルコスト削減を狙う
スケジュール重視かつトータルコスト削減を狙う
サーバ上へのシステム資源の移植
サーバ上へのシステム資源の移植【メリット】
リホスト【メリット】
・スケジュール及び技術面のリスクが小・スケジュール及び技術面のリスクが小・ランニングコストも含めて考慮するとコスト削減が可能
・ランニングコストも含めて考慮するとコスト削減が可能【デメリット】【デメリット】
・・移植対応そのもののコストは比較的高くなる
移植対応そのもののコストは比較的高くなる・・コンバージョンツールに依存したシステムとなるコンバージョンツールに依存したシステムとなる

スケジュール上のリスクはクリア可能。
可能。
スケジュール上のリスクはクリア
スケジュール上のリスクはクリア可能。
メインフレームを使用するため、を使用するため、メインフレームメインフレームを使用するため、ランニングコスト含むトータルコスト
ランニングコスト含むトータルコスト大幅低減は実現不可能
低減は実現不可能。
。
大幅大幅低減は実現不可能。

サーバ採用によるランニングコスト
サーバ採用によるランニングコストの低減によりトータルコスト削減はの低減によりトータルコスト削減は可能。
可能。
大幅な業務の再構築を見据えた大幅な業務の再構築を見据えた要件定義から開始する必要がある
要件定義から開始する必要がある
ため、２００８年９月までに完成さため、２００８年９月までに完成させる事はほぼ不可能。
せる事はほぼ不可能。

コスト面
から見送り

工期面から見送り

サーバ採用によるランニングコスト
サーバ採用によるランニングコストの低減によりトータルコスト削減はの低減によりトータルコスト削減は可能。
可能。
スケジュール上のリスクはクリア可
スケジュール上のリスクはクリア可能。
能。
固有のツールにて移植したシステ
固有のツールにて移植したシステムとなるが、ツール活用以外ではスムとなるが、ツール活用以外ではスケジュールリスクがクリア不可能とケジュールリスクがクリア不可能となる。
なる。

採択
7
DSR Confidential

２．今回のマイグレーションの背景
2.3 今回のマイグレーションに関する課題及び対応策
課題とその対応策としては以下の通りです。
¾ ハードウェアのサイジング¾ ユーザ側にて、別システムで使用していたサーバを流用することが前提¾ 致命的な性能問題でない限り、性能問題を運用でカバー（ＪＯＢの組み換え、業務スケジュールの見直し）¾ ユーザ側の体制¾ ユーザ側システム部門は、別件の対応で手一杯のため当件については支援不可能¾ 運用テストや稼動切替時の体制及び稼動後の保守に不安¾ 既存システム保守を担当していたＳＥ部隊が継続してサポートすることで不安を解消¾ 運用テストフェーズからユーザにも参加して頂くことで、稼動後の運用に関する不安を解消

8DSR Confidential5

２．今回のマイグレーションの背景
2.3 今回のマイグレーションに関する課題及び対応策¾ スケジュールが極めてタイト¾ ２００８年９月末の現行ホスト撤去期限まで、着手から約７ヶ月！
¾ 万一に備え、９月末～１０月の運用サイクルを見直し、最大で２０日のバッファを確保¾ 既存システムを保守していたため、初期調査及び分析工程を大幅に圧縮¾ オンライン画面系については、機能を統合して画面数を圧縮。さらにＶＢ．ＮＥＴでの開発とすることにより（リライト）、オフショア開発が可能となり、工期及びコストを大幅に圧
縮¾ 東京システムハウス㈱殿のマイグレーションツールを採用することにより、短期間で高品質なマイグレーションが可能¾ 並行して大規模メンテナンス案件を対応¾ 法改正のため２００９年３月末までに対応必須な案件有り¾ 既存システム保守により、システム資源の把握も出来ているため、並行してメンテナンスを実施しても、対応内容の反映や資源管理を確実に実施

9
DSR Confidential

３．マイグレーションの方針
3.1マイグレーションの技術的対応方針
マイグレーション前
マイグレーション前
既存資産
COBOL/S / COPY句
簡易言語（ALPS）
JCL
MFDL（画面定義）
SEQ / VSAM / RIQS
ユーティリティ
帳票出力
運用管理
メインフレームOS

マイグレーション後
マイグレーション後
マイグレーション後の資産変換サービスによる変換サービスによるコンバージョン
コンバージョン
新規作成
新規作成
コード変換とデータ移行
コード変換とデータ移行
代替ユーティリティ
代替ユーティリティ
オープン系ミドルウェア
オープン系ミドルウェア

Micro Focus COBOL / COPY句
AJ_JCLスクリプト
VB.NET
SEQ / Oracle
AJTOOL Batch Framework
DURL
JP1
Windows Server 2003

ポイント・メンテナンス性を考慮し、COBOL/Sマクロはマイグレーション後も継続利用・メンテナンス性を考慮し、COBOL/Sマクロはマイグレーション後も継続利用
・簡易言語（ＡＬＰＳ）はＣＯＢＯＬ化（約180機能を27本に集約）してコンバージョン
・簡易言語（ＡＬＰＳ）はＣＯＢＯＬ化（約180機能を27本に集約）してコンバージョン
・画面系は全てオフショアによる新規作成
・画面系は全てオフショアによる新規作成
・照会画面については、サードパーティ製のＤＢ照会ツールにて代用（照会用のＶｉｅｗを作成）
・照会画面については、サードパーティ製のＤＢ照会ツールにて代用（照会用のＶｉｅｗを作成）
・他システムで使用していたサーバを流用（ＯＳ、ＮＷ及びＲＤＢＭＳまでは環境構築済）・他システムで使用していたサーバを流用（ＯＳ、ＮＷ及びＲＤＢＭＳまでは環境構築済）10
DSR Confidential

6

４．マイグレーション実作業
4.1 対応スケジュール
着手から稼動までの７ヶ月間のスケジュールは以下の通りです。
2008年

工程

3月

4月

5月

現状調査、分析

6月

7月

8月

9月

10月

11月

３月２４日：正式受注
３月２８日：キックオフ

設計
自動コンバージョン
マニュアルコンバージョン開発
照合テスト（弊社担当分）結合テスト（お客様と弊社の共同）

実施

準備
準備

１０月１日本稼動

実施

現在安定稼働中
開発機

環境構築
運用テスト
（弊社担当部分）

本番機
準備

並行稼動

稼動開始
開発案件

実施

開発

個別開発案件開発

稼動

個別開発案件に伴う年次処理対応

11
DSR Confidential

４．マイグレーション実作業
4.2 実作業における課題とその対応
実作業を進める上で発生した課題と対応方法は以下の通りです。
《課題①》
パフォーマンスの改善《課題①》 パフォーマンスの改善
汎用的なＩ/Ｏルーチンのためパフォーマンスが悪かった
汎用的なＩ/Ｏルーチンのためパフォーマンスが悪かった
・テスト当初は月次処理が現行システムの１０倍！
・テスト当初は月次処理が現行システムの１０倍！
・夜間処理を想定時間内に終了させる必要がある
・夜間処理を想定時間内に終了させる必要がある《課題②》《課題②》 ミドルウェアの不具合
ミドルウェアの不具合
現状機能でどのように実現するか
現状機能でどのように実現するか
・帳票２部印刷、同一ＪＯＢ内での片面・両面印刷の共存
・帳票２部印刷、同一ＪＯＢ内での片面・両面印刷の共存
・Ｍｉｃｒｏ・Ｍｉｃｒｏ Ｆｏｃｕｓ
Ｆｏｃｕｓ ＣＯＢＯＬの異常終了（メモリ侵害）
ＣＯＢＯＬの異常終了（メモリ侵害）《課題③》《課題③》 照合テストの効率化
照合テストの効率化
スケジュールを厳守するためにどう対応するか
スケジュールを厳守するためにどう対応するか・テスト効率を上げる必要がある
・テスト効率を上げる必要がある

東京システムハウス㈱殿に改善依頼
東京システムハウス㈱殿に改善依頼
・不要な機能の削除、ＳＱＬを個別に見直し
・不要な機能の削除、ＳＱＬを個別に見直し→現行システムに匹敵する処理時間となる→現行システムに匹敵する処理時間となる代替策を立て、動作させることを最優先
代替策を立て、動作させることを最優先
・１ファイルを２回処理することで実現
・１ファイルを２回処理することで実現
・プリンタを論理的に２台用意することで実現
・プリンタを論理的に２台用意することで実現
・ＪＯＢ分割やＪＯＢＳＴＥＰの入替で回避
・ＪＯＢ分割やＪＯＢＳＴＥＰの入替で回避
テスト効率の向上策
テスト効率の向上策
・テスト担当毎に実行環境を構築し並行作業・テスト担当毎に実行環境を構築し並行作業可能とする
可能とする
・ツールコンバージョン仕様をテスト担当に非・ツールコンバージョン仕様をテスト担当に非公開
公開

12
DSR Confidential

7

４．マイグレーション実作業
4.3 成功の要因
当プロジェクトは成功を収めることが出来ました。要因としては、以下の３点が挙げられます。
①業務知識、運用形態の把握①業務知識、運用形態の把握–– 現行システムの事務設計～システム開発～保守までをＤＳＲが担当⇒業務知識、運用形態を熟知
現行システムの事務設計～システム開発～保守までをＤＳＲが担当⇒業務知識、運用形態を熟知–– ＪＯＢの統廃合による整理が可能
ＪＯＢの統廃合による整理が可能–– 処理エラーの特定・対応が素早くできた
処理エラーの特定・対応が素早くできた–– 照合テストを実施するうえで、メインフレーム側のテスト結果がＤＳＲ主導で取得可能照合テストを実施するうえで、メインフレーム側のテスト結果がＤＳＲ主導で取得可能–– 運用（ＪＯＢ）処理順を把握しているため、効率的な照合テストが実施できた運用（ＪＯＢ）処理順を把握しているため、効率的な照合テストが実施できた②お客様の協力体制②お客様の協力体制–– 結合テストフェーズより、エンドユーザを積極的に巻き込んで実施できた
結合テストフェーズより、エンドユーザを積極的に巻き込んで実施できた–– テスト工数の軽減
テスト工数の軽減–– エンドユーザの教育工数の軽減
エンドユーザの教育工数の軽減③東京システムハウス（株）殿の全面的な協力体制③東京システムハウス（株）殿の全面的な協力体制–– マイグレーションツールの変換精度の高さ
マイグレーションツールの変換精度の高さ–– きめ細かいサポート体制
きめ細かいサポート体制–– ＡＪＴＯＯＬＡＪＴＯＯＬ ｆｏｒｆｏｒ Ｍｉｃｒｏ
Ｍｉｃｒｏ Ｆｏｃｕｓなど使いやすい製品の提供
Ｆｏｃｕｓなど使いやすい製品の提供
そして
そして、、

既存システム保守にてにてお客様からの信頼を得ていたＳＥが、お客様からの信頼を得ていたＳＥが、顔が見える顔が見える対応を行った対応を行った
既存システム保守
既存システム保守にてお客様からの信頼を得ていたＳＥが、顔が見える対応を行ったことが、あらゆる場面でお客様とＤＳＲとのシナジー効果を生み出す源となったと考えます。
ことが、あらゆる場面でお客様とＤＳＲとのシナジー効果を生み出す源となったと考えます。
13
DSR Confidential

５．マイグレーション後の評価
5.1 評価できる点
マイグレーション後のシステムについて評価できる点としては・・・– ランニングコストが大幅に削減された¾ メインフレーム継続使用と比較して、推定約１，０００万円／月強のコスト削減に成功– 運用サービスレベルの低下が最小限に留まる¾ 納期優先のため、メインフレームでの運用サービスレベルと同等の機能の作り込みは対応せず。しかし、業務を熟知したＳＥがユーザと打合せを実施しながら妥協点を探る
ことにより、ユーザに不満を抱かせない運用サービスレベルを確保– 保守サービスレベルの維持¾ ユーザからの信頼が厚いＳＥが継続して保守サービスに従事することにより、従来通りの保守サービスレベル（対応品質およびスピード）を維持– 「小回りが利く」対応
z 小規模メンテナンス案件であれば従来通り１～２日で対応可能
z 大規模メンテナンス案件であっても、ブレの少ない見積もり及び高コストパフォーマンス対応が可¾ メインフレームＳＥだった担当ＳＥが、業務知識および従前通りのＣＯＢＯＬで構築されたコアロジックに関するノウハウに加えて、ＳＱＬ及びVB．ＮETを習得することにより、マイグレーション後のシステムにおいても一貫した保守サービスを提供– 画面のメンテナンスが必要となる保守案件についてもスピーディに対応可能
14

14

DSR Confidential

8５．マイグレーション後の評価
5.1 評価できる点– 処理性能の維持¾ 処理性能が悪化した部分（月次処理・夜間処理）は、運用テスト時にチューニングすることにより、メインフレーム使用時と同等の処理性能を確保¾ チェック処理などについては、若干の処理性能の向上を実現¾ 画面系については、ＶＢ．ＮETによるＧＵＩ画面とすることにより、操作性が向上

15
DSR Confidential

５．マイグレーション後の評価
5.2 今後の課題
今後、マイグレーション後システムを維持向上させるための課題としては・・・– 保守サービスレベルの向上¾ 日々運用していく上で、ＤＢＡ的なスキルの必要性が高まりつつある– ＤＢ領域管理やパフォーマンス維持のためのＤＢＡスキルの習得が必要¾ 新システム基盤の完全な把握を目指す– メインフレーム時代と比較すると、保守管理対象がＯＳやＤＢＭＳまで及び、範囲が大幅に拡大– システム基盤ライフサイクルの短期化¾ 「ＷｉｎｄｏｗｓＳｅｒｖｅｒ２００３ ＋ Ｏｒａｃｌｅ９ｉ」の組み合わせ– 予算の都合上、既存システム基盤の流用となり、止む無く稼動時点で最新バージョンの導入ができなかったため、サポート切れまでの期間が短い– 最新バージョンで基盤を構築していたとしても、メインフレームと比較して基盤ライフサイクルの短期化が顕著– 運用サービスレベルの向上¾ メインフレームでの運用時代と比較して、サービスレベルが低下している部分が残存する– スケジュール優先でマイグレーションを実施したため、業務調整による運用制限を16掛けることで回避している部分が残る
DSR Confidential

9６．まとめ当マイグレーションの成功により、以下の点を今後の可能性として見出すことができました。
①ＣＯＢＯＬメインの業務ＳＥの活躍の場をオープン系環境にも拡大★メインフレームＣＯＢＯＬ系のＳＥがオープン系言語を習得するにはハードルが高い●オープン系ＣＯＢＯＬ＋ＲＤＢ（Ｏｒａｃｌｅ、ＳＱＬＳｅｒｖｅｒ）の組み合わせであれば比較的取組み易い
・メインフレームＳＥであっても、ＳＱＬのスキルを持つ技術者は比較的多い
・言語やフレームワーク等、全てが新しい環境に飛び込むより、ＣＯＢＯＬという慣れ親しんだ技術的なコアがある方が、技術習得の手がかりをつかみやすい●東京システムハウス㈱殿提供のＡＪＴＯＯＬ ｆｏｒ ＭｉｃｒｏＦｏｃｕｓ製品群 の使い易さ
・ＡＪＴＯＯＬ製品群のＡＪ＿ＪＣＬを採用することにより、メインフレームＪＣＬライクな記述方法にてＪＯＢ制御が可能
・一般的なＳｈｅｌｌやＢａｔファイルでのＪＯＢ制御より習得が容易②オープン系ＣＯＢＯＬ（今回はＭｉｃｒｏ Ｆｏｃｕｓ ＣＯＢＯＬ＆Ｐｒｏ＊ＣＯＢＯＬ）のパフォーマンスの高さ★ＤＢへのアクセス部品（今回はＲＤＢＭＳとの親和性を考慮して、Ｐｒｏ＊ＣＯＢＯＬにて作成）のチューニングを実施することで、汎用機での大量データ処理性能と遜色ないレベルのパフォーマンスが得られた。Ｍｉｃｒｏ Ｆｏｃｕｓ ＣＯＢＯＬがネックとなるパフォーマンス問題は皆無★ＶｉｓｕａｌＳｔｕｄｉｏ等の開発統合環境と組み合わせる事にて、ホストマシンでの開発と比較してデバッグ効率を大幅に向上させられる（今回の開発では導入せず）●ブレークポイント設定や代入値をウォッチできることにより、デバッグ効率が格段に向上
17・ＣＯＢＯＬのプログラミング教育にも有用
DSR Confidential

６．まとめ③オープン系システム基盤とＣＯＢＯＬの組み合わせによる高コストパフォーマンスの開発★メインフレームと比較すると格段に安価なオープン系システム基盤★他オープン系言語プログラマーに比べて、安価で良質なＣＯＢＯＬプログラマーの調達が可能

経営理念である「人を創り、人を育て、人で勝負する企業を目指す」の観点からも、ＤＳＲにとって貴重な財産である業務ＳＥを継続して活用できる分野を開拓できたことは大きな意義があることと考えます。

18
DSR Confidential10おわりに最後までご清聴いただき心より感謝申し上げます。

DSR Confidential

11