基幹システムリプレイスの進め方｜止めない6手順

「基幹システムが古くなり、機能を足したくても足せない」「パッケージに追加開発を重ねた結果、使わない機能ばかりなのに保守費だけが膨らんでいる」「けれども受発注や請求が止まれば事業が止まるため、作り替えに踏み切れない」。そう悩む経営者や情報システム部門の方は少なくありません。この記事では、業務を止めずに基幹システムをリプレイスするための6つの手順を、移行方式の選び方、パッケージかスクラッチかの判断、データ移行の計画、そしてAIを前提にした作り方まで含めて、実際の進め方に沿って説明します。

基幹システムのリプレイスが難しい理由

基幹システムは、販売・購買・在庫・会計など、止まると事業そのものが止まる業務を支えています。メールやチャットのような情報系のシステムであれば、一時的に止まっても代わりの手段で業務を続けられます。基幹システムにはその逃げ道がありません。リプレイスが他のシステム開発より難しいのは、この「止められない」という前提があるためです。

難しさはもう一つあります。長く使われてきた基幹システムほど、仕様書に書かれていない例外処理や、担当者だけが知っている運用ルールが積み重なっています。新しいシステムを「今と同じように動くもの」として作ろうとすると、何が「今と同じ」なのかを誰も正確に説明できない、という事態が起こります。

「2025年の崖」で指摘された構造的な問題

経済産業省は2018年9月7日に公表したDXレポート（サマリー）で、既存システムが事業部門ごとに構築されて全社横断のデータ活用ができないこと、過剰なカスタマイズによって複雑化・ブラックボックス化していることを課題として挙げました。この課題を克服できない場合、2025年以降に最大12兆円／年の経済損失が生じる可能性があるとし、これを「2025年の崖」と表現しています。同じ資料では、2025年には稼働21年以上の基幹系システムが6割になるという見通しも示されています。

注目したいのは、同レポートが対策として「不要なシステムの廃棄、マイクロサービスの活用による段階的な刷新」などによってリスクを低減する方向を示している点です。全部を一度に作り替えるのではなく、仕分けをしながら段階的に置き換える、という考え方は、この時点ですでに公的な提言に含まれていました。

その後、経済産業省は2025年5月28日にレガシーシステムモダン化委員会総括レポートを公表し、ユーザー企業に対してシステムの可視化と内製化を進めること、現行踏襲を見直しつつ標準化を検討することなどを求めています。「今のシステムをそのまま新しくする」のではなく、何を残し何を変えるかを見極めることが、リプレイスの出発点になります。

一括移行（ビッグバン）と段階的移行の違い

リプレイスの方式は、大きく「一括移行」と「段階的移行」に分かれます。両者の間に、旧システムと新システムを同時に動かして結果を突き合わせる「並行稼働」があり、これは単独の方式としても、段階的移行の各段階での安全策としても使われます。

観点	一括移行（ビッグバン）	段階的移行	並行稼働
切り替え方	全機能・全データを一度に切り替える	機能・部門・拠点などの単位で順に切り替える	新旧を同時に動かし、結果を照合してから旧を止める
移行期間	短い	長くなりやすい	並行期間の分だけ長い
切り替え時のリスク	不具合が出たときの影響範囲が全業務に及ぶ	影響範囲を一部に限定できる	旧システムに戻れるため小さい
現場の負担	切り替え前後に集中する	長期間にわたり分散する	二重入力などで一時的に重くなる
新旧システムの連携	原則不要	移行期間中の連携が必要	照合の仕組みが必要
向いている状況	規模が小さい、業務が単純、停止できる期間を確保できる	規模が大きい、止められない、業務が複雑	誤りが許されない計算や帳票がある

一括移行が向いているケース

一括移行の利点は、移行期間が短く、新旧システムをつなぐ仕組みが要らないことです。対象の業務が少なく、データ量も多くない場合や、年末年始・連休など業務を止められる期間を確保できる場合には、むしろ一括移行のほうが合理的です。段階的移行で必要になる「移行期間中だけ使う連携の仕組み」を作らずに済むため、総コストを抑えやすくなります。

一方で、切り替え当日に問題が見つかった場合、全業務が影響を受けます。戻し方（切り戻し）の手順を準備し、リハーサルで実際に戻せることを確かめておくことが前提条件です。

段階的移行が向いているケース

業務の範囲が広い、拠点や部門が多い、受発注や出荷のように止められる時間がほとんどない、といった条件があるなら、段階的移行を検討すべきです。一度に切り替える範囲が小さくなるので、問題が起きても影響を限定でき、前の段階で得た学びを次の段階に生かせます。

段階的に置き換える考え方は、ソフトウェア設計者のMartin Fowler氏がStrangler Fig Applicationとして紹介しているものが知られています。新しい部品を少しずつ作って既存システムの機能を移していき、最終的に旧システムを役目から外す、という進め方です。

選び方の判断基準

どちらを選ぶかは、次の問いに順に答えると整理しやすくなります。

• 基幹業務を止められる時間は、最大で何時間（何日）か
• 切り替える業務の数、拠点・部門の数、データ量はどれくらいか
• 業務どうしのつながり（受注から出荷、請求、会計へのデータの流れ）はどれくらい密か
• 切り替え後に問題が出たとき、旧システムへ戻せるか
• 移行期間中、新旧システムをつなぐ仕組みを作る予算と時間はあるか
• 現場が長期の移行に付き合える体制があるか

止められる時間が短く、規模が大きく、業務のつながりが複雑なほど、段階的移行の価値は高まります。逆に、止められる時間が十分にあり、規模が小さいなら、一括移行で一気に終わらせるほうが現場の負担は少なくなります。実際には「会計は期首に一括で切り替え、販売・購買は段階的に」のように、領域ごとに方式を組み合わせることも珍しくありません。

パッケージか、必要な機能だけのスクラッチか

移行方式と並んで決めなければならないのが、新しい基幹システムを何で作るかです。大きくは、既製のパッケージ（ERPなど）やクラウドサービスを導入する方法と、自社の業務に合わせてスクラッチで開発する方法があります。

パッケージに追加開発を重ねた結果、起きていること

リプレイスの相談で多いのが、パッケージを導入したものの、自社の業務に合わない部分を追加開発（アドオン）で埋め続けてきたケースです。導入当初は標準機能で回っていても、年月とともに細かな改修が積み重なり、次のような状態になっていきます。

• 使っていない標準機能が多い一方で、本当に必要な処理は追加開発の部分にある
• パッケージのバージョンアップのたびに、追加開発した部分の改修と検証が必要になる
• 画面や帳票が業務の流れと合っておらず、Excelや手作業で補っている
• データの持ち方がパッケージの都合で決まっていて、AIや他のシステムに渡しにくい

この状態でリプレイスを考えると、「同じパッケージの新しい版に上げる」以外の選択肢が見えにくくなります。しかし、追加開発がここまで増えているなら、そもそもパッケージの標準に業務を合わせる前提が崩れています。

必要な機能だけをスクラッチで作るという選択

もう一つの選択肢が、自社の業務に本当に必要な機能だけを、スクラッチでモジュール単位に作ることです。棚卸しで「やめる」と仕分けた業務や使っていない機能は作らず、残す業務も今のやり方をなぞるのではなく、あるべき流れで作り直します。

観点	パッケージ＋追加開発	必要な機能だけのスクラッチ
機能	使わない機能も含めて一式そろう	業務に必要なものだけを作る
業務との合い方	合わない部分は追加開発か運用で補う	業務の流れに合わせて画面と処理を作る
改修・機能追加	追加開発とバージョンアップの両方に縛られる	自社の都合で、必要なときに足せる
データの持ち方	パッケージの設計に従う	AIや分析で使う前提で設計できる
向いている業務	会計・人事給与など、法令や慣行で標準化された業務	受発注・見積・生産・物流など、自社の強みや独自のやり方がある業務
注意点	追加開発が増えるほど、パッケージの利点が薄れる	要件を絞り込む力と、稼働後に保守・改善を続ける体制が要る

どちらが正しいということはなく、領域ごとに使い分けるのが現実的です。たとえば会計や給与計算はクラウドサービスを使い、自社の競争力に直結する受発注や見積の業務は必要な機能だけをスクラッチで作り、両者をデータでつなぐ、という構成です。Riizeでも、パッケージに追加開発を重ねてきた企業から、必要な機能だけをAIの活用を前提にスクラッチで作り直す相談を受けることが多くあります。

判断に迷ったら、次の問いで考えると整理しやすくなります。

• 現在の追加開発は、パッケージの標準機能と比べてどれくらいの割合を占めているか
• その業務は、他社と同じやり方で問題ないか、それとも自社の強みそのものか
• 刷新後に、AIを使った機能を自社のペースで足していきたいか
• 稼働後に、保守と機能追加を続けられる体制（社内または外部）を用意できるか

業務を止めずにリプレイスする6つの手順

ここからは、段階的移行を前提にした進め方を6つの手順で説明します。一括移行を選ぶ場合も、手順1・2・4・6はほぼ共通です。

手順1：目的と「やらないこと」を決める

最初に決めるべきは、リプレイスで何を良くしたいのかです。「古いから新しくする」だけを目的にすると、新しいシステムも同じ課題を抱えたまま作られ、費用に見合う効果が出ません。二重入力をなくしたい、月次の締めを早めたい、データを全社で使えるようにしたい、新しい機能を自社で足せるようにしたい、といった目的を、できるだけ数字で測れる形にします。

同じくらい大事なのが「今回はやらないこと」を決めることです。基幹システムの刷新は関係者が多く、要望が際限なく膨らみがちです。範囲を決めずに走り出すと、要件定義が終わらず、カスタマイズが膨らみ、結果としてスケジュールと予算が崩れます。

手順2：現行業務とシステムを棚卸しする

次に、現行の業務とシステムを棚卸しします。ここでの目的は、仕様書を作り直すことではなく、「誰が・いつ・何を入力し・どこへ渡しているか」を工程単位で見える化することです。

棚卸しで押さえる項目は、次のとおりです。

• 業務の工程（見積、受注、発注、入荷、出荷、請求、入金など）と担当部門
• 各工程で入力・参照しているデータと帳票
• 同じ情報を複数の場所に入力している箇所（二重入力・転記）
• システムの外で行っている処理（Excel、紙、メール、電話）
• 他システムとの連携（会計、銀行、EDI、倉庫など）とそのタイミング
• 例外処理や担当者しか知らないルール
• 月次・年次など、たまにしか発生しない処理

特に見落とされやすいのが、月末や期末にだけ発生する処理と、システムの外で人が補っている処理です。これらを拾い漏らすと、切り替え後に「前のシステムではできていたことができない」という問題になります。

棚卸しの結果をもとに、各業務を「そのまま移す」「やり方を変えて移す」「やめる」に仕分けます。経済産業省が求める「現行踏襲の見直し」は、ここで実行します。業務の分け方や価値の付け方は、姉妹記事のAI化すべき業務の見極め方で紹介している「手間×頻度×価値」の考え方がそのまま使えます。

手順3：移行方式を決め、モジュールに分割する

棚卸しの結果を見ながら、前章の判断基準で移行方式を決めます。段階的移行を選ぶ場合は、システムをどの単位で区切るかを設計します。

区切り方の基本は、業務のまとまりとデータのまとまりを一致させることです。たとえば「見積」「受発注」「請求」「取引先・商品マスタ」のように、業務の工程とその工程が主に扱うデータをひとまとめにして1つのモジュールとします。区切った単位どうしは、決めた形式でデータを受け渡すようにしておくと、後から一部だけを入れ替えたり、機能を足したりしやすくなります。

移行する順番は、次のような観点で決めます。

観点	先に移すとよいもの	後に回すとよいもの
業務への影響	止まっても代替手段がある業務	止まると出荷や請求が止まる業務
効果の見えやすさ	二重入力など、現場の負担が大きい業務	効果が小さい業務
依存関係	他の業務から参照されるマスタ	マスタに依存する業務
学習効果	範囲が小さく、試しやすい業務	範囲が大きく、複雑な業務

最初の段階は、小さく、効果が見えやすく、失敗しても取り返しがつく範囲を選ぶのが定石です。最初の切り替えで成功体験を作ると、現場の協力も得やすくなります。

手順4：データ移行の計画を立てる

データ移行は、リプレイスでもっとも過小評価されやすい工程です。システムの機能がいくら良くても、移したデータが正しくなければ業務は回りません。データ移行の計画は、システムの設計と同時に始めます。詳しくは次の章で説明します。

手順5：モジュール単位で構築し、並行稼働で確かめる

各モジュールを構築したら、本番に切り替える前に、新旧の結果を照合する期間を設けます。たとえば請求モジュールなら、同じ月の取引データから旧システムと新システムで請求額を計算し、一致するかを確かめます。差が出たら、どちらが正しいのかを業務の担当者と一緒に確認します。旧システムのほうが誤っていた、というケースも実際にあります。

段階的移行では、移行期間中に新旧システムが同時に動くため、両者の間でデータを受け渡す仕組みが必要になります。この仕組みは移行が終われば不要になるものですが、ここを手抜きすると、二重入力が一時的に増えて現場の負担が跳ね上がります。どのデータを、どちらからどちらへ、どのタイミングで渡すのかを、モジュールごとに決めておきます。

手順6：切り替え、定着させ、拡張する

切り替えたあとは、問い合わせ窓口を明確にし、最初の締め処理（月次・期末）が終わるまでは手厚く支援する体制を残します。締め処理は、普段使わない機能やデータが一斉に動くため、問題が表に出やすいタイミングです。

最後のモジュールを切り替え、旧システムを止めたら終わり、ではありません。業務は変わり続けるので、刷新後も保守と機能追加を続けられる体制を作っておくことが、次の「作り替えられないシステム」を生まないための条件です。

データ移行の計画で押さえる4つのポイント

データ移行は「移行対象の整理」「クレンジング」「リハーサル」「切り替え当日」の4つに分けて計画すると、抜け漏れを防げます。

移行対象の整理

まず、何をどこまで移すかを決めます。すべての過去データを新システムに移す必要はありません。

• マスタデータ（取引先、商品、単価、担当者など）：原則として移します
• 残高・未完了データ（受注残、売掛金、在庫など）：切り替え時点の状態を正確に移します
• 過去の取引履歴：法令上の保存義務や分析の必要性に応じて、移す期間を決めます。移さないデータは、参照用に残す方法を決めます

過去データを全部移そうとすると、データの形式の違いや古いデータの誤りへの対応で工数が大きく膨らみます。「新システムで業務に使うデータ」と「参照できればよいデータ」を分けるだけで、移行の負担はかなり変わります。

クレンジング

長年使われたデータには、重複した取引先、使われなくなった商品コード、入力ルールが途中で変わった項目などが必ず含まれています。これらを整理するのがクレンジングです。

クレンジングで決めておくことは次のとおりです。

• 重複や表記ゆれをどう統合するか（同じ取引先が別コードで登録されている、など）
• 使われていないデータをどう扱うか（移さない、無効フラグを付けて移す、など）
• 旧システムと新システムで項目の意味が違う場合の変換ルール
• 誰が最終的に「このデータで正しい」と判断するか

最後の点は特に重要です。データの正しさを判断できるのは、システム部門ではなく業務の担当者です。クレンジングの判断を業務部門に持ってもらう体制を最初に決めておきます。

リハーサル

本番のデータ移行は、ぶっつけ本番では行いません。本番と同じ手順・同じ量のデータで、少なくとも1回、できれば複数回のリハーサルを行います。

リハーサルで確かめることは次のとおりです。

• 移行にかかる時間が、確保できる停止時間に収まるか
• 移行後の件数・金額の合計が旧システムと一致するか
• 業務担当者が新システムで実際の業務を流せるか
• 問題が起きたときに旧システムへ戻せるか（切り戻しの手順）

件数と金額の照合は、取引先別・月別など複数の切り口で行うと、ずれの原因を見つけやすくなります。

切り替え当日

当日は、リハーサルで固めた手順書に沿って進めます。事前に決めておくべきなのは、作業の順番と担当者だけではありません。「どの時点で、どの条件を満たさなければ切り戻すか」という判断基準と、その判断を誰が下すかを決めておくことが重要です。現場の判断に任せると、「もう少しで直りそうだから」と切り戻しが遅れ、翌営業日に影響が出ることがあります。

切り替え当日のチェックリストの例を挙げます。

• 旧システムへの入力停止の告知と、停止時刻の確認
• 最終データの抽出と、件数・金額の記録
• 新システムへの投入と、件数・金額の照合
• 業務担当者による主要業務の動作確認
• 切り戻し判断の時刻と判断者の確認
• 翌営業日の問い合わせ窓口と連絡手段の周知

よくある失敗と対策

基幹システムのリプレイスで起こりがちな失敗と、その対策をまとめます。

よくある失敗	起きること	対策
「今と同じ」を要件にする	不要な業務や例外処理まで作り込み、費用と期間が膨らむ	棚卸しで「移す・変える・やめる」を仕分ける
要件定義を飛ばして製品・ベンダーの比較から入る	業務に合わず、カスタマイズが膨張する	業務の棚卸しと目的の定義を先に行う
業務部門が関わらない	切り替え後に「使えない」と言われる	棚卸し・クレンジング・照合に業務担当者を入れる
データ移行を後回しにする	切り替え直前に不整合が見つかり、延期になる	設計と同時にデータ移行の計画を始める
リハーサルを省く	当日に時間が足りない、戻せない	本番と同じ手順・同じ量で試す
一度に全部を切り替える	不具合が全業務に波及する	規模と停止許容時間を見て段階的移行を選ぶ
移行期間中の連携を軽視する	二重入力が増え、現場が疲弊する	モジュールごとにデータの受け渡しを設計する
パッケージに追加開発を重ね続ける	使わない機能と改修費が増え、AIや他システムとつなぎにくくなる	独自業務は必要な機能だけをスクラッチで作ることも比べる
切り替えをゴールにする	刷新後に機能を足せず、再びレガシー化する	保守と機能追加を続ける体制を作る

これらの失敗に共通しているのは、システムを作る話から始めてしまい、業務の話が後回しになっていることです。リプレイスは技術の更新である以上に、業務の見直しの機会です。経営判断としての範囲設定と、開発としての段階設計の両方がそろって、はじめて業務を止めずに進められます。

AIネイティブな基幹システムにする

いまリプレイスするなら、「刷新後にAIを足せるか」ではなく、「AIを使う前提で業務とシステムを作る」ところまで考えておく価値があります。ここではそれを「AIネイティブ」と呼びます。AI-OCRによる帳票の読み取り、問い合わせや見積依頼への一次対応、過去の取引をもとにした提案や需要予測などは、どれも基幹システムのデータとつながってはじめて効果を出すからです。

パッケージに追加開発を重ねたシステムでは、データの持ち方や画面の流れがパッケージの都合で決まっているため、AIを組み込もうとしても「データを取り出すだけで一苦労」「AIの結果を戻す場所がない」となりがちです。必要な機能だけをスクラッチで作り直す場合は、最初から次のような作りにしておけます。

作り方	内容	AIにとっての意味
データを1か所にまとめる	見積・受発注・請求などを単一のデータ基盤に置く	AIに渡すデータを集める手間がなくなる
データの意味をそろえる	取引先・商品のコードを統一し、入力のルールを決める	AIの判断や集計がぶれにくくなる
履歴と理由を残す	誰が・いつ・なぜ変更・判断したかを記録する	過去の判断をAIの学習や提案に使える
機能の追加口を用意する	モジュール間のデータの受け渡し方を決め、外からも呼び出せるようにする	新しいAI機能を、既存機能を壊さずに差し込める
人が確認して確定する画面を持つ	AIの結果を担当者が確認・修正してから確定する流れを業務フローに入れる	誤りを業務に流さず、確認の結果を改善に使える

逆に言えば、データが分断されたままのシステムの上にAIだけを載せようとしても、うまくいきません。AI導入が試験段階で止まりやすい理由については、姉妹記事のAI導入がPoCで止まる原因でも詳しく扱っています。

実例：医療卸の基幹システム刷新とAI-OCR

Riizeが支援した医療卸の基幹システム刷新では、見積・受発注・請求がそれぞれ独立して管理され、同じ取引情報を複数の帳票やシステムに重複して入力している状態でした。既存システムは業務の変化に追随できず、新しい機能を足せなくなっていました。

この案件では、分断していた業務を工程単位で棚卸しして再設計し、見積・受発注・請求・取引管理をモジュールとして構成したうえで、単一のデータ基盤の上に再構築しました。そのうえで、刷新した基盤の上にAI-OCRによる入力自動化を追加しています。結果として二重入力と転記ミスが解消され、月次処理が短縮されました。稼働後も保守運用と機能追加を続け、業務の変化に合わせて拡張できる状態を保っています。

この順番、つまり「業務の棚卸し → モジュール化とデータの統合 → その上にAI」は、この記事で説明してきた手順そのものです。AIを先に入れるのではなく、まずデータの土台を整えたことが、AI-OCRを実際の業務で使える形にできた理由の一つです。ほかの案件は実績一覧でも紹介しています。

まとめ：止めないリプレイスは「仕分け」と「段階設計」から

• 基幹システムのリプレイスが難しいのは、止められないことと、仕様書にない運用が積み重なっていることが原因です。
• 一括移行は期間が短く連携の仕組みが不要な一方、問題が全業務に及びます。止められる時間が短く、規模が大きく、業務が複雑なほど段階的移行が向いています。
• 進め方は「目的と範囲の決定」「現行業務の棚卸し」「移行方式とモジュール分割」「データ移行の計画」「構築と並行稼働での確認」「切り替えと定着・拡張」の6つの手順です。
• パッケージに追加開発を重ねて使わない機能が増えているなら、自社の強みに関わる業務は必要な機能だけをスクラッチで作り、会計などの標準業務はパッケージやクラウドサービスに任せる、という使い分けを検討します。
• データ移行は「移行対象の整理」「クレンジング」「リハーサル」「切り替え当日」に分け、切り戻しの判断基準と判断者を事前に決めておきます。
• データを1か所にそろえ、履歴を残し、機能を差し込める形にしておけば、AIを使う前提の「AIネイティブ」な基幹システムになります。

Riizeでは、業務の棚卸しと移行計画づくりから、AIを前提にした必要な機能だけのスクラッチ開発、データ移行、稼働後の保守・機能追加まで、業務・基幹システムの開発とリプレイスを一貫して支援しています。今のパッケージをどうするかの整理からでもご相談いただけます。