リプレース
日本語 | 交代 |
英語 | replace |
ふりがな | りぷれーす |
フリガナ | リプレース |
旧システムを新システムに移行すること。
「旧システム」とはその名の通り数年年~数十年ほど前に作られたシステムのことである。
主にクライアントサーバーシステムであり、クライアントはVisual BasicやVisual C++によって作製され、サーバーはWindows NTやバージョンのUNIX系OS、もしくは汎用機であり、Windows系であればサーバーにIISを使用しASPによって実装され、UNIX系もしくは汎用機であればC言語等によって実装されている。
それに対し「新システム」は、主にWebアプリケーションであり、クライアントはInternet Explorerを用い、サーバーはWindows 2003 ServerもしくはLinuxであり、Javaを用いたサーブレットや、.Netによって実装される。
リプレースは、旧システムのサーバーの、ハードウェアもしくはソフトウェア的なサポート期限切れ、もしくはハードウェアのリリース期間終了等によって行われる。
新システムは多くの場合Webアプリケーションとなる。これは、クライアント用アプリケーションを新規に作成する必要がなく、クライアントのインストール及びバージョンアップが容易であり、Linux等を使用することで安価に行える、といったメリットがあるためである。単に流行である、という理由も捨てがたい。
リプレースは「旧システムが存在する」という理由から、容易であると思われやすい。
だが、現実は真逆である。
旧システムはJava言語以外で書かれており、これをJava言語へと移植するのは思いの外難しい。言語の「思想の違い」から単純な置き換えは不可能であり、プログラマーは両言語の知識が必要となる。
旧システムをそのままJavaに変換すればいい、という誤った考えにより、再設計の必要がないと判断され、概要設計及び詳細設計のフェーズが省かれ、この工数削減による値引きを営業が勝手に行う場合がある。その場合、工数は異常に短くなる。
旧システムは昔に作られているため、ドキュメントが存在しない場合が多い。旧システムを作製した者がいなかったり連絡が取れないことも多く、情報は「今目の前にあるプログラム」だけである。そのプログラムもいわゆる「スパゲッティプログラム」となっており複雑怪奇な場合も多い。
新システムへの移行は一部のみという場合も多く、特に情報を管理するデータベースサーバーは旧システムのまま、ということもある。その場合、旧システム向けに設計されたテーブルを対象とすることになり、またイレギュラーなデータが大量に存在するためその解析が必要になることもある。
クライアントはInternet Explorerを用いるため、旧システムのVisual Basicによるクライアントアプリケーションに比べて「可能なこと」が少なくなる。特にエンドユーザーが触れる部分のため、多くの場合「バージョンダウンした」と感じられてしまう。これはサーバーにも当てはまり、Java特有の性能的限界により処理が重くなり、これも「バージョンダウンした」と感じられる要因となる。
こういったデメリットのカバーを行うため、無償の「改修」や「バージョンアップ」を求められる場合も多い。「旧システムをそのままリプレースする」という要件において、旧システムに明かなバグが見つかった場合、それを治すべきか、といった問題が発生することもある。
リプレースは、容易どころか最悪である。リプレースを行うプロジェクトには、阿鼻叫喚の地獄絵図が待っている。
だが、リプレースは全てのシステムにおいて必ず発生するものであり、大企業がその「旧システム」のプロジェクトに関わっている場合には、必ずリプレースの案件も受注できるため、安定して受注できる数少ないプロジェクトである。少なくとも、新規顧客の開拓を行うよりはずっと簡単に受注できる。
そのため、リプレースのプロジェクトは決して減らず、残念ながら回避は不可能である。
「旧システム」とはその名の通り数年年~数十年ほど前に作られたシステムのことである。
主にクライアントサーバーシステムであり、クライアントはVisual BasicやVisual C++によって作製され、サーバーはWindows NTやバージョンのUNIX系OS、もしくは汎用機であり、Windows系であればサーバーにIISを使用しASPによって実装され、UNIX系もしくは汎用機であればC言語等によって実装されている。
それに対し「新システム」は、主にWebアプリケーションであり、クライアントはInternet Explorerを用い、サーバーはWindows 2003 ServerもしくはLinuxであり、Javaを用いたサーブレットや、.Netによって実装される。
リプレースは、旧システムのサーバーの、ハードウェアもしくはソフトウェア的なサポート期限切れ、もしくはハードウェアのリリース期間終了等によって行われる。
新システムは多くの場合Webアプリケーションとなる。これは、クライアント用アプリケーションを新規に作成する必要がなく、クライアントのインストール及びバージョンアップが容易であり、Linux等を使用することで安価に行える、といったメリットがあるためである。単に流行である、という理由も捨てがたい。
リプレースは「旧システムが存在する」という理由から、容易であると思われやすい。
だが、現実は真逆である。
旧システムはJava言語以外で書かれており、これをJava言語へと移植するのは思いの外難しい。言語の「思想の違い」から単純な置き換えは不可能であり、プログラマーは両言語の知識が必要となる。
旧システムをそのままJavaに変換すればいい、という誤った考えにより、再設計の必要がないと判断され、概要設計及び詳細設計のフェーズが省かれ、この工数削減による値引きを営業が勝手に行う場合がある。その場合、工数は異常に短くなる。
旧システムは昔に作られているため、ドキュメントが存在しない場合が多い。旧システムを作製した者がいなかったり連絡が取れないことも多く、情報は「今目の前にあるプログラム」だけである。そのプログラムもいわゆる「スパゲッティプログラム」となっており複雑怪奇な場合も多い。
新システムへの移行は一部のみという場合も多く、特に情報を管理するデータベースサーバーは旧システムのまま、ということもある。その場合、旧システム向けに設計されたテーブルを対象とすることになり、またイレギュラーなデータが大量に存在するためその解析が必要になることもある。
クライアントはInternet Explorerを用いるため、旧システムのVisual Basicによるクライアントアプリケーションに比べて「可能なこと」が少なくなる。特にエンドユーザーが触れる部分のため、多くの場合「バージョンダウンした」と感じられてしまう。これはサーバーにも当てはまり、Java特有の性能的限界により処理が重くなり、これも「バージョンダウンした」と感じられる要因となる。
こういったデメリットのカバーを行うため、無償の「改修」や「バージョンアップ」を求められる場合も多い。「旧システムをそのままリプレースする」という要件において、旧システムに明かなバグが見つかった場合、それを治すべきか、といった問題が発生することもある。
リプレースは、容易どころか最悪である。リプレースを行うプロジェクトには、阿鼻叫喚の地獄絵図が待っている。
だが、リプレースは全てのシステムにおいて必ず発生するものであり、大企業がその「旧システム」のプロジェクトに関わっている場合には、必ずリプレースの案件も受注できるため、安定して受注できる数少ないプロジェクトである。少なくとも、新規顧客の開拓を行うよりはずっと簡単に受注できる。
そのため、リプレースのプロジェクトは決して減らず、残念ながら回避は不可能である。
参考サイト
- (参考サイトはありません)
「……ずいぶん悪意の隠った説明だこと」
「悪意というより呪いだな」
「そういえば、去年やったプロジェクトは最終的に約4名の呪いが」
「具体的呪い言うなー!!」
「……約?」
「たぶん樹海にでも」
「黙れ言うなすみませんおねがいします」
「悪意というより呪いだな」
「そういえば、去年やったプロジェクトは最終的に約4名の呪いが」
「具体的呪い言うなー!!」
「……約?」
「たぶん樹海にでも」
「黙れ言うなすみませんおねがいします」
「……ずいぶん悪意の隠った説明だこと」 「悪意というより呪いだな」 「そういえば、去年やったプロジェクトは最終的に約4名の呪いが」 「具体的呪い言うなー!!」 「……約?」 「たぶん樹海にでも」 「黙れ言うなすみませんおねがいします」