ホスト環境の複雑化とオフショア開発上の課題

　ホストシステムの更改は高額な投資を必要とし、業務に与える

影響も大きいことから、容易には行えない。そのため、フロントエ

ンドのみWeb化を進め、結果的にシステム環境の複雑化・肥大化

を招いているケースや、複数の異なるホスト基盤の運用に苦労しな

がらも、なかなか統合に踏み切れないというケースは多い。こうした

中で、リスクを考慮した実現性のあるマイグレーションを、より短

期間で可能にするソリューションを求める声が増えているという。

　加えて、今日多くの企業が直面しており、今後ますます増えてい

くと思われるのが、オフショア開発上の課題だ。オフショア開発に

おいては言語や文化の壁を乗り越えなければならないのはもちろ

んだが、課題はそれだけではない。森下氏は、解決すべきポイント

として、設計情報を確実に伝える方法の確立、属人性の排除、オフ

ショア側の作業スコープ検討（コーディングや単体テストだけで

なく、基本設計や結合テストも含めたオフショア化でコスト削減

効果を高める）などを挙げた。

　そして、森下氏はこれらを含めたシステム開発上の様々な課題

とその原因を整理。解決すべき内容を、次のように定めた。

マイグレーションにおいて必須の現行保証を上流工程で実現

　これらを具現化したソリューションとして森下氏が提案するの

が、従来のV字モデル（ウォータフォールモデル）にリバースソ

リューションによる現行分析工程を組み合わせ、ソフトウェアエ

ンジニアリングの手法を取り入れた「N字統合開発ソリューショ

ン」だ。

　ほとんどの場合、ホストマイグレーションにおいては現行機能

保証が必須となる。通常のコンバージョンツールを使ったマイグ

レーションでは、コンバージョン実施後にテスト局面にて現行保

証が確定するため、テスト工数の増加や手戻り発生のリスクが大

きい。N字統合開発ソリューションでは、従来のV字モデルにおけ

る設計工程の前段階に、リバースによる現行分析を実施。現行分析

情報と設計情報はXupper IIの設計リポジトリにより一元管理さ

れ、上流工程での現行保証が可能となる。　

　分析工程では、まず現行プログラムのソースコードをベースに

現行設計書にリバースして設計情報を現状最新化し、現行システ

ムの全体像としての、フォワード開発のベースラインを確立する。

リバース作業は、2つのアプローチで行なう。1つはソースコード

リバースからプログラム設計レベルのリバースアプローチであり、

もう1つは不完全な現行設計情報のベースをトップダウン観点で

整理しながらリバース作業を通じて詳細設計、外部設計、要件定義

レベルに仕上げていくアプローチである。2つのアプローチの成果

物は、設計リポジトリとしてプロセスモデル、データモデルが整合

性の取れた形でXupperリポジトリに実現でき、設計のベースライ

ンを確立することができる。

1990年代から担当プロジェクトの9割でXupperを活用し、これまでMDFrame/XやXupper IIのIPOエディターなどXupper自体の機能拡充にも深く関わってきた日本アイ・ビー・エムの森下氏。同氏は今回、ホストシステムのマイグレーションやオフショア開発において多くのユーザー /ベンダーが直面している課題を解決し得るソリューションとして、Xupper IIを核とした「N字統合開発ソリューション」を発表した。

ホストマイグレーションやオフショア開発を支援する「N字統合開発ソリューション」

日本アイ・ビー・エム株式会社　GBS コンプレックスPMコンピテンシー エグゼクティブ・プロジェクト・マネジャー　森下隆治氏事例2

あるべきソリューションの狙い・目標

① システム業務全体像の見える化と要件を決めるベースラインの確立

② システム改変による全体への影響分析と変更実現性の評価を可能とする

③ マイグレーションによるベースラインの確立と資産の有効活用

④ 業務要求について発注側と請負側の双方で共通理解を持つ方法の確立

⑤ 成果物の変更による整合性を保証し、設計内容とテスト仕様の不整合をなくす

⑥ オフショアで有効な開発方法の確立

⑦ 並行開発における設計情報更新の整合化を図る

⑧ 機能要件の上流での実現性評価とテスト段階での早期検証

⑨ 設計リポジトリとプロジェクト管理上有効なエンジニアリングの活用

⑩ 従来型のウォータフォールモデル開発から反復型開発方式へのシフト

［第16回Xupperユーザ事例紹介セミナーレポート］

　最初のリバース作業でのポイントは、移行対

象のソースはできる限り棚卸してデッドコード

を排除し、規模の最適化を行うこと。特に4GL

からの移行では、利用しているマクロ関係を展

開すると規模が膨らむため、マクロ変換して畳

むなどの開発保守対象規模を抑える工夫が必要

である。2番目のアプローチでは、全体像を把

握するのに必要なプログラム構造分析、ジョブ

フロー図、判定条件検出などのリバースツール

を活用しながら、現行設計ベース情報を設計リ

ポジトリとしてXupperリポジトリに構築す

る。1番目のアプローチでソースリバースした

プログラム仕様（IPO情報）を設計リポジトリ

にインポートすることで、設計情報とソース情

報のトレーサビリティを実現する。

　現行保証は2段階で実施。まず、移行後の

ソースレベルで現行比較し、保証されたものを

ベースに設計に反映する。そして、テストによ

る現行保証を行う。すなわち、リバースの結果

ベースラインとして作成した設計リポジトリに

ソースとの紐付けを行い、現行ソースの追跡を

可能とし、テスト工程での現新比較の精度向上

を実現する。

　これにより、手戻りリスクを最小限に抑え、

かつ現行設計情報・プログラムを最大限活用で

きるという（図1）。

設計リポジトリによる課題解決とオフショア開発への活用

　課題解決ソリューションとして、Xupper II自体の持つメリット

は最大限に活かすことができる。要件管理機能では、業務要件とシ

ステム要件の対応、要件と実装との関係などのトレーサビリティ

を実現し、業務全体の見える化が可能（図2）。処理機能記述をIPO

（入力情報、処理、出力情報）形式で定義するIPOエディターによ

り、リポジトリ情報を参照しながらIPO情報を定義することで整合

性を保持できる。要件変更によるシステムへの影響調査も、クロス

リファレンス機能で設計・ソースレベルまで一貫した分析が可能

だ。リポジトリを活用した設計作業により、膨大な成果物（設計情

報）間の整合性の保証ならびに並行開発における設計情報の整合

性も保証できる。

　N字統合開発ソリューションでは全工程をXupper IIの設計リポ

ジトリで一元管理することから、リモート開発やオフショア開発

との親和性も高い。設計情報からコーディングレスでソースコー

ドを自動生成するツールを取り入れているため、安定した開発品

質と生産性を確保できるほか、単体テストの自動化およびテスト

ケース抽出機能とテスト半自動化ソリューションの採用もオフ

ショア開発において有効だ。とりわけ、クラウド環境を活用した設

計リポジトリのオフショアとのシェアにより、最新情報の提供や、

スキル伝達と同時に人材の流動性のリスク対策が可能である点は

大きなメリットといえるだろう。

現行プログラム設計情報

4GL, COBOL（移行対象）

現行仕様抽出結果

現行設計書付随資料等

Xupper（現行 IPO）

HLL/WB（現行）

■規模の最適化　棚卸し

■規模の最適化　マクロ変換

■ソースレベル　での現行保証

■リバース資産の　フォワード活用

■変更対象外機　能の現行保証

■現行 IPOの設計　リポジトリ取り込み

■リバースツール利用　による設計情報抽出

Xupper（現仕様+IPO）

現行分析

2）設計モデル初期構築

3）現行仕様分析 Xupper

（新仕様追加）

10）プログラム結合試験

12）システム全体試験11）現新比較

4）要件定義

⑤現新比較

②言語変換 9）単体試験

新要件

HLL/WB（新仕様）

5）アプリケーション設計

：整合性ポイント

■設計書 ：Xupper（現仕様）■Source ：Xupper（現物理：IPO）

：ツール適用

Xupper（新仕様+IPO）

7）プログラム設計

6）サブシステム内部構造設計

8）プログラム製造

新要件（共通サブ再編）（モジュール分割）

Xupper（IPO部品）

8）新要件反映（部品化）③IPO変換

4GL、COBOL（全体）

1）現状調査

リバース情報

現行設計書

現行設計書

基本設計

要求分析

詳細設計

プログラム設計

初期複製

プログラム製造

テスト仕様抽出

テスト仕様抽出

UAT基準抽出

総合テスト

結合テスト 現新比較

（従来手法）単体テスト

運用テスト

現行分析 設計

上流工程で現行機能保証

開発 テスト 保守

リポジトリ管理

整合性確保と現行設計ベースライン確立

●●

●●

●●

●

●

● ● ●

●

●

●

●

●

●

図1：N字モデル 開発工程実装イメージ（N字モデルによる現行保証と最適化開発方式）

業務要件

業務フロー

テスト仕様 エンテイティ

データ項目画面 /帳票

要件の階層 エンティティが保有するデータ項目

IPOエディターで使用するデータ項目

画面や帳票で使用するデータ項目

システム機能に対応する画面や帳票

業務のシナリオごとのテスト仕様

業務機能に関連する要件

どのように詳細化されているか

業務機能の機能の詳細記述

業務機能のうちシステムで実現する機能

業務機能に対応するシステム機能の記述

ビジネス・ルール定義

システム機能の外部仕様（IPOエディター）

業務機能に関連する画面や帳票

図2：統合開発ソリューションによる全体業務の見える化と成果物関連図