レガシーマイグレーションという名のシステム移行はデスマーチになりやすい

2005年の古い記事だが、レガシーマイグレーションという名のシステム移行に関して、概念が良くまとまっているのでメモ。

【元ネタ】
ITレポート（動向／解説） - 失敗しないレガシー・マイグレーション（1）：ITpro

ITレポート（動向／解説） - 失敗しないレガシー・マイグレーション（2）：ITpro

【1】レガシー・マイグレーションとは一言で言えば、旧式（レガシー）のシステムを新しいシステムに移行すること。
メインフレーム上のCobolシステムをオープン系のWebシステムに変えたい、VBとSQLServerのクラサバをJavaやPHPのWebシステムに変えたい、とか。
レガシーマイグレーションを実施したい理由は、いくつかあるだろう。
保守費用が高い割には、業務ロジックのカスタマイズが追いつかず、既存の業務に影響を与えていること。
あるいは、長年の手パッチによる修正によって、保守性や移植性の品質が劣化してしまい、機能追加や障害修正に手間取っていること。
あるいは、Cobol開発者が減ってしまい、システムを修正する要員を確保しにくくなっていること。

だから、一気にシステムを変えようとする。
いわゆるシステムリプレース案件は、受託システム開発では結構多い。
そして、たいていの案件はデスマーチになりやすい。
その理由は、下記に書いた。

システムのリプレース案件が最も危険な理由: プログラマの思索

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

ERPの落とし穴part5～システム移行という名のデスマーチ: プログラマの思索

【2】レガシーマイグレーションの手法は上記の記事によれば4つある。

(1)リビルド
ビジネスロジックのレベルからシステムを見直し、根本的にシステムを作り変える方式。
別名は、リエンジニアリング。
つまり、一からのシステム再構築と同じ。
よくある例は、ERPパッケージの新規導入。

利点は、新技術を使えるので、最適なシステムを構築できること。
弱点は、現行のシステムをスクラップ＆ビルドするための時間やコストがかなりかかること。
デスマーチプロジェクトの典型的なパターン。

ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索

(2)リライト
ビジネスロジックはそのまま維持し、プログラムコードだけをJavaやC言語など新しい言語で書き直す方式。
いわゆるリプレース案件で結構多いパターン。

利点は、プログラム設計やデータ設計が明確になるので、機能追加・修正の効率化や品質向上を期待できる。
弱点は、新しいプログラミング言語で書き直すための時間やコストが結局かかること。

また、ユーザもバグありのシステムで業務を運用していたので、安易にバグを修正してしまうと、今までの業務フローが変わってしまうために、マニュアル修正やユーザ教育などの手間がかかる。
普通は、純粋なリライトはあまりなく、部分的に機能を追加したり、機能を修正したりするから、ユーザと要件を事前に詰めておかないと、リリース後に痛い目にあう。

システムのリプレース案件が最も危険な理由: プログラマの思索

(3)ラッピング
メインフレームなどの旧システムをオブジェクトと見なして外部システムからアクセスできるように、外部接続やWebサービス等のミドルウェアを用いてメインフレームを「ラップ」する方式。
いわゆるシステム間連携、外部接続を使って、旧システムと新システムとの間でデータのやり取りを実現する方式。

利点は、メインフレーム本体やメインフレーム上のアプリケーション、データベースがそのまま残るので、今までの資産(アプリケーション、データ)を流用できること。
弱点は、旧システムは残したままなので、運用コストの削減にはつながらないこと。

よくある例は、旧システムからの外部接続方式で、オンライン連携にするか、バッチ処理による非同期連携にするか、で大きく変わる。
RPCによるオンライン連携ならば、SOAPやRESTを使う。
バッチ連携なら、EDI方式が多いだろう。
例えば、FTPによるファイル連携、あるいは、HULFTによるファイル連携などの実現方法がある。

もし潤沢な予算があるならば、EAIツールのようなミドルウェアを使って、スクラッチ開発を回避する手法もある。

ERPの落とし穴part3～外部システム連携がプロジェクトのボトルネック: プログラマの思索

HULFTって何？: プログラマの思索

外部接続による実現方式は、実装コストも少なく、既存のシステムを連携するためにリビルドやリライトの方式に比べてリスクは少ないゆえに、予算が限られているプロジェクトではよく使われる。
しかし、外部接続に関するテストの工数は意外に増えやすいし、方式設計(アーキテクチャ設計)で漏れがあったり間違いがあると後で痛い目に合う。
だから、事前にアーキテクチャ設計の段階で、SOAP・EDI・EAIの各方式の利点と弱点を把握しておき、新旧システムと業務のフィットギャップ分析を十分にやっておくのが重要。

(4)リホスト
ハードウェアのみ移行して既存の業務アプリケーションを仮想的に動作させる方式。
例えば、Cobol資産はそのままでハードウェアのみ性能アップしたサーバーへ交換する、とか、JDK1.4のプログラムとOracle8iのデータベースは同じだが、性能が良いサーバーへ移行するときに、JDK7とOracle11gで動かすようにする、とか。

利点は、比較的短期間でシステムを移行できること。
弱点は、例えば、メインフレーム環境とオープン環境では、開発言語が同じでもソースコードは一般的にそのまま利用できるものではなく、環境に応じた修正が必要になること。
つまり、ソースコードは同じでもリコンパイルは必要になる。
だから、プログラム修正のコストはなくても、既存の機能が依然と同様に動くことを確認する回帰テストの工数はかかる。
この回帰テストを実施してみると、実はミドルウェア(JDK、Oracleなど)のバージョンアップのためにプログラム修正が必要になることが分かったりする。

また、メインフレームのような旧システムのアプリケーション資産をそのまま移行してしまうため、既存資産の悪い部分(スパゲティ状態)が残ってしまうこと。
保守性や移植性が悪いままシステムを引き継ぐため、運用保守のコストは改善されない可能性がある。

【3】レガシーマイグレーションやシステムリプレース、システム移行などの開発案件は、ユーザ企業にとって新しい価値を生み出すようなものではなく、既存の業務を維持するためのものと言える。
ビジネス上は全く価値がないのと同じだ。
だから、失敗しなくて当然と思われているが、実際のプロジェクトではデスマーチになりやすい。

その根本原因は、回帰テストを保証する開発インフラがそろっていないからだと思う。
リビルド・リライト・ラッピング・リホストのいずれの方式にしても、既存の機能がデグレしていないことを保証する回帰テストの工数は結構大きい。

しかし、古いシステムほどドキュメントが欠落したり紛失したりするから、本来の仕様を探ることが難しい。
過去のテスト仕様書すらない場合もある。
だから、バグありの現行システムと移行後の新システムの機能を単純に差分比較してテストする場合が多い。
このような単純なテストは手作業が多く、工数もかかるし、仕様の不明点もたくさん出やすい。

回帰テストを自動化できるインフラがあれば、テスト工数を減らせるだけでなく、テスト結果を何度も再現できるから、システムの品質も良くなる。
開発者もプログラム修正に自信を持って行える。

XPが指摘したTDD＋CIのプラクティスは、こういうシステム移行のような詰まらない案件で大きな威力を発揮するのだと思う。

【追記】リビルド・リライト・リホストに関する別の記事を見つけたのでリンクしておく。
説明は分かりやすい。

マイグレーションサービスの内容 | マイグレーション～システム移行の基本

リビルド手法・リライト手法 | マイグレーション～システム移行の基本

リホスト手法 | マイグレーション～システム移行の基本