結論：一括刷新（ビッグバン）は避け、業務単位で切り出して置き換える

基幹システムの刷新で最も失敗が多いのが、全機能を一度に置き換える一括移行です。稼働日に問題が出れば業務が止まり、切り戻しもできません。現実的なのは、外側の業務から順に切り出して、旧システムと並行させながら縮小していく進め方です。

そもそも刷新すべきか

刷新には数千万円規模の投資が必要になることもあります。まず「本当に今やるべきか」を判定してください。

刷新を急ぐべきサイン

サイン リスクの中身
保守ベンダーが撤退・サポート終了を通告した 障害時に直せる人がいなくなる
OS・ミドルウェアのサポートが切れている 脆弱性が塞がれず、セキュリティ事故の原因になる
改修できる技術者が社内外に1人しかいない その人が離れた時点で停止する
法改正への対応ができない インボイス・電帳法などで実務が回らなくなる
ハードウェアの部品が調達できない 故障＝停止

上2つのいずれかに当てはまるなら、投資判断より先にリスク管理の問題です。

急がなくてよい場合

  • 動いていて、改修も年数回できている
  • 業務側から具体的な不満が出ていない
  • 保守費用が過大でない

「古いから」だけを理由にした刷新は、投資を回収できないことが多くあります。

進め方：ストラングラー方式

旧システムを一度に捨てず、外側から機能を剥がして新システムへ移す方法です。名前は「絞め殺しの木」に由来し、旧システムを新システムが徐々に覆っていくイメージです。

手順

① 現行の棚卸し

何の機能があり、どれが実際に使われているかを洗い出します。多くの場合、機能の3〜4割は使われていません。ここを移さないだけで、費用と期間が大きく減ります。

② 切り出す順序を決める

外部との接点が少なく、独立性が高い業務から着手します。

優先度 例
先に移しやすい 帳票出力、マスタ管理、参照系の画面
中盤 受発注、在庫
最後 会計、締め処理（他の全てが依存するため）

③ 並行稼働の期間を設計する

新旧が同時に動く期間を明示的に設けます。どちらが正なのか、いつ旧を止めるのかを決めずに始めると、両方が中途半端に生き残ります。

④ データ移行を先に試す

本番移行の前に、実データでの移行リハーサルを最低2回行います。データの品質問題（文字化け、桁あふれ、想定外の値）はここで必ず出ます。

⑤ 切り戻し手順を用意する

問題が起きたときに旧へ戻せる手順を、書面で用意してください。これがないと、稼働日に判断ができなくなります。

費用と期間の目安

規模 内容 費用の目安 期間
部分刷新 1〜2業務を切り出して置換 300〜800万円 4〜8か月
中規模 受発注・在庫・請求の範囲 800〜2,500万円 8〜18か月
全面刷新 会計を含む基幹全体 2,500万円〜 18か月〜

パッケージ（ERP）導入か、個別開発かでも大きく変わります。業務をパッケージに合わせられるなら、そのほうが安く早く済みます。

費用を膨らませる要因

  • 現行仕様のドキュメントが無く、調査から始める必要がある
  • 「現行踏襲」を要件にしてしまう（使われない機能まで作る）
  • 移行データの品質が悪い
  • 稼働後も旧システムを止められない

「現行踏襲」という言葉に注意

要件定義で「現行と同じで」と言うと、使われていない機能まで作り込むことになります。これが刷新プロジェクトが膨らむ最大の原因です。

刷新は、やめる業務を決める機会です。棚卸しの段階で「この帳票、誰が見ていますか」を全項目について確認してください。答えられない機能は、移さない候補になります。

クラウド移行を同時に検討する場合

刷新のタイミングでオンプレミスからクラウドへ移すか、という論点が出ます。

観点 オンプレミス継続 クラウド移行
初期費用 ハードウェア更新が必要 不要
継続費用 保守・電気・場所 従量課金（規模により逆転あり）
可用性 自社で確保 サービス側の仕組みを利用
制約 自由度が高い データ保管場所の制約を確認要

「クラウドにすれば安くなる」とは限りません。 常時フル稼働するシステムでは、オンプレミスのほうが安いこともあります。試算した上で判断してください。

よくある質問

Q. ベンダーロックインを避けるには？

ソースコード・データベース定義・環境構築手順の引き渡しを契約で定めてください。データが標準的な形式でエクスポートできるかも確認事項です。

Q. 現行を作ったベンダーに頼むべきですか？

現行を理解している利点は大きい一方、同じ設計思想を引き継ぐことにもなります。棚卸しと要件定義だけを別の会社に依頼し、開発は競争させるという進め方もあります。

Q. 社内に情シスがいません

外部のPMO（プロジェクト管理支援）を入れることを検討してください。ベンダー任せにすると、業務側の要求が反映されないまま進みます。

Q. 補助金は使えますか？

システム刷新が対象になる制度があります。ただし公募時期・要件は年度で変わり、採択は保証できません。制度に合わせて要件を歪めないことのほうが重要です。

当社の対応

Nortiq Labs は、基幹システムの全面刷新を一社で請け負う規模の会社ではありません。その前提でお伝えできることがあります。

  • 部分的な切り出し（1〜2業務を新しい形で作り直す）は対応できます
  • 現行の棚卸しと、移すべき/移さない機能の整理はご一緒できます
  • 大規模な全面刷新が必要な場合は、その旨を率直にお伝えします

規模が合わない案件を無理に受けるより、適切な規模の相手を見極めていただくための材料をお渡しするほうが役に立てると考えています。

関連記事

  • 社内システムクラウド移行の失敗を防ぐ、発注ステップガイド
  • システム開発会社の選び方｜失敗しない比較チェックリスト