モダナイゼーション10の罠｜9.現行保証の罠

「現行保証の罠」とは？

レガシー・システムのモダナイゼーション、特にコンバージョンのように既存システムの機能踏襲となるプロジェクトでは、「業務継続性」の担保が重要となります。その場合には、現新比較による品質担保が一般的であり、テスト工程がプロジェクト工数の多くの割合を占めます。しかしながら、既存システムのテストケース再利用を検討したものの、設計書と同様に当時のテスト仕様書が残っていないケースが多くあります。さらに、機能拡張やAPI化などにより外部接続インターフェース変更を伴う場合には、現新比較による現行保証は困難となります。

このように現行保証における様々な問題を「現行保証の罠」と呼び、いかにして「業務継続性」を担保するのかがポイントとなります。今回は現行保証が求められる、リホストやリライトを対象に「現行保証の罠」を考えます。

実際に起こっている問題

「現行保証の罠」では実際にどのような問題が起こっているのでしょうか。レガシー・システムは何十年も運用されており、度重なる改修や構築時メンバーの退職などにより、システム自体がブラックボックス化しているケースが多くあります。そのような条件下で、どこまでテストを実施すれば品質を担保できたと言えるのかについてあらかじめ戦略を立てずにテスト・フェーズに入っていった結果、テストを際限なく実施するような事態に陥り、テスト工数や期間が大幅に増えてしまうようなケースが数多く起こっています。そういった事態に陥らないように、プロジェクトの序盤からテスト戦略に関する検討が必要です。

「現行保証の罠」の乗り越え方

「現行保証の罠」を乗り越えるためには、テスト戦略の中で各工程における品質の積み上げ方を明確に組み立てることが重要です。モダナイゼーション手法や採用ソリューションなどによりテスト工程の考え方は多少異なりますが、V字モデルをベースに徐々に検証範囲や深度を深めていくことで、品質を積み上げていくテスト工程の例を図1に示します。

図１ V字モデル

今回はテスト戦略上で重要となる、現新比較テストとシステム・テストを見ていきます。

現新比較テスト
現新比較テストでは、現行システムと新システムで同じ処理結果になることをジョブ単体や画面単体で確認します。既存のテストケースやデータが利用できる場合は流用することが望ましいですが、利用できない場合は本番データの利用を使用したテストを検討します。図2のように、本番環境から対象処理のインプットデータを検証環境へコピーし、現行システムと新システムで同じ処理結果になることを確認します。

図2 現新比較対象イメージ

この場合、テスト・シナリオとしてはインプットとアウトプットデータを一覧化する必要があります。洗い出しの際には、ADDI^※1 のような可視化ツールを用いてファイルの使用状況やCRUD（クラッド：Create/Read/Update/Deleteの基本機能）を機械的に洗い出したのち、テスト対象を精査するような方法が効率的です。また、実際にテストデータを取得する際には、データ断面の整合性が重要となります。対象データの取得前に他の処理により上書きされてしまうような場合には、現行システム側にデータを退避する処理を一時的に追加するような対応などが必要となります。他にも、IBM InfoSphere Optim Test Data Management for z/OSなどのように本番データをテスト環境へコピーするような製品を利用する方法も考えられます。

また、テスト品質の向上や効率化を目的としたツール活用をお勧めします。例えば、IBMには様々なテスト・プラットフォームが用意されており、IBM Z Virtual Test Platform（ZVTP）^※2 やIBM Z Development and Test Environment（ZD&T）^※3 はメインフレーム環境でのテスト効率化に貢献します。また、Webアプリケーションがある場合には、GTAM^※4 などのテスト自動化ツールにより画面テストの自動化が可能となります。

外部接続インターフェースの変更を伴う場合には、単純な現新比較が行えないため注意が必要です。インターフェースのレイアウトが同じであれば一度テキストファイルに落とし込むことで項目ごとの現新比較が可能な場合や、周辺システムで取り込んだインターフェースに対するログを吐いており、そのログ同士で比較を行うなどのように現新比較ポイントをずらすことで単純な現新比較が可能な場合があるため、個別に検討が必要となります。

システム・テスト
システム・テスト以降からは「業務継続性」の観点で品質を検証していきます。システム・テスト内においても、図3、4のように段階的に検証深度と範囲を広げていく方法が考えられます。

図3 システムテストにおける検証範囲の概念

図4 システム・テストの区分

ST3では最終的に並行稼働として現行システムと新システムで変わることなく正しく処理ができることを確認します。テストを際限なく実施するような事態に陥らないように、本番サービスインに向けてどのような断面をどの程度検証すれば良いのかを見極めることが重要です。過去のお客様の例では月末から月初にかけた11稼働日を実施することで、データ・バリエーションとしても十分であり、重要な日次/月次処理が確認できるため、本番リリースにあたり品質が担保できると計画されたケースがありました。このように業務や処理の観点でどこまでテストを実施すれば品質を担保できたと言えるのかについて決めることが重要です。

まとめ

「業務継続性」の担保の観点でテスト戦略を立てていくことが重要です。システムの特徴や業務の優先度、予算などによりテスト戦略が異なってくるため、どこまでどういった確認を行うのかをプロジェクトの序盤から議論を深めていく必要があります。今回ご紹介したような品質の積み上げ方を参考に、各プロジェクトでの検討にお役立てください。

本ブログでは、モダナイゼーションを進めるうえで陥りがちな10の罠について、IBMの経験に基づき、傾向と乗り越え方をシリーズでお伝えしております。今後の解説もぜひご覧ください。

参考文献
システム再構築を成功に導くユーザガイド（IBM外のWebサイトへ）

脚注
※1 ADDI（IBM Application Discovery and Delivery Intelligence）：IBMのメインフレーム・アプリケーションの分析プラットフォーム。保守開発における変更時の相互関係の分析などに使用するが、モダナイゼーション・プロジェクトにおいても資産の関係性分析やCRUD分析が行えるため積極的な活用をお勧めする
※2 IBM Z Virtual Test Platform（ZVTP）：既存ミドルウェアやデータを必要とせず、開発者およびテスト担当者がトランザクション・テストおよびバッチ・テストを実行するための機能を提供するプラットフォーム。キャプチャー・アンド・リプレイ機能により、テストデータ準備やテスト実行作業負荷を軽減する
※3 IBM Z Development and Test Environment（ZD&T）：メインフレーム・アプリケーションのデモンストレーション、開発、テストおよび教育のためのプラットフォーム。z/OSの開発環境をエミュレートし、Linux環境での実行が可能
※4 GTAM：Guide and Toolkit for Application Modeling Test Toolの略。オープン・ソースのSeleniumおよびAppiumをコア・エンジンとするUIテスト自動化ソリューション。画面モデルを元にテスト・スクリプトの作成を支援し、テスト自動化でハードルとなるテスト・スクリプトの開発・保守の負荷を軽減する

次の記事『モダナイゼーション10の罠｜10.運用保守性の罠』を読む