システムリプレイスの進め方|現状分析から移行まで、止めずに置き換える手順

業務を支えているシステムが古くなり、作り直すかどうかを考え始めた方に向けた記事です。結論から言うと、今のシステムが黙って担っている仕様を現状分析で洗い出してから、置き換える範囲と順番を決めることが、リプレイスを成功させる条件です。この記事では、リプレイスすべきかの判断、現状分析で調べること、置き換えの順番、移行の注意点、よくある失敗を順に説明します。

リプレイスはなぜ新規開発より難しいのか

今のシステムの動きが、仕様書ではなくプログラムの中にしか残っていないことが多いからです。長く使われてきたシステムには、例外の処理や現場の工夫が積み重なっていて、誰も全体を説明できない状態になりがちです。

経済産業省のDXレポートは、こうした「老朽化、肥大化・複雑化、ブラックボックス化したシステム」をレガシーシステムと呼び、克服できなければ2025年以降、最大12兆円/年の経済損失が生じる可能性があると指摘しました(DXレポート サマリー、2018年)。

さらに、リプレイスでは業務を止められず、外部のシステムとの連携も引き継がなければなりません。難しさの中身は「システム再構築(リプレース)は新規開発より困難を極める」で詳しく説明しています。

リプレイスすべきかは、どう判断するのか

「古いから」ではなく、今のシステムを持ち続ける費用と危うさが、作り直す費用を上回るかで判断します。次の項目に当てはまるほど、リプレイスを考える時期です。

• 直せる人が社内外に1〜2人しかいない
• 小さな変更にも時間と費用がかかり、新しい施策が出せない
• 使っている技術やOSのサポートが終わる、または終わっている
• 利用者の不満(遅い、迷う、端末によって動きが違う)が事業に響いている

直せる人が限られている状態の危うさは、「中小企業におけるシステム内製化の最大のリスクは「退職」です」に書いています。

判断の選択肢は、全面的な作り直しだけではありません。

選択肢	向いている状況	気をつける点
全面的に作り直す	技術が古く、部分的な改修では利用者の不満を解消できない	期間と費用が最も大きい。移行の計画が欠かせない
段階的に置き換える	業務を止められず、機能のまとまりごとに分けられる	新旧が並ぶ期間の連携と、データの持ち方を設計する
残して、足りない部分を補う	基幹のシステムは使えていて、特定の業務だけが回らない	補うシステムとの連携を保守し続ける必要がある

現状分析では何を調べるのか

今のシステムが「何をしているか」を、業務とデータの両方から調べます。仕様書があっても、実際の動きと合っているとは限らないので、現場の操作とデータで確かめます。

1. 業務の流れ:誰が、いつ、どの画面で、何をしているか
2. 画面と帳票:入力している項目、出力している帳票、Excelでの加工
3. データ:どんなデータを持ち、どこから来てどこへ渡しているか
4. 外部との連携:決済、基幹システム、計測ツールなど、つながっている先とその取り決め
5. 暗黙の仕様:例外の処理、月末だけの動き、現場の運用で補っていること

5つ目の暗黙の仕様が、リプレイスで最も漏れやすいところです。現状分析の考え方は「システム導入の成否は、現状分析が９割」に、Excelで補っている業務の扱いは「脱・Excelか、続・Excelか。それが問題だ。」に書いています。

どの順番で置き換えればよいのか

業務を止めずに済む単位に分け、影響の小さいところ、または効果がはっきり見えるところから置き換えます。一度にすべてを置き換えると、問題が起きたときに原因を絞り込めません。

• 新旧のシステムが並ぶ期間に、どちらのデータを正とするかを先に決める
• 外部との連携は、置き換えの前後で同じ取り決めを守れるかを確かめる
• 置き換えの単位ごとに、何をもって完了とするか(テストの基準)を決める

移行で止めてはいけないものは何か

止めてはいけないのは、業務とデータです。移行の計画には、少なくとも次の3つを入れます。

1. データ移行:移す範囲、変換のルール、移した後の照合方法
2. 並行稼働:新旧を同時に動かして結果を比べる期間
3. 切り戻し:問題が起きたときに、元のシステムへ戻す手順と判断の基準

よくある失敗と避け方

失敗	原因	避け方
「今と同じ」で作ったのに、現場で使えない	今の動きを調べずに、画面の見た目だけをまねた	現状分析で暗黙の仕様を文書にし、残す・変える・やめるに分ける
移行の直前に、連携先の取り決め違いが見つかる	外部との連携を後回しにした	連携先と取り決めを最初に洗い出し、早い段階で結合して確かめる
ついでの改善が膨らみ、終わらない	リプレイスと業務改革を同時に進めた	最初の置き換えでは変える範囲を絞り、改善は次の段階に回す

当社ではこう進めています

当社は、作り直す範囲を決めるところから参画しています。置き換えの形が異なる3つの案件を紹介します。

GILT・GLADDを含む3アプリのFlutterリプレイス(la belle vie様)は、全面的に作り直した例です。会員数数百万人のアプリが、AndroidはWebViewベース、iOSだけネイティブという構成で、端末によってユーザー体験が大きく違っていました。当社はTech Lead/PLとして、既存アプリのコードとAPI仕様を参照しながら、3つのアプリを順にFlutterへ置き換えました。当社からは2名、チームは最大4名で、2023年2月から2025年2月まで約2年をかけています。

モバイルオーダーの再構築(大手外資系ファーストフードチェーン)は、10年ほど前にリリースされ、全国1,000店舗強で使われているシステムの作り直しです。外部システムとの連携が非常に多いサービスだったため、連携要件の遵守と組み込みを慎重に進めました。2026年11月初旬にフルリニューアルを終えています。

販売・在庫管理システム(3社合同)は、作り直さなかった例です。会計・販売の基幹には使い慣れた弥生販売を残し、弥生販売では管理できなかった先の予約注文と在庫を、補うシステムで管理できるようにしました。

まとめ

• リプレイスの難しさは、文書に残っていない今の仕様を引き継ぐことにある
• 判断の選択肢は、全面的な作り直し、段階的な置き換え、残して補う、の3つ
• 現状分析で暗黙の仕様を洗い出し、業務を止めない単位と順番で置き換える

自社のシステムをどう置き換えるか相談したい方は、お問い合わせからご連絡ください。