システムやハードウェアは長期間利用していると、動作が不安定になったり故障したりしてしまうことがあります。こうした際に必要になるのが、古いシステムを新しいシステムに置き換える「リプレース」と呼ばれる取り組みです。本記事ではこのリプレースの意味や目的、4つの移行方式などについて分かりやすく解説します。
そもそもリプレースとはどのようなことを指すのでしょうか。ここではITにおけるリプレースの意味や目的などを解説します。
リプレース（replace）とは、英語で「取り替える」や「交換する」などを意味する言葉です。ここから転じて、ITの世界においては、既存のシステムやハードウェア、ソフトウェアなどを新規のものに交換するという意味で使われます。
リプレースではなくリプレイスと表記されることもありますが、どちらも同様の意味です。
リプレースは主に、製品のパフォーマンスの向上や保守管理の簡易化などを目的に実施されます。
ハードウェアは長期間稼働していると、どうしても部品が劣化してきてしまうため、故障率の上昇が避けられません。これはシステムについても似たようなことが当てはまり、長年使用しているシステムはカスタマイズなどを繰り返すうちに内部構造が複雑になり、ブラックボックス化してしまうことがあります。
また、長年利用されている製品にはメーカーによるサポート期間の終了などのリスクもあります。メーカー保守に入ると機器の故障に対して保守対応を行ってもらえますが、メーカー保守には一定の対応期限が定められているため、それを過ぎると保守サービスが受けられません。こうした理由から、サポート期限の終了にあわせてリプレースを実施する企業も多いと考えられます。
リプレースと類似した概念として「マイグレーション（migration）」という言葉もあります。マイグレーションの元々の意味は「移行」や「移住」などですが、ITの世界ではソフトウェア・システム・データなどを新しいインフラ・プラットフォーム・OSなどへ移行することを意味します。
リプレースとマイグレーションの主な違いは、システムの変更が部分的なものに留まるか、抜本的に刷新されるかという点です。
リプレースは主に「劣化した製品を新しくする」ことを目的に実施されます。たとえば、「いま使っている機器を気に入っているけれど、調子が悪くなってきたから同一の機種に買い替える」といった事例でもリプレースに該当します。つまり、リプレースの場合は、交換先の製品・システムが必ずしも既存のもの以上の機能を持っている必要はありません。
これに対してマイグレーションは、既存のシステムをより優れた機能を持つものにアップグレードしたり、最新技術に対応したりするために実施されます。それゆえ、マイグレーションにおいては、新しいOSやプラットフォームへの移行といった根本的な変化を伴うのが特徴です。
リプレースを行う方法は4つあります。以下では、それぞれの方法の概要と、メリット・デメリットを解説します。
一括移行方式は、システム全体を一度にリプレースする方法です。この方式は比較的単純な仕方で行えるので、移行作業に必要なコストを節約するのに優れています。既存のシステム自体に何か変更を加えることはないので、何かトラブルが生じた際に簡単に元のシステムを復活できるのもメリットです。
ただし、一括移行方式では、新旧のシステムを入れ替える際にダウンタイムが発生してしまいます。特にシステムやデータが大規模な場合、その時間はより長くなるでしょう。また、一度に全て入れ替えることによって、問題が見逃されてしまい、移行後に何らかの不具合が発生する可能性が高くなります。
したがって、一括移行方式は、24時間365日稼働していなければならないシステムに対しては適していません。逆に週末は稼働を停止できたり、移行するデータが単純で小さかったりする場合は有力な選択肢になります。
段階移行方式は、データをモジュールごと、サブシステムごとなどに分割し、時間をかけて少しずつ移行する手法です。
この場合、リプレースは問題を確認・解決しながら段階的に進められるので、一括移行方式に比べて移行後のトラブル発生リスクが小さくなるのがメリットです。また、一括移行方式と違って、部分ごとにデータを移行させるので、システムを全面停止させる必要がありません。データ量も分割されるため、一度当たりのデータ移行時間も短くできます。
ただし、段階移行方式では、モジュール間の依存関係や新旧のシステムの相性を適切に把握しながら移行作業を進めなければいけないため、入念な計画が必要です。また、全体の作業量や作業回数、作業時間は一括移行方式よりも多くなります。
並行移行方式は、新しいシステムと古いシステムを一定期間同時に運用する手法です。既存のシステムは、新しいシステムが正しく機能していることが確認された後で停止されます。この方法の利点は、システムの稼働状態を中断せず、新規のシステムがその役割を完全に引き継ぐ前に、移行に伴う問題を処理できることです。
並行移行方式は、新しいシステムに問題が発生した場合に元のシステムへ簡単に戻せるため、上記の2つの方式よりリスクを低く抑えられます。ただし、一定期間は同時に2つのシステムを運用しなければならない分、作業負担や移行費用が大きくなるのが欠点です。
パイロット方式とは、影響の少ない部分、または一部の部署のみを先行してリプレースする方法です。「パイロット（pilot）」という英語には「試験的」という意味がありますが、その言葉通り、移行の影響を慎重にテストしてから全体のリプレースへとつなげられるのでリスクを抑えられます。もし試験段階で問題が発生しても、それを一種のケーススタディにできるのもメリットです。
パイロット方式のデメリットは、手間や時間がかかることです。また、いくら試験段階では問題が生じなくても、移行を全体に広げたらトラブルが発生したという場合もあるので、その点は留意しておかなくてはいけません。
続いては、リプレースの実施によって想定される課題を解説します。
リプレースを行う際の課題としては、第一に導入コストの問題が挙げられます。移行方式によって程度の差はありますが、リプレースには経済的な意味でも労力的な意味でもそれなりのコストがかかります。
また、複雑化した現行システムが把握できないなどの理由で、プロジェクトが予定通りに進まないといったことも起こりえます。通常、システムの移行は機器のメーカー保守期限のタイミングに合わせて検討されることが多いですが、このスケジュールが遅れてしまうとリプレースが完了する前にメーカー保守期限が来てしまうことになります。もし、メーカー保守期限後に現行機器の故障が起きても保守対応してもらえず、業務に大きな支障をきたす可能性もあります。
上記のように、リプレースを適切に行うのは簡単なことではありません。では、自社が期待する効果をリプレースで出すには、どのような点に注意すればいいのでしょうか。
まず大切なのが、自社の現状やリプレースに伴うリスクを正確に把握し、しっかりと計画的に事前準備を行うことです。現状を維持し続けた場合はどのような事態が生じるのか、そしてリプレースを実施した場合はどのような効果やリスクが見込まれるのか、リプレースの費用やスケジュールなども考慮しながら基本方針を立てましょう。
リプレース後に期待した通りの効果が得られるかは、要件定義をしっかり行い、リプレースを実施する業者に自社のニーズを正確に伝えられるかどうかが非常に重要です。要件定義と同時に移行前のシステムの仕様に関して両者の間で事前に合意しておくことも欠かせません。リプレースを成功させるには、クライアント側と業者側の双方がお互いに意思疎通の努力を続けることが大切になります。また、こうした事前準備を入念に行っておくことで認識違いによる修正などがなくなり、スケジュールが遅れるリスクを低減することにもつながります。
ただしそのような準備を行っても、リプレースは思うようにうまく進められないことも多いため、スケジュールに遅れが出ることもしばしばあります。
その際に困るのが、メーカーの保守期限の問題です。何らかの事情でリプレースが進められないまま保守期限がすぎてしまい、メーカーから必要なサポートを受けられなくなった場合どうすればいいのでしょうか。
こうしたときに役立つのが弊社の提供する第三者保守サービスです。SATはトラブル時の質疑応答や、故障時の部品提供、修理などのサービスを通じて、保守期限切れの機器の延命保守を行っています。
このサービスを使えば、メーカーのサポートが切れてからリプレースを行うまでの期間を補完したり、保守切れの機器とそうでない機器のリプレースの時期を調整したりすることが可能です。
リプレースを行うことで、老朽化したシステムや機器を刷新し、業務上のニーズを満たしたり、セキュリティの安全性を高めたりできます。
しかしリプレースのために事前準備を重ねても、うまく進行できずに計画が遅れてしまうことは十分に起こりえます。そこで発生するメーカーの保守期限切れの問題を解決する方法として、第三者保守を知っておけば不測の事態にも柔軟に対応できるでしょう。保守期限切れの機器を抱えることになった場合は、ぜひSATにご相談ください。