世の中ではシステム開発が進み、数多くのシステムを保守されています。
今回はそのシステムのマイグレーション（老朽更新、移行）に潜む罠についてです。
前回の開発では１億だったから、単純な老朽更新だと半分だとか、ビジネス的な投資価値はないから３分の１くらいでやって欲しいとか、そんな話は何回も耳にしたことがあります。
移行の内容にもよりますが、機器の保証期間も切れて、古いマシンでは動かせなくなるため、システムを再構築するケースでは、数多くの課題が存在することが多いので、今回はそのあたりを整理してみました。
マイグレーションプロジェクトのコストが増える理由
マイグレーションプロジェクトでコストが増える理由を書きだしました。
今回は９点、順に説明します。
１．仕様書・設計書が存在しない、あっても最新状態になっていない。
２．今動いている現行システム通りといわれる。
３．現行システムのシステムの仕様を熟知している人がいない。
４．現行システムの作りがスパゲッティだ。何をやっているかわからない。
５．移行先のプログラミング言語が、似ているようでまるで異なる。
６．移行先のプログラミング言語の仕様がかわったため、従来のプログラムコードが動かない。
７．システムまわりを、バージョンアップすると、従来利用していたソフトウェアが利用できなくなる。
８．バージョンアップにより影響する外部システムとの連携ができなくなる。
９．データの移行が単純にはできない。
１０．機能・データ以外の非機能・運用を作りこむ必要がある。
こんなに理由があります。
実際、移行を専門に実施している企業の方とも何社かと話をしたことがありますが、最初に開発したときの費用を１とすると、１．２程度は単純な移行でもかかってしまう。という話が多かったです。
依存システムが、単純にマシンの耐用年数を過ぎたための更新なので付加価値がない、などの理由からコストカットは迫られると思いますが、見積もりは慎重に行う必要があります。
コストが増える理由詳細
１．仕様書・設計書が存在しない、あっても最新状態になっていない。
「すでに動いているシステムだから、仕様検討いらないよね」
「仕様書も設計書もあるので、それを使ってもらえますから」
お客様は、まず言ってきますが、現行の調査をしてください。
仕様書があるっていわれても、７割あるけど、３割存在しないとか、一部がみつからないとかいうケースがあります。
また実際に本当に最新化されているかといえば、そういうプロジェクトの方が珍しいと思います。
仕様書通りだと思って移行をはじめても、調査してみると仕様書と動いているシステムに違いがある、
その場合は、システムが正しいはずだけど、実はバグだったなんてケースもあります。
実際にコーディングをすべてひも解いて仕様を理解するほどのコストもかけられない、でも違う部分をどうするかを決めないといけない。
お客様に理解いただけるのは大変かもしれませんが、現行調査して、新たに仕様書・設計書を作り直すタスクをいれてユーザレビュー承認を得るのがリスクのない方法になります。
２．現行システムのシステムの仕様を熟知している人がいない。
再構築、老朽更新ともなると、実際のシステム仕様の全体を理解している人が残っていないケースも多くあります。
作り直す、または新しいマシンやバージョンアップしたＯＳに乗せ換えるシステムである以上、利用している人は数多くいるのでしょうが、人は自分が使う範囲と使い方でしか理解していないものです。
全ての仕様を知っている人がいないので、質問しようと思っても確認相手がなかなかいないということが発生します。
現行システムをそのまま作り直すといっても、結局は、システム仕様をどうするか、確認の上、わからなかったら、今回の仕様はこうするということを決める必要がでてくるのです。
調査＋決定というプロセスを踏むため、工数、つまりコストがかかることになります。
３．今動いている現行システム通りといわれる。
「現行システム通りとしてください」
よく聞く話がこれです。
しかし、上で書いたように現行システムの仕様書は無いし、熟知している人もいないとなれば、現行システム保証ということばは、一言でいえてしまいますが、ものすごく重たい話になります。
「そもそも現行システムって何？」
というスコープがあいまいなのです。
なので、現行システム通りを要求された場合は、現行システムの仕様書を要求もとのお客様に提示してもらうことです。
システム側はそれをもとに開発するというのが、セオリーです。
無い場合には、発注元の責任で作成してもらうことになります。
開発とは別契約で現行調査、仕様作成を行うこともよくやりました。
４．移行先のプログラミング言語の仕様がかわったため、従来のプログラムコードが動かない。動作が異なる。
これはよくあります。
Ｃ言語で作られていたからそのままで動くはず、と思っていたらどうしても動作しない。しかも、この場合、以前動いていたのがやっかいで、動作しない理由の解明が困難だったりします。
変数の初期化が従来はゼロで埋められていたのが、なくなったために暴走してとまらないとか、処理が落ちるとか、はよく聞く話です。
画面や操作性については、さらに多くあって、画面がすべての画面の一番前にでてくる仕様だったのに前にでてこなくなったとか、カーソルの動く順番がかわったとか、画面やフォントが崩れるとか、エラーになるのであればわかるのですが、エラーにならずに動作が変わってしまうのは、困ります。
これも、事前にバージョンの違いによる差を洗い出して、影響範囲に対して対応していくことが必要になり、単純に動作する、というわけにはいかないことが多々発生します。
５．移行先のプログラミング言語が、似ているようでまるで異なる。
これは、システムに対してあまり詳しくないお客様の誤解から規模の合意調整が難航する場合があります。
「VisualBasicで開発していた仕組みを、.NETのVisualBasicに移行したいのですが、.NETでもVBだから一緒ですよね。
プログラムは右から左に移すだけだと思いますので、その前提でお見積りください」
従来のＶＢから、ＶＢ.ＮＥＴは、かなりバージョンアップされており、一部の構文を除き互換性はありません。
作り直すと思ってもらった方がいいと思います。
.NET専門で移行している会社の方の話では、単純移行でも通常のケースでは新規開発相当はかかるとのことでした。
「C＋＋で開発されたものを、同じCですが、.NETのC#への移行お願いします。同じＣ言語ですよね、格安でお願いします」
C++から.NET C#も違う言語ですね。
むしろ、何も触りたくないのであれば、.NET C++への移行が選択肢になると思います。
こちらは、VBほどの違いはありませんが、それでも変更ははいってますので、検証は慎重にする必要があります。
「ストアドプロシージャをOracleから、SQLPlusに移行したいのですが、SQLは標準化されてるから一緒ですよね」
ＳＱＬ文は方言だらけですし、ストアドプロシージャに関しては、完全に別言語になります。
そもそも、データベースそのものが、インデックスの使い方とか構造とかの違いで、従来３秒のものが、３時間以上処理時間がかかったり等、何が発生するかわかりません。
「Javaで開発したものを、JavaScriptに移行したいのですが、Javaなので簡単ですよね」
全く別物で、そもそもこのケースだと、何をつくるのかにはよりますが、言語選定が間違っていると思われます。
移行時の開発言語選定は慎重に行う必要があります。
６．現行システムの作りがスパゲッティだ。何をやっているかわからない。
上で、開発言語の選定は慎重にと書きましたが、実際に単純にそのままの言語では動かない（VisualBasicのように後継に言語しかない）ケースは、ある程度の置き換えが必要になります。
でも、動いているかもしれないものの、とてもではないけれど何をやっているかわからないソースコードなんて、世の中に山のようにころがっています。
仕様もプログラムもわからない場合は、調査、仕様確認、仕様決定、再設計、実装、テストと新規開発＋調査という進め方になるので、やはり工数がかかってしまうということです。
７．システムまわりを、バージョンアップすると、従来利用していたソフトウェアが利用できなくなる。
バージョンアップの影響は、単に開発用のプログラミング言語に限りません。
周辺で利用していた、通信用のソフト、印刷用のソフトがＯＳバージョンアップで利用できなくなったとか、そちらのソフトもバージョンアップするのだけれど、機能が変更になっていてプログラムから利用するには作り直しが必要だとか、大きな影響になることもあります。
周辺ソフト・利用ソフトは調査しておく必要があります。
８．バージョンアップにより影響する外部システムとの連携ができなくなる。
バージョンアップは、請け負った対象となる範囲だけの影響ですまない場合があります。
外部に連携しているシステムが利用しているソフトとの互換性が崩れてつながらなくなるとかも発生しうるので、事前調査が重要になります。
９．データの移行が単純にはできない。
既存システムのマイグレーションの場合は、プログラムの移植だけではありません。
既につかわれているデータが存在するわけで、その移植も必要になります。
データの移行は工数も時間もかかるし、業務がうらで実行されているときに移行するのであれば、更新データをどのように取り込むか等、考慮すべき点も数多くあります。
マイグレーションのときは、データ移行はしっかり見積もりましょう。
１０．機能・データ以外の非機能・運用を作りこむ必要がある。
マイグレーションは、システムの機能やデータだけを移し替えればよいわけではありません。
非機能、ようするに性能面、運用面もかかわってきます。
移し替えたはいいけれど、性能がでない。
運用ができないでは、実際の業務に影響します。
また、移行もあるタイミングを境に一気に切り替えるのか、それとも並行期間をもうけるのかで体制などもかわってきます。
非機能・運用の実現にもコスト増になる原因が存在します。
以上、今回はマイグレーションでコストが増える理由をまとめました。
最後までお読みいただきありがとうございました。
このブログでは、実際の自分の経験も元に、プロジェクトマネジメントやＩＴ最新技術などの発信をおこなっております。
変化の激しいＩＴ業界は、日々話題もつきません。
継続して発信予定ですので、今後ともよろしくお願いします。
