結論：一括刷新（ビッグバン）は避け、業務単位で切り出して置き換える
基幹システムの刷新で最も失敗が多いのが、全機能を一度に置き換える一括移行です。稼働日に問題が出れば業務が止まり、切り戻しもできません。現実的なのは、外側の業務から順に切り出して、旧システムと並行させながら縮小していく進め方です。
そもそも刷新すべきか
刷新には数千万円規模の投資が必要になることもあります。まず「本当に今やるべきか」を判定してください。
刷新を急ぐべきサイン
| サイン | リスクの中身 |
|---|---|
| 保守ベンダーが撤退・サポート終了を通告した | 障害時に直せる人がいなくなる |
| OS・ミドルウェアのサポートが切れている | 脆弱性が塞がれず、セキュリティ事故の原因になる |
| 改修できる技術者が社内外に1人しかいない | その人が離れた時点で停止する |
| 法改正への対応ができない | インボイス・電帳法などで実務が回らなくなる |
| ハードウェアの部品が調達できない | 故障＝停止 |
上2つのいずれかに当てはまるなら、投資判断より先にリスク管理の問題です。
急がなくてよい場合
- 動いていて、改修も年数回できている
- 業務側から具体的な不満が出ていない
- 保守費用が過大でない
「古いから」だけを理由にした刷新は、投資を回収できないことが多くあります。
進め方：ストラングラー方式
旧システムを一度に捨てず、外側から機能を剥がして新システムへ移す方法です。名前は「絞め殺しの木」に由来し、旧システムを新システムが徐々に覆っていくイメージです。
手順
① 現行の棚卸し
何の機能があり、どれが実際に使われているかを洗い出します。多くの場合、機能の3〜4割は使われていません。ここを移さないだけで、費用と期間が大きく減ります。
② 切り出す順序を決める
外部との接点が少なく、独立性が高い業務から着手します。
| 優先度 | 例 |
|---|---|
| 先に移しやすい | 帳票出力、マスタ管理、参照系の画面 |
| 中盤 | 受発注、在庫 |
| 最後 | 会計、締め処理（他の全てが依存するため） |
③ 並行稼働の期間を設計する
新旧が同時に動く期間を明示的に設けます。どちらが正なのか、いつ旧を止めるのかを決めずに始めると、両方が中途半端に生き残ります。
④ データ移行を先に試す
本番移行の前に、実データでの移行リハーサルを最低2回行います。データの品質問題（文字化け、桁あふれ、想定外の値）はここで必ず出ます。
⑤ 切り戻し手順を用意する
問題が起きたときに旧へ戻せる手順を、書面で用意してください。これがないと、稼働日に判断ができなくなります。
費用と期間の目安
| 規模 | 内容 | 費用の目安 | 期間 |
|---|---|---|---|
| 部分刷新 | 1〜2業務を切り出して置換 | 300〜800万円 | 4〜8か月 |
| 中規模 | 受発注・在庫・請求の範囲 | 800〜2,500万円 | 8〜18か月 |
| 全面刷新 | 会計を含む基幹全体 | 2,500万円〜 | 18か月〜 |
パッケージ（ERP）導入か、個別開発かでも大きく変わります。業務をパッケージに合わせられるなら、そのほうが安く早く済みます。
費用を膨らませる要因
- 現行仕様のドキュメントが無く、調査から始める必要がある
- 「現行踏襲」を要件にしてしまう（使われない機能まで作る）
- 移行データの品質が悪い
- 稼働後も旧システムを止められない