基幹システムの刷新｜老朽化と2025年の崖対策

01はじめに｜この記事でわかること

要点：この記事は、稼働から10年以上たった基幹システムの入れ替えを考えている経営者・情報システム担当の方に向けたガイドです。老朽化のサイン、刷新の4つの進め方、費用と期間の目安、そして進め方の手順までを一度に確認できます。

「動いてはいるけれど、中身がわかるのは一人だけ」。「改修を頼むたびに、見積りが前回より上がる」。基幹システムの相談は、たいていこの2つの言葉から始まります。

止まっていないので緊急ではない。でも、このまま使い続けるのも不安。その宙ぶらりんの状態が、いちばん判断を先延ばしにさせます。この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発の現場で使っている判断の順番をお伝えします。

まずは全体像をつかめる解説動画をご紹介します。

02基幹システムの刷新とは｜何を入れ替えるのか

要点：基幹システムの刷新とは、販売・在庫・生産・会計といった会社の土台になっている仕組みを、新しい基盤に作り替えることです。画面だけを新しくする改修とは別物で、データの持ち方と業務の流れまで見直します。

基幹システムという言葉の範囲は、会社によって少しずつ違います。多くの場合、次の業務のどれかが含まれます。

• 販売・受発注。見積から受注、出荷、請求、入金までを扱います。詳しくは販売管理システムの機能と導入の進め方で解説しています。
• 在庫・購買。入出庫と発注点を管理します。在庫管理システムの開発で費用と機能の考え方をまとめました。
• 生産・工程。製造指示と進捗を追いかけます。製造業では、ここが刷新のいちばんの難所になります。
• 会計・人事。仕訳や給与を扱う領域です。法改正の対応が必要なため、パッケージを使う会社が多くあります。

刷新と改修は分けて考えてください。改修は今の仕組みに機能を足す作業、刷新は土台そのものの入れ替えです。改修を10回重ねても老朽化は止まりません。継ぎ足した分だけ、中身は読みづらくなります。

03「2025年の崖」とは何だったのか

要点：「2025年の崖」は、経済産業省が2018年のDXレポートで示した警告です。老朽化したシステムを抱えたままだと、2025年以降に大きな経済損失が生じうると試算されました。年が過ぎた今も、課題そのものは残っています。

経済産業省のDXレポート（サマリー）では、老朽化・複雑化・ブラックボックス化した既存システムを放置した場合、2025年以降に年間で最大12兆円規模の経済損失が生じうると試算されました。同省は2024年度に「レガシーシステムモダン化委員会」を設け、2025年5月に総括レポートを公表しています。年号が過ぎても、議論は続いているということです。

崖の中身を分解すると、3つの困りごとに整理できます。

• 直せる人がいなくなる。開発当時の担当者が退職し、外部の開発会社も同じ技術を扱える人を確保できなくなります。
• データが取り出せない。売上や在庫の数字が中に閉じ込められ、経営判断に使える形で出てきません。
• サポートが終わる。OSやデータベースの提供元がメンテナンスを終了すると、脆弱性が見つかっても修正が届きません。

独立行政法人情報処理推進機構（IPA）のDX動向2025でも、レガシーシステムの刷新状況はデータ活用の前提として扱われています。数字を使いたいなら、まず土台を替える。その順番は変わっていません。

04老朽化のサイン｜刷新を考えるべき7つの症状

要点：老朽化は、止まる前に「重くなる」というかたちで現れます。改修費用の上振れ、担当者の属人化、データの取り出しにくさ。この3方向のどこかで詰まり始めたら、入れ替えを検討する時期です。

次の7つのうち3つ以上が当てはまるなら、検討を始めてよい段階だと考えています。

1. 改修の見積りが年々上がる。同じような修正なのに、前回より工数が増えていきます。中身が複雑になっている証拠です。
2. 触れる人が一人しかいない。その方が休むと改修が止まります。退職の話が出た時点で、判断は待ったなしです。
3. 設計書が残っていない。あっても実物と食い違っている。調査だけで数十万円かかる状態です。
4. Excelでの補完が増えている。システムに入れられない情報が、部署ごとのファイルにたまっていきます。
5. 他のシステムとつながらない。ECサイトやクラウドサービスとの連携ができず、CSVの手作業が残ります。
6. サポート期限が近い。OSやデータベースのメンテナンス終了日が公表されていて、更新の予定がありません。
7. 数字を出すのに時間がかかる。月次の集計に数日かかり、経営判断がいつも遅れます。

4番目のExcel補完は、見落とされがちなサインです。Excel業務をシステム化すべきサインでも触れましたが、ファイルが増え続けている場所は、システムが業務に追いついていない場所そのものです。

05稼働年数で不具合はどれだけ増えるのか

要点：稼働年数が10年を超えたあたりから、不具合の件数と対応工数は急に増えます。5年未満の年間4件に対し、20年以上は38件。工数では約13倍です。年数は、それ自体がリスクの目安になります。

注目していただきたいのは、件数より工数の伸び方です。件数は約10倍ですが、工数は約13倍になっています。1件あたりの調査時間が延びている、ということです。

06刷新を先送りすると何が起きるか

要点：先送りの本当の損失は、障害対応の時間ではありません。新しい取り組みができなくなることです。ECとの連携も、クラウドサービスの導入も、土台が古いままだと見送りが続きます。

先送りの影響は、次の順番で現れます。

• 予算がメンテナンスに固定される。使えるIT予算の大半が現状維持に消え、新しい投資の枠が残りません。
• 連携の依頼を断ることになる。取引先からEDIやAPIでのやり取りを求められても、応じられません。API連携の仕組みを知っていても、つなぐ先が古ければ実現できないのです。
• 人が採れなくなる。古い技術しか使わない環境は、若い技術者に選ばれにくくなります。
• 刷新の費用が上がる。先送りするほど、移行するデータも、解読すべき仕様も増えます。

最後の1点は見落とされがちです。待てば安くなる、という性質のものではありません。むしろ、毎年少しずつ高くなっていきます。

07IT予算はどこに消えているのか

要点：稼働20年以上のシステムを抱える会社では、IT予算の約86%がメンテナンスと運用に消えていました。新しい取り組みに回せるのは14%です。刷新の判断材料は、この配分の変化にあります。

この表を社内の稟議に使うと、話が進みやすくなります。「刷新に◯◯万円かかります」ではなく、「いまメンテナンスに消えている◯◯万円を、別の使い方に振り向けられます」と説明できるからです。費用の全体像はシステム開発の費用相場もあわせてご覧ください。

08刷新の4つの進め方｜方式ごとの向き不向き

要点：基幹システムの刷新には、リホスト・リライト・リビルド・パッケージ移行という4つの進め方があります。分かれ目は「業務の流れを変えるかどうか」です。変えないならリホスト、変えるならリビルドが軸になります。

実際には、この4つを組み合わせることが多くあります。会計はパッケージ、販売と在庫はリビルド、というように領域ごとに分けるやり方です。全社で1つの方式に統一する必要はありません。

どこまで自社で抱えるかは、別の判断軸になります。システム開発の外注と内製で、中小企業向けの基準を整理しています。

09方式別の費用と期間はどのくらいか

要点：リホストは300万円台から3〜6か月、リビルドは1,500万円以上で12〜24か月が目安です。金額の幅が大きいのは、移行するデータ量と例外取引の数で工数が変わるためです。

金額そのものより、上振れの要因に目を向けてください。どの方式でも、費用が膨らむきっかけは「文書化されていないもの」と「部署ごとに違うもの」です。

10一度に全部を替えない｜段階的な刷新の考え方

要点：全社を一度に切り替えると、止まったときの影響が大きくなります。領域を区切って順に替え、その間は新旧をデータ連携でつなぐやり方が現実的です。中小企業ではこの進め方が主流になっています。

段階的に進めるときの順番には、目安があります。

1. 出口に近い業務から。請求や帳票など、外に出ていく処理から替えると効果が見えやすくなります。
2. 入口の業務は後に。受注や生産指示は他の処理と密につながっているため、慣れてから着手します。
3. 会計はいちばん最後に。締めの時期を避けられず、間違いが許されない領域だからです。

切り替えの途中は、新旧のシステムが並んで動きます。この期間をつなぐのがデータ連携です。仕組みの基本はAPI連携とは何かで解説していますが、移行期間中の連携は「一時的なもの」と割り切って、作り込みすぎないほうがうまくいきます。

11データ移行が刷新でいちばん重くなる理由

要点：データ移行が重くなるのは、量が多いからではありません。同じ取引先が違う名前で登録されていたり、使われていない項目が残っていたりと、長年の運用でできた「ずれ」を直す作業に時間がかかるためです。

移行作業でつまずくのは、たいてい次の3つです。

• マスタの重複。同じ取引先が「株式会社◯◯」と「(株)◯◯」で別登録されています。統合の判断は、システムではなく人にしかできません。
• 項目の使い回し。備考欄に納期や特記事項を書き込む運用が続いていて、機械的には分解できません。
• 過去データの扱い。何年分を移すかで工数が変わります。全部移すのが正解とは限りません。

3つ目については、割り切りをおすすめしています。直近3年分だけを新システムへ移し、それ以前は参照用に古いデータを保管しておく。この方法で、移行の工数を大きく下げられます。

マスタの整理は社内でしか進められません。刷新の話が出た時点で、取引先と商品のマスタを一覧に出してみてください。着手が早いほど、後の工程が軽くなります。

12刷新の効果はいつ数字に出るのか

要点：効果がはっきり出るのは、稼働から6か月目以降です。最初の3か月は改修要望が増え、かえって忙しくなります。この停滞を織り込んでおかないと、社内で「失敗した」と受け取られてしまいます。

3か月後の滞留件数に注目してください。稼働前の22件から26件へ、いったん増えています。新しい画面を使い始めた現場から、要望が一気に出てくるためです。これは失敗の兆候ではなく、使われている証拠です。

13刷新プロジェクトの進め方

要点：基幹システムの刷新は、棚卸しから始めて、範囲を区切り、並行稼働を経て切り替えるという順番で進みます。最初の棚卸しに時間をかけるほど、後半の手直しが減ります。

基幹システムを刷新する5つのステップ

初回のご相談から本稼働まで、次の順番で進めます。

1. 現行システムの棚卸しをする。使っている機能、使っていない機能、外部とつながっている部分を一覧にします。使われていない機能が3割ほど見つかるのは珍しくありません。
2. 止まっている業務とメンテナンス費用を数える。どこで手が止まり、メンテナンスにいくら払っているかを数字にします。刷新の範囲と優先順位は、ここで決まります。
3. 方式を決めて範囲を区切る。領域ごとにリホストかリビルドかを判断し、第1弾で替える範囲を決めます。要件定義はこの段階で固めます。画面の使い勝手はワイヤーフレームで先に確認しておくと、後の修正が減ります。
4. データ移行と並行稼働を設計する。何年分を移すか、新旧をどうつなぐかを決めます。移行リハーサルは必ず2回以上行ってください。
5. 区切った単位で切り替える。締め1回分を並行で回し、数字が一致することを確かめてから完全に切り替えます。そのうえで次の範囲へ進みます。

開発会社に依頼する場合は、この棚卸しの結果をそのまま提案依頼の材料にできます。書き方はRFPの書き方にまとめました。

14よくある失敗｜稼働前に見えていた兆候

要点：刷新の失敗は、稼働してから起きるわけではありません。設計の段階で兆候が出ています。現場が打ち合わせに来ない、例外業務の話が後から出る、移行データの確認が後回しになる。この3つです。

• 現場が打ち合わせに来ない。情報システム部門だけで進めた刷新は、稼働後に「使いにくい」という声で止まります。実際に入力する方を、設計段階から1名は入れてください。
• 例外業務が後から出てくる。特定の取引先だけ違う締め日、特定の商品だけ違う単価。テスト段階で出てくると、追加費用と納期の遅れに直結します。
• 移行データの確認が後回しになる。「移行は最後の作業」と考えていると、直前に大量の不整合が見つかります。移行リハーサルは早い段階で始めてください。

3つに共通するのは、「後で考える」と先送りされた項目だという点です。開発会社を選ぶ際は、この3点を初回から聞いてくる相手かどうかを見てください。判断の基準はシステム開発会社の選び方にまとめています。

15相談前に整理しておきたい5項目

要点：相談前に5つの項目を書き出しておくと、初回の打ち合わせで概算まで進みます。稼働年数、対象範囲、例外業務、現在のメンテナンス費用、そして希望する時期です。

• 稼働年数と構成。いつ導入し、どの言語やデータベースで動いているかを確認します。わからなければ、メンテナンス会社に聞けば教えてもらえます。
• 刷新の対象範囲。販売だけか、在庫や会計まで含めるかを決めます。顧客管理の領域を含めるかも、ここで整理しておきます。
• 例外業務の一覧。締め日や単価が他と違う取引を、思いつく限り書き出します。数が多いほどパッケージから遠ざかります。
• 現在のメンテナンス費用。年間いくら払っているかを確認します。刷新後との比較材料になります。
• 希望する時期。サポート終了日や決算期など、動かせない予定があれば先にお伝えください。

この5項目がそろっていると、初回の打ち合わせで方式の候補と概算の幅までお話しできます。すべて埋まっていなくても構いません。

16まとめ｜判断の順番

要点：老朽化のサインを確かめ、メンテナンス費用の割合を数え、領域を区切って方式を決める。この順番で進めれば、基幹システムの刷新は判断しやすくなります。製品比較はいちばん最後です。

ここまでの内容を、判断の順番として並べ直します。

1. 7つの老朽化サインのうち、いくつ当てはまるかを確かめる。
2. IT予算のうち、メンテナンスと運用に消えている割合を計算する。
3. 刷新する領域を区切り、出口に近い業務から順番を決める。
4. 領域ごとに、業務を変えるかどうかで方式を選ぶ。
5. マスタを整理し、締め1回分を並行稼働させてから切り替える。

製品名から入ると、機能の多さで目移りします。自社の状態から入れば、必要な範囲は自然と絞られます。Webシステム開発のご相談では、この棚卸しからご一緒することが多くあります。中小企業のDXの進め方とあわせてご覧いただくと、全体の流れがつかみやすくなります。

17よくある質問

1. 基幹システムの刷新にはどのくらい費用がかかりますか？

方式によって幅があります。基盤だけを移すリホストなら300〜800万円、業務から作り直すリビルドなら1,500万円以上が目安です。パッケージへの移行は100〜1,000万円と幅が広く、追加開発の量で変わります。中小企業では、領域を区切って段階的に進めることで、1回あたりの負担を抑える例が多くあります。

2. 「2025年の崖」は過ぎましたが、いま刷新する意味はありますか？

年号は目安にすぎません。実際の課題は、直せる人がいなくなること、データが取り出せないこと、サポートが終了することの3つです。経済産業省も2025年5月にレガシーシステムのモダン化に関する総括レポートを公表しており、議論は続いています。年が過ぎたことは、判断を先送りする理由になりません。

3. 一度に全部を刷新すべきですか、段階的に進めるべきですか？

中小企業では段階的な進め方をおすすめしています。全社を一度に切り替えると、止まったときの影響が大きく、費用も一時に集中するためです。請求や帳票など出口に近い業務から替え、移行期間中は新旧をデータ連携でつなぐ形が現実的です。会計は最後に回すのが基本になります。

4. パッケージ導入と自社開発、どちらを選ぶべきですか？

判断の基準は、例外的な取引の数です。締め日や単価が他と違う取引が少なく、標準的な流れに業務を合わせられるならパッケージが適しています。商流が独特で、他システムとの連携も多い会社は、開発を検討する価値があります。両方を組み合わせ、領域ごとに使い分ける方法もあります。

5. 基幹システムの刷新にはどのくらいの期間がかかりますか？

リホストで3〜6か月、リビルドで12〜24か月が目安です。期間を左右するのは、文書化されていない仕様の量と、部署ごとに違う運用ルールの数です。事前に棚卸しを済ませておくと、調査の期間を短くできます。効果が数字に表れるのは、稼働から6か月目以降とお考えください。