Softroad
  • contact
  • menu
qanda移行Q&A

移行によくある誤解

システム更新に対する誤解は非常に多く、その一部の誤解を解き明かします。

【誤解その1】
移行に比べ、新規開発は使いやすく、新しい機能をきちんと取り込むシステムを構築できる。

新規開発すれば、大きい設計作業、ブラックボックス等との悪戦苦闘に陥り、利便性、業務機能改善を考える余裕が少ない。また、機能漏れ、バグなどで、長年改善してきたシステムが改悪になってしまうケースが多い。能力の高い移行会社は機能改善/追加、システム/データの構成変更を実施することができるので、高品質・低コスト・短納期のシステム更新を行い、節約したコストと時間で業務改善の課題に集中し、事業に貢献することをお勧めします。

【誤解その2】
超高速開発ツールでシステムを再構築すると、コストが低い上に保守もしやすい。

超高速開発というのは、効率の高いコーディングツールでスクラッチ開発を行うもの。製造生産性を高める上、バグを減らすことより、テスト工数もある程度減らす。但し、設計と業務機能テストの省略が不可能である。大規模開発において設計と業務機能テストが半分以上のコストを占めるので、新規の半分以下になるコストダウンは不可能。(業務をよく知っている人が仕様書を書かず、テストもそれほどしない例外もある)
移行というのは、既存システムのIF一つ、LOOP一つを全部再現する必要があり、人力でソースを詳しく理解し、高速開発ツールに正確に登録するのは工数がかかり、品質のコントロールも難しい。大規模基幹システムの移行に向かない。
また、非主流言語を保守できなくなり、主流言語に移行せざるを得ないケースはたくさん経験してきた。将来にシステム構築方法の主流として利用される超高速開発ツールでなければ、避けた方が賢明だと考える。
殆どの専門的なシステム更新は新規開発コストの1/2以下で、品質もとても高いことを踏まえ、大規模システムの移行において、超高速開発による再構築より、移行を行った方が有利である。

【誤解その3】
Javaに変えれば、半永久的に更新しなくてもいい。

どんな言語も老朽化する。
古いバージョンのJavaフレームワークは新しいOS(マシン)で動かなかったり、セキュリティ問題が出たりする。
Struts1、seasar2、WACs等の古いJavaフレームワークを沢山移行してきた。
言語・フレームワーク・ミドルウェアなどの更新頻度、保守性、移行コストなどを総合的に考慮し、移行先を検討した方がいい。
既存システムの現状を教えて頂ければ、日本一豊富な移行経験の元に、皆さんがよく利用される移行パターンを説明できる。

【誤解その4】
Java、.netなど新しい言語に移行すれば、保守性が高くなる。

移行の業界では、無理にJava等の他言語にツール変換するケースが多い。その場合、新しいソースが読みにくく、保守性が逆に悪くなってしまう。最悪、移行段階でもバグを迅速に直せず、移行自身が失敗することもある。
移行先のJava、.netの可読性、データのRDB化・正規化、お客様標準フレームワークとの統一などを考える必要がある。
既存システム状況と更新要望を教えて頂ければ、日本一豊富な移行経験の元に、皆さんがよく利用される移行パターンを説明する上に、松竹梅の選択肢をご提示します。

【誤解その5】
ツールの変換率が高いので、品質が高く納期も守りやすい。

ツールの変換率が高い場合、高度な技術で、複雑な変換ロジックが適用されるケースが多い。
解決しにくい問題が出たり、性能問題が出たりするリスクがある。
COBOLのバージョアンアップなど簡単な移行はともかく、言語変換の場合、下記のポイントは重要。

  • 無理なツール変換をしない。
  • 豊富な移行経験で問題を事前に把握する。
  • 何回も実証された移行ツールの利用。

【誤解その6】
自動変換率が高いとうたって、安く提案している会社は、技術力が高く、品質も高い。

以下のような安い理由もあるため、移行経験を確認し、慎重に選択した方がいい。

  • 無理に自動変換するので、保守性が悪く、運用保守が難しくなる。
  • 移行経験が不十分な為、問題をちゃんと把握せず、変換率を高く見積もった。
  • 1、2割しかテストしないで、その後の作業をお客様に任せる。

【誤解その7】
保守担当による移行なら安心。

移行は特殊開発だから、保守技術者に任せると、分野違いで手作業の割合はとても高くなり、品質、生産性が大幅に悪化し、納期保証も大幅に弱くなる。
小さいシステムならば、保守の空き工数で保守担当にやってもらった方がいいケースもあるが、大規模システムを専門移行会社に任せた方がいい。

【誤解その8】
これからの情報システムはなるべくパッケージを利用すべきだ。
グローバルスタンダードを導入すべきだ。

服装で例えれば、パッケージは既製品で、スクラッチ・システムリフォームは特注品。
差別化しない分野はパッケージ、差別化する分野はシステムリフォームとスクラッチ開発を利用すべきである。
また、パッケージの機能変更が難しく、将来の足かせになる可能性も高い。
グローバルの視点から言えば、日本はベトナムと同じスタンダードに準ずれば、給料も同じようにしないとダメで、差別化と成長性が日本企業の生命線。
コストの観点から見ても、基幹システムは平均的に15年間も利用されるので、パッケージの15年間のライセンス料、仕様変更の割高のランニングコストも考慮する必要がある。
よりよい日本であり続ける為に、当社はシステムリフォームという改善の手法を生み出した次第です。

CONTACT コンタクト

システム移行に関するお問い合わせは
こちらからどうぞ。