レガシーモダナイゼーション

ソフトウェア生産技術革新

リホスト

メインフレーム

情報システムの継続的利用のためのレガシーモダナイゼーション
大規模なメインフレームシステムは複雑化やブラックボックス化が進み，保守開発やシステム更改の費用が高い状況が続いています．オープンシステムへの移行によって費用を抑えようとしても，全く異なるプラットフォームへの移行は容易ではありません．本稿では，大規模メインフレー
ムシステムのリホストによるオープン化の難しさと，システム開発の自動化を活用した打開策について説明します．

た に のひであき

谷野 英昭
NTTデータコンピュータに置き換わるかに思われ直面しています．
もっとも顕著なのは，ましたが，ここ １ ，２ 年で減少ペースシステムの運用にかかる費用が高いとが止まってきました．大規模（ １ 台2.5いう問題です．
その原因は，ハードウェ1980年代から全盛期を迎えたメイ

億円以上）なメインフレームは増加のアが高価なだけでなく，長年利用してンフレームは，ピーク時には国内の出傾向もみえます．これは，当面の間は改造を加え続けたアプリケーションが荷台数で約3500台，出荷金額は １ 兆

メインフレームが継続して利用される

肥大化 ・ 複雑化し，小さな変更が発生円を超える規模となりました．
しかし，ことを示しています．

した場合でも膨大な影響範囲の調査と残された大規模メインフレーム

1990年代中ごろからはオープン化のテストの実施が必要となるためです．

レガシーシステムの問題

波にのまれ，その規模は10分の １ 以下

特に，日本のメインフレームで運用さにまで縮小しました（図 １ ）．特に，NTTデータは，残されたメインフ

れているシステムは大量の帳票を出力中小規模（ １ 台2.5億円以下）のメイ

レームシステムを国内でもっとも多くするバッチ処理が大規模 ・ 複雑であンフレームは急激に減少しました．こ

運用している企業の １ つであるため，り，きめ細やかな業務処理を実現するのままメインフレームはオープン系のメインフレームに関する多くの問題にためにアプリケーションも細部までつ

(台)
1500

急激に減

1000

少

大規模なメインフレームが中心に残っていく

500

02003

2004

2005

4 千万円未満
4 千万円〜2 億 5 千万円以上

図128

NTT技術ジャーナル 2014.10

2006

2007

2008

2009

2010

2011

2012

出典：JEITA（電子情報技術産業協会）の集計よりグラフを作成

メインフレームの規模別出荷台数の推移

(年)

特 集

くり込みをしてきた経緯があります．

処理順序や起動条件，処理やバック

さらに，200₇年問題によって，大量アップの時間，失敗したときのリカバのメインフレーム技術者が引退したた

リ方法などを考慮しながらシステム全打開策はアプリケーションを変換しめ，システムのブラックボックス化が体を正しく動作させることは針の穴にて再利用することではなく，信頼でき進み，問題を深刻にしているのです．

糸を通すような繊細な作業なのです．

るソースコードなどの資産を使って設

これらを非機能要件が異なる新しいプ計書を作成し，その設計書を再利用すラットフォームで動かそうとすると，ることです．はじめに，正しい設計書メインフレームを使ったシステムのプログラム単体のテストでは問題なを手に入れることで現状のシステムの運用の費用を抑えたいというニーズにかったものが，結合テストをしてみる仕様を正確に把握し，次に最適なシスこたえるため，一躍脚光を浴びてきたと大量に不具合が起きるのです．

テムを実現するためにシステム開発をリホストによるオープン化

Ｎ字型による開発の自動化のがリホストと呼ばれる開発手法によ

もう 1 つの大きな原因は，現状把握徹底的に自動化して高速に開発するのるオープン化です．リホストでは，メの難しさによる見積りの精度の低さでです．この開発プロセスは通常のV字インフレームで使われていたアプリ

す．過去20〜30年をかけてつくり込型の開発プロセスの前段に，再利用すケーションや処理の順番を記述した

んだシステムは，その場しのぎでイレる設計書をつくるプロセスを加えたＮ

JCL（Job Control Language）やジョギュラーにシステムを変更しているも字型となるのです（図 ₃ ）．

ブネットをオープンシステム上で動作のが大量に組み込まれています．シス

Ｎ字型開発の最初は復元フェーズでするように変換して再利用します．今テムの一部の領域だけを調査しただけあり，現状の業務とシステムを可視化まで使ってきた資産をそのまま利用しでは，イレギュラーケースやリスクのして理解するところです．そこには，て，早く，安く，品質を変えずにオー見落としによって，精度の高い見積りリバースエンジニアリング技術をフルプンシステムに移行することをねらっができないのです．最悪の場合はすべ活用しています．ビジネスロジックとています．
当初は，変換するアプリケーてのアプリケーションを 1 つひとつ確

アプリケーション構造の可視化はコンション数が数百程度でしたが，対象シ認する必要があるのですが，そのためピュータで自動的に実施できるためでステムも大規模化し，アプリケーショの費用と期間によってリホストの魅力す．次に，人間が業務とシステムを関ン数が 1 万を超える大規模システムにを失ってしまうのです．

連付けて理解するために，可視化したもリホストによるオープン化が取り組構造やデータに業務的な意味付けをしまれるようになりました．

ます．オンライン処理であればシステ

このころから，リホストの費用や期間が当初想定を大幅に超えて問題化する例が多く聞かれるようになりましメインフレームシステムオープンシステム

た．調査をすると，もっとも大きな原
因はアプリケーション変換に対する過業務アプリケーション信でした．変換さえしてしまえば新し（COBOL，PL/I）

いシステムがつくれるという誤解によデータベースが必要な点をおろそかにしていたので（NDB，VSAM…）す（図 ₂ ）
．再設計が必要となるのは，

アプリケーション基盤・制御

主にバッチ処理やシステム運用，アプリケーション基盤の部分ですが，その規模はバッチ処理だけでJCLやジョブネットの数は数万本にもなります．

製造

試験

設計書の整備アプリケーション
変換

総合・運転試験
現新比較

再設計〜試験

（ジョブネット，JCL）

リホスト

り，再設計によるインテグレーション

運用

設計（ユーティリティ，マクロ…）

再設計〜試験・移行

インテグレーション
実装検討〜試験

メインフレーム，ミドルウェア

図2

オープンコンピュータ，ミドルウェア

リホストで見落としやすい「インテグレーション」

その膨大な数の 1 つひとつに対して，NTT技術ジャーナル 2014.1029

ソフトウェア生産技術革新

復元フェーズ開発フェーズ

モニタリング

要件定義
抽象度の高い情報への復元
機械的なレベルの復元テスト

設計

テスト
自動化

最適化
設計

設計書
リカバリ

製造

図3

コード自動生成

Ｎ字型開発

ムの利用者が扱う画面から，実際に処にできれば，次のシステムの設計におステムが抱えている問題を解決するこ理を動作するアプリケーションやデーいて現状のシステム構造や処理方式にとができます．大規模メインフレーム

タベースまで一貫したトレーサビリ

とらわれずにあるべきシステムの姿がシステムが抱えている問題の １ つとしティと意味付けをします．バッチ処理設計できるのです．て，大量のバッチ処理によってオンラ

では，人が認識をしやすい処理の塊のＮ字型開発の後半は，開発フェーズインのサービス時間が限定され，リア単位に意味付けをします．処理の塊のです．ここでは，前段の復元フェーズ

ルタイムで業務状況を把握しにくい点

単位は複数階層にして整理し，上位階で作成した成果物を次期システムの上があります．これは，開発当時ではコ層では業務用語を使って名称や説明流設計のインプットとします．イン

ンピュータパワーが不足していたたを付与します．この業務とシステムプットの形式を標準化することで，シめ，応答時間を重視するオンラインでの理解のプロセスによって，システステム開発の自動化にもスムーズにつ処理をさせず，できるだけ夜間のバッ

ム全体の俯瞰と詳細な把握が可能になげることができます．NTTデータでチ処理で対応してきたためです．できなります．

開発したTERASOLUNA ViSCやIDEるだけオンラインでリアルタイム処理

処理の理解と同時に，データの理解によるソースコードの自動生成やするためには，情報をつくり出すためも必要です．システムで扱うデータのTERASOLUNA RACTESによるテスの業務仕様から整理をして処理を設計

１ つひとつに正しい名称と内容を定義

トの自動化だけでなく，さまざまなする必要があり，Ｎ字型開発による再するためには，データどうしの関係をツール群を活用した高速開発が実現で設計による最適化が必要となるので（1）

整理して静的な構造を把握した後に，きます ．新たな要求や最適化を行う

す．データ管理についても大きな問題

データの導出ロジックを明確にする必際には，TERASOLUNA DSを使ってがあります．メインフレームシステム

要があります．その際にも，リバース設計フェーズから整合性を自動的に確でNDB（Network DataBase）が使わエンジニアリングの技術が利用できま（2）

認します．
TERASOLUNA Simulator

れている場合は，オープンシステムです．CRUD図 を自動でつくることで，を使えば仕様の妥当性までも早い段階

はRDB（Relational DataBase）に 変データの導出や変更ロジックを特定すで精度高く確認ができるのです．設計更する必要があります．その際に，ることができるのです．このフェーズ

書を再利用するN字型開発によって自NDBの 構 造 を 色 濃 く 残 し た ま ま のの最終ゴールは，システムのつくりに動化ツールを最大限活用し，システムテーブル構造にしてしまうと，テーブ依存しない，純粋な業務の仕様を明ら更改をもっとも早く，確実な開発を実ルの結合やデータアクセスが頻繁に発かにすることです．業務仕様を明らか現できます．

生してしまい，効率の悪いデータベー＊＊ CRUD図：データが，どのアプリケーションで作成（Create），参照（Read），更新（Update），削除（Delete）されるかを表形式で表現した
もの．

30

NTT技術ジャーナル 2014.10

最適化と再レガシー化防止

スアクセスによる性能問題を引き起こしてしまいます．N字型開発であれば，リホストとは異なり，Ｎ字型開発は業務要件から最適なテーブル設計を行システムを再設計するため，現状のシうため，データ構造が引き起こす問題

特 集

機能追加を繰り返すと…

機能追加

機能追加

新たなレガシー化

トレーサビリティとモニタリングを組み込むと…

新システム

機能追加

機能追加

トレーサビリティ

トレーサビリティ

老朽化しない適切な追加かをチェック

図4も最小限に防ぐことができます．

再レガシー化の防止や未実施の原因となり，継続した活動

しかし，最新化されたシステムでに は な り ま せ ん． 人 に 頼 ら ず コ ン

あっても，設計書がメンテナンスされピュータで自動的に実施することが重ずにソースコードと設計書が乖離する要です．と，再びシステムはレガシー化します（図 ４ ）．設計書の不備はシステムのブ■参考文献（1） 我妻：“NTTデータにおけるソフトウェア開発自動化の取り組み,” NTT技術ジャーナル，Vol.26，No.10，pp.14-19，2014．
（2） 金子：“真の上流工程へのシフトを実現するTERASOLUNA Simulator,” NTT技術ジャー
ナル，Vol.26，No.10，pp.20-23，2014．

開発とチェックの自動化

ラックボックスや有識者不足を招き，メインフレームの多くはレガシーシ

システムの複雑化が加速して運用コスステムとも呼ばれ，人員の流動化や新トの上昇を招きます．小さなシステム

しい生産技術の導入の遅れを招いてい変更であっても多くの稼働と時間が必ます．
システム更改をしようとしても，要となってくるのです．システムを改

大規模 ・ 複雑化 ・ 有識者不足によって造する際は，ルールに従って設計書を難易度も高くなっており，大きな投資最新化することが重要ですが，限られが必要になります．しかし，システムた時間と関係者だけで実施することは更改をしても，再び規模や複雑さ，有困難な状況です．

識者不足という問題にぶつかっては意

対策は，設計書間の整合性のチェッ味がありません．ある事例では，シスクやルールに従った変更が行われていテムの保守を10年も続けると規模はるかをコンピュータで自動的にチェッ1.5倍にも肥大化し，新商品やサービクをすることです．システムを改造す

スを導入する際に必要な期間は当初のる際の設計書やプログラムを常に２ 〜 ４ 倍にもなることもあるのです．

チェックして変更ができれば，上流工

この負のスパイラルを断ち切り，情報

程 で の 不 具 合 検 出 に も つ な が り，システムを継続的に利用するために，QCD（Quality, Cost, Delivery）の改

人手に頼らない開発とチェックの自動善にも大きく貢献します．このチェッ化に移行することがますます重要にな

クプロセスは人が実施すると抜け漏れります．

谷野 英昭
レガシーシステムの問題は，今後はオープンシステムでも起きることが予想されるため，社会的な課題に発展することも考えられます．そのため，この問題に対してはさらに加速して取り組んでいきます．

◆問い合わせ先NTTデータ
技術開発本部
ソフトウェア工学推進センタ
E-mail case-nttgjournal kits.nttdata.co.jp

NTT技術ジャーナル 2014.1031