メインフレームのオープン化に
つきまして
ＩＴライブラリーより （pdf １００冊）
http://www.geocities.jp/ittaizen/itlib1/
一般社団法人
情報処理学会 正会員
腰山 信一
[email protected]
本資料の関連資料は下記をクリックして
ＰＤＦ一覧からお入り下さい。
ＩＴライブラリー （pdf １００冊）
http://www.geocities.jp/ittaizen/itlib1/
レガシー・マイグレーションが求められている理由
レガシー・マイグレーションが脚光を浴びている背景には,メインフレーム
ユーザーにおける「コストの限界」,「メンテナンスの限界」,「人と技術の限
界」といった問題があります。
オープン系サーバーの性能や信頼性が向上すると同時に,マイグレーション
のツールや方法が出そろってきたことで、レガシー・マイグレーションが現実
的な解決策となってきた事が大きな理由です。
コストの限界
・ハードウエアのリース料やソフトウエアのレンタル料
などが高額
・削減傾向のシステムコストをメインフレームの維持
運用費が圧迫
メンテナンスの限界
・アプリケーションの構造が複雑化し,体制や機能追加
時の影響を把握できない
・変化の激しいビジネスニーズヘの追随が 困難
メインフレームの処理能力向上の限界
経営中期計画 中期事業計画 システム中期計画 システム化計画 システム設計構想 システム基本方針 全社システム計画 システム移行方針 企画・検討 現行システムの調査 システム化要件 実現可能性検討 投資対効果
移行計画の策定・基本方針決定
移行大方針決定
現行システム化業務と計画 システム化稼動状況 システム課題と対応策 現行システムインフラ 移行対象システム検討 新規業務要件の実現計画 現行の課題と拡張計画 システム移行のリスク評価 移行ツール 移行検証 移行計画 投資検討マイグレーション基本方針の決定
現行システムの把握
移行検証の方法とデータの明確化：テストシナリオ
移行目標と対象システム： 移行方法の選択： 移行日程計画の策定 ポリシー：可用性、データ保全、運用、セキュリティ リホスティング、 リラティング、 リビルディング 資産の棚卸 データの棚卸 解析不可能資産の洗い出し プログラム資産 ＤＢ・ファイル・データ ＥＣＵ・個別データ テストの基本方針 テスト方法 全体・部分、業務処理別、バッチ/オンライン 単体・結合・システムテスト、併行ラン移行目的の明確化・方針
移行プロジェクト体制の
編成・確立
移行対象業務の影響
度の調査
移行方法論の検討
システム規模と処理量
キャパシティ計画
移行先システムインフ
ラの検討と選定
移行後の運用ルール
全社最適に沿った意向目的 移行専従チーム 役割の明確化 移行目的の検証 リスクの評価と指針 移行方式の検討・選択 システムの把握 ＳＬＡの基準定義 業務量の予測 現行システムの能力の評価 データ量予測と所要量計画 ターゲット基盤の検討 最適なインフラ評価・選定 最適運用管理ルール検討 ＳＬＡの充足検討システムの現状 現行システムの把握 オープン・システム への移行 全社最適 新システム構築
ＩＴコスト
増大するＩＴ投資 困難なシステム把握 システム基盤の混在 ＩＴ要員の不足と世代交代 プログラム資産棚卸 現行システムの可視化 非稼動資産の整理 移行計画立案 オープン・システム 基盤の構築 ＲＤＢ導入 システム機能の継承 ＤＢ正規化/再編 不要資産の整理 全社最適システムの設計（ＥＡ） 全体最適システムの構築ＩＴコスト
オープン化（レガシーマイグレーション）における
３つの手法と各手法のメリット・デメリット
レガシーマイグレーションの種類
リホスティング
リラティング
リビルディング
再構築
ＥＲＰ
既存のアプリケーションを単純に移植する（主にツール利用） 旧プログラムと同じ機能のプログラムをオープン・システム化で書き直す アプリケーションを新たに作り直す（ＢＰＲをともなう） ＢＰＲを絡めたシステム更改 ＢＰＲを絡めたＥＲＰ導入ビジネスロジック
プログラムコード
リホスティング
リラティング
リビルディング
リホスティングのと特長 リラティングの特長 リビルディングの特長 ビジネスロジックの維持 社内体制を維持し、ユーザー への再教育も不要 プログラムをそのまま移行 コスト、リスクを削減し、メイン フレーム資産の有効活用 プログラムを書き換えてアプ リケーションを継続的に利用 可能 新しいビジネスロジックの採用 業務プロセスを変更 新たな投資 新しいテクノロジーへの投資 ビジネスロジックの維持 社内体制を維持し、ユーザー への再教育も不要維持
変更
維持
変更
マイグレーションに投入できる「費用」と
得たい「効果」のバランスを考えた
マイグレーション開始 マイグレーション開始 リホスティング 全面再構築 メインフレーム継続利用 1年目 2年目 3年目 4年目 5年目 1年目 2年目 3年目 4年目 5年目 1年目 2年目 3年目 4年目 5年目 年間費用 リホスティング費用 マイグレーション完了、 メインフレーム撤去 年間経費の削減分で、リホス ティング費用を何年以内に回 収できるか？ 再構築費用 再構築完了、メイ ンフレーム撤去 年間費用 オープン化するより も年間経費が低いこ とが実証できるか。 今後、このＩＴで競合 に勝ち抜けれるの か？ リホスティング開始 年間費用 再構築費用やコスト 削減効果のメドが立 つか。戦略的システ ムが構築できるか？ 再構築開始
リホスティング
リラティング
リビルディング
（再構築）
業務改革
リスク
コスト
期間
無
リビルディング
（ＢＰＲ導入）
無
有
有
低
中
中
中
中
高
高
高
高
安
短
長
維持コスト削減
効果
売上拡大効果
移行リスク
ＴＣＯ（総所有コス
ト）
マイグレーション
全面再構築
継続利用
メインフレーム
リホスティング
方法
ハード
ビジネス
言語
メリット
デミリット
COBOL等
移植
変更なし
移植（ｺﾝﾊﾞｰﾄ等）
■初期（移植）コストが安い ■ビジネス（業務・運用）が変わらず、スムーズな運用開始が可能 ■開発期間が「短い」 既存のアプリケーションを単純に移植する（主にツール利用）ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行
■ビジネスの改善が行えない（既存ビジネスの硬化状態が継続） ■悪い部分もそのまま継承 ■コストに見合ったマイグレーション効果が出にくい方法
ハード
ビジネス
言語
メリット
デミリット
COBOL等
ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行
リラティング
旧プログラムと同じ機能のプログラムをオープン・システム化で書き直す 別言語 若干の改善を実施 オープン系 言語で書直し ■初期（移植）コストが「比較的安い」 ■ビジネス（業務・運用）を「若干改善」 （基本的には同等） ■開発期間が「比較的短い」 ■コストに見合ったビジネスの改善が伴わない場合もある ■ビジネスの抜本的な改善が行えない （既存ビジネスの硬化状態が継続）方法
ハード
ビジネス
言語
メリット
デミリット
COBOL等
ｵｰﾌﾟﾝ系ｻｰﾊﾞへ移行
リビルディング
（再 構築、ＥＲＰ導入） 別言語 ＢＰＲ実施全面再構築
■ビジネス（業務・運用）の「抜本的な改善」が可能 ■コスト見合いで改善の組み込みが可能 アプリケーションを新たに作り直す（ＢＰＲをともなう） ■開発期間が「長い」 → リスク大 ■初期（再構築、ＥＲＰ導入）コストが「高い」 ■ＥＲＰ導入の場合、理想型に会社のビジネスを合せる必要あり現行機能の維持の
保障
現行ＩＴスキルの
維持・ 継承
短期間でのシス
テム移行
ＴＣＯ（総所有コスト）
の大幅削減
移行テスト負荷の
大幅軽減
プログラム変更 の最小化現行資産の継承
メインフレーム COBOLソース ＪＣＬ ＤＣ 画面定義体 帳票定義体 ＳＯＲＴ ＤＢ オープン系サーバー COBOLソース ＪＣＬ ＤＣ ＳＯＲＴ Oracle 、 ＳＱＬ Ｓｅｒｖｅｒ 画面定義体 帳票定義体 ビジネスロジックの 維持・継承 ユー ザーへの教育も最小 化 プログラムをそのま ま移行 メインフレー ム資産の有効活用 移行作業の大幅軽減移行費用の極小化
効
果
リホスティング【メリット】
ロジックはそのままなので、ファイルアクセスのタイミングは変わら
ず変換時のバグは少ない
【デメリット】
ＳＱＬ分の利点を使いこなしていない。（１件毎の処理はそのまま！）
パフォーマンス頭打ち
ストレートコンバージョンの課題
リホスティングの問題点
リホストはツールを使うことで「早く安く」移行できるため、現在レガシー・マイグ
レーションの一手段となっています。しかし、アプリケーションの保守性や拡張
性が低いという従来の問題がそのまま残ります。
レガシーシステム
ツールでかなりの部 分を自動的に移行複雑化したアプリケーショ
ン構成、バッチベースの
古い処理、巨大化・複雑
化したデータ構造
オープンシステム
アプリケーションに
関する問題がその
まま残る
リホスティング成功のポイント
注意点
既存のアプリケーション資産を流用するマイグレーションは、ゼロから再構 築したり、ERPを導入するのとは、違った難しさがあります。 ポイントを押さえて進めないと 「まったく予想していなかった問題がテストで見つかった」、 「変換でトラブルが起こり、作業工数が大幅に増えた」といった 危険性があります。最悪の場合、ゼロからの再構築やパッケージ導入より安く早く完了す
るというリホスティングのメリットが失われてしまいます。
ポイント１
棚卸しで不良資産を整理します。
リホスティングを実施する際に欠かせないのが、アプリケーション資産の棚卸し、すなわち
レガシー・システムで使っているアプリケーション資産の規模と内容を把握することです。
プログラムで言えば、全体の本数やステップ数、開発言語だけでなく、利用頻度や相互
の依存関係まで調べる必要があります。
棚卸しの過程で変換が難しいプログラムを発見しておけば、その後の変換にかかる工数を
より正確に把握できます。
こうすることでレガシー・システムに埋もれていた不要なプログラムを新システムに移植
する工数を省きます。
当然、テストにかかる工数が減らす事ができますし、新システ
ムヘ切り替えてからの保守性も向上します。
ポイント２
自動変換ツールは１００％完全ではありません。
COBOLからJavaといった具合に開発言語を変える場合はもちろん、メインフレームのCOBOL
プログラムをオープン系COBOLに変換する場合も、100%自動変換は難しいのが実態です。
同じCOBOL同士でも完全に自動変換できないのは、
メインフレームとオープン系でシステムの開発・実行環境が大きく異なるからです。
特に①データベース・アクセスの記述、
②文字コードの違い、
③演算精度や文法の相違
この３つが、１００％自動変換の妨げになりやすいケースが多いです。
ポイント３
帳票の移行を早めに確定させる事も重要です。
プログラムの変換ばかりに目を奪われて、それ以外のアプリケーション
資産の変換をおろそかになる危険性がよくあります。
データベースのスキーマ/ファイル定義や、端末の画面定義ファ
イル、帳票のレイアウト定義ファイルも、大事なアプリケーション
資産です。 また、アプリケーション資産に加えて、データベース
に格納されたデータの変換・移行も必要になります。
一例を挙げると帳票のレイアウト定義の移行は、メイ
ンフレームで使っていた連続紙プリンタを継続利用す
るかオープン系で一般的なページ・プリンタに移行す
るかで対処方法が変わります。
継続利用するのであれば、新システムのサーバーに連続紙
プリンタを接続した状態で、すべての帳票を正しく予定時間
内に印刷できるかどうか事前にテストする必要があります。
プリンタ制御コードの違いから印字がずれたり、印字は正常だが
入出カチャネルがボトルネックとなり予定時間内に印刷が終わら
ない危険性があります。
最悪、メインフレームを「帳票用のプリント・サーバー」として
残さざる得ない状況になった場合、オープン化の目的が根底
から崩れます。
ポイント４
画面や操作性が変わる事をエンドユーザーに納得してもらう必要があります。
画面の設計思想が、メインフレームとオープン系で根
本的に違います。
メインフレームの端末は画面表示が変わる際、前の画
面データとの差分データだけを端末に送る仕様になっ
ていることが多いです。
2400ビット/秒といった低速回線でも使えるという貴重
なテクノロジーだと思います。
オープン化ではすぐにエンドユーザーに慣れてもら
う為に、ＷＥＢブラウザ形式の採用が多いです。
プロジェクト開始
現行システム調査
システム移行設計
言語変換
移行の検証
インフラ設計・構築
運用設計
データ移行
現行資産の棚卸し プログラム・ＤＢの調査 移行方針策定 移行方針決定 ソースプログラムの変換 ＪＣＬ、運用ツール変換 システムテストでの移行結果の検証 ハードウェア・ソフトウエア・ＤＢの選定 導入・据付・調整 システム運用の設計 ＪＣＬの移行・検証 本番データの移行ツール 本番データの移行本番
調査 パターン分析 機能設計 変換機能確認テスト① 量産設計 変換・修正実施 統合テスト システムテスト 比較検証テスト 本番移行 変換機能確認テスト② 量産計画 調査報告書・プロジェクト計画書 パターン分析一覧表 移行設計書・機械変換仕様書 変換機能確認テスト①報告書 変換/テスト手順書 変換後資産 統合テスト報告書 システムテスト報告書 テスト後資産、テスト報告書 本番移行 変換機能確認テスト②報告書 変換/テストスケジュール
