システムリプレイスの目的と進め方を詳しく解説

システムリプレイスは、古くから使い続けてきたシステムを新しく作り替えることです。

一般的に昔から使われてきたシステムは、現在はあまり知られていないOS（例：UNIX）やプラットフォーム（例：PDP-11）が使用されている場合があります。IT技術を利用しAIとの連携を行うようなことができない場合が多いです。
また、最も古いものでは、社外とのアクセスを許していない場合もあります。

そこで、昔から使われてきたシステムを最新技術を利用した新しいシステムに作り替える必要性がでてきました。

本記事では、システムリプレイスを行う目的を紹介します。
目的を明確にしたあとで、システムリプレイスを行うための4つの方式と、実際に導入するための7つの進め方について詳しく解説します。

システムリプレイスとは

システムリプレイスとは、昔から使われているシステムにIT技術やAI連携のようなトレンドな仕組みを利用しシステム全体を作り替えることです。
場合によっては、緊急性や費用を考慮し一部分だけ作り替えることもあります。

システムリプレイスのことを「システムリプレース」と表現している場合があり、意味は同じです。リプレイス、リプレース共に語源は、英語の「replace（取り替える・交換する）」です。

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

マイグレーションは、システムを作り替えるのではなく、OSや処理言語などの環境を変更するということです。

一般的に環境を変更するだけで、新たに機能を追加することはしません。

例えば、オンプレミス環境で稼働している社内システムをデータセンターのクラウド環境に移すことを指すことがあります。そのほかに、古い開発言語で作られているソフトウェアを現代的な開発言語へ変更する場合があります。

システムリプレイスの場合も同じように環境を変更しますが、さらに不足している機能があれば追加します。また、今後の事業拡大を想定し新しい機能を追加して作り替えます。

「攻め」と「守り」に分かれる

システムリプレイスは、「攻め」と「守り」に分かれます。

「攻め」とは、業務の見直しや今後の事業拡大を想定して現行業務に新しい機能を追加して作り替えることです。

たとえば、AIやIoT・社員のテレワークなど、最新のテクノロジーを使用するための作り替えです。

「守り」とは、このまま利用し続けると老朽化により、ソフトウェア・ハードウェアの保守ができなくなり、事業継続が難しくなる場合です。また、担当する技術者が少なくなり保守ができなくなるリスクを軽減するために作り替えることです。

たとえば、システムの老朽化に対しては、ハード面では、新しいハードに入れ替えたり、ソフト面では、古い言語で開発されたものを、現代的な開発言語に作り替えることが挙げられます。

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

システムリプレイスを行う目的は、次の3つが考えられます。

1. 最新技術への対応
2. 老朽化への対応
3. 技術者減少への対応

順番に解説していきます。

目的①最新技術への対応

ITを活用した事業やAIを利用した業務・社員のテレワーク勤務など、トレンドな技術を利用した経営を行うことが求められています。

たとえば、新しいシステムでは、AIを利用し業務の効率化が行えます。また、テレワークを取り入れることによりワークライフバランスを実現できます。その結果、離職率が低くなり生産性の向上につながります。

目的②老朽化への対応

事業を継続するためには、古くなったシステムを保守運用できるように、ハードウェアを最新にすることが求められています。

突然ハードウェアの故障が発生するかもしれません。また、それが頻発する可能性もあります。

たとえば、修理したくてもハードウェアの保守切れのため、修理対象部品がない場合があります。その場合は、修理ができません。

修理できない状態にならないように、システムリプレイスを行います。

目的③技術者減少への対応

古くなったシステムは、10年以上前に開発されたものが多く、当時のことがわかる技術者が年々少なくなってきています。

自社開発した機能は、担当社員の退職に伴って処理がブラックボックス化する場合があります。また、古い言語で開発されている場合が多く、技術者の退職などでソフトウエア保守できる人が少なくなっています。

たとえば、オンプレミス環境にCOBOLやC言語で作られたプログラムを利用している会社が考えられます。OS・プラットフォームおよび開発言語が古い場合となります。

会社独自の機能がブラックボックス化されてしまう前に、システムリプレイスを行う必要があります。

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

システムリプレイスの方式には、次の4つが考えられます。

1. 一括移行（一斉移行）方式
2. 段階移行方式
3. 順次移行方式
4. パイロット移行方式

順番に解説していきます。

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

1回の作業で移行を完了させる方式となります。

現在運用中の業務を停止させます。
停止している間に運用データを抜き取り、新しいシステムに登録します。
データの同期が完了した段階で新しいシステムを使用して業務を開始します。

メリットとしては、1回の切り替え作業で移行が完了することです。
今まで使用していたシステムとの同期は、業務を停止させている間に行うことで作業コストを低く抑えることができます。

デメリットとしては、同期を行う作業に時間がかかるため比較的長い業務停止が必要となります。切替失敗した場合には、大きな影響がでてしまいます。

比較的長い作業停止期間がとれる場合に選択されます。

方式②段階移行方式

たとえば全体を小さなグループに分け、そのグループ単位に順番に新しいシステムで作業開始する方式です。

メリットとしては、小さなグループごとの移行となるため移行が失敗しても、影響範囲が小さくなります。

デメリットとしては、すべての切り替え作業が終了するまでに期間がかかります。また、その間は、利用中のシステムと新しいシステムを使わなければなりません。そのため、両システム間の同期も必要となりコスト高となります。

長期間の業務停止ができない場合や、トラブル発生のリスクを小さくしたい場合に選択します。

方式③順次移行方式

利用中のシステムと新しいシステムで並行運用を行います。両システムの運用結果が同じになることを確認してから移行を行う方式です。

メリットとしては、移行前に新しいシステムの稼働状況を事前に確認できます。
これが一番安全な方式です。

デメリットとしては、両システムを使って運用するため2重作業が発生します。単純に作業量は2倍となります。運用停滞を回避するために、人員の増員が必要となる場合も考えられます。

処理結果が両システムで同じになり、安定運用ができると判断されたとき、新しいシステムのみで運用を行います。

両システムを使用するため作業量が2倍となる点に注意が必要です。

方式④パイロット移行方式

最初に利用開始する部署（パイロット部署）を決めて移行を開始します。先行することで運用状況などを確認し問題ないと判断されたとき、残りの移行を行う方式です。
「パイロット」とは、実験的に探りながら何かをテストしていくという意味で使用されています。

メリットとしては、最初にパイロット部署で業務を開始し問題点の洗いだしを行えることです。また、不具合等が起こった時には、パイロット部署のみに影響を抑えることができます。正常に業務が行えると判断できたとき、残りの部署も利用を開始します。

デメリットとしては、パイロット部署と残りの部署でデータの同期や更新が必要となります。また、パイロット部署で正常に業務が行えたとしても、残りの部署が新しいシステムを利用した時、トラブルがないという保証はありません。

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

システムリプレイスの進め方には、次の7つが考えられます。

1. プロジェクトチームを発足する
2. 要件を整理する
3. 移行計画を立てる
4. 予算を確保する
5. システムを開発する
6. リハーサルを実施する
7. 移行を実施する

順番に解説していきます。

進め方①プロジェクトチームを発足する

システムリプレイスは、開発担当者のほかに、システム利用者や管理部署など、さまざまな役割を持った社員が参加するプロジェクトチームを発足させます。多くの人が参加するため事前に以下の役割を、割り振っておく必要があります。

• プロジェクト全体を取りまとめる役割
• 予算を確保、管理する役割
• 技術的な観点から検討する役割
• 利用者の観点から検討する役割
• 最終判断をする役割

進め方②要件を整理する

プロジェクトメンバーは、開発担当者、利用者を中心にシステムを作り替えるための要件整理をします。

現在利用している機能とシステム化できていない機能を洗い出し、どのような機能にすべきかなど検討します。
担当者にヒアリングし、利用者が手作業で作業している処理がある場合は、新しいシステムに機能追加すべきかどうかなど利用者の意見を確認して進めます。

要件整理があいまいなまま、次の作業に進めてしまうと、時間をかけて作り替えを行っても、求めていたシステムを構築できなくなってしまう可能性が高いのです。

プロジェクトメンバーは、要件が整理できた段階で担当部署に持ち帰り、要件にぬけがないか最終確認するようにしてください。

業務を進めるうえで致命的な欠陥が現れるリスクもあるため、必ず要件を明確に整理してから次の段階へ進めてください。

進め方③移行計画を立てる

要件整理が完成すると、システムを作り替えるための移行計画を作成します。

開発期間、開発順番、開発機能、移行する必要があるデータやそのデータ量も含め、細かい部分まで綿密に計画を立てる必要があります。関連する部署や担当者との間で認識の相違が起きないように注意しておくことが大切です。

開発スケジュールや開発費用については、開発会社に提案を依頼します。特に費用については、複数社に見積もりを依頼した上で見積内容（詳細な提案内容）を確認したあとで、移行計画に反映します。

進め方④予算を確保する

移行計画および見積もり情報から、予算確保のためにメンバーと協力し稟議などの社内手続きをして予算を確保します。

システムリプレイスは、新規システム開発より相当難易度が高いです。
そのため経営層には、余裕を持った予算や開発期間・開発人員の必要性を、丁寧に説明し理解してもらうことが必要です。

進め方⑤システムを開発する

要件定義・詳細設計・プログラミング・テストの順序で、開発会社が開発を行います。
システム開発では、システムに求める機能や性能などを明確に数値化し要件定義を作成します。要件定義から詳細設計を作成しプログラミングを始めます。

ここでの要件定義が最も重要となります。プロジェクトメンバーは、開発会社が作成した要件定義を確認するとともに自部署に持ち帰り機能のぬけがないかなど確認します。

プログラミングを終えたあとは、システムが正常に動作することを確認するために、プロジェクトのメンバーおよび利用者に協力してもらいテストを行って検証します。

進め方⑥リハーサルを実施する

システム移行前に本番移行を想定した移行リハーサルを実施してください。

システムの移行途中にトラブルが発生すれば、業務に支障をきたす恐れがあります。トラブルを防ぐためには、極力本番移行に近い方法で、移行リハーサルを行って問題点ならびに課題を明らかにした上で、その対処法を準備してください。

移行リハーサルにかかった時間が、当初想定した移行スケジュールと合致するか確認してください。大幅に時間がずれていた場合は、原因を特定しスケジュールに反映してください。

事前準備は大事です。移行リハーサルを行って事前に課題への対処法を準備しておけば、移行後も安心して業務に入れる可能性が高まります。

進め方⑦移行を実施する

移行リハーサルで問題なく移行できると判断できたとき、実際にシステムを移行します。

移行後は、元のシステムと新しいシステムでデータの整合性が取れているか確認を行います。確認が取れた段階で、利用者は、新しいシステムで業務を開始します。

立ち止まってしまうよりまずは一歩前に

本記事では、システムリプレイスとは古いシステムを新しいシステムに作り替えることと解説しました。

古いシステムを新しいシステムに作り替える必要性を感じていただいたと思います。

この記事を読んで「自社に当てはまる」と感じている方も多いかと思います。

理解はしたが、実際に作り替えるとなると不安になるのではないでしょうか。

そこで提案なんですが、「EMEAO!」というサイトを活用してみてはどうでしょうか。
コンシェルジュが希望条件や要件に即した複数の優良業者を選定して紹介してくれます。

まずは一歩前に進めてはどうでしょう。