基幹システムの再構築｜費用・期間・進め方と移行の注意点

保守の期限が近い場合は「基幹システムの再構築はどう進めるのか」、パッケージの見積もりが予算を超えた場合は「基幹システムを再構築すべきか」、依頼先を比べたい場合は「弊社に頼むと、どう進むのか」の章から読むと、答えに早くたどり着けます。

基幹システムの再構築とは何か｜リプレイス・移行との違い

基幹システムの再構築とは、受注・在庫・生産・原価など、会社のお金とモノの流れを管理する仕組みを、業務に合わせて見直し、構築し直すことです。リプレイス（リプレース、入れ替え）は既存のシステムを別のシステムに置き換えること、移行はデータや処理を新しい環境へ移すことを指します。「刷新」を含めて意味は重なるので、計画では業務、機能、データのどこを変えるのかを明示します。この記事では、個別開発に加えて、パッケージへの入れ替えも扱います。基幹システムの基本は基幹システムとはで解説しています。

多くの会社で問題になるのは、データが分かれていることです。管理の業務は販売管理や生産管理など複数のシステムに分かれ、現場の記録はExcelや紙に残っています。同じ取引先を部門ごとに別のコードで登録していると、全社の数字を集計するたびに対応を確かめる手間がかかります。基幹システムの再構築では、取引先や品目のコードをそろえ、部門をまたいでデータを照合、集計できる状態を目指します。

基幹システムを再構築すべきか｜延命・部分入れ替えの判断基準

機器の老朽化だけが問題なら、プログラムを残してサーバーを移す方法があります。業務を変えたい場合は、製品への入れ替えや個別開発を検討します。それぞれの違いは次のとおりです。

今の困りごとからは、次のように候補を絞れます。

再構築の目的は、月次集計にかかる日数、二重入力の作業時間、改修にかかる期間などで具体的に決めます。今の値と目標、稼働後に確かめる担当者を決めると、残す機能と作り直す機能の優先順位を付けやすくなります。パッケージ、クラウドERP、個別開発の比べ方は、基幹システム開発のサービスページで説明しています。

基幹システム再構築の費用と期間はどのくらいか

費用と期間は、替える範囲で大きく変わります。公開されている目安は次のとおりです。この数字は開発会社の解説にある経験上のもので、調査統計ではありません。

出典：シースリーインデックス「基幹システムの費用相場」（2026年8月更新）。弊社の価格ではありません。

同じ記事は、期間の目安をスクラッチ開発（既製品を使わず一から開発すること）で6か月〜2年、パッケージ導入で3か月〜1年としています。実際の開発費用は、対象の現行システムを調べてからでないと、正確には見積もれません。

複数の見積もりを比べるときは、開発費や製品の利用料に加えて、データの整理と移行、他のシステムとの連携、操作研修、新旧の並行運用、稼働後の保守が含まれているかを確かめます。比べる年数をそろえ、現場の担当者が調査やテストに使う時間も見込みます。

基幹システムの再構築はなぜ遅れるのか

一般社団法人日本情報システム・ユーザー協会（JUAS）の調査では、システム開発の規模が大きいほど、工期の遅延と予算の超過を答えた割合が高くなりました。規模は人月（1人が1か月でこなす作業量）で表します。500人月以上の区分では、工期が「予定より遅延」が47.8%、予算が「予定より超過」が42.2%です。10人月未満の区分では、それぞれ9.6%と6.0%です。基幹システムに限らない、システム開発全体の数字です。

JUASが工期の遅延を答えた企業に理由を聞いた結果（複数回答）では、計画時の考慮不足が52.5%、想定以上の現行業務・システムの複雑さが48.8%、仕様変更の多発が42.4%でした。基幹システムの再構築に当てはめると、発注する会社は、今の業務の例外処理と、誰も全体を把握していない処理を着手前に調べる必要があります。

経済産業省のレガシーシステムモダン化委員会の総括レポートの発表（2025年5月）も、ユーザー企業に対して、システムの可視化を進め、現行踏襲を見直すことを求めています。今の仕様をそのまま写すと、不要な処理も新しいシステムに持ち込むことになります。

基幹システムの再構築はどう進めるのか｜現行調査から運用までの進め方

この章から「本番切り替えの前に何を確かめるのか」までは、実務を担当する方向けの内容です。

最初に行う現行調査で見落とされやすいのは、画面に出てこない運用です。手で直している数字や特別な取引先の処理は、システムの資料を読んでも分かりません。発注する会社の取りまとめ担当者と開発会社が現場の担当者に聞き取り、使っている機能、データ、連携先、例外の処理を一覧にします。

保守の期限がある場合は、切り替え後に安定して使う期間と予備を確保してから本番の日を決め、移行リハーサル、受入テスト（発注する会社が、業務に使えるかを確かめるテスト）、開発、要件定義、現行調査の日程を逆算します。間に合わない場合は、延長保守ができるかと、先に移す業務を検討します。

発注前に、各工程で何を決め、どの文書を残すのかを開発会社に確認してください。弊社の資料で使っている工程と文書の例を示します。呼び方と順番は会社によって変わります。

移行方式はどう選ぶのか｜一括・段階・並行・パイロットの違い

基幹システムの移行方式は、業務を止められる時間、業務や拠点を分けて移せるか、新旧を並行して動かせるかで選びます。業務どうしのつながりも確かめます。たとえば生産だけを先に移して在庫と原価を旧システムに残すと、材料の払い出しや完成入庫のデータを新旧でつなぐ必要があります。

参考：ISSOH「システムリプレイスの移行方式」（2026年7月）、マネーフォワード「システムリプレイス」（2026年4月更新）をもとに、弊社で整理しました。

方式は組み合わせられます。在庫は拠点ごとに段階で移し、請求の計算結果は旧システムと比べて確かめる、といった形です。新旧の計算結果を照合する前に、照合する項目と、どこまでの差を許容するかを決めます。並行運用を終えて新システムだけで処理する条件も、先に定めておきます。

データ移行で何を決めるのか｜マスタ・履歴・進行中の取引

基幹システムのデータ移行では、マスタの重複の整理、移す履歴の範囲、新旧のコードの対応、進行中の取引の扱い、移行後の照合の基準を決めます。旧システムと新システムでは項目の持ち方が違うので、ファイルを移すだけでは済みません。

どの作業を開発会社が担い、どの作業を発注する会社が担うのかも、見積もりの段階で確かめます。どのコードを残すかは、業務を知る現場の担当者が判断する必要があります。そのため、マスタの整理をすべて開発会社に任せるのは難しく、現場の協力が欠かせません。

本番切り替えの前に何を確かめるのか｜チェックリスト

発注する会社と開発会社は、本番の前に次の項目を確かめます。マクティズムのチェックリスト（2026年7月）を参考に、弊社で整理しました。

受入テストでは、受注、資材の手配、製造、検査、出荷、売上、月次の締めまでを同じ取引で通して試します。製造業なら、分納、再加工、仕掛品、部品表、ロット、棚卸差異も確かめ、数量と金額が想定どおりになるかを業務の責任者が確認します。

仕様書がなく、作った人もいないときはどうするのか

動いているシステムの入力と出力を比べれば、処理の中身をたどれることがあります。弊社が受注データの変換ソフトを作り直した事例では、作成者が退職してパスワードが分からず、仕様書もありませんでした。弊社は変換前と変換後のデータから元の処理をたどり、取引先22ファイルすべてを変換できることを確かめてから開発しました。ただし、これは1つのソフトの例です。規模の大きいシステムでは、データを取り出せるかどうかを要件定義の中で確かめる必要があります。

社内では誰が関わるのか

発注する会社には、少なくとも業務を知る現場の担当者、全体をまとめる担当者、最後に決める責任者の3役が要ります。兼務でもかまいませんが、要件定義の期間は決めることが集中します。JUASの調査でも仕様変更の多発は遅れの理由の上位に入っているので、取りまとめ担当者は、要件定義の節目で、必要な機能と再構築の範囲を決裁者に確認してもらいます。開発の途中で、合意した方針が覆るのを防ぐためです。

弊社に頼むと、どう進むのか

要件定義の1〜2か月は、お客様に今の業務をご説明いただき、必要な機能をご確認いただきます。その内容をもとに、弊社が基本的にフルスクラッチで開発します。全体を作り直す場合で半年から1年が目安で、替える範囲と移行の条件によって変わります。開発の後も、受入テストと操作の練習にはお客様の担当者に入っていただきます。完成後は伴走支援を続けられます。費用は個別にお見積もりします。作るものの形は、登録なしで触れる基幹システムの体験デモで確かめられます。

よくある質問

登壇・セミナー実績

開催レポートを読む →

開催レポートを読む →

神戸商工会議所・石川県庁など、各地の商工会議所や自治体でAI活用セミナーに登壇しています。現場で得た知見をもとに、上場企業を含むさまざまな規模の会社のAI導入を支援しています。