目次
マイグレーション（migration）とは？まずは意味を知ろう
リホスト・リライト・リビルド・リプラットフォームの違いとは？
マイグレーションプロジェクトは難しい
マイグレーションを迎えるために
まとめ
1.マイグレーション（migration）とは？まずは意味を知ろう
マイグレーションを学ぶ前に、まずユーザー企業が考える理想の基幹システムについて考えてみましょう。理想の基幹システムには「コストを抑え、安定した現行システムの移行に加え、新しい要件を実現できること」を求めているのではないでしょうか。つまり、現行システムの良いところを残して安定した移行を目指し、新しい要件も実現して、安く導入したいということです。
ユーザー企業がマイグレーションで要望する４つのポイント
- 現行システムの資産を活かしたい
- 安定したシステム移行
- 移行コストを抑えたい
- 新しい要件も追加し、導入メリットを増やしたい
マイグレーションは、現行システムをベースとするため、様々な制約があります。よって新しい業務要件がたくさん実現できるわけではありません。ただし、出来る限りのメリットを出していきたいのが実情です。このバランスをとるために、マイグレーションにはいくつかの手法が存在します。
ではマイグレーションにはどんな手法があるのでしょう？まずリホスト、リライト、リビルドの違いから理解してみましょう。読めば、一挙にわかりますよ！
2.リホスト・リライト・リビルド・リプラットフォームの違いとは？
マイグレーションの手法の中で、よく耳にするのが リホスト、リライト、リビルド、リプラットフォーム です。 それぞれの特徴や違いについて解説していきましょう。
リホスト
リホストは、アプリケーションやプログラムには手を加えず、 IT基盤（ハードウェアやインフラ環境）を入れ替える手法です。
機器の保守切れやスペック向上を目的として、 サーバーやストレージなどのハードウェアを新たに入れ替えるケースが該当します。
また、オンプレミス環境からクラウド環境へそのまま移行する いわゆる Lift & Shift もリホストに含まれます。
リホストのみでマイグレーションが完結するケースは少なく、 大規模マイグレーションプロジェクトの第1フェーズとして 実施されることが多いのが特徴です。
なお、よく似た言葉に「リプレイス／リプレース」がありますが、 こちらはより広義な表現であり、 リホストを指す場合もあれば、 現行アプリケーションを新規アプリケーションに入れ替える行為を指す場合もあります。
リプラットフォーム
リプラットフォームは、 アプリケーションの構造や業務ロジックは大きく変更せず、OS、ミドルウェア、データベースなどの実行基盤を新しい環境向けに最適化する手法です。
例えば、
オンプレミス環境で稼働していたシステムをクラウドへ移行する際に、ミドルウェアやDBをクラウド対応のものに置き換えたり、 構成を最適化したりするケースが該当します。
リホストよりも若干の改修が必要になりますが、その分、性能や運用性の向上、コスト最適化といった効果が期待できます。
一方で、業務要件そのものは基本的に変更しないため、 リビルドほどの自由度はありません。
リライト
リライトは、アプリケーションの機能や業務仕様はそのままに、プログラムを新しい環境や技術に合わせて書き換える手法です。
例えば、
VBで書かれた現行プログラムを、 JavaやC#などの新しい言語へ書き換えるケースが リライトに該当します。
後述する「リビルド」と比較すると、 短期間・低コストで実現可能である一方、 業務要件の大幅な変更は難しく、自由度はやや低くなります。
なお、「コンバージョン」という言葉もよく使われますが、 こちらも広義な意味を持ち、 リライトそのものを指す場合もあれば、 プログラムやデータ、ファイル形式の変換全般を指す場合もあります。
リビルド
リビルドは、現行システムを廃止し、新たにシステムを再構築する手法です。
基本的にはスクラッチ開発と同義ですが、 現行システムの資産から業務仕様を引き継いだり、データのみを移行するといったケースもあります。
要件定義から改めて実施するため、 業務要件の見直しや改善がしやすく、 自由度と将来性が最も高いアプローチと言えます。
一方で、 相応のプロジェクト期間とコストが必要になる点には注意が必要です。また、ERPパッケージシステムを新たに導入するケースも、 広義にはリビルドに含まれることがあります。
まとめ
リホスト・リプラットフォーム・リライト・リビルドは、「どこまで変更するか」 という観点で整理できます。
- リホスト：環境のみ変更（最小リスク）
- リプラットフォーム：基盤を最適化して移行
- リライト：業務を維持したまま技術刷新
- リビルド：業務・システムを全面刷新
これらの違いを理解することで、 自社に適したマイグレーション戦略を検討しやすくなります。
それでは次に、 マイグレーションを進める際の検討ポイントについて、 もう少し掘り下げて説明していきましょう。
3.マイグレーションプロジェクトは難しい
前述した「ユーザー企業がマイグレーションで要望する４つのポイント」を思い出してみましょう。リホスト、リライト、リビルド、そのどれをとっても、すべての要望を満たす手法はありません。要望のトレードオフをかけながら、どの手法を採用するか、あるいは組み合わせるかを慎重に検討する必要があります。基幹システムのマイグレーションとなれば、プロジェクトに関わるステークホルダー（利害関係者）も非常に多くなり、プロジェクト発足の難易度は大きく跳ね上がります。
また、プロジェクトを遂行する上でも様々な問題が潜みます。ここでは、よくある問題やリスクについてアプローチをしていきます。
- 現行システムの仕様や要件が不明確
レガシーシステムで見られがちな問題のひとつに、「開発設計書が揃っていない」点が挙げられます。併せて、現行システム構築に携わったメンバーも残っておらず、有識者の確保も難しいため、現行システムそのものが「ブラックボックス」化するケースがあります。現行資産の活用という観点に対して、大きく阻害する要因のひとつになります。
- コストの肥大化
プロジェクトが進むにつれ、追加要件や現行システムの改修反映といったインシデントが発生します。また、OSのアップグレードや周辺システムの仕様変更など、外的要因による対応コストの増加も考えられます。これらは、プロジェクトが長期に渡れば渡るほど、発生する可能性が高まっていくものです。
- リソース管理が難しい
大規模プロジェクトになれば、特に人的資源のコントロールには困難を極めます。人材の調達はもちろん、プロジェクトマネジャや有識者を中心とした属人化や、負担箇所の集中も起こりがちです。
上記が影響し、プロジェクトが中断、または中止するケースは多くあります。マイグレーションプロジェクトの難しさについて、理解いただけたのではないでしょうか。
4.マイグレーションを迎えるために
「現行システムを新しいシステムへ移行する」と一口で表現するのは簡単ですが、その実態はとても大変な活動です。入念な準備と計画が必要であることはもちろんですが、その中で、現行システムの仕様や業務フローを明らかにすることが大切です。これには、システムマイニングのツールを活用し、現行システムの仕様やフローを把握する方法もあります。また、特にボリュームが膨らみがちなテスト工程において、マンパワーで解決しようとしない仕組み化も併せて検討したいところです。
5.まとめ
本記事では「マイグレーションとは？リホスト、リライト、リビルド、りプラットフォームの違いと手法が一挙にわかる！」 というテーマのもと、マイグレーションの基本概念から、 各手法の特徴や違いについて解説してきました。
マイグレーションは単なるシステム移行ではなく、 業務継続・品質確保・リスク管理といった観点が強く求められる、 難度の高いプロジェクトです。 そのため、適切な手法選に加え、 移行過程における品質管理やテスト戦略が成功の鍵となります。
当社では、レガシーシステムのマイグレーションにおける課題解決を目的としたマイグレーション品質向上支援サービスをご提供しています。
システムマイニングツールを活用して 現行システムの構造や業務フローを可視化し、
リスクを把握した上でマイグレーションを推進します。 また、マイグレーション経験を有する専門メンバーが品質管理支援担当としてプロジェクトに参画し、 テスト・品質活動を強力にサポートします。
レガシーシステムの移行や刷新をご検討中の方は、 ぜひお気軽に 当社までお問い合わせください。 貴社の状況や課題に応じた最適なマイグレーション戦略をご提案いたします。
