1. HOME
  2. 移行ノウハウ
  3. Q&A

移行ノウハウ

移行問題

① 棚卸・スリム化で不要資産を削減する。
② 仕様変更の機能に対し、保守性の高いJava等に変更し、保守コストを抑える。
③ 仕様変更があまり発生しない機能に対し、言語バージョンアップで、低コストの移行を行う。
④ 思い切ってリホストで移行コストを抑える。※ランニングコストも考慮する必要がある。

移行設計が必要なため、小規模システムであっても、3,4ヶ月以上かかる場合が多い。
また、機能の設計を行わないため、大規模システムであっても、1年程で再構築できる場合が多い。

ツールによる変換だけに頼らず、比較テストを徹底的に行うので、新規開発より格段に品質が高い。
豊富な移行経験に基づく、変換率の高い変換ツール、徹底的な比較を行えるテストツールが必要である。

自動化で、移行開発の期間が短く、納期保証が簡単だと思われる向きがある。
性能・保守性を考慮するソース変換の高度な技術を必要とし、移行対象システムが毎回違い、属人的なシステム開発による多数の技術パターンも生み出している。
そのため、高い技術力を必要とするツールのカスタマイズが必要となり、また、比較テスト、バグ対応の為のツール修正も時間がかかる。
以下は納期保証の主要ポイントである。
・多数の技術パターンを有した豊富な移行経験
・新しい問題に迅速に対応できる柔軟なツール
・即時にキーマンを投入できる大きい移行研究/ツール開発部隊
・移行先の高い保守性も、問題対応時間を短縮する重要ポイント

移行では性能問題がよく発生すると言われている。
メインフレーム等の移行前のマシンが速いわけではなく、移行先の新しいマシン、OSに合わない古い処理方式がそのまま移行されることが性能問題の主な原因である。
例えば、SQL文で検索せず、ホストのファイル処理方式のまま、1件1件、データを取出し、処理する悪い移行が散見される。
以下は性能保証の主要ポイントである。
・豊富な移行経験より、事前に性能問題とその解決方法を押さえる。
・性能問題を解決できる高度な変換ツール
・移行しながら、ツールで性能テストを実施する。
・本開発時に万が一性能問題が発生した場合、瞬時にキーマンを投入できる大きい移行研究/ツール開発部隊
・移行先の高い保守性でスムーズな性能改善を可能にする。

移行作業は高い専門性が求められる。
全ての開発工程に対応でき、柔軟な変換・テストツールを有し、大きい移行研究/ツール開発の専門部隊を持つ経験豊富な移行会社を利用する。
また、発注側作業をきちんと対応することも重要。

業務知識による影響

ツールにて、プログラムソースの相関関係、動き(ログ)、類似度を正確に分析できるため、正味資産、不足資産、不要資産、共通化可能レベルを正確に把握できる。

経験豊富な当社では、以下の理由で新規開発より格段に品質の高いテストが実施できる。
・移行バグの出処をほぼ把握している。
・テストされた箇所をツールで把握しており、十分なカバー率を実現する。
・新旧比較で、厳格にテストを行う。
※必要に応じて、ユーザーから操作を教えて頂く必要がある。

機能変更はシステム全体の2,3割以内なら、再開発ではなく、 移行+機能変更した方がいい。
当社では、以下のように、改修の為の業務知識を把握する。
① 移行時、システムの操作を教えて頂き、操作して比較テストを行う為、移行段階で業務知識を得ている。
② 仕様書再生:ソースから仕様書を作成できる。
③ 改修箇所は、ユーザーが気になるところであるため、既存機能の概要と変更仕様を説明することになる。
④ 移行開発をしてきた期間での内容把握とシステムリフォームで節約した多くの工数より、余裕をもって機能変更することが可能。
⑤ 移行後、保守担当等による改修も可能である。
 システムリフォームは改善のために生み出された開発方式である。
 そのため、ユーザーは業務改善検討に時間と工数をかけられることで、よりよい付加価値の実現が可能。

移行の目標と出来栄え

通常のマイグレーション技術は移行後システムの保守性を守れない。
リライト(手で言語変換)の場合はコストが高く、品質も不安である。
システムリフォームはシステムを成長する為に産み出した再構築技術で、システムリフォームツール変換は、手書きに近い保守性を実現する。
少ない手修正で更に高い保守性も実現できる。
また、テストツールで、手修正箇所をカバーする比較テストを実施する。
Javaへの移行、データ構造変更、フレームワーク変更のシステムリフォームが多い。

プログラムを共通化するには2つのレベルがある。
① 業務機能レベルで分析し、再設計・再開発で、最大限に共通化を図る。
② コピーして作ってきた類似プログラムを共通化分析ツールで見つけ、共通化を行う。
①の場合、ユーザーから見て、費用対効果が出にくく、品質も懸念されるため、当社では行っていない。
②の場合、ツールで高いコストパフォーマンスを出せるため、数多く対応している。
但し、プログラムの類似度の低いプログラムにおいて、保守性が悪くなる可能性が高いため、勧めていない。

再設計・再開発により、システムのスパゲッティ状態を解消するケースが殆どだが、高コストの為に予算が取りにくく、保守担当は多数のブラックボックスで判断がつかず、中途半端な結果になってしまうケースが多い。
システムリフォーム技術のスリム化、共通化、フレームワーク変更、見える化、機能変更対応で、無理なく、高品質・低コストのスパゲッティ解消が可能になる。

通常のマイグレーションでは、保守性が劣化する場合が多い。
特にツール変換でJava等の他言語に変換する場合、移行後のソースが分かりにくく、元のCOBOL等のソースよりも保守性が格段に悪くなってしまうケースが多い。
システムリフォームはシステムを成長する為に産み出した再構築技術で、ユーザー要望に合わせて保守性を改善できる。
例えば、システムリフォームのツールは手書きに近いJavaに変換したり、データをRDB化したり、ユーザの標準フレームワークに変更したりする。

原則として、既存を正として移行するため、既存のバグを無くすことは難しい。
当社は業務機能のテストも実施するので、ある程度の既存のバグを修正することにつながる。

ユーザー負担

システムリフォームは他の構築手法に比べ、一括請負で、既存機能を実現する責任を負うため、ユーザーは作業が少なく、機能設計書レビュー等の責任も押し付けられることがない。
但し、発注側には次の作業を対応する必要がある。
① 比較テストの為に、既存データを提供する必要がある。
 ※画面系ならば、必要な操作シナリオがスムーズに実施可能なマスター等のデータ、バッチ系ならば、複数の各種営業日等のデータが必要。(データマスキングする場合もある)
② 当社が業務シナリオテストを実施できるようにするために、ユーザーは既存システム運用・操作方法を当社に教える。(複雑な画面ならば、1画面数分間程度の操作説明等)
③ ユーザーは、移行設計の時に移行目標に合意して承認する。他システムとのI/Fが変わる場合、他システム部分を設計して、修正する。
④ 比較テストの場合、不一致だが、良しとする場合もある。その不一致を承認する。
 例:既存システムの計算精度は小数点後20桁であるが、新しいシステムは小数点後24桁になる場合。
⑤ 総合テスト(他システム連携のテスト)において、他システムでの作業を実施する。
⑥ 既存システムについて当社からの質問に時々対応する必要がある。大規模基幹システム移行では、運用テスト以外に、ユーザー側1~3名の体制での対応が一般的。

上記の発注側担当作業で説明した通りに、ユーザーが多忙であったり、既存システムがブラックボックスになっているからこそ、システムリフォームが有効である。

難しい移行について

当社が移行設計のツールをカスタマイズしたり技術検証をするため、小規模システムなら4ヶ月以上、大規模システムならば1年以上の作業期間が必要。
既存システム状況・規模、移行パターン、移行経験、ツール、移行会社の規模等の条件で、移行開発の作業期間が変わる。

可能であるが、場合によっては、コストが高くなることがあるので、お問合せ下さい。

ソースを移行するので、ユーザーがソースの利用権利を持つ必要がある。

プログラムソースがない場合、逆コンパイルでソースを生成することも可能。
但し、アセンブラしか生成できなかったり、きれいなソースを生成できなかったりする場合もある。
具体的な状況をお問合せ頂ければ、対応の可否を確認します。

移行は専門性がとても高いため、当社の技術、方針に準じて遂行されることをお勧めする。

言語バージョンアップ、リホストによくある不安

① 既存メインフレームに合う、実績の多いリホストミドルウェアを選択する。
② 当社はミドルウェアメーカーと協力して問題を解決するため、2重の保険を掛けていることになる。

先に説明したリホスト技術問題による失敗を避けるを前提に、ランニングコストが低く、保守性改善の効果が大きいミドルウェアを選択する。
既存システムの情報を教えて頂ければ、候補の提案ができるため、お問合せ下さい。

■ 言語バージョンアップの場合、移行先システム構成、データ構造等をきちんと設計し、移行効率と保守性を両立する。
 リホストなら、リホスト用ミドルウェアをきちんと選択する。
 ※柔軟に移行できる当社は、きれいに変換しても、安価な場合が多い。
■ Javaに移行し、データ、システムの構造もきちんと改善することは徹底的な対応法となる。
 但し、移行先のJavaの保守性が極端に悪かったり、データ構造が古いままのマイグレーションが多いため、注意が必要。

① COBOL人口はまだそれなりに多く、バッチデータ処理にも向いているので、必ずしも保守性が悪いとは限らない。
② データ構造変更等、システム心臓部を柔軟な移行によって保守性・成長性のあるシステムに移行することが一番大切。
 ※リホストの場合、データ構造変更等が難しい。
③ オフショア保守を利用して古い言語も長く対応できる。

① 基盤ソースを公開してもらい、自社内利用を可能になるように交渉する。
② 柔軟にユーザー基盤に合わせることができる当社にお問合せ下さい。

その他質問

以下のSTEPとなる。
■ 打ち合わせを行い、移行目的、既存システム状況、移行先へのご要望を教えて頂く。
 当社も主な移行選択肢とそのメリット、デメリットをご説明する。今後の検討の方向性で合意する。
■ 当社が用意するA4用紙2ページ相当のヒアリングシート(Excelシート)にご記入頂く。
 ※OS等の環境情報、ソース規模などで、保守担当者ならそれほど負担を感じずに記入が可能。
■ 1,2週間で、当社より複数の移行選択肢の概算見積、移行提案を提示する。
■ 棚卸・スリム化を行う。有償にはなるが、今までの経験において2割以上の資産削減率を実現したことが多く、ユーザーにとってメリットが大きい。
 ※受注前のスリム化効果の無償調査も可能。
■ 棚卸・スリム化の結果をふまえて詳細見積・最新提案書を提示する。
■ 開発が決まれば、移行設計を発注、サンプル開発で当社の品質を確認する。
■ 移行設計が成功した後に、本移行の発注を決定し、本移行を行う。
※具体的な案件によって、上記の内容を調整することもある。

殆どのレガシー言語がサポートされ、継続利用は可能。
但し、技術者調達、維持コスト、ハード・ソフトの保障期限、改善対応、DX推進、AI・BIGDATA・クラウド化などの新しい技術導入等で、計画的な更新を検討した方がいい。
当社は数多くのシステム更新検討をサポートしているため、お問合せ下さい。

言語バージョンアップ、エミュレーション方式(リホスト)の場合、とても高い変換率で高い生産性を実現できるが、言語変換の場合、変換率が落ちる。
ソース変換率が90%(10%の手修正)になっても、凡そ10行のソースに対し、1回手修正が必要となり、その為、修正ソース前後のソースを理解する必要、テストの為の業務機能理解が必要のため、新規開発と比べ、生産性の極端な改善は期待できない。
当社の主要の言語変換では99%以上の自動変換率を実現しているが、それでも、手書きとほぼ同等の保守性の維持、徹底した比較テストで、新規開発と比べ、10倍以上の生産性とはならない。
但し、品質維持には自動変換が極めて重要である。