移行の課題と解決策
 移行問題  

  ・移行のコスト感を知りたい。
  ・移行コストを削減したいが、どんな対策があるか?
  ・移行の工期の感触を知りたい。
  ・どう品質を保証するか?
  ・どう納期を保証するか?
  ・移行で発生する新たな性能問題を防ぐ方法は?
  ・移行を成功させるもっとも重要なPOINTは何か?

 業務知識に関係するテスト、機能変更、仕様書再生など  

  ・ソフトロードは仕様がわからないのに棚卸・スリム化を任せることができるか?
  ・ソフトロードは仕様がわからないのに、どうやってテストするのか?
  ・ソフトロードは業務知識を持たない。どうやって機能改善するのか?
  ・仕様書を作りたい。

 移行の目標と出来栄え  

  ・Java等他言語への移行、データ構造変更、自社のフレームワークへの移行など難しい場合、どうすればいいか?
  ・プログラムの共通化を図りたい。
  ・スパゲッティ状態を解消したい。
  ・移行後の保守性について、どう考えればいいか?
  ・既存バグを無くしたい。

 ユーザー負担  

  ・発注側が担当する作業を知りたい。
  ・ユーザー企業様が忙しいが、大丈夫か?

 難しい移行について  

  ・短期間で移行したいが、どうすればいいか?
  ・DBMagic、NotesのようなシステムをJavaなどに移行したい。可能でしょうか?
  ・パッケージをJavaなどに移行したい。
  ・プログラムソースがないが、どうすればいい?
  ・顧客側が考えている移行方法に準じることは可能か?

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

  ・リホストの技術が原因となる失敗を避ける方策はあるか?
  ・リホストのミドルウェアをどう選択するか?
  ・リホスト、言語バージョンアップで将来の再構築が難しくなるリスクをどう緩和するか?
  ・COBOL等古い言語が残る場合、保守性、技術者確保の問題が解決できるか?
  ・移行ベンダーの基盤依存化を避ける方法はあるか?

 その他質問  

  ・提案依頼をしたいが、今後のプロセスと依頼する側の準備作業を教えて下さい。
  ・古いコンピュータ言語はどこまで続けられそうでしょうか?
  ・ソース変換ツールはどこまで生産性を向上できるか?

 移行問題   Top
課題 : 移行のコスト感を知りたい。
  回答 : 各移行パターンのコスト感について、各種システムの移行方針・移行先の選択肢をご参照下さい。
コスト比較を含める主要移行手法のメリットとデメリットは、移行方式のパターンと特徴をご参考下さい。


課題 : 移行コストを削減したいが、どんな対策があるか?
  回答 : @棚卸・スリム化で不要資産を削減する。
A柔軟な変換ツールで言語変換を行い、低コスト体質保守性の為の手修正もちゃんと行う
Bバッチ、変更の少ない機能などを言語バージョンアップ(COBOL、PL/1等の言語のまま)で、低コストに移行
  する。
  ※オフショア保守で、COBOL等の保守を長期的に安価に実現する。
C思い切ってリホストで移行コストを抑える。※ランニングコストも考慮する必要。


課題 : 移行の工期の感触を知りたい。
  回答 : 移行設計が必要なので、小規模システムであったとしても、1〜2ヶ月以上かかる場合が多い。
    機能設計は省略するので、大規模システムであったとしても、1年程度で再構築できる場合が多くなる。


課題 : どう品質を保証するか?
  回答 : ツールによる変換だけに頼らず、比較テストを徹底的に行うので、新規開発よりも格段に品質が高い。
    比較テストしても完全にバグを取り除けないので、専門的な経験、ツールや適切なテストカバー率が求められる。


課題 : どう納期を保証するか?
  回答 : システム移行は、短納期でできると想像されがちだが、実際は、ツールの改善やシステムの性能を改善することが技術的に難しい。このことが短納期を難しくする原因だ。豊富な移行経験、無理なソース変換をしないという方針、移行先の保守性を重視するポリシーがキーポイントである。


課題 : 移行で発生する新たな性能問題を防ぐ方法は?
  回答 : ツールや手作業による変換で、移行前の処理方法に似た書き直しが行われるので、移行先で性能問題が発生する。
例えば、SQL文でRDB化されたデータを検索するような新しい方式を利用せず、ホストのファイル処理方式のままだと、新システムのデータ処理が遅くなる。
対策は、移行先の新しい仕組みに準じて移行すること。さらに、保守性を守る移行をすれば、性能問題が発生しても、スムーズに改善することができる。
性能問題の発生源や、正しい移行方針を把握するためには、豊富な移行経験が必須。


課題 : 移行を成功させるもっとも重要なPOINTは何か?
  回答 : 移行作業は高い専門性が求められます。経験豊富で、全ての開発工程に対応できて、高い技術力とパワーを持つ移行開発会社をご利用することが重要なPOINTです。また、発注側作業をきちんと対応いただくことも重要。


 業務知識に関係するテスト、機能変更、仕様書再生など  Top
課題 : ソフトロードは仕様がわからないのに棚卸・スリム化を任せることができるか?
  回答 : プログラムソースの相関関係、ログ、ソースの類似度等をツールで分析して、正味資産、不足資産、不要資産、共通化の分析を高い精度でおこないます。


課題 : ソフトロードは仕様がわからないのに、どうやってテストするのか?
  回答 : 経験豊富なソフトロードだからこそ、バグの原因を把握しているし、比較テストという厳格なテストを効率よく実施できる。必要十分なカバー率で格段に高いレベルの品質保証が可能。
※但し、脱ホストによる大規模移行で長編のシナリオでの比較ができないからといって、ユーザーによる運用テストを省略できるものではない。必要に応じて、ユーザーからの操作説明なども必要になる。また、仕様書再生を実施しているので、ある程度の業務機能を把握することができる。


課題 : ソフトロードは業務知識を持たない。どうやって機能改善するのか?
  回答 : 機能を変更する部分が全体の2、3割以内なら、再開発ではなく、移行+機能変更した方がいい。
次の理由から機能を変更することは可能である。
@ソフトロードは仕様書再生を行うことができる。
A移行が終わってから、保守会社などに改修を依頼する。
リフォームは改善(リフォーム)の為に生み出した開発方式である。
ユーザー企業は業務改善検討に時間をかけられることで、よりよい付加価値の実現が可能。


課題 : 仕様書を作りたい。
  回答 : 仕様書を再生できる会社は少ない。仕様書再生の説明をご参照下さい。

 移行の目標と出来栄え   Top
課題 : Java等他言語への移行、データ構造変更、自社のフレームワークへの移行など難しい場合、どうすればいいか?
  回答 : 通常のマイグレーション技術は移行後システムの保守性を守れない。
リライト(手で言語変換)の場合はコストが高く、品質も不安である。
まず、ツールでIF、LOOP、計算等の基本機能を自動変換し、さらに手修正で高い保守性を確保する。
比較テストはツールで行う。詳しくは、言語移行方式変換のイメージデータ構造変更をご参考下さい。


課題 : プログラムの共通化を図りたい。
  回答 : プログラムを共通化するには2つのレベルがある。
@業務機能レベルで分析し、再設計・再開発で、最大限に共通化を図る。
Aコピーして作ってきた類似プログラムを共通化分析ツールで見つけ、共通化を行う。
@ の場合、エンドユーザーから見て、費用対効果が出にくく、品質も懸念されるので、ソフトロードでは行っていない。
A の場合、ツールで高いコストパフォーマンスを出しやすい。但し、経験としてシステムによっては効果が限られる場合もある。


課題 : スパゲッティ状態を解消したい。
  回答 : 再設計・再開発によって、スパゲッティプログラムを解消したいという希望が多い。
但し、高コストの為に予算が取りにくく、現場担当は多数の具体的な箇所に対し判断がつかず、中途半端な結果になってしまうケースが多い。
スリム化、共通化、見える化、限られた箇所だけを仕様書再生してから再開発することにより、高品質・低コストのリフォーム的スパゲッティ解消をお勧めする。


課題 : 移行後の保守性について、どう考えればいいか?
  回答 : 通常のマイグレーションでは、保守性が劣化する場合が多い。特にツール変換で作成したJava等は分かりにくく、 元のCOBOL等のソースよりも保守性が格段に悪くなってしまうケースが多い。
リフォームは改善の為の再構築なので、ユーザー要望に合わせて保守性を改善できる。
例えば、エミュレーション方式移行(リホスト)の場合、きちんとミドルウェアを選べば、OPEN環境で簡単に
プログラム編集・テスト等も実施できるし、言語バージョンアップなら運用を簡単にすることもできる。また、
言語変換でJava等に変更すれば、保守性が確実によくなるDBの正規化スパゲッティ状態解消なども行える。


課題 : 既存バグを無くしたい。
  回答 : 原則として、既存を正として移行するので、既存のバグを無くすことは難しい。
ソフトロードは業務機能のテストも実施するので、ある程度の既存のバグを修正することにつながる。


 ユーザー負担   Top
課題 : 発注側が担当する作業を知りたい。
  回答 : リフォームは他の構築手法に比べ、既存機能を実現する責任を負うので、ユーザー様は作業が少なく、責任も軽い。但し、発注側には次の作業を対応いただく必要がある。
    @比較テストの為に、高いカバー率の出る本番データを提供する必要がある。
※画面系なら、操作がスムーズに行えるデータ、バッチ系なら各種類の営業日などのデータが必要。
(データマスキングする場合もある)
Aソフトロードが業務シナリオテストを実施できるようにするために、ユーザーは既存システム運用・操作方法をソフトロードに教える。(難しいホスト系画面系なら、1画面数分間程度の操作説明等)
Bユーザーは、移行設計の時に移行目標に合意して承認する。
他システムとのI/Fが変わる場合、他システム部分を設計して、修正する。
C比較テストの場合、不一致だが、よしとする場合もある。その不一致を承認する。
例:既存システムの計算精度は小数点後20桁だけど、新しいシステムは小数点後24桁になる場合。
D総合テスト(他システム連携のテスト)において、他システムでの作業を実施する。
E既存システムについてソフトロードからの質問に時々対応する必要がある。
    大規模システム移行では、運用テスト以外に、ユーザー側1〜3名の体制でご対応いただくことは一般的です。


課題 : ユーザー企業様が忙しいが、大丈夫か?
  回答 : ユーザーが忙しかったり、既存システムがブラックボックスになっているからこそ、システムリフォームが有効である。
発注側の主な作業をご確認下さい。


 難しい移行について Top
課題 : 短期間で移行したいが、どうすればいいか?
  回答 : ソフトロードが移行設計のツールをカスタマイズしたり技術検証をするので、小規模システムなら4ヶ月以上、大規模システムなら 1年以上の作業期間が必要。
既存システム状況と移行パターン、経験、ツール、移行会社の規模、これらの条件に作業期間は大きな影響をうけます。


課題 : DBMagic、NotesのようなシステムをJavaなどに移行したい。可能でしょうか。
  回答 : 可能だが、場合によっては、コストが高くなることがあるので、気軽に概算の問い合わせをして下さい


課題 : パッケージをJavaなどに移行したい。
  回答 : ソースを移行するので、ユーザーがソースの利用権利を持つ必要がある。


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


課題 : 顧客側が考えている移行方法に準じることは可能か?
  回答 : 移行は専門性がとても高いので、ソフトロードの技術や方針に準じて遂行されることをお勧めします。


 言語バージョンアップ、リホストによくある不安 Top
課題 : リホストの技術が原因となる失敗を避ける方策はあるか?
  回答 : @既存メインフレームに合う、実績の多いリホストミドルウェアを選択する。
Aソフトロードはミドルウェアメーカーと協力して問題を解決するので、2重の保険を掛ける効果につながる。


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


課題 : リホスト、言語バージョンアップで将来の再構築が難しくなるリスクをどう緩和するか?
  回答 : ・ 保守性を考慮して、移行先の言語、システム構成、データ構造、リホストならリホスト用ミドルウェアもきちんと選択する。
※柔軟に移行できるソフトロードは、きれいに変換しても、安価な場合がある。
・ 思い切って言語変換方式でJavaに移行すれば、簡単に解決すると思わない方がいい。
無理にレガシー言語をJavaにツール変換したら、保守性が極端に悪い。
ソフトロードに相談し、次回の再構築も考慮した移行方法を選ぶ。


課題 : COBOL等古い言語が残る場合、保守性、技術者確保の問題が解決できるか?
  回答 : @COBOL人口はまだそれなりに多いし、バッチデータ処理にも向いているので、必ずしも保守性が悪いとは限らない。
Aデータ構造変更等、システム心臓部を柔軟な移行によって保守性・成長性のあるシステムに移行することが大切。
※リホストの場合、データ構造変更等が難しい場合が多い。
Bオフショア保守を利用して古い言語も長く対応できる。


課題 : 移行ベンダーの基盤依存化を避ける方法はあるか?
  回答 : @基盤ソースを公開して頂き、自社内で限定した利用ができるように交渉する。
A柔軟にお客様基盤に合わせることができるソフトロードにご相談下さい。


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


課題 : 古いコンピュータ言語はどこまで続けられそうでしょうか?
  回答 : 殆どのレガシー言語がサポートされ、継続利用は可能。
例えば、世界のIT技術者の10%がCOBOLに対応できる。
但し、技術者調達、維持コスト、ハード・ソフトの保障期限、改善対応、AI・BIGDATA・クラウド化などの新しい技術導入等、いろんな要因で計画的に更新を検討した方がいい。
ソフトロードは数多くのシステム更新の検討をサポートしているので遠慮なくお問い合わせ下さい


課題 : ソース変換ツールはどこまで生産性を向上できるか?
  回答 : 言語バージョンアップエミュレーション方式(リホスト)の場合、 とても高い変換率で高い生産性を実現できるが、言語変換の場合、変換率が落ちる。
ここで、60%、70%のソース変換率でも、生産性がとても高いと思われがちだが、移行の世界では、変換率が90%(10%手で修正する)を超えない限り、高い生産性を期待できない。
例えば、変換率80%の場合、人間は2割のソースを作成することになり、他の8割自動生成されたソースを理解する必要があるし、業務機能もきちんと理解する必要があり、ソースを書く時間を省略するだけで、生産性の大きな改善は不可能である。但し、品質維持には自動変換がとても重要である。



※ 上記の質問回答は、あくまでも大きな方向性的なもので、例外もある。

   具体的な移行、既存システムに対し、気になることがあれば、問い合わせして下さい。