1

メインフレームのオープン化に

つきまして

ＩＴライブラリーより （pdf １００冊）http://itlib1.sakura.ne.jp/

一般社団法人

情報処理学会 正会員

腰山 信一

ftks7856@ybb.ne.jp

2

本資料の関連資料は下記をクリックして

ＰＤＦ一覧からお入り下さい。

ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/

目次番号 １６０番 他

レガシー・マイグレーションが求められている理由

レガシー・マイグレーションが脚光を浴びている背景には,メインフレームユーザーにおける「コストの限界」,「メンテナンスの限界」,「人と技術の限界」といった問題があります。

オープン系サーバーの性能や信頼性が向上すると同時に,マイグレーションのツールや方法が出そろってきたことで、レガシー・マイグレーションが現実的な解決策となってきた事が大きな理由です。

3

コストの限界

・ハードウエアのリース料やソフトウエアのレンタル料などが高額

・削減傾向のシステムコストをメインフレームの維持運用費が圧迫

メンテナンスの限界

・アプリケーションの構造が複雑化し,体制や機能追加時の影響を把握できない

・変化の激しいビジネスニーズヘの追随が 困難

4

メインフレームの処理能力向上の限界

５年で１．４倍がメインフレームの平均値

5

オープン化方針決定までの検討項目と手順につきまして

6

経営中期計画 中期事業計画 システム中期計画

システム化計画システム設計構想システム基本方針全社システム計画

システム移行方針

企画・検討現行システムの調査 システム化要件 実現可能性検討

投資対効果

移行計画の策定・基本方針決定移行大方針決定

現行システム化業務と計画

システム化稼動状況

システム課題と対応策

現行システムインフラ

移行対象システム検討

新規業務要件の実現計画

現行の課題と拡張計画

システム移行のリスク評価

移行ツール

移行検証

移行計画

投資検討

7

マイグレーション基本方針の決定

現行システムの把握

移行検証の方法とデータの明確化：テストシナリオ

移行目標と対象システム：

移行方法の選択：

移行日程計画の策定

ポリシー：可用性、データ保全、運用、セキュリティ

リホスティング、 リラティング、 リビルディング

資産の棚卸

データの棚卸

解析不可能資産の洗い出し

プログラム資産

ＤＢ・ファイル・データ

ＥＣＵ・個別データ

テストの基本方針

テスト方法

検証データ

全体・部分、業務処理別、バッチ/オンライン

単体・結合・システムテスト、併行ラン

各フェーズでのテストデータ準備8

移行目的の明確化・方針

移行プロジェクト体制の編成・確立

移行対象業務の影響度の調査

移行方法論の検討

システム規模と処理量

キャパシティ計画

移行先システムインフラの検討と選定

移行後の運用ルール

全社最適に沿った意向目的

移行専従チーム

役割の明確化

移行目的の検証

リスクの評価と指針

移行方式の検討・選択

システムの把握

ＳＬＡの基準定義

業務量の予測

現行システムの能力の評価

データ量予測と所要量計画

ターゲット基盤の検討

最適なインフラ評価・選定

最適運用管理ルール検討

ＳＬＡの充足検討9

システムの現状

現行システムの把握

オープン・システムへの移行

全社最適

新システム構築

ＩＴコスト

増大するＩＴ投資

困難なシステム把握

システム基盤の混在

ＩＴ要員の不足と世代交代

プログラム資産棚卸

現行システムの可視化

非稼動資産の整理

移行計画立案

オープン・システム基盤の構築

ＲＤＢ導入

システム機能の継承

ＤＢ正規化/再編

不要資産の整理

全社最適システムの設計（ＥＡ）

全体最適システムの構築

ＩＴコスト

10

オープン化（レガシーマイグレーション）における

３つの手法と各手法のメリット・デメリット

11

レガシーマイグレーションの種類

リホスティング

リラティング

リビルディング

再構築

ＥＲＰ

既存のアプリケーションを単純に移植する（主にツール利用）

旧プログラムと同じ機能のプログラムをオープン・システム化で書き直す

アプリケーションを新たに作り直す（ＢＰＲをともなう）

ＢＰＲを絡めたシステム更改

ＢＰＲを絡めたＥＲＰ導入

12

ビジネスロジック

プログラムコード

リホスティング リラティング リビルディング

リホスティングのと特長 リラティングの特長 リビルディングの特長

ビジネスロジックの維持社内体制を維持し、ユーザーへの再教育も不要

プログラムをそのまま移行コスト、リスクを削減し、メインフレーム資産の有効活用

プログラムを書き換えてアプリケーションを継続的に利用可能

新しいビジネスロジックの採用業務プロセスを変更

新たな投資新しいテクノロジーへの投資

ビジネスロジックの維持社内体制を維持し、ユーザーへの再教育も不要

維持

変更

維持 変更

13

マイグレーションに投入できる「費用」と得たい「効果」のバランスを考えた選択が必要です。

14

マイグレーション開始

マイグレーション開始

リホスティング 全面再構築 メインフレーム継続利用

1年目 2年目 3年目 4年目 5年目 1年目 2年目 3年目 4年目 5年目 1年目 2年目 3年目 4年目 5年目

年間費用

リホスティング費用

マイグレーション完了、メインフレーム撤去

年間経費の削減分で、リホスティング費用を何年以内に回収できるか？

再構築費用

再構築完了、メインフレーム撤去

年間費用

オープン化するよりも年間経費が低いことが実証できるか。今後、このＩＴで競合に勝ち抜けれるのか？

リホスティング開始

年間費用

再構築費用やコスト削減効果のメドが立つか。戦略的システムが構築できるか？

再構築開始

15

リホスティング

リラティング

リビルディング（再構築）

業務改革 リスク 期間コスト

無

リビルディング（ＢＰＲ導入）

無

有

有

低

中 中中

中

高

高 高

高

安 短

長

16

維持コスト削減効果

売上拡大効果

移行リスク

ＴＣＯ（総所有コスト）

マイグレーション 全面再構築メインフレーム継続利用

17

リホスティング

方法 ハード

ビジネス

言語

メリット

デミリット

COBOL等 移植

変更なし

移植（ｺﾝﾊﾞｰﾄ等）

■初期（移植）コストが安い

■ビジネス（業務・運用）が変わらず、スムーズな運用開始が可能

■開発期間が「短い」

既存のアプリケーションを単純に移植する（主にツール利用）

ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行

■ビジネスの改善が行えない（既存ビジネスの硬化状態が継続）

■悪い部分もそのまま継承

■コストに見合ったマイグレーション効果が出にくい

18

方法 ハード

ビジネス

言語

メリット

デミリット

COBOL等

ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行

リラティング 旧プログラムと同じ機能のプログラムをオープン・システム化で書き直す

別言語

若干の改善を実施

オープン系言語で書直し

■初期（移植）コストが「比較的安い」

■ビジネス（業務・運用）を「若干改善」 （基本的には同等）

■開発期間が「比較的短い」

■コストに見合ったビジネスの改善が伴わない場合もある

■ビジネスの抜本的な改善が行えない

（既存ビジネスの硬化状態が継続）

19

方法 ハード

ビジネス

言語

メリット

デミリット

COBOL等

ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行

リビルディング（再構築、ＥＲＰ導入）

別言語

ＢＰＲ実施

全面再構築

■ビジネス（業務・運用）の「抜本的な改善」が可能

■コスト見合いで改善の組み込みが可能

アプリケーションを新たに作り直す（ＢＰＲをともなう）

■開発期間が「長い」 → リスク大

■初期（再構築、ＥＲＰ導入）コストが「高い」

■ＥＲＰ導入の場合、理想型に会社のビジネスを合せる必要あり

20

リホスティングのメリット・デメリットにつきまして

21

現行機能の維持の保障

現行ＩＴスキルの維持・ 継承

短期間でのシステム移行

ＴＣＯ（総所有コスト）の大幅削減

移行テスト負荷の大幅軽減

プログラム変更の最小化

現行資産の継承

メインフレーム

COBOLソース

ＪＣＬ

ＤＣ

画面定義体

帳票定義体

ＳＯＲＴ

ＤＢ

オープン系サーバー

COBOLソース

ＪＣＬ

ＤＣ

ＳＯＲＴ

Oracle 、ＳＱＬ Ｓｅｒｖｅｒ

画面定義体

帳票定義体ビジネスロジックの維持・継承 ユーザーへの教育も最小化

プログラムをそのまま移行 メインフレーム資産の有効活用

移行作業の大幅軽減

移行費用の極小化

効果

22

リホスティング

【メリット】

ロジックはそのままなので、ファイルアクセスのタイミングは変わらず変換時のバグは少ない

【デメリット】

ＳＱＬ分の利点を使いこなしていない。（１件毎の処理はそのまま！）パフォーマンス頭打ち

ストレートコンバージョンの課題

23

リホスティングの問題点

リホストはツールを使うことで「早く安く」移行できるため、現在レガシー・マイグレーションの一手段となっています。しかし、アプリケーションの保守性や拡張性が低いという従来の問題がそのまま残ります。

レガシーシステム

ツールでかなりの部分を自動的に移行

複雑化したアプリケーション構成、バッチベースの古い処理、巨大化・複雑化したデータ構造

オープンシステム

アプリケーションに関する問題がそのまま残る

24

リホスティング成功のポイント

25

リホスティング成功のポイント

注意点

既存のアプリケーション資産を流用するマイグレーションは、ゼロから再構築したり、ERPを導入するのとは、違った難しさがあります。

ポイントを押さえて進めないと

「まったく予想していなかった問題がテストで見つかった」、

「変換でトラブルが起こり、作業工数が大幅に増えた」といった

危険性があります。

最悪の場合、ゼロからの再構築やパッケージ導入より安く早く完了するというリホスティングのメリットが失われてしまいます。

26

ポイント１

棚卸しで不良資産を整理します。

リホスティングを実施する際に欠かせないのが、アプリケーション資産の棚卸し、すなわちレガシー・システムで使っているアプリケーション資産の規模と内容を把握することです。

プログラムで言えば、全体の本数やステップ数、開発言語だけでなく、利用頻度や相互の依存関係まで調べる必要があります。

27

棚卸しの過程で変換が難しいプログラムを発見しておけば、その後の変換にかかる工数を

より正確に把握できます。

こうすることでレガシー・システムに埋もれていた不要なプログラムを新システムに移植する工数を省きます。 当然、テストにかかる工数が減らす事ができますし、新システムヘ切り替えてからの保守性も向上します。

28

ポイント２

自動変換ツールは１００％完全ではありません。

COBOLからJavaといった具合に開発言語を変える場合はもちろん、メインフレームのCOBOLプログラムをオープン系COBOLに変換する場合も、100%自動変換は難しいのが実態です。

同じCOBOL同士でも完全に自動変換できないのは、

メインフレームとオープン系でシステムの開発・実行環境が大きく異なるからです。

特に①データベース・アクセスの記述、

②文字コードの違い、

③演算精度や文法の相違

この３つが、１００％自動変換の妨げになりやすいケースが多いです。

29

ポイント３

帳票の移行を早めに確定させる事も重要です。

プログラムの変換ばかりに目を奪われて、それ以外のアプリケーション資産の変換をおろそかになる危険性がよくあります。

データベースのスキーマ/ファイル定義や、端末の画面定義ファイル、帳票のレイアウト定義ファイルも、大事なアプリケーション資産です。 また、アプリケーション資産に加えて、データベースに格納されたデータの変換・移行も必要になります。

一例を挙げると帳票のレイアウト定義の移行は、メインフレームで使っていた連続紙プリンタを継続利用するかオープン系で一般的なページ・プリンタに移行するかで対処方法が変わります。

30

継続利用するのであれば、新システムのサーバーに連続紙プリンタを接続した状態で、すべての帳票を正しく予定時間内に印刷できるかどうか事前にテストする必要があります。

プリンタ制御コードの違いから印字がずれたり、印字は正常だが入出カチャネルがボトルネックとなり予定時間内に印刷が終わらない危険性があります。

最悪、メインフレームを「帳票用のプリント・サーバー」として残さざる得ない状況になった場合、オープン化の目的が根底から崩れます。

31

ポイント４

画面や操作性が変わる事をエンドユーザーに納得してもらう必要があります。

画面の設計思想が、メインフレームとオープン系で根本的に違います。

メインフレームの端末は画面表示が変わる際、前の画面データとの差分データだけを端末に送る仕様になっていることが多いです。

2400ビット/秒といった低速回線でも使えるという貴重なテクノロジーだと思います。

オープン化ではすぐにエンドユーザーに慣れてもらう為に、ＷＥＢブラウザ形式の採用が多いです。

32

オープン化手法

プロジェクト開始

現行システム調査

システム移行設計

言語変換

移行の検証

インフラ設計・構築

運用設計

データ移行

現行資産の棚卸し

プログラム・ＤＢの調査

移行方針策定

移行方針決定

ソースプログラムの変換

ＪＣＬ、運用ツール変換

システムテストでの移行結果の検証

ハードウェア・ソフトウエア・ＤＢの選定

導入・据付・調整

システム運用の設計

ＪＣＬの移行・検証

本番データの移行ツール

本番データの移行

本番

34

調査

パターン分析

機能設計

変換機能確認テスト①

量産設計

変換・修正実施

統合テスト

システムテスト

比較検証テスト

本番移行

変換機能確認テスト②

量産計画

調査報告書・プロジェクト計画書

パターン分析一覧表

移行設計書・機械変換仕様書

変換機能確認テスト①報告書

変換/テスト手順書

変換後資産

統合テスト報告書

システムテスト報告書

テスト後資産、テスト報告書

本番移行

変換機能確認テスト②報告書

変換/テストスケジュール

主要成果物

35

36

本資料の関連資料は下記をクリックして

ＰＤＦ一覧からお入り下さい。

ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/

目次番号 １６０番 他