「基幹システムがもう限界。でも、どこから手をつければいいのか」——販売・生産・会計を支える基幹システムの刷新を検討し始めた情シスやDX推進のご担当者から、私たちが最も多くいただく相談です。老朽化は分かっている。ただ、業務を止められない基幹システムだからこそ、進め方を間違えると数千万円規模の投資が“動かないシステム”に化ける。その怖さが一歩を鈍らせます。
結論から言えば、基幹システム刷新は「現状調査→要件定義→方式選定→移行設計→移行・稼働」の5ステップで進め、最初に現行業務の棚卸し(現行調査)へ最も時間をかけるのが成功の型です。 失敗の大半は技術ではなく、この上流工程の手抜きと「ベンダー丸投げ」から生まれます。この記事では、情シス領域のBPR・システム統合支援で私たちが繰り返し見てきた現場知見を軸に、公的資料(経済産業省・IPA)で裏を取りながら、失敗しない進め方を順序立てて解説します。
なお、なぜ刷新が急がれるのかの背景は2025年の崖とは?レガシーシステム放置のリスクと対策をわかりやすくで、システム刷新を含むDX全体の進め方は中小企業のDXの進め方|何から始めるかを5ステップで解説で整理しています。本記事はその中の「基幹システムを実際にどう刷新するか」に焦点を当て、進め方の5ステップに加え、方式の選び方・費用や期間の目安・移行の判断軸まで扱います。
基幹システム刷新とは?なぜ今やるべきなのか
基幹システム刷新とは、販売管理・生産管理・在庫・会計など、事業の根幹を支える情報システムを、老朽化・ブラックボックス化した現行システムから作り替えることです。 単なるバージョンアップではなく、業務のやり方(As-Is)ごと見直す点が特徴です。
なぜ今か。経済産業省は2018年のDXレポートで、老朽化した基幹システムを刷新できないと2025年以降に最大12兆円/年の経済損失が生じると警告しました(経済産業省 DXレポート(2018年))。その後2025年5月の「レガシーシステムモダン化委員会総括レポート」でも、レガシー脱却は道半ばで、大規模なモダン化は数年計画に及び、着手後の停滞でさらに長期化しやすいと指摘されています(経済産業省(2025年5月28日))。
刷新を先送りするほど、次の3つのコストが静かに膨らみます。
- 維持コストの増大:改修のたびに費用と工数がかさむ「技術的負債」が複利で積み上がる。
- ブラックボックス化:仕様を説明できる人がいなくなり、法改正・制度変更に追随できない。
- データを活かせない:システムが分断され、経営判断や生成AI活用(社内データのRAG化など)の足かせになる(参考:社内向け生成AIの構築方法|RAGと社内データ活用)。
つまり刷新は「古いから替える」ではなく、「変化に対応できる状態を取り戻す」ための投資です。
基幹システム刷新はなぜ失敗するのか?
基幹システム刷新の失敗は技術力より上流工程で決まります。最大の要因は、自社で要件を整理せずベンダーに任せきる「丸投げ」です。 私たちが現場で繰り返し見てきた失敗要因は、次の4つに集約されます。
| # | 失敗要因 | 何が起きるか |
|---|---|---|
| 1 | ベンダー丸投げ | 発注側が要件を握らず、出来上がったシステムが自社業務に合わない |
| 2 | 現行業務の理解不足 | 「現行と同じで」の一言で発注し、実際の運用が抽出されないまま設計が進む |
| 3 | 例外運用の抽出漏れ | 帳票の手修正・特定取引先だけの特別処理などが稼働直前に露見する |
| 4 | 目的が“更新”止まり | コスト削減か攻めのDXか目的が曖昧で、要件の優先順位が決められない |
IPAも、システム再構築の失敗を避ける鍵として「現行業務仕様の理解不足」の回避と、ユーザ企業とベンダ企業の目線統一、上流工程でのリスク共有を挙げています(IPA システム再構築を成功に導くユーザガイド)。
現場の所感(匿名事例①・中堅製造業):従業員300名規模の製造業で20年超稼働の販売・生産管理システムを刷新した案件では、要件をベンダーへ実質丸投げしていたため、現場が長年回していた「例外運用」(特定顧客向けの納期計算や手作業の在庫調整)が現行調査で拾えていませんでした。稼働直前のテストで判明した想定漏れは十数パターンに及び、並行稼働の期間を当初計画から2〜3か月延長せざるを得ませんでした(数字は匿名化した概算)。技術の問題ではなく、現行業務を言語化する工程を誰も担っていなかったことが原因です。
匿名事例②・流通業(移行方式の判断):複数拠点をもつ流通業の刷新では、当初「一括移行のほうが速い」と方式が決まりかけていました。しかし現行調査で拠点ごとに帳票の運用差が大きいと分かり、段階移行へ切り替え。最初に切り替えた1拠点で見つかった想定漏れを次拠点までに反映でき、全社停止という最悪シナリオを避けられました。方式は「速さ」ではなく「失敗したときの被害範囲」で選ぶ——この判断が明暗を分けます。
失敗要因の裏返しが、そのまま次章の「進め方」になります。
基幹システム刷新の進め方は?失敗しない5ステップ
基幹システム刷新は、次の5ステップで進めます。ポイントは、STEP1〜2の上流工程に全体の4〜5割の労力を割くことです。 IPAも「上流工程の強化」を成功条件に挙げています。

- STEP1 現状調査(現行調査):現行システムと業務を「機能・データ・連携・業務フロー」の4視点で棚卸しする。
- STEP2 要件定義(As-Is/To-Be):現状(As-Is)を踏まえ、あるべき姿(To-Be)と要件の優先順位を定義。標準機能と現場運用の差=Fit&Gapを洗い出す。
- STEP3 刷新方式の選定:再構築/マイグレーション/ERPパッケージの中から、目的と現状に合う方式を選ぶ。
- STEP4 移行方式の設計:一括移行・段階移行・並行運用のどれで切り替えるかを、業務停止リスクから設計する。
- STEP5 移行・テスト・稼働・定着:データ移行、テスト、並行稼働を経て本番へ。稼働後の定着・改善まで含める。
各ステップの所要感は、部門システムで数か月、全社の基幹システムでは1年以上に及ぶこともあります。以下、要点を掘り下げます。
STEP1・2の進め方は業務可視化がすべて
STEP1〜2は、実は「システムの話」というより「業務の棚卸し」です。ここは業務改善(BPR)の可視化とまったく同じ作法で進めます。現行の業務を洗い出す具体的な手順は業務棚卸しの手順|抜け漏れない洗い出し方、フロー化の描き方は業務フロー図の作り方|記号・粒度・テンプレ、可視化全体の考え方は業務可視化のやり方が実務でそのまま使えます。
現行調査では何を調べればいい?(現行調査4点セット)
現行調査は「機能・データ・連携・業務フロー」の4点を必ず調べます。私たちはこれを“現行調査4点セット”と呼び、どれか1つでも欠けると稼働直前に破綻します。
| 視点 | 調べること | 抜けると起きる事故 |
|---|---|---|
| ① 機能 | 現行システムのどの機能を、誰が、どの頻度で使っているか | 使われない機能まで丸ごと作り込み、コストが膨張 |
| ② データ | マスタ・トランザクションの種類・量・品質(重複/不整合) | 移行時にデータが載らない・二重計上が発生 |
| ③ 連携 | 他システム・EDI・帳票・Excel等との入出力インターフェース | 稼働後に「あの帳票が出ない」と業務が止まる |
| ④ 業務フロー | 正規の流れ+例外運用(手修正・特別処理・属人作業) | 例外が設計に入らず、現場が新システムを使えない |
特に見落とされるのが④の例外運用です。正規フローはマニュアルに書いてありますが、現場が回している例外は言語化されていません。ここを掘るには、システムの画面ではなく人に聞く必要があります。属人化した業務のほどき方は業務の属人化を解消する進め方と仕組み化のコツが参考になります。
なお、M&Aに伴う刷新(買収先と基幹を統合する)の場合は、この現行調査を買収前のITデューデリジェンスから引き継ぐと精度が上がります。詳しくはITデューデリジェンスの進め方|買収前に情報システムの何を見るかとM&A後のシステム統合の進め方|基幹・情シスの統合手順と注意点をご覧ください。
刷新方式は再構築・マイグレ・ERPのどれを選ぶ?
刷新方式は大きく3つ。「業務を作り替えたいか」「現行機能を活かしたいか」「標準に業務を合わせられるか」で選びます。 特定製品の優劣ではなく、自社の目的と現状で判断するのが原則です。
| 方式 | 概要 | 向くケース | 留意点 |
|---|---|---|---|
| 再構築(リビルド) | 業務要件から作り直す | 業務を抜本的に見直したい/独自性が競争力 | コスト・期間が最大。要件定義力が問われる |
| マイグレーション | 現行機能を維持しつつ基盤だけ刷新 | まず老朽化リスクを外したい/業務は当面維持 | 技術的負債を引き継ぐ懸念。延命策になりがち |
| ERPパッケージ導入 | 標準機能に業務を合わせる | 業務を標準化したい/属人化を減らしたい | 標準に合わせる覚悟が必要。過度なカスタマイズは失敗の元 |
判断の勘どころは、「業務をシステムに合わせるか、システムを業務に合わせるか」という一点です。ERP導入は前者、再構築は後者の色が濃い。ここを曖昧にしたまま製品を選ぶと、標準ERPを選んだのに現行踏襲のカスタマイズを大量発注し、コストが跳ね上がる——という典型的な失敗に陥ります。方式選定の前に、業務そのものを見直すBPRの発想が効きます(参考:BPRとは?業務改善との違いと進め方)。
段階移行と一括移行はどちらを選ぶ?
移行方式は「一括移行・段階移行・並行運用」の3つ。業務を止められない基幹システムでは、原則として段階移行か並行運用でリスクを分散します。
| 移行方式 | やり方 | メリット | デメリット・向くケース |
|---|---|---|---|
| 一括移行(ビッグバン) | ある日を境に全業務を新システムへ | 移行期間が短く、二重運用がない | 失敗時の影響が全社に及ぶ。小規模・単一業務向き |
| 段階移行 | 拠点・業務・機能ごとに順次切り替え | 影響範囲を限定でき、学習しながら進める | 期間が延び、新旧併存の連携が複雑。中〜大規模向き |
| 並行運用(並行稼働) | 一定期間、新旧を同時稼働し結果を突合 | 本番前に精度を検証できる | 現場の負荷が二重。ミッションクリティカル向き |
私たちが基幹システム刷新で第一に勧めるのは、段階移行を軸に、切替直前に並行運用で突合する組み合わせです。一括移行は一見スマートですが、例外運用の抽出漏れがあった場合に全社が止まります。段階移行なら、最初の拠点・業務で発覚した想定漏れを次の切替までに修正でき、失敗を“致命傷”にせず“学習”に変えられます。
移行の直前には、データ移行のクレンジング(重複・不整合の除去)とテスト仕様書づくりが待っています。この定型作業は、生成AIで下書きを一気に作り人が確認する進め方が有効です。どの業務からAIを使うかの考え方は業務改善にAIを活用する進め方|どの業務から自動化するかで整理しています。
基幹システム刷新の費用・期間はどれくらい?
費用と期間は方式と規模で大きく変わり、正確な金額は現行調査を終えて初めて見積もれます。断定できる相場はありませんが、判断の目安は次のとおりです。 「まず概算だけ知りたい」段階では、レンジと変動要因で押さえるのが実務的です。
| 方式 | 費用感の傾向 | 期間の目安 |
|---|---|---|
| マイグレーション | 相対的に小さい(基盤刷新が中心) | 数か月〜1年程度 |
| ERPパッケージ導入 | 中〜大(ライセンス+導入+カスタマイズ) | 半年〜1年半程度 |
| 再構築(リビルド) | 最大(要件定義から作り込む) | 1年〜数年 |
金額を左右する最大の変数は、カスタマイズ量と移行データの量・品質、そして現場の例外運用の多さです。全社の基幹システムでは総額が数千万円規模に達することも珍しくなく、経済産業省も大規模なモダン化は数年計画になり、着手後の停滞でさらに長期化しやすいと指摘しています(経済産業省 モダン化総括レポート)。だからこそ、見積もりの精度は現行調査の精度で決まります。相見積もりを取る前に、STEP1の棚卸しを自社で握ることが、結果的にコストを抑える近道です。
基幹システム刷新を成功させるポイントは?
成功の分かれ目は「経営が握る」「現行調査を外注に依存しない」「目的を先に決める」の3点です。 これは私たちの現場知見と、経済産業省・IPAの提言が一致する部分でもあります。
- 経営層がオーナーになる:経産省のモダン化総括レポートも、経営層のコミットとITガバナンスの強化を筆頭に挙げています。基幹刷新は情シスの案件ではなく経営の意思決定です。
- 現行調査は自社が主導する:ベンダーに任せるのは実装であって、業務の言語化は自社にしかできません。丸投げしないための最小限として、STEP1の4点セットは自社(+伴走者)で握る。
- 目的を先に一つに絞る:「コスト削減」「属人化解消」「データ活用(DX/AI)」のどれを主目的にするかで、方式も要件の優先順位も変わります。目的が曖昧なまま製品比較を始めない。
推進体制は「4つの役割」で組む
刷新の進め方でつまずく企業ほど、体制が曖昧です。最低限、次の4つの役割を明確に分けます。
- 経営オーナー:投資判断と目的の決定、部門間の利害調整を担う(社長・役員クラス)。
- 業務側リーダー:現行調査と要件の優先順位付けを主導(各部門の実務責任者)。
- 情シス/PMO:全体進行・ベンダー管理・移行計画の統括。ここが弱いと丸投げに逆戻りする。
- ベンダー:実装と技術的な実現方式を担う。要件の主体ではない。
社内にPMO人材が足りない場合は、外部の伴走者をPMOに据えるのが現実的です。
私たちキュリオシティは、この上流(現行調査・要件定義・移行設計)を、業務改善(BPR)の可視化手法と“現場主義×AI”で伴走します。現場に入って例外運用まで言語化し、移行データのクレンジング(重複・不整合の抽出)やテスト仕様書の下書きには生成AIを使って初稿を一気に作り、人が確認・確定する進め方をとります。実務では、こうした定型ドキュメント(テスト仕様書・移行データ定義書など)の初稿作成工数を体感で半分程度に圧縮でき、担当者は「判断」に時間を回せるようになります。刷新を「システム更新」で終わらせず「業務変革」にするための支援内容は業務改善コンサルティングにまとめています。
まとめ:進め方の順番を守ることが、失敗しない最短ルート
基幹システム刷新は、現状調査→要件定義→方式選定→移行設計→移行・稼働の順に進め、上流工程(特に現行調査4点セット)に労力を集中させることが成功の型です。失敗の多くはベンダー丸投げと業務理解の不足から生まれます。逆に言えば、業務を自社で言語化し、段階移行でリスクを分散すれば、刷新は十分に“動くシステム”に着地します。
まずは、刷新の起点となる現行業務の棚卸しから始めてみてください。抜け漏れなく洗い出すための「業務棚卸しテンプレート」を無料でご用意しています。
📄 無料ダウンロード:業務棚卸しテンプレート(基幹システム刷新の現行調査にそのまま使えます)
💬 自社の基幹システム刷新の進め方や方式選定に迷ったら、無料相談へお気軽にどうぞ。現場に入って現行調査から伴走します。
よくある質問(FAQ)
Q. 基幹システム刷新の進め方で、最初にやるべきことは何ですか?
A. 現行調査(現状調査)です。現行システムと業務を「機能・データ・連携・業務フロー」の4視点で棚卸しし、特に現場の例外運用まで言語化します。ここを飛ばして製品選定から入ると、稼働直前に想定漏れが露見して失敗します。
Q. 基幹システム刷新はなぜ失敗するのですか?
A. 最大の要因は「ベンダー丸投げ」です。自社で要件を整理せず任せきると、出来上がったシステムが実際の業務に合いません。IPAも現行業務仕様の理解不足と、ユーザ・ベンダの目線のズレを失敗要因に挙げています。業務の言語化は自社が主導する必要があります。
Q. 一括移行と段階移行、どちらがよいですか?
A. 業務を止められない基幹システムでは、原則として段階移行を軸にし、切替直前に並行運用で突合するのが安全です。一括移行は期間が短い反面、例外運用の抽出漏れがあると全社が止まるため、小規模・単一業務向きです。
Q. 刷新にはどのくらいの期間がかかりますか?
A. 規模によりますが、部門単位のシステムで数か月、全社の基幹システムでは1年以上に及ぶこともあります。経済産業省も大規模なモダン化は数年計画になり、着手後の停滞でさらに長期化しやすいと指摘しています。上流工程に時間をかけるほど、後工程の手戻りは減ります。
