業務システムマイグレーションの難易度が高い４つの理由と対策

Pocket

私は以前社内SEとして働いていたこともあり、マイグレーションというものを何度か経験しました。その中でも、業務システムのマイグレーションというのは、非常に難易度が高く、色々考えさせられました。

今回は、業務システムのマイグレーションをどんなところに注意して行うべきかを、実体験からお話しさせていただきます。

マイグレーションとは
マイグレーションの難易度
業務システムマイグレーションの難易度が高い４つの理由と対策
まとめ

マイグレーションとは

一般的にずっと同じシステムを使い続けるというのは困難です。

ハードウエアの保守切れ/老朽化
ＯＳサポート終了
保守費用の見直し
データ量増加による圧迫
パッケージシステムの導入

などにより、サーバーやアプリケーションを乗せ換えるというのは、どの企業でも発生します。

こうした乗せ換え／移行というものを、IT分野では「マイグレーション」と呼びます。

類似用語で「リプレイス」もありますが、こちらは機械故障で同等のものに乗せ換えるなど、同じ基盤・仕組みへの移行を指すため、今回のお話しするスコープには含めていません。

マイグレーションの難易度

マイグレーションは、システムに詳しくない方からすると「現行踏襲だから設計もさほど変わらないし簡単」と思われがちなのですが、移行先によっては難易度が高くなります。

（ちなみに本記事では、「事前に全体像を把握するのが難しい」ことを、「難易度が高い」としています。工数が大規模でも、事前調査の想定通りでギャップがなければ、難易度は低いと考えています。）

ＯＳバージョンアップであれば、使用しているアプリケーションの影響調査がメインです。該当アプリケーションが次世代ＯＳに対応しているならば、難易度は低いといえます。

自社設置サーバーを別の場所のサーバーに乗せ換えたり、クラウドに乗せ換えたりするリホストであれば、通信速度想定やバックアップ手法、リカバリプラン見直し、周辺サーバー・機器とのドライバ確認など、一般的に想定できる項目でスケジュールと工数は算出できると思います。組み合わせにより時間はかかるかもしれませんが、難易度は高くないでしょう。

しかし、業務システムのマイグレーションは、仕組みがお客様独自のものであるため、簡単には全体像を把握できません。現状調査で、プログラム本数・ソースのステップ数などの規模から算出するのはとても危険です。

業務システムマイグレーションの難易度が高い４つの理由と対策

なぜ業務システムのマイグレーションが難しいのでしょうか。その理由と対策を整理していきましょう。

１．移行元と移行先のギャップを押さえなければならない

例えば、プログラミング言語が変わる場合、値の持ち方（型・桁）の影響調査が必要です。また手続き型言語からオブジェクト指向言語に変わるのであれば、設計自体の大幅な見直しを余儀なくされます。またプログラムの組み方や命名規約で一定のルールがないと、移行が煩雑になります。

始めに一通りのプログラムを解析しなければならないため、サンプルでトライアルをして、調査にかかる実際の時間を想定することが重要です。

２．業務を理解しなければならない

プログラム解析で「この経路でこう処理されて出力されている」というロジックはおおよそわかります。ただ、業務を知らない開発メンバーだと「何のためのプログラムか」「受け取る・渡すデータはどうあるべきか」がわかりません。そうすると、テスト実施時に結果が期待値と乖離していても気が付かないことになりかねません。

設計書には業務機能の記載はあれど、業務自体の説明が無い場合が多いです。該当業務はお客様独自の場合があるため、憶測せずに内容を確認しなければなりません。画面の打鍵の順序やインプットする書類の流れ、締め処理、手作りのファイルがないかなど、お客様に協力いただき整理することで「業務的な正解」が見えてきます。

なるべく早い段階で該当業務を理解できると、データやロジックの調査・分析にも役立ちます。

３．業務上ありえないテストを行う可能性がある

画面が多くあるシステムでは、すべての入力値の組み合わせをテストをすると、テストケースが何万通り、何十万通りになってしまいます。ただ、入力値の組み合わせによっては、「業務上発生しえないもの」であり、テストケースとして不適合の場合があります。このような無駄な組み合わせのテストケースをなくせば、工数の削減につながります。

このために行うのが「実データの分析」です。セキュアな業務になればなるほど、実データをお目にかかれるのは後ろの工程となってしまいがちです。それでも、メンバー限定などで権限を付与してもらい、調査フェーズでデータを解析することで、入念に行うべきテスト・無駄なテストを整理できます。

実データがわかれば、設計時点でデッドロジックに気が付くかもしれません。またお客様の業務整理を行う過程で、実装しなくてよい機能が出るかもしれません。

４．リソース規模により難易度が変わる

ハードウエアマイグレーションであれば、どれだけプログラム・データ量が多くても、移行時間が取れるか否かという運用時間調整の問題は発生すれど、難易度が大きく変わることはありません。

一方、大規模なシステムマイグレーションでは、システムのプログラムが、過去の改修の積み重ねにより、つぎはぎになってることが多々あり、全体把握が困難です。ある項目を当初の想定とは異なる用途で使用したり、退職した元担当者の応急処置ロジックが含まれていたりすることもあるでしょう。お客様側も過去の経緯がわからないため、削除を判断できない可能性もあります。こうした問題は、解析に時間がかかる要因です。

ただ、時間がかかるからといって、解析せずにそのまま実装するというのは逆効果です。正解のわからないテストを行ってしまうでしょうし、マイグレーション後の保守フェーズでも、問題は変わらず付きまといます。

お客様の協力のもと、業務の観点・実データ解析より、きれいなロジックに設計しなおし、判断がつかないものは後から削除する可能性を見据えて目印をつけ、削除の仕方を整理しましょう。これにより、第三者（担当外の人・後任など）も理解しやすくなります。