基幹システムのリプレイスとは？費用・期間の決まり方と流れ、替えるかどうかの判断の物差し

今のシステムの保守サポートが、あと数年で終わる。

提供元からそんな通知が届くと、経営者は3つを決めることになります。

替えるのか。いつ始めるのか。いくらかかるのか。

基幹システムのリプレイスとは、販売・購買・在庫・会計など、会社の中核業務を支えるシステムを別の製品やサービスに入れ替えることです。

流れは6つの段階で進みます。

目的を決める→選択肢を比べる→製品と支援会社を選ぶ→作り込みとテスト→データ移行と切替→定着の順です。

ERP導入の期間は一般に6〜12か月程度とされ、規模と範囲によってはそれ以上かかります。

（出典：Oracle NetSuite公式「6 Key Phases of an ERP Implementation Plan」、2026年9月確認）

ただ、この目安どおりに収まる会社ばかりではありません。

費用も同じで、会社ごとに大きく開きます。

では、その差はどこで生まれるのか。

ユーザー数だけでは説明がつきません。

入力の二度手間、締めてみないと出ない数字、担当者1人しか分からない仕組み。

こうしたひずみを抱えたまま、替える時期を測りかねている会社は少なくありません。

一方で、急いで替えない方がよい会社もあります。

その条件は第4章に並べました。

📌 この記事で分かること

• 基幹システムのリプレイスの定義と、全体の流れ（6つの段階）
• 費用の区分と、費用・期間の差を生む4つの要因
• 見積もりで比べる項目と、期間を保守期限から逆算する方法
• リプレイスが向く会社・まだ早い会社の見分け方
• よくある3つの失敗と、その避け方

言葉の整理：基幹システムは、会社の中核業務を支えるシステムの総称です。

ERP（統合基幹業務システム）は、会計・販売・在庫などを1つのデータベースでまとめて扱う仕組みです。

両者の違いと移行の判断は、基幹システムとERPの違い・移行判断の考え方で扱っています。

基幹システムのリプレイスとは｜定義と全体の流れ

似た言葉との違い

基幹システムを新しくする方法は、リプレイスだけではありません。

言葉	何をするか	業務の見直し
延命（保守延長）	今のシステムを、保守を延ばして使い続ける	ほぼしない
マイグレーション	今のシステムを、別の環境（クラウドなど）へ移す。ロジックは原則変えない	小さい
リビルド	システムをゼロから作り直す	大きい
リプレイス	別の製品・サービスに乗り換える	大きい

リホスト・リファクタなど、ほかの手法を含めた選び方は、モダナイゼーションとはにまとめています。

近年のリプレイスで多いのが、古い基幹システムからクラウドERPへの乗り換えです。

クラウドERPとは、インターネット経由で使うERPのことです。

基礎はクラウドERPとはをご覧ください。

全体の流れは6つの段階

段階	やること	経営者が決めること
① 目的を決める	何を実現したいかを、測れる言葉にする	リプレイスの目的と優先順位
② 選択肢を比べる	延命・更新・乗り換え・いまは替えないを比べる	替えるかどうか
③ 製品と支援会社を選ぶ	候補を絞り、見積もりと提案を比べる	製品と支援会社、予算
④ 作り込みとテスト	設定・連携・帳票を作り、業務の流れで試す	標準に合わせる範囲
⑤ データ移行と切替	データを整えて移し、並行稼働で照合する	切替日と、戻す条件
⑥ 定着	現場で使い続け、改善を回す	効果の測り方

流れを図にすると、次のとおりです。

各段階の中身は第7章に書きました。

データ移行（⑤）の実務は、基幹システムのデータ移行ガイドで扱っています。

なぜ今、リプレイスを考えるのか

基幹システムは、普段あまり意識されません。

問題が表に出たときに初めて、経営への影響の大きさに気づきます。

検討のきっかけは、主に3つです。

老朽化と保守期限

古いシステムの不調は、最初は「少し遅い」「たまに不安定」という程度です。

それが積み重なると、業務全体を止めるリスクに変わります。

ハードウェアは古くなるほど故障しやすくなります。

ソフトウェアのサポートが終われば、いざというときに提供元の支援を受けにくい。

製造業なら生産管理の不具合が現場の混乱に、流通業なら在庫や出荷のずれが顧客対応に直結します。

保守期限が切れたシステムを使い続けるリスクは、基幹システムの保守切れリスクで詳しく扱っています。

機能不足が成長のブレーキになる

昔は十分だった仕組みが、今の経営に合わなくなることがあります。

• 数字をリアルタイムで見たい
• 複数の拠点の情報をまとめたい
• どこからでも確認したい
• データを経営判断に生かしたい

古いシステムでは、在庫や原価の状況は締めてみないと見えません。

資料づくりに時間がかかり、判断が遅れる。

成長している会社ほど、この差は大きくなります。

「遅い・重い」が悩みの中心なら、パフォーマンス改善と刷新の判断軸も参考になります。

AS/400（IBM i）など、長く使われてきたシステムの将来の選択肢は、AS/400（IBM i）とはで扱っています。

セキュリティは経営の責任

サポートが切れたソフトウェアを使い続けることは、鍵の壊れたオフィスを使い続けるようなものです。

情報漏えいやシステム停止が起きれば、失うのは復旧の費用だけではありません。

取引先の信頼や、現場の時間も失われます。

経済産業省も、2025年5月の報告書で、モダン化は経営課題として取り組むべきだと提言しています。

経営層の強いコミットメントと、トップダウンでの推進が要るとしています。

（出典：経済産業省「レガシーシステムモダン化委員会総括レポート」2025年5月28日、2026年9月確認）

リプレイスで経営はどう変わるか

変化の面	何が変わるか	経営にとっての意味
業務	手入力と確認の作業が減る	人と時間を、本来の仕事に回せる
費用	サーバーの保守や個別の改修の費用が見えるようになる	削るのではなく、続けられる形に整える
判断	数字が早く、部門をまたいでつながって見える	変化に早く気づき、早く手を打てる

在庫の入出庫がすぐに反映されるだけで、確認の電話や表計算の突き合わせは減ります。

地味に見えて、効き目は小さくありません。

ただし、どれも入れれば自動的に起きるわけではなく、第7章の①で決めた目的に照らして稼働後に測ります。

リプレイス先の選択肢｜「合う条件」で比べる

オンプレミス型とクラウド型

リプレイス先は、まずオンプレミス型（自社でサーバーを持つ型）とクラウド型に分かれます。

観点	オンプレミス型	クラウド型
初期投資	大きくなりやすい（サーバー・構築・ライセンスの買取）	抑えやすい（利用料が中心）
運用	保守・更新・障害対応を自社で担う	インフラの維持は提供元が担う
バージョンアップ	大きなプロジェクトになりやすい	提供元が定期的に行う
拡張	機器の追加・改修が要る	利用量に応じて調整しやすい
利用場所	社内ネットワークが中心	インターネット経由でどこからでも
連携	個別に接続を開発することが多い	標準の接続口（API）で連携しやすい

全体最適と運用負担の軽さを重視する中堅・中小企業では、クラウド型が選ばれる傾向があります。

乗り換え先の種類ごとの合う条件

製品の優劣ではなく、今のシステムから何に乗り換えると無理がないかで比べます。

乗り換え先	合う条件	乗り換えで気をつけること	AIとの親和性
クラウドERP（NetSuiteなど）	分かれた販売・在庫・会計を1つにまとめたい。拠点や会社が増える	旧システムの作り込みを持ち込まず、標準に合わせる	高。データが1か所にそろう
国産の業務パッケージ	日本固有の商習慣への対応を重視する	周辺システムとの連携を別に設計する	中。連携の作り方による
Odoo	必要なアプリから小さく始めたい	設定・運用を社内で担う力が要る	中〜高。構成の自由度が高い
AIスクラッチ開発	パッケージで合わない部分がはっきりしている	作った後の保守の担い手を先に決める	高。ただし設計次第
いまは替えない（延命）	保守期限に余裕があり、業務の変化も小さい	替える時期を先に決める	低。データが分かれたまま

経済産業省の報告書は、中堅・中小企業はオーダーメイドのスクラッチ開発を避け、パッケージやSaaSを原則とすべきとしています。

（出典：経済産業省、第2章2-3と同じレポート）

ただ、AIを使った開発で、費用と期間の前提は変わりつつあります。

独自性の高い部分に限って作る選び方の判断軸は、AIでスクラッチ開発とERP、どちらを選ぶべきかにあります。

製品ごとの比較は、ERP・クラウドERPを徹底比較とOdooとNetSuiteの比較をご覧ください。

AIを使う前提で、乗り換えの機会に整えること

AIの使い道は、データの整い方で大きく変わります。

リプレイスは、次の3つを整える数少ない機会です。

• データを1か所に集める：部門ごとに分かれたデータは、AIに渡すたびに集め直しが要る
• マスタの定義をそろえる：同じ取引先が別のコードで登録されていると、AIの集計もずれる
• 履歴を残す：過去の取引の傾向を見るには、一定期間の履歴が要る

考え方は、AI導入の成否は「データの整い方」で決まるで詳しく扱っています。

判断の物差し｜リプレイスが向く会社・まだ早い会社

リプレイスが向く会社

次の条件が2つ以上当てはまるなら、具体的に検討する価値があります。

• 保守期限やサポート終了が、3年以内に見えている
• 会計・販売・在庫が別々のシステムで、表計算でつないでいる
• 月次の締めに時間がかかり、数字が出るのが遅い
• 仕組みを分かる担当者が限られ、その人が辞めると困る
• 拠点・子会社・海外展開など、事業の形が変わる予定がある

まだ早い会社

一方で、次のような場合は急いで替えない方がよいこともあります。

• 今のシステムの保守期限まで余裕があり、業務の不満も小さい
• リプレイスの目的を、まだ言葉にできていない
• 事業の形が1〜2年で大きく変わる見込みで、要件が固まらない
• 推進役を担える人が、社内にまったくいない

「まだ早い」は、何もしないという意味ではありません。

替える時期と条件を決めておくことです。

たとえば「保守期限の2年前に着手する」「拠点が3つを超えたら見直す」といった決め方があります。

更新にとどめるか乗り換えるかの分かれ目は、基幹システムは「更新」か「乗り換え」かで詳しく扱っています。

費用｜費用と期間を決める4つの要因

「いくらかかるのか分からない」。

この不安が、検討を先延ばしにする大きな理由になっています。

金額は、同じ製品を選んでも会社ごとに大きく開きます。

相場の数字を探すより先に、何が金額を動かすかを知っておくと、見積もりが読めるようになります。

費用と期間を決める4つの要因

差を生む要因は、次の4つです。

• 機能範囲：購買・販売だけか、在庫・会計・プロジェクト管理まで載せるか
• 開発の量：アドオン開発（標準にない機能の追加開発）と、とくに外部システムとの連携開発
• 顧客側の体制：情シスが少ないと支援を厚くする必要があり、期間も長くなりやすい
• ユーザー数：受入テストと教育の工数が増え、社内の調整で長期化しやすい

ユーザー数は4つのうちの1つにすぎません。

人数が少なくても、在庫・会計まで載せ、社内に情シスがいなければ、費用も期間も膨らみます。

効いてくるのは、人数より範囲と体制です。

費用の3つの区分と、NetSuiteのライセンス

見積もりは、次の3つを合わせた総額で見ます。

費用の区分	中身	性質
ライセンス費用	製品本体の利用料	月額または年額の継続費用
導入支援費用	要件定義・設定・開発・データ移行・教育	初期にまとめて、または分割で発生
運用保守費用	稼働後の保守・問い合わせ対応・改修	継続費用

NetSuiteのライセンス費用は、ミニマム構成で月額20万円〜が出発点です。

モジュール（機能の範囲）・ユーザー数・オプションで変わり、月額・年額ともに数百万円規模になることもあります。

誰が何を担うかも、見積もりを読む前に押さえておきたい点です。

• 日本オラクル：ライセンス、トレーニング、製品サポート
• ベンチャーネット：要件定義、設定、カスタマイズ、アドオン開発、保守、PM（発注元のPM業務やOracleとの調整を含む）

ライセンスの最終的な金額を提示できるのは、Oracle NetSuiteの担当営業だけです。

ベンチャーネットは、Oracleの担当営業と一緒に対応します。

契約は請負契約に対応（準委任も相談可）で、常駐せず、国内のチームがリモートで進めます。

NetSuiteの価格の考え方と導入費用の例はNetSuiteの価格、数年間の総額はクラウドERPの費用・料金相場で扱っています。

見積書に出てこない費用

• 社内の人件費：要件定義・テスト・教育・現場との調整に使う時間
• データ移行の手間：データの整理・変換の仕組みづくり・リハーサル
• 教育：現場の研修、手順書の整備
• 並行稼働：新旧のシステムを一緒に動かす期間は、両方の費用が重なる

中でも社内の人件費は、どの見積書にも載りません。

担当者の時間の何割をプロジェクトに使うかを、先に決めておきます。

見積もりで比べる項目

一般的な相場は、自社の条件に当てはまらないことが多くあります。

複数の見積もりは、次の項目をそろえてから比べます。

比べる項目	差が出る理由
対象の業務の範囲（会計だけか、販売・在庫・生産までか）	範囲で導入支援の工数が大きく変わる
ユーザー数と、使う部門・拠点・会社の数	ライセンスと設定の量が変わる
標準で足りない部分の作り込みの量	追加の開発と、将来の保守の費用が変わる
他システムとの連携の数	接続ごとに設計と試験が要る
データ移行の範囲と、誰が整理するか	社内でやるか外に頼むかで費用が変わる
帳票の数と、様式の作り込み	見落とされやすく、後から増えやすい
稼働後の保守の中身と、月の対応時間	継続費用の大きさが決まる
追加の要望が出たときの費用の決め方	予算超過を防ぐ

見積もり依頼の書き方は、ERP見積もり依頼書（RFQ）の書き方を参考にしてください。

社内稟議の通し方は、ERP導入の社内稟議書の書き方にあります。

期間｜目安と、期間を延ばす要因

一般的な目安は6〜12か月

NetSuite公式の解説記事は、ERP導入の一連の流れに通常6〜12か月かかると説明しています。

（出典：Oracle NetSuite公式「6 Key Phases of an ERP Implementation Plan」、2026年9月確認）

この目安は、あくまで出発点です。

購買・販売に絞って開発を持ち込まなければ、目安より短く済むことがあります。

連携開発が多い会社や、社内に情シスがいない会社は、目安を超えやすくなります。

目安の数字だけで計画を組むと、自社がどちら側に振れるかを見誤ります。

自社の期間は、候補の支援会社に段階ごとの計画を出してもらって比べます。

NetSuiteの場合の段階ごとの期間は、NetSuiteの導入期間で扱っています。

期間を延ばす要因

5-1の4つの要因は、そのまま期間にも効きます。

リプレイスでは、さらに旧システムの側の事情が加わります。

• 今のシステムの複雑さ：長年の作り込み・データ・周辺の連携の量
• 新しいシステムの作り込みの範囲：標準をどこまで使い、どこから個別に作るか
• 社内の推進体制：オーナーの関与、現場との調整役、決める速さ

期間をもっとも左右しやすいのは、社内の推進体制です。

「何を実現したいか」「誰がどう決めるか」がはっきりした会社ほど、早く進みます。

一気に切り替えるか、段階的に切り替えるか

観点	一気導入（ビッグバン）	段階導入（フェーズ型）
期間	全体として短い	全体として長い
初期の費用	集中する	分散する
業務停止のリスク	高い（全業務が同時に切り替わる）	低い（領域ごとに切り替わる）
現場の負担	一時的に集中する	分散できる
問題の見つけやすさ	原因の切り分けが難しい	段階ごとに見つけやすい
向くケース	制度対応など、期限がはっきりしている	業務の継続を優先したい

「せっかくやるなら、一度で全部きれいにしたい」。

そう考えたくなるものの、一度にすべてを変えると、かえってリスクが高まる場合があります。

まず会計から始めて販売・在庫へ広げる、拠点ごとに切り替える。

段階導入は、慎重さのためだけでなく、現実的で強い進め方です。

保守期限から逆算する

保守期限がある会社は、期限から逆算して着手の時期を決めます。

逆算の項目	考え方
稼働の目標日	保守期限より前に置く。決算の繁忙期は避ける
予備の期間	遅れに備えて数か月を見込む
導入の期間	6-1の目安を出発点に、支援会社の計画で詰める
選定の期間	候補の比較・見積もり・社内の稟議にかかる期間を足す
着手の日	上の期間を、稼働の目標日から引いた日

着手の日から保守期限までを、時間の順に図にすると次のとおりです。

選定と予備の期間を足した分だけ、着手は前倒しになります。

稼働の時期は、データ移行の締めの時期とも関わります。

考え方は、基幹システムのデータ移行ガイドをご覧ください。

進め方｜6つの段階でやること

6つの段階は、順番を入れ替えると手戻りが出ます。

① 目的を決める

最初に考えるのは、「どんなシステムが欲しいか」ではありません。

会社として何を実現したいかです。

• 経営の数字を、もっと早く見たい
• 拠点や部門をまたいで、情報を1つにまとめたい
• 事業の拡大に耐えられる仕組みにしたい
• 特定の人に頼った業務を減らしたい

現場は「入力が大変」と言い、経営は「数字が遅い」と言います。

この2つは、本来つながっています。

現場の困りごとと経営の目標を結びつけるのが、この段階の仕事です。

② 選択肢を比べる

目的が決まったら、延命・更新・乗り換え・いまは替えないを、第3章・第4章の表で比べます。

この段階で「替えない」と決めることも、立派な結論です。

③ 製品と支援会社を選ぶ

機能の多さだけで選ぶと、稼働後に困ります。

見るのは、自社の経営課題を解決できるかと、稼働後まで伴走できる支援会社かどうかです。

提案を比べるときは、次の問いを各社に同じように投げると差が見えます。

• 自社の業務のうち、標準で足りない部分はどこだと考えるか
• その部分を、作り込み・運用の変更・別の仕組みのどれで補うか
• データ移行で、社内に何を求め、支援会社は何を担うか
• 稼働後の問い合わせに、誰がどの時間で答えるか
• 見積もりに入っていない費用は何か

答えが具体的な支援会社ほど、自社の業務を理解しようとしています。

標準に合わせる部分と個別に作る部分の仕分けは、Fit&Gap分析で扱っています。

④ 作り込みとテスト

設定を進め、連携や帳票を作り、利用者の研修を行います。

テストでは「予定どおり動くか」だけでなく、現場が実際に使えるかを見ます。

テストの段階	見ること	主に担う人
機能ごとのテスト	設定・帳票・連携が、1つずつ正しく動くか	支援会社
業務の流れのテスト	受注から請求・入金まで、つながって動くか	支援会社と業務の担当者
受け入れのテスト	現場が実際の業務で使えるか	現場の利用者
件数・時間のテスト	月末や繁忙期の件数でも処理が間に合うか	支援会社と情報システムの担当者

受け入れのテストは、現場の利用者自身が行います。

月末の締めや繁忙期の件数など、実際の業務の流れで試します。

⑤ データ移行と切替

リプレイスでいちばん難しいのが、この段階です。

長く使ってきたデータには、重複・欠損・表記ゆれ・使われていない項目がたまっています。

• 何を移し、何を移さないかを決める
• データを整えてから、リハーサルで何度も試す
• 新旧を一定期間並べて動かし、件数・金額を照合する（並行稼働）
• うまくいかないときに旧システムへ戻す条件を決める（切戻し）

戻す条件を決めるのは、失敗を前提にしているようで縁起が悪い。

そう感じる方もいます。

実際は逆で、戻す条件を決めた会社ほど、落ち着いて本番に臨めます。

具体的な手順と失敗例は、基幹システムのデータ移行ガイドで詳しく扱っています。

⑥ 定着

システムは、現場に定着してはじめて意味があります。

①で決めた目的が達成できたかは、稼働前の数字と比べないと分かりません。

効果の種類	測る物差しの例	稼働前に取っておく数字
締めの速さ	月次の締めにかかる営業日	直近3か月の締めの日数
手作業の量	手入力・転記の件数や時間	担当者ごとの1か月の作業時間
数字の見え方	在庫・原価を把握できるまでの日数	月末から数字が出るまでの日数
運用の費用	保守・改修・サーバーの年間費用	過去数年の保守と改修の支払い

投資の効果の考え方は、NetSuiteのROIで扱っています。

読者の二つの立場

はじめて本格的なERPに移る会社

表計算や会計ソフトを組み合わせて回してきた会社にとって、これはリプレイスというよりはじめての統合です。

範囲を購買・販売に絞り、開発を持ち込まなければ、短い期間で稼働させやすくなります。

まず今の業務の流れを書き出し、二重入力が起きている箇所から載せていくのが近道です。

中堅・中小企業のERPの選び方は、ERPパッケージとはも参考になります。

いまのシステムや導入パートナーを見直す会社

保守期限、更新の案内、パートナーへの不満。

きっかけのある会社は、期限を1枚にまとめることから始めます。

保守期限・契約の更新日・ハードウェアの保守期限を並べ、どれを選ぶかを決める期日を置きます。

見落としやすいのが、今のシステムからデータをどの形で取り出せるかです。

保守が切れた後では、取り出すための支援を受けにくくなることがあります。

導入の途中でパートナーを替える、という選び方も取れます。

考え方は、ERP導入失敗の原因はパートナーにあり？「パートナー変更」という選択肢にまとめています。

AS/400からの移行はAS400リプレイスのポイント、SAPを使っている会社はSAP 2027年問題の解決策をご覧ください。

グループ会社なら、本社のシステムは残し、子会社や海外の拠点から替える進め方もあります。

詳しくは2層ERP（Two-Tier ERP）とはと、中小企業の海外進出で見落としがちな「基幹システム」の落とし穴で扱っています。

よくある3つの失敗

失敗1：目的があいまいなまま進める

起きること：「業務効率化のため」「DXのため」と掲げたまま、契約まで進む。

稼働後に「何が良くなったのか分からない」状態になる。

原因：解決したいことが、測れる言葉になっていない。

その結果、提案を丸ごと受け入れるか、現場の要望をすべて積み上げるかになる。

前者は使わない機能への投資に、後者は作り込みの膨張につながる。

避け方：目的を測れる言葉にしてから着手します。

• 「業務効率化」ではなく「月次決算を5営業日短くする」
• 「データの見える化」ではなく「在庫回転率を1.5倍にする」
• 「DX」ではなく「手作業の経費精算をなくす」

目的が具体的になれば、要る機能も優先順位も、成功の判定基準も決まります。

失敗2：今の業務をそのまま再現しようと作り込む

起きること：「今のとおりに動かしてほしい」という要望に応え、大量の作り込みをする。

新しいシステムの上に、古い業務がそのまま乗る。

原因：「この担当者しか分からない手順」まで、仕分けずに移している。

作り込みが多いと、製品のバージョンアップに追いつきにくい。

改修のたびに費用がかかり、「新しくしたのに、また古くなる」状態に戻る。

避け方：Fit to Standard（業務を製品の標準機能に合わせていく考え方）で進めます。

中核部分の作り込みを最小にするクリーンコアの考え方も役立ちます。

「本当に特殊な部分」と「変えられる部分」を分け、特殊な部分だけを個別に作ります。

経済産業省の報告書も、現行機能の保証や現行踏襲へのこだわりを捨てるよう提言しています（出典：経済産業省、第2章2-3と同じレポート）。

開発が増えるほど、費用も期間も膨らみます（第5章5-1）。

標準に寄せる判断を経営として通せるかが、費用にも期間にも効きます。

失敗3：データ移行と切替を「作業」として軽く見る

起きること：「今のデータを入れればよい」と考え、作業時間だけで予定を組む。

本番の直前に、数字が合わない・帳票が作れないといった問題が次々に見つかる。

原因：データの整理とリハーサルの時間を見込んでいない。

並行稼働の期間も、旧システムに戻す条件も決めていない。

トラブルの場面で「あと少しで直る」「すぐ戻すべき」と議論が割れ、業務が止まる。

避け方：データ移行を品質を作り込む工程として計画します。

• コードの体系、マスタの統合の方針、整理のルールを最初に決める
• 手順を文書にし、特定の人に頼らない
• リハーサルを複数回行い、かかった時間と不具合を記録する
• 照合の観点（件数・金額・合計・締めの結果）を事前に決める
• 戻す条件・最終判断者・戻した後の再開の手順を、文書で合意する

失敗の根本の原因は、ERP導入はなぜ失敗するのかとクラウドERPの失敗事例と回避策でも扱っています。

NetSuiteへ替える場合の要点は、NetSuiteへのリプレイスを成功させる実践ポイントをご覧ください。

支援会社（パートナー）の選び方

同じ製品を選んでも、うまくいく会社とつまずく会社に分かれます。

分かれ目になりやすいのが、支援会社です。

観点	見るところ
標準に寄せる判断を支えられるか	「なぜ標準に寄せるか」「例外を認める条件」を材料として示せるか
非機能要件を最初に決められるか	性能・障害時の復旧・バックアップを、要件定義の段階で具体化するか
移行と切替を型で設計できるか	照合の観点・並行稼働の期間・戻す条件を、事前に文書にするか
仕様の変更を統制できるか	変更の理由・影響・判断者を整理してから可否を決めるか

リプレイスの難しさは、設定や移行の作業そのものより、線引きと合意にあります。

現場から「この処理だけは例外にしたい」という声は、必ず出ます。

要望をそのまま受け取る支援会社だと、作り込みが増え、費用と将来の改修の負担が膨らみます。

経験のある支援会社は、例外を認める条件と、将来の費用への影響を判断の材料として示します。

非機能要件とは、性能・可用性・監視・バックアップなど、機能以外の品質の要件です。

障害からの目標の復旧時間（RTO）と、どの時点まで戻せるか（RPO）も含みます。

稼働後に問題が出やすく、後から直しにくい領域です。

契約前の確認点は、NetSuiteパートナーの選び方で詳しく扱っています。

ベンチャーネットが支援したリプレイスの事例

リプレイスは、老朽化への対処や制度対応といった守りの施策として語られがちです。

実際の成否を分けたのは、どのERPを選んだかより、どの課題を解き、業務と意思決定をどこまで変えたかでした。

背景の異なる3社が、クラウドERPを軸に基幹システムを刷新した例です。

株式会社キュリエ：事業拡張に耐える経営基盤を再設計

株式会社キュリエは、プリンター用の互換インク・トナーといったオフィスサプライの輸入・卸売を主軸に成長してきた企業です。販売の重心をECへと移し、楽天市場・Amazonなどの主要モールでの展開を加速しています。

課題

事業の多角化と規模拡大が進む一方で、販売管理・在庫管理・会計データがそれぞれ別システムで管理され、一部はExcelに依存していました。

全社の業績を横断的に把握するまでに手間と時間がかかり、経営判断に必要な数値をリアルタイムで確認することが困難な状態でした。将来的にIPOを見据える中で、属人的な管理を改め、再現性のある経営基盤の構築が必要となっていました。

結果

NetSuiteを採用し、販売・在庫・会計といった基幹データを単一プラットフォームに集約。経営数値をリアルタイムで把握できる体制が整いました。

在庫領域では自動化が進み、適正在庫の維持とSKU単位の詳細分析を両立。新規事業「スマラピ」でも、売上予測や在庫管理の精度が向上しています。

キュリエ社の導入事例ページ／キュリエ社の導入事例詳細（PDF）

株式会社アペックス：27年運用のSAP R/3から脱却、ゼロベースで再選定

株式会社アペックスは1963年創業、コーヒーをはじめとするカップ式自動販売機オペレーターの先駆者です。1998年から27年間、基幹システムとしてSAP R/3を運用してきましたが、2025年の保守サポート終了（2025年問題）を機に、全面刷新を決断しました。

課題

紙の帳票を前提とした複雑な業務が根付き、既存システムの全体像を1人で理解している人はいない状態でした。

SAP S/4 HANAは、中堅企業には過剰な機能でコストの負担が大きいと判断。長年のアドオンやカスタマイズが新システムに持ち込まれ、非効率な業務までそのまま引き継がれる懸念もありました。そこでゼロベースで選定し、延べ12製品を比較検討しました。

結果

クラウドネイティブのOracle NetSuiteを採用しました。

請求書・支払明細書の電子作成・送付により、帳票の送付にかかる外部への支払いコストは約73%削減、内部の作業コストは約80%削減。33種類の帳票のうち26種類を完全に電子化し、作成と送付を自動化しました。月次決算の分析時間は、月5〜10時間から月2〜3時間になりました。

途中で導入パートナーをベンチャーネットに交代し、予定どおり2025年10月1日にカットオーバー（本番稼働）しています。

アペックス社の導入事例ページ／アペックス社の導入事例詳細（PDF）

株式会社南海エクスプレス：受発注・在庫情報を統合し、物流現場の非効率を解消

株式会社南海エクスプレスは、1950年に前身企業が創業して以来、南海電鉄グループの国際物流事業を担ってきた企業です。物流オペレーターにとどまらず、荷主企業への業務設計支援や情報システム提案までを行っています。

課題

顧客企業（輸入食品販売）では、出荷依頼や欠品連絡を電話・メールで受け、手作業で取りまとめていました。

店舗側でも、物流センターや他店舗の在庫状況をリアルタイムで確認する仕組みがなく、Excelによる個別管理が常態化。南海エクスプレス自身も、配送依頼後の在庫引当やデータ登録を手作業で行っていました。

結果

NetSuite採用により、受発注・在庫・配送に関わるデータが一元化され、本部・店舗・物流センター間で情報をリアルタイムに共有できる環境が整いました。

注文の取りまとめ作業が不要となり、業務工数が大幅に削減。店舗側では他店舗・物流センターの在庫状況をNetSuite上で即座に確認できるようになり、欠品対応や販売機会損失の抑制につながっています。

南海エクスプレス社の導入事例ページ

事例に共通すること

3社に共通するのは、システムを入れたことより、経営の動き方が変わったことです。

数字が早く見え、情報がつながり、判断が速くなり、現場の負担が減りました。

成果の中心にあったのは、機能の多さではなく情報がつながることでした。

ベンチャーネットならこう見る

ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。

仕事は、ゼロからの導入より、他社のあとの引き継ぎと立て直し、そして他システムとの連携が多くを占めます。

途中から入るときも、ゼロから始めるときも、進める順番は変えません。

使うのは、次の2つの枠組みです。

見える化→整理整頓→Fit&Gap

1. 業務の見える化：今の業務の流れを、現場の実際のとおりに書き出す
2. 整理整頓：やめる業務、まとめる業務、標準にそろえる業務を分ける
3. Fit&Gap：整えた業務を、新しい製品の標準機能と突き合わせる

製品がすでに決まっている会社でも、見える化からやり直します。

整理整頓を飛ばすと、やめてよい業務まで新しいシステムに移すことになるからです。

標準に合わせる／開発する／残す

Fit&Gapで標準に収まらない業務が見つかったら、選択肢は3つです。

• 標準に合わせる：業務のやり方を製品に合わせて変える。開発の費用はかからない
• 開発する：アドオン開発や連携開発で補う。競争力に直結する部分に絞る
• 残す：その業務は新しいシステムに載せず、今のやり方のまま残す

3つのどれにするかは、見える化の後に決めます。

先に「開発する」と決めると、アドオンや連携の開発が積み上がり、費用と期間を押し上げます。

進める前には、次の3つを社内で答えられるようにしておいてください。

• 期限はいつか：保守期限・契約の更新・ハードウェアの寿命のうち、最も早いのはいつか
• 何が困っているか：システムの古さか、業務の流れか、データの分断か
• 誰が決めるか：部門の利害がぶつかったとき、最終的に決める人は誰か

今日できること｜「期限と困りごと」を1枚にまとめる

次の表を、1時間で埋めてみてください。

項目	記入例	自社
今のシステムの名前とバージョン	販売管理：○○ Ver.5
保守期限・契約の更新日	2028年3月
仕組みを分かる担当者の数	1人
表計算でつないでいる業務	在庫の月末の集計
月次の締めにかかる日数	10営業日
いちばん困っていること	在庫の金額が月末まで分からない

最も早い期限から2年を引いた日が、検討を始める目安の日です。

その日がすでに過ぎていれば、選択肢を比べる段階から始めます。

表の「表計算でつないでいる業務」と「担当者の数」は、5-1の要因のうち機能範囲と社内の体制の見当にもなります。

よくある質問

Q1. 基幹システムのリプレイスとは何ですか

中核業務のシステムを別の製品やサービスに入れ替えることです。

販売・購買・在庫・会計などのシステムが対象です。

今のシステムを別の環境に移すマイグレーションや、ゼロから作り直すリビルドとは区別します（第1章）。

Q2. リプレイスの費用はどれくらいかかりますか

機能範囲・開発の量・社内の体制・ユーザー数の4つで大きく変わります。

見積もりは、ライセンス・導入支援・運用保守の3つを合わせた総額で比べます。

NetSuiteのライセンスはミニマム構成で月額20万円〜が出発点で、構成により数百万円規模になることもあります（第5章）。

Q3. 期間はどれくらいかかりますか

一般には6〜12か月程度が目安です。

NetSuite公式の解説記事が示す一般的な目安です（出典：Oracle NetSuite公式、2026年9月確認）。

範囲を絞り開発をしなければ短く済むことがあります。

情シスがいない会社や、連携開発が多い会社ほど長くなりやすい傾向です（第6章）。

Q4. 通常の業務を回しながら進められますか

進め方を誤らなければ進められます。

会計など特定の領域から始める段階導入が向いています。

重要な業務は、切替の期間の手作業の手順を用意しておきます（第6章6-3）。

Q5. 社内に専門の人材が少なくても進められますか

社内で決めることと外部に任せることを分ければ進められます。

経営判断・業務の要件・現場の調整は社内で担います。

設定・開発・データ移行は、支援会社に任せるのが一般的な分担です。

情シスが少ない場合は支援を厚くする分、期間と費用が増えやすい点も見込んでおきます（第5章5-1）。

Q6. リプレイスしない方がよい場合はありますか

急がない方がよい場合もあります。

保守期限に余裕があり、目的もまだ言葉にできない場合です。

その場合も、替える時期と条件は決めておきます。

「保守期限の2年前に着手する」といった決め方です（第4章4-2）。

Q7. 中堅・中小企業でも効果は期待できますか

期待できます。

規模の大小より、情報の分断や属人化をどう解消するかが成果を左右します。

NetSuiteは、世界220地域・44,000社以上で使われているクラウドERPです（出典：Oracle NetSuite公式サイト、2026年9月時点）。

導入の事例は、NetSuiteの導入事例で紹介しています。

まとめ：替えるか・いつ・いくらかは、期限と中身で決まる

• リプレイスは、中核業務のシステムを別の製品に入れ替えること
• 流れは目的→比較→選定→作り込み→移行と切替→定着の6段階
• 期間の一般的な目安は6〜12か月程度。範囲・開発・体制で前後に振れる
• 費用はライセンス・導入支援・運用保守の総額で見る。差を生むのは機能範囲・開発の量・社内の体制・ユーザー数
• 進め方は見える化→整理整頓→Fit&Gap、収まらない業務は標準に合わせる／開発する／残すで決める
• 替えない選択肢も並べ、替える時期と条件を決めておく

保守期限の通知が届いたときに決めることは、3つでした。

替えるかどうかは、第4章の条件で見当がつきます。

いつ始めるかは、最も早い期限から逆算します。

いくらかかるかを決めるのは、載せる業務の広さ、開発の量、社内の体制です。

まず第13章の表を、1時間で埋めてみてください。

もう少し詳しく知りたい方へ

自社の場合に、替えるべきか、どの順番で進めるべきかは、期限と業務の状態で変わります。

「替えない方がよい」という結論も含めて、ご相談をお受けしています。

• 基幹システムのリプレイスを検討したい方へ：NetSuite 基幹システムリプレイスサービス
• 実際の画面を見てみたい方へ：NetSuite無料デモのお申込み
• まず話を聞いてみたい方へ：お問い合わせ