リプレイスとは？ITのリプレイスの流れや問題への対処法、事例を紹介

「置き換え」や「入れ替え」を意味するリプレイス。

近年では、IT分野で「システムを入れ替える」意味で使用されることが増えました。インターネットを活用することが一般的になった現在、新たな機能を持つシステムが次々に登場してきており、企業の中でリプレイスについての関心が高まっています。

今回は、リプレイスの意味、目的、必要とされる背景、リプレイスの方法、リプレイスの作業手順、事例など紹介します。リプレイス時に発生しやすい問題や対処法についても説明するので、担当者の方はぜひご覧ください。

リプレイスとは

リプレイスとは英語のreplaceのことで「置き換わる」「入れ替わる」ことを意味します。人事の領域では「後任になる」という意味です。また、ゴルフでは規則上で「拾い上げたボールを元の位置に再び置くこと」としてリプレイスという言葉が使用されます。

現在ではIT関連で、社内既存のハードウェアやソフトウェアを新しいものに置き換える、入れ替えるリプレイス（システムリプレイス）として使用されることも一般的となりました。一部分の入れ替えや、全体の入れ替えどちらに対してもリプレイスと呼びます。

リプレイスの目的

自社システムのリプレイスを行うのには、下記のような目的があります。

システムの老朽化

システムの老朽化にともない、システムの作業パフォーマンスの低下を改善させる目的があります。システムの使用年数を重ねることで、データ使用容量が不足し、処理能力が低下している場合もあるでしょう。

また、老朽化したシステムを把握した人材が社内におらず、メンテナンスに対応できる人材が枯渇するなど多岐的な問題が老朽化により発生します。老朽化の問題をそのままにしておくと、プラットフォームなどシステムを提供している会社のサポートが終了するなどの問題も将来的に危ぶまれるでしょう。

システムの複雑化

長年修繕を繰り返し、機能の追加や拡張を繰り返してシステムが複雑化している点が挙げられます。システムが複雑化することで容量を必要とする割に、運用やメンテナンスには手間がかかる難点があります。また、複雑化しているせいで修正すべき箇所を変更できない、必要な機能を追加できないという問題があるでしょう。

システムのブラックボックス化

また、システムを管理していた技術者が退職することで、一部のシステムの中身がよくわからないという「ブラックボックス化」の問題もあります。ベンダー側のシステムを導入した当時の担当者までいなくなり、当事者が全くいなくなるというケースも少なくありません。ブラックボックス化したシステムに変更を加えることで、他にどのような影響がでるかわからないとして、そのまま放置されてしまっているのが現状でしょう。

新技術の活用

デジタル技術は急激な進化をとげ、現在では社内システムにもAI、ビッグデータ、IoT、AR/VRなどさまざまな技術を用いた仕組みが登場してきています。

そういった技術を活用して、機能の拡充や作業の効率化にあてたいと考える企業も少なくありません。また、基幹システムの他に顧客管理システムなども刷新することで、販売戦略に情報を有効活用するなどビジネスに変革をもたらしたい企業もいるでしょう。

リプレイスが必要とされる背景

そもそも日本は大手企業を中心に、既存製品や雛形を使用せずに開発を行うスクラッチという手法で独自のシステム開発を行ってきました。

そして、団塊世代が退職を迎えた2007年問題によって、技術者が大量に退職したことによりシステムのブラックボックス化が進行。2022年を迎えた現在、問題の深刻化を迎えている企業は少なくありません。

さらに、日本は事業部ごとに業務者の求めに応じてシステムを構築する流れが強く、全体の最適が図られずシステムが複雑化している企業が多い傾向があります。

また、他国と違いユーザー企業にIT人材が蓄積しておらずベンダー企業に圧倒的に人材が集中していることから、社内にノウハウが蓄積していないのも難点です。こういったことを背景に、日本企業のIT関連費用の約8割は既存システムの運用と保守にあてられています。

早期にリプレイスへと真剣に取り組まなければ、現状のシステムを維持することに費用がかかるばかりで、抜本的な解決には結びつかないという問題を抱えた企業少なくはないのです。

リプレイスの2つの方法

日本では、システムのリプレイスはベンダーに委託することが一般的です。リプレイスの方法には、大きくわけてパッケージ型とスクラッチ型の2つの方法でベンダーへ委託します。

パッケージ型

パッケージ型のシステムをベースとして構築する方法です。あらかじめ機能がパッケージで搭載されており、外部との連携できるシステムについても決められています。

パッケージ型のシステムを使用する場合で、初期導入ではなくリプレイスであれば大小の差はあるにせよ機能のすり合わせは必要でしょう。
自社に必要な機能を洗い出し、パッケージの標準機能以外で必要な範囲についてはカスタマイズかもしくはアドオンで開発して機能を追加します。

スクラッチ型

独自開発にてシステムを再構築する手法です。スクラッチ型の中でも再構築の場合は再構築したい内容によって方法が異なります。

例えば、プログラムは同じ言語のままでプラットフォームを移管する「リホスト」、設計書を基に異なる言語で実装する「リライト」、業務要件を基にアプリケーションを作り変え新規システムを構築する「リビルド」などです。各手法のメリット・デメリットやリスクを勘案して選択しましょう。

リプレイス作業の流れ

ここでは、リプレイスの作業手順を見てみましょう。

企画の段階で、現行システムの調査・分析を行い新システムに必要な事項の優先順位をつけます。コスト、期間、リスク、有識者の関与度合い、構築後の効果測定・移行期間などを含め検討し、再構築の方法をひとつから複数選択しましょう。

その後、現行の機能と比較しながら必要となる機能の要件定義を行います。要件定義に合ったシステムを設計し、設計書を完成させます。単体でのテストを繰り返しながら開発を進めていきます。選定・開発したシステムの動作テスト・実務者によるテストを行い、バグを修正。移行期間を経てリリース後も効果測定を行い逐一修正していきます。

パッケージ製品を利用する場合は、要件定義の前に上記作業を「企画」フェーズで進める必要があります。パッケージ製品を使用する目的や期待する効果をあらかじめ設定。後々実現性やコスト面などで期待する効果が本当に得られるのか判断指標とします。要件を基にいくつか製品をピックアップしたら、Fit＆Gap分析を行いましょう。

後ほど、要件定義で改めて分析しますが、パッケージの採否や見積もりを算出のため実施します。Fit＆Gap分析で、必要な機能について「標準機能で適合」「カスタマイズ対応」「アドオン開発」「運用対処」に分け実現方針を検討。パイロット製品でテストを実施し、製品を確定させます。最後に品質保証や運用方法について検討した後、要件定義に移ります。

「システム再構築を成功に導くユーザガイド」

IPA 独立行政法人情報処理推進機構

リプレイス時に発生する問題

ここでは、リプレイス時に発生しやすい問題をいくつか紹介します。

期待通りにシステムが完成しない

まず、発生しやすい問題として、ユーザー企業が期待した通りにシステムが完成しないという問題があります。その原因は、要件定義が十分になされていない点にあります。

前述した通り、開発初期の技術者がおらずシステムを把握している人材が不足しているケースや、実務者とエンジニアとの間で理解している知識が分断しているケースなどがよくあるでしょう。

それにより、「最低限現行のシステムは踏襲したい」という要望に対して、現行通りの要件定義ができておらず、期待するシステムが完成しないという問題が発生します。

設計書・ソースコードと実態がズレる

現行のシステムとベンダーへの指示内容がズレる場合もあります。
設計書が古い状態である場合や、ソースコードではなく実務者の手作業や他のツールによって対応されており実装されていなかった内容が設計図に明記されていなかったケースなどです。

ユーザー企業の想定していないシステムとなってしまい、稼働後実務者の使用時に多くの不具合が発生するでしょう。

また、設計書内での時限と実務の実態との差にも注意が必要です。例えば、設計書内では時限が10秒と記載されていた処理について、今まで１秒ですんでいたのが、新システムでは5秒かかってしまうなどあります。

スケジュールの大幅な超過

スケジュールを大幅に超過することも問題としてよく挙げられるでしょう。

前述の要件定義や設計書の不備によるものもそうですが、ユーザー企業の意図が上手くベンダーに伝わらないという原因もあります。実際の開発作業者へ指示が出されるまでには、ユーザー企業の実務者からSEへと伝わり、ベンダー企業の担当者を経て、分業体制のSE（開発作業者）へと伝えられます。

伝言ゲームのようになってしまい、正しい要求が実際の作業者へ伝わらずやり直しが発生し、スケジュールを超過することにつながってしまうのです。

予算超過によるコスト増加

予定通りに要望のシステムが完成せずスケジュールが超過することによって想定していた予算を超過し、コストが増加してしまいます。

上記のような問題によりシステムの稼働後に、大幅な修正が急ピッチで必要になるケースもあり、そのための追加費用がかかってしまう場合があるでしょう。

リプレイス時の問題に対する5つの対策

ここではシステムのリプレイス時に発生する問題への対策を5つ紹介します。

詳細に要件定義をする

まず、要件定義にしっかりと時間を使い、詳細に設定することが重要です。
「現行のシステムを踏襲したいだけ」と甘くみていると、痛い目に合います。実務者とSE両方からしっかりとヒアリングを行い実態に沿った、また実態よりも改善が図れる要件定義を行います。

ベンダー任せにしない

ベンダーに任せっきりにしないという点も重要です。

日本は他国と違いユーザー企業が技術者を十分に確保している企業は多くありません。そのためベンダー企業に委託してシステム構築を行うのが一般的。

しかし、「ベンダー企業に委託したのだから」と委託先に任せきりにし、想定通りのシステムが構築できなかった事例が少なくはないのです。

システムのリプレイスは、実態の把握とそこからの要望、運用後の実現したい目的をユーザー企業が明確にし、しっかりとベンダーとすり合わせをしなければ実現は難しいでしょう。

無謀な計画を立てない

DX戦略の潮流が強まるなかで、企業でもデジタルトランスフォーメーションに向けて動かねばと過剰な機能を求めて実現化しないケースもあります。

また、現行踏襲を目的としたリプレイスであっても莫大な費用がかかるため、経営陣を納得させる材料として、コスト対効果を見込んで新たな機能の搭載をする企業も少なくありません。

こういった過剰で無謀な計画はシステムの実現化を阻む要因となるので、現実可能かつ自社にとって本当に必要なシステム開発を計画しましょう。

稼働後に改善する

システムのリプレイスにおいて、稼働時に完璧な完成を期待しないことも重要です。

もちろんこれは、要件定義を詳細にユーザー企業実務者・ＳＥとベンダー側とですり合わせ開発を実行した上での話です。それでも、機能の追加や修正事項は出てきてしまうでしょう。

コア機能を担保した上で、あと稼働後にも改善していくという姿勢をユーザー側経営者・チーム、ベンダー側チームで共通認識しておきます。

準委任契約にする

ベンダーとの契約をできれば準委任契約にしておくことも大切です。

契約書の範囲内で完成を以って完了とする請負契約では、稼働後に問題点が発生したとしても、「契約内容に入っていない。」として追加料金を求められてしまいます。

準委任契約は、仕事の完成ではなく行為を行うことを約束する契約です。報酬や契約の完了については、両者が条件を協議して決定します。最初から100％完璧なシステムを作るのは難しいので、正式稼働後、半年間は無料で修正するなどの契約内容にしておくと安心でしょう。

リプレイスを実施した企業事例2選

ここではシステムのリプレイスを実施した企業の事例を2つ紹介します。

DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～より

DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～

リプレイスでスムーズな運用を実現しよう

システムのリプレイスは企業にとって喫緊の課題です。ブラックボックス化していることを把握していても「今はまだ大丈夫だから」とリプレイスを伸ばし伸ばしにしていると、将来的に多大な費用がかかることになりかねません。

DXビジネスが台頭していく中で、複雑化しているシステムを解消しておくことは大前提となります。信頼できるベンダーの力をかりながら、自社システムのリプレイスを成功させましょう。