きょう、ITモダナイゼーションSummitを聞いてきた。
その内容をメモメモ(まずは、第一弾。午後から行った)
■ご挨拶
COBOLコンソーシアム
1960年 COBOL
2000年 COBOLコンソーシアム
COBOLが古いのではなく、古いシステムがCOBOLで書かれている
■りそなグループ様マイグレーション事例のご紹介
CIJの人
話すこと
言語変換
データ変換
照合試験
環境
OS IBM Z/OS
PL/I、アセンブラ→COBOL
JCL→Bash
DB2→SQLServer
マイグレーションのアプローチ
手変換
変換ツール型
変換ツールを作る
照合試験
運用試験
言語変換
構文解析
↓
構文ツリー
↓
言語生成←生成ルール/手修正情報
↓
整形前プログラム
↓
プログラム整形
PL/I言語変換 留意点は印刷物見てね
JCL変換も同様
ファイル処理、ログ出力機能などを作るのが重要
成功要因
・PL/I生成ツール
・実行基盤
運用変更に伴う追加機能
外部インターフェース
・ジョブネットの変更
・ジョブの変更
データ変換
移行データ
マルチレイアウト→レコードレイアウト→実データで検証
照合試験
変換ツールによる変換
運用の変更
データ変換
追加作成(ユーティリティ)
→照合試験→総合試験→並行稼動
照合試験
・変換ルール網羅試験
・プログラム網羅試験
■プロジェクト事例に学ぶ陥りやすいレガシーオープン化の
落とし穴と対策
会社案内
1.レガシーモダナイズの全体像
レイヤ
ユーザー層 プログラム/入出力/データ→等価性
メカニズム層 API/処理方式/外部連携/ユーティリティ
コンテキスト層 非機能/固有要件
2.レガシーモダナイズの課題事例
COBOL→COBOLの案件
企画:移行資産の確定
設計・変換:
ユーザー層:オープン化方針に依存して、難易度が変化
データ移行
メカニズム層:システムごとに発生傾向が異なる
コンテキスト層:現行実現手段にこだわると深刻化
試験:照合試験:どこまでカバレージするか
業務知識必要
ソリューション
変換サービス
リホスト製品
マイグレーションサービス
システム再構築
3.当社の提言
・データ重要:経験、実績が有効
・レガシーナレッジが必須
・トップダウンの大胆な割り切り
■マイグレーション時に考えなければならないこと・進め方
自己紹介
本説明の前提と内容
・リホスト手法
・はじめてマイグレーション
COBOLさえあれば、オープン化できる
リホスト設計不要?
リスクは?
・Q&A形式で
Q1.マイグレーションを検討したいが、何からすべきか?
A.現行COBOL資産の棚卸から始めてください
資産棚卸の位置づけ
Q2.効率のよいリホスト・プロジェクトの進め方は?
A.資産の一部をパイロット変換し、課題を把握・確認してから
本格変換作業に入ります
基本変換ツール→固有機能変換ツール
パイロット移行を実施しない場合のリスク
Q3.効率のよい評価方法は
A.現システムとの並行評価をするのが効率的です
テスト仕様、テストデータの準備→業務が分かっている人
NGが出た場合→業務に影響するか判断
移行時に機能追加・変更はしない
Q4.その他の懸案事項は
A.十分な事前設計必要
お客様限定
ソース消失
大量印刷・オンライン印刷
外字
文字コード
■実績に基づくCOBOLモダナイゼーションのススメ
富士通
システム移行を考える
・きっかけ
ハード保守が近づいた
見識者がいなくなった
メンテナンスに想定以上のコスト
・希望
手間はかけたくない
コストは抑えたい
仕様が不明確:現行は踏襲したい
・傾向
資産:どこから手をつけたら
知らない複雑な仕組み
理解できない業務ロジック→テストできない
COBOLの特徴
・いつまでも変わらない文法(85)
・生産性・品質が読みやすい
→継続しやすい
・将来性の不安
・COBOLからオープン技術を使いにくい
・ベテラン中心→引継ぎ
見える化のススメ
・まずは、業務を把握して整理しましょう
・つぎに、資産を把握して整理しましょう
・そして、資産を整頓して管理しましょう
→ドキュメント、版数管理
業務見える化の期待
アプリケーション構造の見える化
ソフトウェア地図
アプリケーション資産の見える化
稼動資産分析
類似分析
資産特性分析→インパクトスケール(登録商標)
システム相関分析
【事例】見える化(金融B社、製造業C社)
・類似資産を把握し、次期システムの開発規模を明確化
構成管理のススメ
よくある話
・ソースがない
・実行モジュールと合っていないソース
・多数の管理外資産
どうにもならない資産
諦めて 使い続けてください/作り直してください
なぜ、構成管理が必要なのか
ソフトウェア構成管理の構成
構成管理
プロセス管理
案件管理
インシデント管理
障害管理
ドキュメント整備のススメ
・ドキュメントの鮮度はすぐ落ちる
ソースからのリバースは夢のまた夢
ドキュメントが現行ソースと乖離
引継ぎできない資産
ついていけない人材
事前に資産やドキュメント
生成可能なドキュメント
モダナイゼーションのススメ
・レガシー機能を今風に
オンライン→Web化
バッチ→Shell
データベース→オープン系RDB
帳票→電子帳票、PDF
→COBOL資産
NDB
→DBアクセス部分で部品化
性能問題はある。チューニングは必要
品質保証のススメ
25%のテストで80%カバー
【事例】22%で71%
業務の見える化→シナリオ試験
モダナイ後/最新技術のススメ
オープンスタンダードな開発環境
NetCOBOL Studio
Hadoopと連携
最後に
・COBOLのロジックは継続性に優れている
・長年使っているだけに、とにかく資産の管理は徹底的に
・新しい技術もしっかり対応
→ALL富士通でお客様のCOBOL資産を全力でサポート
フォローアップセミナー参加のススメ
その内容をメモメモ(まずは、第一弾。午後から行った)
■ご挨拶
COBOLコンソーシアム
1960年 COBOL
2000年 COBOLコンソーシアム
COBOLが古いのではなく、古いシステムがCOBOLで書かれている
■りそなグループ様マイグレーション事例のご紹介
CIJの人
話すこと
言語変換
データ変換
照合試験
環境
OS IBM Z/OS
PL/I、アセンブラ→COBOL
JCL→Bash
DB2→SQLServer
マイグレーションのアプローチ
手変換
変換ツール型
変換ツールを作る
照合試験
運用試験
言語変換
構文解析
↓
構文ツリー
↓
言語生成←生成ルール/手修正情報
↓
整形前プログラム
↓
プログラム整形
PL/I言語変換 留意点は印刷物見てね
JCL変換も同様
ファイル処理、ログ出力機能などを作るのが重要
成功要因
・PL/I生成ツール
・実行基盤
運用変更に伴う追加機能
外部インターフェース
・ジョブネットの変更
・ジョブの変更
データ変換
移行データ
マルチレイアウト→レコードレイアウト→実データで検証
照合試験
変換ツールによる変換
運用の変更
データ変換
追加作成(ユーティリティ)
→照合試験→総合試験→並行稼動
照合試験
・変換ルール網羅試験
・プログラム網羅試験
■プロジェクト事例に学ぶ陥りやすいレガシーオープン化の
落とし穴と対策
会社案内
1.レガシーモダナイズの全体像
レイヤ
ユーザー層 プログラム/入出力/データ→等価性
メカニズム層 API/処理方式/外部連携/ユーティリティ
コンテキスト層 非機能/固有要件
2.レガシーモダナイズの課題事例
COBOL→COBOLの案件
企画:移行資産の確定
設計・変換:
ユーザー層:オープン化方針に依存して、難易度が変化
データ移行
メカニズム層:システムごとに発生傾向が異なる
コンテキスト層:現行実現手段にこだわると深刻化
試験:照合試験:どこまでカバレージするか
業務知識必要
ソリューション
変換サービス
リホスト製品
マイグレーションサービス
システム再構築
3.当社の提言
・データ重要:経験、実績が有効
・レガシーナレッジが必須
・トップダウンの大胆な割り切り
■マイグレーション時に考えなければならないこと・進め方
自己紹介
本説明の前提と内容
・リホスト手法
・はじめてマイグレーション
COBOLさえあれば、オープン化できる
リホスト設計不要?
リスクは?
・Q&A形式で
Q1.マイグレーションを検討したいが、何からすべきか?
A.現行COBOL資産の棚卸から始めてください
資産棚卸の位置づけ
Q2.効率のよいリホスト・プロジェクトの進め方は?
A.資産の一部をパイロット変換し、課題を把握・確認してから
本格変換作業に入ります
基本変換ツール→固有機能変換ツール
パイロット移行を実施しない場合のリスク
Q3.効率のよい評価方法は
A.現システムとの並行評価をするのが効率的です
テスト仕様、テストデータの準備→業務が分かっている人
NGが出た場合→業務に影響するか判断
移行時に機能追加・変更はしない
Q4.その他の懸案事項は
A.十分な事前設計必要
お客様限定
ソース消失
大量印刷・オンライン印刷
外字
文字コード
■実績に基づくCOBOLモダナイゼーションのススメ
富士通
システム移行を考える
・きっかけ
ハード保守が近づいた
見識者がいなくなった
メンテナンスに想定以上のコスト
・希望
手間はかけたくない
コストは抑えたい
仕様が不明確:現行は踏襲したい
・傾向
資産:どこから手をつけたら
知らない複雑な仕組み
理解できない業務ロジック→テストできない
COBOLの特徴
・いつまでも変わらない文法(85)
・生産性・品質が読みやすい
→継続しやすい
・将来性の不安
・COBOLからオープン技術を使いにくい
・ベテラン中心→引継ぎ
見える化のススメ
・まずは、業務を把握して整理しましょう
・つぎに、資産を把握して整理しましょう
・そして、資産を整頓して管理しましょう
→ドキュメント、版数管理
業務見える化の期待
アプリケーション構造の見える化
ソフトウェア地図
アプリケーション資産の見える化
稼動資産分析
類似分析
資産特性分析→インパクトスケール(登録商標)
システム相関分析
【事例】見える化(金融B社、製造業C社)
・類似資産を把握し、次期システムの開発規模を明確化
構成管理のススメ
よくある話
・ソースがない
・実行モジュールと合っていないソース
・多数の管理外資産
どうにもならない資産
諦めて 使い続けてください/作り直してください
なぜ、構成管理が必要なのか
ソフトウェア構成管理の構成
構成管理
プロセス管理
案件管理
インシデント管理
障害管理
ドキュメント整備のススメ
・ドキュメントの鮮度はすぐ落ちる
ソースからのリバースは夢のまた夢
ドキュメントが現行ソースと乖離
引継ぎできない資産
ついていけない人材
事前に資産やドキュメント
生成可能なドキュメント
モダナイゼーションのススメ
・レガシー機能を今風に
オンライン→Web化
バッチ→Shell
データベース→オープン系RDB
帳票→電子帳票、PDF
→COBOL資産
NDB
→DBアクセス部分で部品化
性能問題はある。チューニングは必要
品質保証のススメ
25%のテストで80%カバー
【事例】22%で71%
業務の見える化→シナリオ試験
モダナイ後/最新技術のススメ
オープンスタンダードな開発環境
NetCOBOL Studio
Hadoopと連携
最後に
・COBOLのロジックは継続性に優れている
・長年使っているだけに、とにかく資産の管理は徹底的に
・新しい技術もしっかり対応
→ALL富士通でお客様のCOBOL資産を全力でサポート
フォローアップセミナー参加のススメ