システムリプレイスとは。目的や進め方、失敗しないためのポイントを解説

システムリプレイスとは

システムリプレイスとは「システムを新たなものに置き換える、作り替える」という意味です。システムリプレースと表現する場合もありますが、同じ意味を表します。リプレイス、リプレースともに語源は英語の「replace（取り替える）」です。ここからは、さらに詳しくシステムリプレイスについて解説していきます。システムリプレイスを行い、生産性向上を実現したいという方は、こちらから生産性向上BOOKをダウンロードなさってください。

リプレイスとマイグレーションの違い

システムリプレイスと似た言葉で、「マイグレーション」があります。

マイグレーションは環境（プラットフォームOS、開発言語）を変更して同じシステムをそのまま利用することです。「古いプラットフォームやOSのサポートが切れ、セキュリティ上のリスクが顕在化する」「古いシステムを保守運用するためのコストが肥大化する」などの課題に直面したときに必要になります。

一方、リプレイスはまったく別のシステムに入れ替えることです。

システムリプレイスの目的

システムリプレイスの目的は主に3つ存在します。

1. ビッグデータ、IoT、AI、Fintechなど、最新トレンドへの対応
2. 社内で利用している基幹系システムの老朽化への対応
3. 現行システムに精通した技術者減少への対応

それぞれ、新たなビジネスチャンスの獲得を目指す「攻めの投資」、現状の問題や不具合の解消に対応する「守りの投資」の2種類の目的に分けられます。

仮に不具合が発生していなくても、時間の経過と共に、システムは下記の劣化が発生していますので、注意が必要です。

• 処理するデータ量の増加によりスペックが追い付かなくなり、動作が重くなる
• 最新のソフトウェアやアップデートに対応ができなくなる
• セキュリティ対策が陳腐化し、日々進化するウイルスの脅威に耐え切れなくなる
• システム構成が複雑化し、ランニングコストがかかりすぎる
• 業種・業態の変化にシステムが対応できず、運用の手間が発生する

システムリプレイスの実施時期

システムリプレイスを行う期間は明確な基準が定められておらず、いつ実施しても特に問題ありません。一方で、何らかの基準がないと、いつシステムリプレイスすればよいのかの判断が付きにくいかと思います。

基準の一つとして、システムの入れ替えは5年以内を目安に行うことが一般的です。なぜならば、国税庁が定めるソフトウェアの耐用年数（*1)は5年だからです。

また、会社の運用に合わない場合や社員の不満が高まっている場合は、早期に見直す必要があるため、日常的に現場へのヒアリングを行うといいでしょう。

システムリプレイスの進め方

システムリプレイスの具体的な進め方についてご紹介します。

プロジェクトチームの発足

システムリプレイスの際はシステムを管轄する情報システム部門だけでなく、実際にシステムを利用している部門の参画が必要です。

あらかじめシステムリプレイスを実現するためのプロジェクト計画を策定しておくと実現性が高まります。チーム内では、少なくとも以下の役割を担う人や部門を決めておくといいでしょう。

• 予算を確保する人・部門
• システムをどのように入れ替えるかを技術的に検討する人・部門
• どのように利用者にシステムを使ってもらうかを判断する人・部門
• プロジェクトを取りまとめる人・部門

要件の洗い出し

プロジェクトチームが発足し、参画メンバーが決まり次第、要件を洗い出しましょう。まずは、既存システムで「達成できていること」、「達成できていないこと」を明らかにします。そうすることにより、「どのようにシステムを構築すべきか」が見えてきます。 システムを構築する前に要件を明らかにしておかなければ、利用者の不満につながる恐れがあります。最悪、必要な機能が不足しており、業務が成り立たないといったケースも存在します。

移行計画の策定

要件をまとめたら、システムリプレイスを実現するまでの移行計画を作成します。スケジュールだけでなく、移行するデータの範囲や機能を決めておく必要があります。計画があいまいだと、予算不足やスケジュール遅延、他部門との認識齟齬が生じる可能性が高いです。

一方で、この時点ではシステムリプレイスにどれだけの費用がかかるのか判断が付きにくいと思います。そのような状態を打開するためには、複数のシステム開発会社に問い合わせて概算の見積もりを出すといいでしょう。

プロジェクト予算の確保

プロジェクトの計画や予算計画など社内のプロセスに準じた形で予算を確保してください。

システム開発・準備

システム開発の方法はいくつかありますが、主に以下の工程があります。

• 要件定義
• 設計
• プログラミング
• テスト

要件定義とは、システム開発会社がシステムを開発する目的を明確にし、その目的を実現するために必要な機能や性能を明らかにする作業です。要件定義で実施すべき作業と構築物が明らかになった後は、システムの設計とプログラミングを行います。プログラミング後は、プログラムが想定どおり動くかどうかのテストを実施します。

移行のリハーサル

システム移行は予期せぬトラブルが発生する恐れがあるため、リハーサルの実施が欠かせません。リハーサル中に発見した問題は、移行までに解決しましょう。前もって問題に対処しておくことで、実際の移行作業や移行後の業務をスムーズに行うことができます。

移行の実施

リハーサルが無事に完了したら、実際の移行作業に移ります。移行元と移行先のシステムでデータの整合性が取れているかは必ず確認するようにします。

システムリプレイスの4つの方式

システムリプレイスには4つの方法があります。それぞれのメリットとデメリットは以下のとおりです。

一括移行（一斉移行）方式

現行システムを停止して移行作業を行い、移行完了後に新システムの稼働を開始する方式です。システムの停止が発生するため、通常は週末や連休などを利用して行うことが多いです。移行にかかる時間や負荷が少なく済みますが、システム全体を一度に入れ替えるため、データの移行に失敗してトラブルが発生した場合、トラブルの影響範囲が大きいという特長があります。

段階移行方式

ひとかたまりの業務単位、または拠点単位などに分けて次第に移行する方式です。一度に長期間のシステム停止が許されないケースや、一括移行方式のリスクを負えない場合は段階移行方式を採用することが望ましいです。移行失敗時の影響範囲が少ない一方で、数回に分けて移行を行うため、全ての作業が完了するまでに時間を要します。

順次移行方式

現行システムと新システムを同時並行で稼働させ，結果を比較検証しながら移行する方式です。サービス開始後、しばらくは現行システムと新システムを二重で稼働させ、新システムの動作が保障されたタイミングで移行します。 利点はシステムを停止することなく切り替えられることです。欠点は新旧2つのシステムを運用する手間とランニングコストがかかってしまうことです。

パイロット移行方式

社内の特定の部門（パイロット部門）で新システムへの移行を先行して実施する方式です。先行移行で発生する問題点の把握や移行のノウハウを取得します。パイロット部門での運用が安定した後、蓄積したノウハウを用いて他部門への展開を行います。移行開始から完了までのリードタイムがかかることがデメリットです。

失敗しないための3つのポイント

システムリプレイスのニーズは多い一方で、失敗するケースも多いです。具体的には、開発の初期コストやランニングコストの増加、移行がうまくいかずサービス開始時期が遅延する、などといったケースが存在します。そこでシステムリプレイスに失敗しないためのポイントを3点紹介します。

①企画・要件定義フェーズを軽視しない

システムリプレイスは新規構築よりも難易度が高いとされており、企画・要件定義といった上流工程での課題認識が浅いと、後工程で問題が表面化します。例えば、要件定義にて「現行踏襲」というあいまいな仕様で進めてしまうと、次第に仕様の抜け漏れが判明します。そのような状態では、リプレイス時期の遅延や稼働後のトラブルが発生し、ビジネスの機会損失につながってしまう恐れがあります。

また、担当者だけでなく経営層もシステムリプレイスの難しさを認識する必要があります。経営層にシステムリプレイスの難しさが理解されていないがために、十分な予算や期間を確保できないという事態に陥ってしまったら、そもそもシステムリプレイスが始められません。

企画・要件定義を適切に行うために実施すべきことは以下の3点です。

• 現状分析を踏まえた検討を行い、再構築の課題を出し尽くす
• 新システムにおいて、必要な機能が過不足なく備わっているかをチェックする
• システムリプレイスにおける課題と対応策を経営層に共有する。経営層は課題を認識したうえで投資判断を行う

②システム利用部門は上流工程から参加する

実際にシステムを業務で利用している部門のメンバーを上流工程から参加させることで、システムの使い勝手に関する課題を早期に解決することが重要です。

例えば、システム化されていない業務が手作業で補完されており、設計書などのドキュメントに反映されていない場合があります。その状態でシステムを再構築してしまうと、業務に必要な機能が抜けたままになります。

③「品質保証方針」「業務継続性」を明確にする

上流工程の段階で「品質保証方針」「業務継続性」を明確にすることも重要です。「品質保証方針」はどのような設計・製造・テストを行うことでシステムの品質を担保していくのかを示したもので、システム部門だけでなく利用部門、経営層と合意する必要があります。

システムリプレイスは本稼働時に既存業務の継続性を担保することが求められます。システムテスト時、運用テスト時、本稼働後、それぞれのリスク対応を明確にすることにより「業務継続性」を明らかにしましょう。

システムリプレイスのリスクを甘く見てはいけない

システムリプレイスのリスクを経営層やシステム利用部門に共有せず、対応方針を明確にしないまま進めてしまうと、後工程でリリース時期の遅延や開発コストの増加などといったリスクが顕在化してしまいます。 システム部門、利用部門、システム開発会社でリプレイスのリスクを洗い出し、その予防策・対応策を明らかにすることが重要です。そうすることで、あらかじめ計画したスケジュールやコストに沿った形でシステムリプレイスを推進することが容易になります。

まとめ

システムを新たなものに置き換える、作り替えるという意味のシステムリプレイス。新規のシステム構築よりも難易度が高く、コストの増加やスケジュールの遅延などといったリスクがあります。

システムリプレイスには主に4つの方法があるので、現行業務の規模や状況に応じて選択してください。基本的な進め方はどれも共通しており、まず関係部門に声をかけてプロジェクトチームを発足させ、移行計画を策定します。移行作業前は本番を想定した念入りなリハーサルが大切です。

また、システムリプレイスのリスクを軽視せず、上流工程で関係部門が積極的に参画することも重要です。システム開発会社を含めてリプレイスのリスクを洗い出し、予防策を明らかにして実施しましょう。

参考

*1:ソフトウエアの取得価額と耐用年数