基幹システム刷新とは｜進め方と移行方式の選び方

◆監修・編集責任者　小園 将隆　2026年9月4日

B2B EC-COLUMN

基幹システム刷新とは

基幹システム刷新とは、受注・出荷・在庫・購買・会計といった基幹業務を支える仕組みを入れ替える取り組みを指します。部分的な手直しではなく、作り直しや別方式への移し替えを伴う点が違いです。判断の起点になるのは老朽化した年数ではありません。保守を公式に続けられるか、業務の変化に追随できるかという2点です。本節では刷新と更新と改修の違い、対象となる業務領域の範囲、レガシーシステムと呼ばれる状態の見分け方を順に整理します。

刷新と更新と改修は、手を入れる深さが異なります。改修は現行の仕組みを保ったまま機能を足し引きする作業です。更新は同じ製品の版を上げたり、動かす機器を入れ替えたりする作業を指します。刷新はこの2つと違い、業務の流れと持つデータの形まで見直します。呼び分けが曖昧なまま議論を進めると、予算の規模も体制も噛み合いません。

対象となる業務領域の範囲は、受発注、在庫、購買、生産、原価、会計の6領域にまたがります。卸売や商社では受注から出荷指示までの流れが中心となり、製造業では生産計画と原価の計算が加わります。周辺には取引先との受け渡しを担う仕組みや、倉庫の運用を支える仕組みが並びます。範囲を決める作業は、どこまでを一度に入れ替えるかを決める作業と同じです。

レガシーシステムと呼ばれる状態は、稼働年数だけで決まるものではありません。公的機関の委員会が2025年に公表した総括レポートは、脱却に向けた論点を技術と業務の両面から整理しています¹。このレポートは経済産業省 商務情報政策局 情報産業課がまとめたもので、2025年5月28日付で公開されています1。同じ委員会が2025年に開設した特設ページでは、モダン化の考え方が公開されています^*2。実務上の目安になるのは、改修が積み重なって仕様を説明できる担当者が減り、変更のたびに影響範囲を読み切れなくなった状態です。

老朽化の度合いは、3つの観点で見ると判断しやすくなります。第一に、製品や基盤の保守が公式に続くかどうかです。第二に、業務の変更依頼に対する見積もりと修正が期日内に収まるかを見ます。第三に、現行仕様を説明できる担当者が社内に残っているかどうかも確かめます。3つのうち2つが崩れていれば、検討に入る時期に来ています。

刷新の目的を置き換えだけに限定すると、稼働後の効果が見えにくくなります。受注のやり取りを紙や電話から電子的な手段へ移す、在庫の引き当てを日次から即時に切り替えるなど、業務側の到達点を先に決める進め方が求められます。到達点が定まれば、機能の要否を判断する基準も決まります。到達点のない要件は、後から削る根拠を失います。

刷新は情報システム部門だけで完結する案件ではありません。受注の締め時刻や検収の条件など、取引先との約束事を変える判断が必ず含まれます。業務部門と経営層が判断に加わる体制を最初に用意しておくと、後戻りを減らせます。体制を後から作ると、要件定義の途中で決裁待ちの時間が積み上がります。

刷新を検討する背景と判断のタイミング

刷新を検討する合図は、保守を続けられるかどうかと、業務要件の変化に追随できるかどうかの2つです。基幹系のパッケージには、公式の保守方針として2040年までの保守提供時期を公表している製品もあります³。この方針は2020年に示されたもので、2026年9月時点でも同じ内容が掲示されています3。期限が先に見えても、要件定義から稼働までの期間を差し引くと、着手できる余地は想像より狭くなります。判断は感覚に頼らず、保守期限の確認、業務要件の変化、内製できる範囲、投資判断の時期という4つの材料をそろえて進めます。

保守期限の確認は、製品ごとの公式の告知を当たるところから始めます。主流の保守と延長の保守では対象製品と条件が分かれるため、原典で読み分ける必要があります³。先に触れた保守方針は、SAP Business Suite 7とSAP S/4HANAという2つの製品系統を対象として、2040年までの保守提供時期を示しています（2026年9月時点）3。社内の資料や口頭で伝わってきた期限は更新が止まっている場合があり、確認の手順を残しておくと判断が揺れません。基盤やデータベース、周辺のミドルウェアの期限も同じ一覧に並べます。

業務要件の変化への追随のしにくさは、追加開発の履歴に表れます。取引先ごとの帳票や締めの例外が個別開発として積み上がると、改修のたびに影響範囲の確認へ時間を取られます。年度ごとの改修件数と平均の対応日数を並べれば、現場の実感を数で説明できます。件数が増えているのに対応日数も伸びている場合、限界が近いと読めます。

刷新の必要性を社内で説明する場面では、公表資料の年版を確かめて引くと議論が主観に寄りません。業界団体の調査は2025年度に957社の有効回答を集め、企業のIT投資の動きを追っています⁴。公的機関がまとめたDXの動向調査は2026年に公表され、国内企業1,799社を対象に取り組みの状況を調べています5⁶。このうちプレス発表は2026年7月16日付で公表され、1,799社の調査結果の要点を示しています6。調査ごとに対象と方法が異なるため、数値を並べる際は単純比較を避けます。国の情報通信白書も2026年に令和8年版が公表されました^*7。

内製できる範囲は、人数だけでなく知識の分布で決まります。現行仕様を説明できる担当者、新しい基盤を扱える担当者、業務側で判断を下せる担当者の3種類が要ります。いずれかが欠けたまま着手すると、要件定義の途中で判断が止まります。欠けている役割を外部から補うのか、期間をずらして育てるのかを先に決めます。

投資判断の時期は、保守期限から逆算して決めます。要件定義、設計と開発、データ移行、並行稼働、稼働後の安定化という5つの塊を置き、それぞれの期間を業務の繁忙と重ねます。期末や棚卸しの時期を切り替えに当てると、現場の負荷が跳ね上がります。逆算の結果、今期のうちに予算を確保する必要が見えることもあります。

今すぐ着手しない判断も成り立ちます。保守が続き、改修が期日内に収まり、仕様を説明できる担当者が残っているなら、記録と監視を整えながら次期に備える選択も取れます。待つ場合でも、判断の材料と見直しの時期を文書に残しておくと、次の検討が短く済みます。判断を口頭で終わらせると、担当者が替わった時点で振り出しに戻ります。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

刷新の進め方と工程の全体像

刷新の工程は、現行の可視化、あるべき業務の定義、移行と並行稼働の3段階に分けると管理しやすくなります。公的機関が2018年に公表した再構築のユーザガイド第2版は、利用側と開発側が共有すべきリスクと対策を工程ごとに整理しています^*8。3段階の順序は入れ替えられません。可視化の結果が業務の定義の材料になり、定義の結果が移行の設計の前提になるためです。最初の段階を省くと、後の段階で要件が膨らみ、費用と期間の両方が伸びます。

現行の可視化は、業務の棚卸しから始めます。部門ごとの手順、例外処理、取引先ごとの約束事を書き出し、システムに載っていない運用も拾います。表計算や手作業で補っている処理は、担当者の記憶にしか残っていない場合があります。棚卸しの粒度は、画面や帳票ではなく業務の単位でそろえると比較しやすくなります。

連携先の洗い出しは、刷新の影響が社外へ及ぶ範囲を決める作業です。受け渡しの相手、項目、頻度、方式を一覧にし、取引先との取り決めが絡む部分に印を付けます。企業間の受発注や倉庫の運用を支える仕組みとの接点は、切り替え当日の手順にも関わります。ここが抜けると、稼働の直前に出荷が止まる事態を招きます。

あるべき業務の定義では、現行の再現ではなく到達点を先に置きます。業務要件の整理では、変える業務と残す業務を分け、変える理由を業務側の言葉で書きます。受注の入力を電子的な受け渡しへ移す、在庫の引き当てを即時に切り替えるといった到達点があると、機能の要否を判断できます。理由の書かれていない要件は、後で削る根拠がなくなります。

適合と差異の判定は、費用と保守の負担を左右する分岐点です。標準機能で賄える範囲、運用の工夫で吸収できる範囲、個別開発が要る範囲の3つに仕分けます。個別開発が増えるほど、稼働後の版上げのたびに確認の手間が積み上がります。仕分けの結果は判断者が分かる形で残し、後から蒸し返さない取り決めを添えます。

移行と並行稼働は、工程の中で見積もりが外れやすい部分です。データ移行の設計では、移行対象の期間、重複や欠損の扱い、コード体系の読み替え規則を先に決めます。取引先コードや品目コードの不一致は、移行の直前ではなく可視化の段階で見つけておきます。移行の試行は1回で終わらせず、件数と差異の確認を繰り返します。

並行稼働の計画では、現行と新環境を突き合わせる期間と対象を決めます。全件を人手で照合する進め方は現実的ではないため、金額の合計や件数による照合の方法を先に用意します。切り替えの判定基準と、戻す場合の手順もあわせて文書にします。判定基準がないまま当日を迎えると、判断が担当者の勘に委ねられます。

移行方式の選択肢と比較の観点

移行方式は、再構築、現行資産の移行、パッケージ活用、段階的な刷新の4つに整理できます。方式に優劣はなく、保守期限までの残り時間、業務を変える意思、社内で確保できる体制の3つで選び方が決まります。同じ会社でも領域ごとに別の方式を採る判断は成り立ちます。会計は標準機能へ寄せ、受発注は個別性を残すといった組み合わせです。方式を先に決めてから業務を合わせる進め方は、後戻りの原因になります。

再構築は、業務の流れとデータの持ち方を作り直す方式です。業務の作り直しを伴う場合に向きますが、期間と体制の負担が大きく、要件定義に人手を割けない状態では進みません。現行の仕様を説明できる担当者を確保できるかどうかが、着手の可否を分けます。要件定義の期間を短く見積もると、設計の後半で手戻りが集中します。

現行資産の移行は、業務の作りを保ったまま動かす場所や方式を移す考え方です。保守期限が迫る場合に取られ、期限への対応を先に済ませられます。業務改善が後回しになりやすく、移した先で同じ課題が再び現れる点には注意が要ります。移行の後に業務を見直す計画まで含めて説明すると、投資の説明が通りやすくなります。

パッケージ活用は、製品の標準機能に業務を寄せる考え方です。標準機能に業務を寄せられる場合は導入までの期間を短くできますが、差異を個別開発で埋めるほど費用と保守の負担が増えます。差異の判定を要件定義の早い段階で終えると、後半の追加開発を抑えられます。差異を残す判断をした部分は、残す理由を記録に添えます。

段階的な刷新と一括の刷新は、影響範囲の分け方が違います。段階的な刷新は影響範囲を分割できる場合に向き、1回あたりの検証量を減らせます。ただし現行と新環境の二重運用の期間が伸び、つなぎの仕組みを作る費用が別に発生します。一括の刷新は切り替えが1回で済む代わりに、当日の判断が集中します。

自社に合う方式を選ぶ判断軸は、3つに絞ると議論が進みます。第一に、保守期限までに間に合う方式かどうかです。第二に、業務を変える意思決定を業務部門が担えるかを見ます。第三に、稼働後の保守を誰が担うかを決められるかどうかも欠かせません。3つのいずれかに答えられない段階では、方式の決定を急がない判断が妥当です。

方式の比較を費用の総額だけで並べると、判断を誤ります。稼働後の保守の負担、業務の変更への対応しやすさ、担当者が入れ替わったときの引き継ぎやすさを同じ表に並べます。公的機関が2018年に第2版として公表した再構築のユーザガイドは、想定されるリスクと対策を整理しており、比較の項目を組む際の下敷きになります^*8。比べる項目を先に決めてから各方式を評価すると、後から項目が増える事態を避けられます。

費用と推進体制の考え方

費用は、対象範囲、拠点数、連携先の数、移行データの量、個別開発の量という5つの要因で動きます。金額の相場を先に置くと、範囲の議論が金額に引きずられます。範囲を決め、方式を選び、そのうえで見積もりを取る順序が現実的です。推進体制は、業務側の判断者、情報システム側の取りまとめ役、開発を担う側の3者で組みます。3者のいずれかが欠けると、決められない案件になります。

費用が動く要因のうち、見積もりの差が出やすいのは個別開発の量です。標準機能で賄えない業務が増えるほど、開発だけでなく検証と稼働後の保守も積み上がります。拠点数と連携先の数は、検証の回数と切り替え当日の手順の量に直結します。移行データの量は、変換の設計よりも整備の手間に効きます。

予算計画で抜けやすい項目は、開発以外の部分に集まります。移行データの整備、利用者の教育、並行稼働の期間中の二重入力、旧環境を止めるまでの並走費用、稼働後の改修枠の5つです。いずれも初期の計画では小さく見積もられがちで、期間が延びるほど負担が増えます。見積書の項目に無い作業は、社内の人件費として姿を現します。

内製で進める場合に必要な知識は、6つの領域にまたがります。現行仕様の読解、業務側の意思決定、データ変換の設計、基盤と権限の設計、検証の設計、利用者教育です。これらを通常業務との兼務で回すと、月次の締めや繁忙期に作業が止まります。専任と兼務の割合を着手前に決め、抜けた工数を誰が埋めるかまで決めておく必要があります。

社内担当と開発側の役割分担は、決める人と作る人を分けて書き出します。業務の是非を決めるのは業務側で、代替案を示すのが開発側です。この分担が曖昧だと、業務の判断を開発側へ委ねる場面が生まれ、稼働後の評価が下がります。会議体ごとに決裁の範囲を定め、決められない事項の上げ先も決めておきます。

切り替えの失敗は、費用よりも業務の停止として現れます。出荷指示を出せなければ当日の出荷が止まり、受注残と問い合わせが同時に増えます。取引先との受け渡しが止まれば、相手側の生産や販売にも影響が及びます。復旧の判断基準と戻す手順を用意していない場合、停止の時間はさらに延びます。

内製と外部委託の違いは、費用の総額よりも失敗の確率の下げ方に表れます。外に委ねる範囲を決める際は、業務の判断を社内に残し、移行や検証の設計を委ねる分け方が取りやすい形です。業界団体の調査報告書は2026年に全文が無料公開されており、2025年度調査で集まった有効回答957社分の結果を、社内の説明資料の裏付けとして使えます⁹4。委託先を選ぶ段階では、同種の移行を扱った経験と、稼働後の保守まで担えるかを確かめます。

つまずきやすい論点と社内合意の進め方

刷新がつまずく場面は、技術よりも合意の取り方に起因します。現行踏襲の要求、要件の膨張、経営層と現場の温度差の3つが代表的な論点です。いずれも要件定義の初期に扱えば費用の増加を抑えられますが、後半で表面化すると設計のやり直しにつながります。進め方としては、現行踏襲の要求を受け止め、要件の優先順位を付け、決定事項の記録を残し、経営層への報告へ進む順序が有効です。

現行踏襲の要求は、頭から否定しても解決しません。求める理由を業務単位で聞き取り、法令や取引先との取り決めに基づくもの、業務の効率に基づくもの、慣習として続いてきたものの3つに分けます。前の2つは要件として残し、3つ目は代替案を示して判断を仰ぎます。理由の分類を先に済ませると、感情の対立が論点の議論へ変わります。

要件の膨張は、締め切りと窓口を決めていない場合に起こります。要件の追加は受け付ける窓口を1つに絞り、影響と費用を添えて判断者へ回す手順にします。要件の優先順位は、業務の停止につながるもの、期日の遵守に関わるもの、効率を上げるものの順で並べます。締め切り後の追加は次期の改修枠へ送る取り決めを、着手前に共有します。

決定事項の記録は、蒸し返しを防ぐ仕組みとして働きます。決めた内容だけでなく、選ばなかった案とその理由も残します。担当者が異動した後でも、記録があれば議論を最初からやり直さずに済みます。記録の置き場所を1か所に定め、参照できる範囲を関係者へ開いておきます。

経営層への報告は、進捗の報告ではなく判断の依頼として組み立てます。判断軸、残る課題の件数、決裁が必要な事項を1枚にまとめ、選択肢ごとの影響を並べます。保守期限までの残り期間と、着手を遅らせた場合に狭まる選択肢を示すと、投資の議論が進みます。2026年7月16日に公表された国内企業1,799社の調査結果のように、時点と対象の分かる資料を添えると前提がそろいます⁶。公的機関の再構築のユーザガイドは、利用側と開発側が共有すべきリスクを整理しており、説明の下敷きに使えます8。

現場との合意は、説明会を1回開いて終わりにはできません。部門ごとに代表者を出してもらい、要件の確認と検証に参加してもらう進め方が定着につながります。参加した担当者は、稼働後の問い合わせ窓口としても働きます。関与のない部門ほど、稼働直後の不満が強く出ます。

合意形成の速度は、決められない事項の扱いで決まります。判断が保留になった事項は一覧にし、期限と判断者を必ず付けます。保留のまま設計へ進むと、後で作り直す範囲が広がります。週ごとに保留の件数を確認すると、遅れの兆しを早く捉えられます。

刷新後に成果を出すための運用と拡張

刷新の成果は、稼働の瞬間ではなく稼働後の運用で決まります。定着に向けた運用設計と教育、外部システムとの連携余地の確保、企業間取引のデジタル化への発展の3点を、要件定義の段階から計画へ入れます。稼働後に着手すると、改修の予算を別に確保する必要が生じます。国が2025年に公表した令和7年版の情報通信白書は、各国企業のデジタル化の状況と推進上の課題を整理しています¹⁰。翌年の2026年には令和8年版が公表されており、社内の説明では、こうした公表資料を年版とともに引くと、議論の前提がそろいます7。

定着に向けた運用設計は、問い合わせの受け方から決めます。誰が一次対応を担い、どこまでを社内で判断し、どこから開発側へ回すかを稼働前に決めておきます。手順書は画面の操作ではなく業務の流れで書くと、異動してきた担当者が読んでも通じます。稼働の直後は問い合わせが集中するため、期間を区切って人を厚く置きます。

教育は、役割別に2回へ分けると効果が出ます。切り替えの前は新しい業務の流れを扱い、切り替えの後は例外処理と連絡先を扱います。全員へ同じ内容を一度に流す方式では、担当していない機能の説明が記憶に残りません。教育の記録を残せば、稼働後の問い合わせの傾向と突き合わせて次の教育を組めます。

稼働後の評価は、システムの稼働率だけでは足りません。受注入力にかかる時間、月次の締めに要する日数、問い合わせの件数など、業務側の指標を3つ程度に絞って追います。指標は稼働前の値を測っておかないと比較できないため、現行の可視化の段階で取得します。四半期ごとに見直し、改善の打ち手と結び付けます。

外部システムとの連携余地は、稼働後の拡張の余地を左右します。接続の方式は個別の作り込みへ寄せず、広く使われている受け渡しの形式に合わせておきます。連携先が増えるたびに新しい仕組みを作る進め方では、保守の負担が積み上がります。権限と履歴の扱いも、連携の設計と同時に決めておきます。

企業間取引のデジタル化は、刷新の延長線上に置けます。受発注を電話や紙から電子的な受け渡しへ移すと、入力の重複と行き違いを減らせます。取引先ごとに準備の状況が異なるため、紙と電子が併存する期間を前提に設計します。展開の順序は取引量の大きい先から進め、手順を固めてから広げます。

稼働後の運用を社内だけで担うか、外部と分担するかは着手の前に決めます。必要な知識は、業務の判断、データの整備、基盤の監視、連携先との調整という4領域にまたがります。兼務で回すと改善の作業が後回しになり、刷新の効果が薄れます。2025年5月28日付の総括レポートも、脱却を一度の構築で終わらせず継続の取り組みとして扱う必要を示しています^*1。分担を先に決めておけば、稼働後の改善を止めずに続けられます。

よくある質問

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

期間は対象範囲、拠点数、連携先の数で変わるため、一律の目安は示せません。決め方としては、保守期限から逆算し、要件定義、設計と開発、データ移行、並行稼働、稼働後の安定化という5つの塊に期間を割り付けます。繁忙期を切り替えに当てないだけでも、現場の負荷を抑えられます。

刷新をせずに現行のまま使い続ける判断はできますか

条件がそろえば成り立ちます。製品と基盤の保守が公式に続き、業務の変更依頼が期日内に収まり、現行仕様を説明できる担当者が社内に残っている場合です。3つのうち2つが崩れた時点で検討に入り、判断の材料と見直しの時期を文書へ残しておくと、次の検討が短く済みます。

パッケージの標準機能に業務を合わせる必要がありますか

すべてを合わせる必要はありませんが、差異を個別開発で埋めるほど費用と稼働後の保守が増えます。標準機能で賄える範囲、運用の工夫で吸収できる範囲、個別開発が要る範囲の3つに仕分け、仕分けの理由を記録します。法令や取引先との取り決めに基づく差異は、残す判断が取りやすい部分です。

移行するデータはどこまで持っていけばよいですか

全件を移す前提を置かず、業務で参照する期間と、法令で保存が求められる期間を分けて決めます。過去分は新しい環境へ移さず、参照専用の保管へ回す方法もあります。移行の前に重複、欠損、コード体系の不一致を洗い出しておくと、移行の試行でつまずく回数を減らせます。

検討はどの部門が主導すればよいですか

情報システム部門だけでは決め切れません。受注の締め時刻や検収の条件など、取引先との約束事に関わる判断が含まれるためです。業務側の判断者、情報システム側の取りまとめ役、開発を担う側の3者で体制を組み、決める人と作る人を分けて書き出す進め方が取れます。

1. *1　出典：経済産業省 商務情報政策局 情報産業課「DXの現在地とレガシーシステム脱却に向けて　レガシーシステムモダン化委員会総括レポート」（2025）　経路
2. *2　出典：独立行政法人情報処理推進機構（IPA）「ITシステムのモダン化とは？　レガシーシステムモダン化委員会（特設ページ）」（2025）　経路
3. *3　出典：SAP SE「Maintenance 2040（SAP Business Suite 7およびSAP S/4HANAの保守方針）」（2020）　経路
4. *4　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「『企業IT動向調査2026』プレスリリース第1弾（2025年度調査・有効回答957社）」（2026）　経路
5. *5　出典：独立行政法人情報処理推進機構（IPA）「「DX動向2026」広がるAI導入、DXは変われるか」（2026）　経路
6. *6　出典：独立行政法人情報処理推進機構（IPA）「プレス発表　国内企業のDX動向・AI活用動向のポイントを公表（国内企業1,799社の調査）」（2026）　経路
7. *7　出典：総務省「令和8年「情報通信に関する現状報告」（令和8年版情報通信白書）の公表」（2026）　経路
8. *8　出典：独立行政法人情報処理推進機構（IPA）「SEC BOOKS：システム再構築を成功に導くユーザガイド 第2版〜ユーザとベンダで共有する再構築のリスクと対策〜」（2018）　経路
9. *9　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「最新調査報告書『企業IT動向調査2026』全文無料公開のお知らせ」（2026）　経路
10. *10　出典：総務省「令和7年版情報通信白書「各国企業のデジタル化の状況／デジタル化推進の課題」」（2025）　経路