ベンダーから「このバージョンは来年でサポートが終わります」という案内が届いた。現場からは「Excelで二重入力しているのを何とかしてほしい」と言われ続けている。それでも、いま動いているシステムを入れ替えるとなると、いくらかかるのか、どれくらい止まるのか、そもそも本当に今やるべきなのかの判断がつかない。基幹システムのリプレイスを任された担当者の多くが、この状態から始めます。
先に結論をお伝えすると、基幹システムのリプレイスで最初に決めるべきなのは、開発会社でも製品でもなく「そもそも全面的に入れ替えるのか」です。延命、部分改修、段階移行、全面刷新の4つの選択肢があり、どれを選ぶかで費用も期間も一桁変わります。そしてこの判断は、売る側の開発会社ではなく発注側にしかできません。この記事では、リプレイスに踏み切る判断基準と、決めたあとに失敗させないための進め方を、発注側の目線で整理します。
この記事のポイント
- 入れ替えの判断は導入年数ではなく技術基盤・保守体制・業務適合性など複数の観点で見る
- 延命・部分改修・段階移行・全面刷新の4択を先に決めないと費用も期間もぶれる
- 発注前に目的の定量化・体制・現行業務の棚卸しを社内で終わらせておく
- 失敗の多くは現行踏襲のまま進めることとデータ移行の準備不足から起きる
目次
基幹システムのリプレイスに踏み切る判断基準
まず押さえておきたいのは、基幹システムのリプレイスは「やるかやらないか」の二択ではないということです。よくある失敗が、サポート終了の案内をきっかけに反射的に全面刷新へ動いてしまい、あとから予算も体制も足りないと気づくパターンです。ここでは、入れ替えを検討すべき状態かどうかを見極める観点と、選べる打ち手の幅を整理します。
基幹システムの老朽化を示す5つのサイン
「導入から10年経ったら入れ替え時」という言い方をよく見かけますが、私の感覚では年数だけで決めるのは危険です。15年動いていても保守体制があり基盤を更新できているなら延命できますし、逆に5年でも業務に合わなくなっていれば見直しの対象になります。年数は目安であって判断基準ではありません。
実務では、次の5つの観点で症状が出ているかを見ます。ひとつでも当てはまれば即入れ替え、というものではなく、いくつ重なっているかで緊急度を測るイメージです。
- 技術基盤：OSやミドルウェアのサポートが切れる、または切れている
- 保守体制：中身を分かっている人が社内にも開発会社にも残っていない
- 業務適合性：システムでできないことをExcelや手作業で補っている範囲が広がっている
- セキュリティ：脆弱性の修正パッチが提供されない、多要素認証などの要求に応えられない
- 外部連携：新しく導入したツールやクラウドサービスとデータをつなげない
特に注意して見てほしいのが、2つ目の保守体制です。費用の問題より深刻なのは、改修を頼める相手がいなくなることです。仕様書が残っておらず、当時の担当者も退職していて、開発会社側の担当技術者も別プロジェクトに移っている。この状態になると、小さな法改正対応ですら見積もりが跳ね上がり、身動きが取れなくなります。特定の会社しか手を出せない状態が固定化していく仕組みについては、ベンダーロックインの原因とデメリットで詳しく整理しています。
3つ目の業務適合性も、現場からの声として上がりやすいわりに軽く扱われがちです。Excelでの二重入力や、システム外での申請回覧が増えているのは、システムが業務に追いつけていないサインです。国が示した「2025年の崖」の議論でも、老朽化したシステムを抱えたままではデータを活用できず、維持費が高止まりすることが指摘されてきました。詳しい背景は経済産業省のDXレポートで確認できます。
延命・部分改修・段階移行・全面刷新の選び方
症状が見えたら、次は打ち手を選びます。ここを飛ばして全面刷新に直行してしまうのが、費用が膨らむいちばんの原因です。実際には、次の4つから選ぶことになります。
| 選択肢 | 向いている状態 | 費用と期間の重さ | 注意点 |
|---|---|---|---|
| 延命 | 基盤更新の余地があり、業務にはおおむね合っている | 軽い | 先送りするほど後の移行コストが増える |
| 部分改修 | 不満が特定の業務に偏っている | やや軽い | 継ぎ足しを重ねると全体の複雑さが増す |
| 段階移行 | 止まると影響が大きい業務を抱えている | 重い | 並行稼働の期間が長く現場の負担が大きい |
| 全面刷新 | 基盤も業務適合性も限界で、業務そのものを見直したい | 最も重い | 要件が膨らみやすく体制と予算の確保が前提 |
選び分けの軸はシンプルで、「止まったときの業務影響」と「あと何年戦えるか」の2つです。受注や出荷が止まると即座に売上に響く業務を抱えているなら、一気に切り替える全面刷新はリスクが高く、段階移行を選ぶほうが安全です。逆に、業務プロセスそのものを見直したいという経営課題があるなら、部分改修を積み重ねても目的には届きません。
ここで大事なのは、この4択を開発会社に選ばせないことです。ERPパッケージを売る会社に相談すればパッケージ導入の提案が返ってきますし、移行サービスを持つ会社に聞けばそのまま移す提案が返ってきます。どれも間違いではありませんが、自社にとっての最適解とは限りません。方向性だけは発注側で決めてから相談に入るのが、余計な出費を防ぐ近道です。
リプレイス費用と期間のおおまかな目安
費用は規模と選ぶ打ち手で大きく変わるため、一律の相場は出せません。それでも見当がつかないと稟議も書けないので、目安として整理しておきます。部分改修であれば数百万円規模、パッケージを導入して業務を合わせにいく形なら1,000万円台から、複数拠点で業務も作り込む全面刷新なら数千万円以上を見込むケースが多いです。期間は、部分改修で3〜6か月、全面刷新なら要件定義から本稼働まで1年から2年を見ておくと大きく外しません。
これはあくまで一般的な目安です。実際の判断は、自社の業務範囲と拠点数を前提にした個別の見積もりで確認してください。
見落とされやすいのが、初期費用の外側にある支出です。データ移行の作業費、並行稼働の期間中に二重で払うライセンス費、現場の教育コスト、稼働後の保守費。この4つは提案書の合計金額に含まれていないことがあり、あとから予算超過の原因になります。規模別のレンジと初期費用の内訳、追加費用が出る条件は、基幹システム刷新の費用相場と見積もりの読み方で詳しく整理しています。
基幹システムのリプレイスを失敗させない進め方
方向性が決まったら、次は進め方です。基幹システムのリプレイスは、開発会社の技術力だけで成功するプロジェクトではありません。現場の業務を知っていて、どこを変えるかを決められるのは発注側だけだからです。ここでは、発注側が自分で持つべき仕事を中心に、依頼先の選び方と典型的な失敗までを順に見ていきます。
発注前に社内で決めておく3つのこと
相談に行く前に、次の3つを社内で固めておくと、その後の進行が驚くほど楽になります。逆にここが空白のまま提案を受けると、開発会社ごとに前提が違う提案が並び、比較すらできません。
1つ目は、目的を数字にすることです。「現場の不満をなくす」では目的になりません。月末の締め処理を5営業日から2営業日に短縮する、システムの年間維持費を3割下げる、といった形にすると、プロジェクトが成功したかどうかを後から判定できます。稟議を通すときにも、この数字があるかどうかで通りやすさが変わります。
2つ目は、体制と決裁者を決めることです。基幹システムは部門をまたぐので、営業部と経理部で言い分が食い違う場面が必ず来ます。そのときに「どちらの業務に合わせるか」を決められる人がプロジェクトの中にいないと、判断待ちで止まります。情報システム部の担当者だけに背負わせず、業務側の責任者と、最終的に判断する経営層をあらかじめ巻き込んでおいてください。
3つ目は、現行業務の棚卸しです。いま何の業務が、どのシステムの、どの機能で回っているのか。年に1回しか使わない機能や、実はもう誰も使っていない機能も含めて洗い出します。この作業は地味ですが、後の要件定義の質を決めます。開発会社に頼むこともできますが、費用がかかるうえ、現場の実態は結局こちらが答えることになるので、できる範囲は自社でやったほうが早いです。
開発会社に相談する前の確認リスト
- 刷新後に達成したい状態を数値目標として1つ以上書けているか
- 部門間で意見が割れたときに決める人が決まっているか
- 現行システムで使っている機能と使っていない機能を洗い出せているか
- 延命・部分改修・段階移行・全面刷新のどれで進めるか方向性が出ているか
- 稼働希望時期と、動かせない業務上の締切を把握しているか
RFP作成から開発会社を選ぶまでの流れ
社内が固まったら、依頼内容を文書にして複数社に投げます。ここで作るのがRFP、いわゆる提案依頼書です。目的、現行の業務範囲、実現したいこと、予算感、稼働希望時期を書いて渡すと、各社から同じ土俵の提案が返ってきます。口頭で相談するだけだと、各社が勝手に前提を置いた提案になり、金額を比べても意味がありません。
相談先は大きく3種類あり、得意分野が違います。ERPパッケージのベンダーは、製品に業務を寄せる前提なら早くて安く収まりますが、自社独自のやり方は諦めることになります。大手のSIerは、大規模で複数拠点にまたがる案件や、複数システムの取りまとめに強い一方、費用は高くなります。中堅・専業の開発会社は、業務に合わせた作り込みと距離の近さが強みですが、対応できる規模に限りがあります。
どこに頼むかは、先に決めた4択と連動します。業務を見直して標準的なやり方に寄せるならパッケージベンダー、現行の業務を維持しつつ基盤だけ新しくするなら移行実績のある開発会社、というように、方向性が決まっていれば候補は自然に絞られます。提案を並べて比べるときの観点は、ベンダー選定の進め方と選定基準にまとめてあります。
比較で見るべきなのは、金額よりも前提です。同じ業種・同じ規模の導入実績があるか、要件定義をどちらがどこまで担当するのか、稼働後の保守は誰がどんな体制で見るのか。この3つの答えが曖昧な会社は、あとから追加費用の話になりやすいというのが正直なところです。各社の回答を同じ項目で並べて残しておくと、社内で説明するときにも使えます。項目を一から作るのが手間なら、ベンダー選定比較表テンプレート（10カテゴリ100項目）をそのまま埋める形でも構いません。
現行踏襲とデータ移行で起きる失敗
最後に、実際につまずきやすい2つの落とし穴を挙げておきます。どちらも発注側の準備で防げるものです。
ひとつ目が「現行踏襲」です。要件定義の場で「基本的に今と同じで」と伝えてしまうケースですが、これがいちばん危ない指示だと思っています。今と同じ、の中身は誰も正確に説明できません。結果として、開発が進んでから「この処理が入っていない」が次々と出てきて、追加費用と納期遅れが積み上がります。しかも、せっかく入れ替えるのに非効率な業務までそのまま持ち込むことになります。使っていない機能は捨てる、手作業で補っていた部分は業務のほうを変える、という判断を先にしておいてください。
ふたつ目がデータ移行です。長年動いてきた基幹システムには、表記のゆれた取引先名、廃止したはずのコード、桁数の合わない過去データが必ず溜まっています。これを新システムにそのまま流し込もうとして、本番直前に止まるのが典型的な失敗です。移行するデータの範囲をどこまでにするか、いつ時点のデータを持っていくか、リハーサルを何回やるかを、要件定義の段階で決めておく必要があります。
そして、意外と抜けるのが切り戻しの条件です。切り替え当日に問題が起きたとき、どの状態になったら旧システムに戻すのかを、稼働前に文書で決めておいてください。当日の混乱の中で「戻すか続けるか」を議論すると、判断が遅れて被害が広がります。何時までに何が終わっていなければ中止する、という基準を先に握っておくのは、発注側にしかできない仕事です。
