第20回COBOLコンソーシアム セミナー

「COBOLと共にフロンティアを目指して」～COBOLクラウドサービスによるIT資産の有効活用のご提案～

ＮＴＴデータの総合クラウドサービス

２０１１年４月１５日
株式会社ＮＴＴデータ
星野 亨（エグゼクティブＩＴアーキテクト）

本日の内容１

レガシーシステムとは？

２

ユーザー部門の抱える問題

３

脱レガシーの課題

４

COBOLクラウドサービスとは？

Copyright © 2010 NTT DATA CORPORATION

2

最初にご質問です

本セッション参加の方で自社でレガシーシステムをお持ちの方挙手をお願いします。

Copyright © 2010 NTT DATA CORPORATION

3

自己紹介
現職：基盤システム事業本部 基盤サービスビジネスユニット
事業内容：
ＮＴＴデータの総合クラウドサービス①ミッションクリティカルソリューション
②レガシーマイグレーション「ＢｉｚＸａａＳマイグレーションサービス」
‘86

'87

‘88 ‘89 ‘90 ‘91 ‘92 ‘93 ‘94 ‘95 ‘96 ‘97 ‘98 ‘99 ‘00 ‘01 ‘02 ‘03 ‘04 ‘05

基幹システムBK-SMP DISK更改
ミドルソフト
設計・開発

移行設計

基幹システム 端末更改
設計

新システム
開発

基幹システム更改

電子政府

PORTOMICS
開発

ミドルソフト設計・開発

性能・設備設計

性能・設備設計

PMPM

メインフレーム（DIPS）
メインフレーム（民需機）
オープン系
富士通 GS8800
DIPS-11/５E
DIPS-11/５EX OS/2 日立MP5800
日立 MP5800 パラダイム
パラダイム
シフト
NEC PX7800
DIPS：電電公社開発メインフレーム シフト
Dendenkosha Information
Processing System

パラダイムの異なる３つのプラットホーム上での金融・官公庁を中心とした基幹システム開発
Copyright © 2010 NTT DATA CORPORATION

4

レガシーシステムとは？

Copyright © 2010 NTT DATA CORPORATION

5レガシーシステムの定義
・長年積み重ねてきた動作実績
・専用ハード・ソフトによるベンダプロプライエタリ（垂直統合）なアーキテクチャ
そのため統一感があり、運用がしやすい（使いやすい）・単一ベンダのため、故障時対応の迅速性、原因究明、責任範囲が明確であり、利用者にとっては楽

メインフレーム

オープン系アーキテクチャ

インテグラル（統合型）

モジュラー（部品型）

インタフェース

独自（call-return、非同期通知）

標準（call-return）

設計思想

単一ベンダ製品、すりあわせ

製品選択の自由、疎結合（BlackBox)

Copyright © 2010 NTT DATA CORPORATION

6

モジュラー型とインテグラル型アーキテクチャの違い「モジュラー型」
標準化により、製品相互の組み合わせ自由度がある反面、異常時等を想定したシステムインテグレーションが必要。
「インテグラル型」 製品組み合わせを限定し、製品間のすり合せによるきめ細かい連携が実現できる。

ＡＰＬ

ミドル

ＡＰＬ

単一製品として販売できるよう疎な関係

ＯＳ

割込処理

システム全体の動作を想定した
密な関係

デッドロック、アベンド
ミドル

割込処理
プログラム割込/リソース状態

ＯＳ

割込処理
ハード割込/CPUディスパッチャ

ハードハードモジュラー型アーキテクチャ
Copyright © 2010 NTT DATA CORPORATION

ハードハードインテグラル型アーキテクチャ

7

ITシステムのトレンドの変遷と誤解

ベンダ垂直統合型アーキテクチャ 大

オープンアーキテクチャ

パラダイム
パラダイム
ＵＮＩＸサーバー シフトシフト
汎用機（メインフレーム）
時間軸＝ＣＯＢＯＬ？

オフコン等
レガシーシステム領域

Copyright © 2010 NTT DATA CORPORATION

システム規模過去

小ク＝Ｊａｖａ？
ラ 現在
ウド
ＩＡサーバー

独自イメージ図8

レガシーシステムの現状

1,200,000

レガシーシステムはまだまだ現役！

Super Computer
Business Server
Mainframe
RISC Server
IA64 Server
x86 Server( 出荷金額（百万円）)

1,000,000
800,000
600,000
400,000
200,000
0
2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

出典元：IDC Japan(2010)
Copyright © 2010 NTT DATA CORPORATION

9レガシー＝「悪」か？
レガシーシステムにも二種類あるLegendary（伝説的）なシステム
重要度が極めて高く、サービス継続性・性能、処理の一貫性を求められるシステム（銀行勘定系や社会インフラ系システム） 【MissonCriticalシステム】

メインフレームの継続活用
Legacy（遺産・遺物）なシステム
メインフレームしか選択肢の無かった時代からのシステムでこれまで更改や再構築の機会がなかった処理 【ノンコアシステム】

モダナイゼーションによるTCO削減

Copyright © 2010 NTT DATA CORPORATION

10レガシーシステム特性とモダナイズ方針の考え方
高重要基幹システム

レガシー継続利用

大 システムの戦略性求められるＳＬＡ

ＢＰＲ・リビルドによるＲＯＩの追求

Java等へのリビルドによる生産性向上

リホストによるＴＣＯ削減
小リホストまたはパッケージの活用

一般システム低Copyright © 2010 NTT DATA CORPORATION

インフラシステム

ノンコアシステム
独自イメージ図11

COBOL言語はレガシーか？
Common Business Oriented Langage （汎商業目的言語）
１９６０年に最初の仕様書が発行され、現在まで業務処理言語として活用【ソース資産】
蓄積されたプログラム資産は稼働中だけで全世界で約2000億行とも…
世界の民間企業の8割（2000年時点）がCOBOLプログラム
日本国内の主要開発言語の割合でJavaの25.4%に次いで2位(16.8%)
将来も利用し続ける宿命にある

IPA「ソフトウェア開発データ白書2010-2011」より【開発リソース】 ワールドワイドでは十分【COBOL製品】 グローバルスタンダードなCOBOLコンパイラやOSSも存在
COBOLは現役のプログラム言語である！
Copyright © 2010 NTT DATA CORPORATION

12ユーザー部門の抱える問題

Copyright © 2010 NTT DATA CORPORATION

13

レガシーシステムユーザーの切実な現状

景気後退によるIT経費削減
レガシーシステムの高額な維持費

Copyright © 2010 NTT DATA CORPORATION

レガシー技術者の高齢化
レガシー製品のEOSL(End Of System Life)

14

レガシーシステムを止められない理由

投資対効果の低いシステム更改ベンダプロプライエタリ
アーキテクチャ

高額なシステム
更改コスト

Copyright © 2010 NTT DATA CORPORATION

高いシステム更改リスク

ベンダロックオン

15

レガシーユーザーのジレンマ

究極の個別最適(製品カスタマイズ)

設計書が無い・整合が取れない

ベンダーへの責任転嫁システムに深い
愛着がある

Copyright © 2010 NTT DATA CORPORATION

16

脱レガシーの課題

Copyright © 2010 NTT DATA CORPORATION

17投資対効果の壁

多額の投資はできない

コスト・リスクが増大

レガシーシステム
従来のモダナイゼーション

再構築
AsIsで再構築

Copyright © 2010 NTT DATA CORPORATION

付加価値の追加18

移植リスク

設計書とソースの整合が無い

ソースの複雑化

レガシーシステム

レガシー製品
提供機能の開発

再構築

Copyright © 2010 NTT DATA CORPORATION

階層型ＤＢ
ＪＣＬ
特殊ファイルアクセス
Etc…….

19

レガシーユーザーの心情

どうせ更改するなら.....

あれもやりたいこれもやりたい….

夢は広がる
コスト・リスクも広がる….

ＲＤＢ
ＯＳＳ
ＪＡＶＡ

web
ＳＯＡ

Copyright © 2010 NTT DATA CORPORATION

20

手続き型言語や４ＧＬの将来

レガシーシステム

オープン系システム

ＣＯＢＯＬ以外に変換するなら？
多種・多様な言語（手続き型言語）が存在
業務・サービス毎に一連の処理で記述する言語体系

Ｊａｖａをはじめとしたオブジェクト指向言語
親和性の高いＣＯＢＯＬが現実的レガシー言語を取り込んだＣＯＢＯＬユーザの拡大
Copyright © 2010 NTT DATA CORPORATION

21

弊社が提案するレガシーシステム最適化ストーリー

第一段階：AsIsのリホストによるITコスト削減
削減コストでリホスト投資回収
第二段階：システム再構築（ToBe)に向けたIT投資
ノンコアなシステムの場合、第一段階だけで継続利用も

Copyright © 2010 NTT DATA CORPORATION

22

COBOLクラウドサービスとは？

Copyright © 2010 NTT DATA CORPORATION

23

COBOLクラウドのポイント

従来のダウンサイジング

移行前システム（レガシーシステム）

お客様IT資産肥大化

変換

お客様IT資産
PORTOMICS

個別開発

オープン製品Copyright © 2010 NTT DATA CORPORATION

お客様IT資産

BizXaaS COBOLクラウドを用いたダウンサイジング

レガシー製品

BizXaaSCOBOLクラウド

24ソフトウエア機能構成イメージ

メインフレームシステム
業務AP

オープンシステム
PORTOMICS®

業務

業務系
ビジネスロジック

業務共通AP

システム共通個別ロジックPORTOMICS ®
PORTOMICS
補完ミドル(（業務共通機能） )共通ビジネスロジック
ソフトウェアアーキテクチャ

ＡＰ
個別ＡＰ
共通

IT基盤制御機能基盤

ミドルウェアミドルウェアミドルウェアOS

OS

OS

ハードウエアハードウエアハードウエアCopyright © 2010 NTT DATA CORPORATION

方式

25

レガシーユーザーにとってのクラウドの良さとは？

ITの所有から利用へ
オンデマンドエラスティック

Copyright © 2010 NTT DATA CORPORATION

26

「早い」「安い」の理由「早い」の理由
・システムのクラウド提供によりシステム構築に関する期間が短縮できます・グローバルなマイグレーションリソースの活用によりプログラム変換作業期間が短縮できます・幣社内外のレガシー専門技術者との連携により迅速なコンサルテーション対応が提案できます「安い」の理由・レガシー固有機能のPaaS提供により業務プログラム以外の個別機能開発コストが削減できます・システムのクラウド提供によりお客様IT資産（固定資産）の削減が可能です
・専門技術者による現行資産の徹底的な分析と見える化により適正な見積り根拠で提案します
Copyright © 2010 NTT DATA CORPORATION27

本日のまとめ

Copyright © 2010 NTT DATA CORPORATION28本日のまとめ

レガシーシステムユーザは景気悪化、EOSL等の問題で将来ビジョンの策定が急務ですが、決め手がありませんでした
モダナイゼーションの問題は、投資対効果が不明確かつ更改リスクが高く、実施判断が難しい点です
BizXaaSマイグレーションサービスではレガシーアプリケーションの実行環境をクラウド提供することで、更改コスト・リスク共に最適化し、お客様に安心してモダナイゼーションの可否をご判断いただけます

Copyright © 2010 NTT DATA CORPORATION

29

最後に作り直しに夢を描くのは止めよう
既存仕様の散逸（仕様が分からない中での作り直しって….）
ゼロからのシステム開発（これまでの歴史の繰り返し）
ＣＯＢＯＬはプラットホーム、パラダイムを超える唯一の言語
安心して使い続けよう
レガシー言語モダナイズで To COBOL需要はますます増大する

Copyright © 2010 NTT DATA CORPORATION

30

最後に ～Ａｆｔｅｒ 3.11～
ＩＴに対する従来の価値観を根底から覆す事件が近年立て続けに起きている。
・リーマンショックによる世界経済の悪化 → ＴＣＯ削減
・東日本大震災 → ＢＣＰの見直し
・原発問題 → 電力総量規制対応 → 節電・停電対策・サーバ移転
従来の価値観冗長化による拡張性、信頼性
新たなＩＴ評価基準
・電力消費量・移設のし易さ
・立上げ/下げ時間
・耐震構造
・設置条件
Copyright © 2010 NTT DATA CORPORATION

これからの価値観
省電力、可搬性

ＩＴ部門の方々は非常なご苦労をされていると思います。
少しでもお役に立てることができればと思います。
31

COBOLクラウドでレガシーシステムユーザ様のお役に立ちたい
ＮＴＴデータの総合クラウドサービス※BizXaaSは、株式会社NTTデータの登録商標です。

弊社が考えるMissionCriticalシステムの定義
定義「システムの存在が国民の社会生活や企業活動にとって必要不可欠なもの」
システムが停止した場合、国民の社会生活や企業活動に致命的な影響が生じるITサービス

たとえば、金融機関（銀行、証券、決済）、社会インフラ（旅客運輸、電力、通信）、官庁系（年金、国家予算、国防）
平時の要件充足性以外に構成要素
・２４時間３６５日連続稼動していること【高可用性】 異常（想定外）時の業務処理の安定性、一貫性、即時性が求・障害等によるサービス停止、中断の防止 【高信頼】
められる・り障範囲の局所化、拡大防止
・原因・対策の明確性と即時性
・処理結果のＡＣＩＤ（原子性、一貫性、独立性、永続性）保証
・高い処理能力、高負荷時の安定性【高性能】
・重要処理の優先実行
・想定外の外的要因（突発負荷、異常操作等）に対する安定性
等々、システム毎に要件レベルは異なる

これまではメインフレームの利用が大半
Copyright © 2010 NTT DATA CORPORATION

33

パラダイムの違いに関する課題
メインフレーム、オープンシステムはそれぞれ異なるパラダイムで発展してきたアーキテクチャである。利用者がアーキテクチャをチョイスする際にはＡＳＩＳの実現方式に捕らわれずにパラダイムの違いを考慮した要件整理が必要である。
メインフレームシステムとはオープンシステムとは単一ベンダ製品（ハード・ソフト）によるシステム複数ベンダ製品（ハード・ソフト）の組合せが可能

・単一ベンダの統一された製品構成の 利点 ・要件に適した製品を選択できる（新機能や新規格等に容易に対応可能）
ため統一的なインタフェースによる・初期費用が安い
システム構築・運用管理が可能
・特定ベンダに依存する・初期費用が高い
集中型システム
Copyright © 2010 NTT DATA CORPORATION

・異なる製品を組み合わせるため、統一感
欠点 あるシステムを実現するためには、十分な検証と工夫が必要
得意分野

分散型システム34

アーキテクチャの違いに関する課題
オープン系システムでMissionCriticalシステムを実現するためには、モジュラー型アーキテクチャで不得意な異常時の業務処理の安定性、一貫性を解決する必要がある。
・ハード/ネットワーク故障
そのためには、個々のレイヤ機能の強化ではなく、 ・オーバーロード（過負荷）・ＤＢデッドロック
業務処理を含めたトータルの連携強化が必要。
・ＡＰ異常（ループ）

端末装置

ＡＰＬ
いかなる場合でも、端末装置とセンター間の業務取引結果の一貫性をシステムとして保証する必要がある

ネットワークCopyright © 2010 NTT DATA CORPORATION

ミドルＯＳ
ハード
35

MissonCriticalシステムを含む基幹系システムの歴史
基幹系システムは当初はメインフレーム上にオールインワンで構築後、時代のニーズ対応するため個別最適で拡張を行った結果、レガシーシステムを中核に複雑に発散を続けている。
ゲートウェイサーバー
外部システム接続

業務パッケージ切り出し
基幹サーバー

SOA導入
ESB

レガシーシステム 新サービスの追加

個別最適によるサーバーの乱立とシステムの複雑化

インターネット対応
Webサーバー
Copyright © 2010 NTT DATA CORPORATION

ＩＴシステムの進化イメージ

情報系システム36

弊社の取り組み例②
PORTOMICS®では、前述のMissionCriticalシステムに求められる異常時の業務処理の一貫性を保証するための各種異常処理呼び出し出口を設けることで、異常発生時のきめ細かい対応を実現しています。
アプリケーションプログラム

前処理

後処理
異常処理

製品
DB（データベース）

ビジネスロジックＡＰサポート機能

ＡＰ制御機能製品
DC（通信ミドルウェア）

呼び出し

ＡＰフレームワーク
Copyright © 2010 NTT DATA CORPORATION

37