レガシーシステム刷新の手順｜中小企業が2025年の崖を越える実践5ステップ

「そろそろ、あの古い基幹システムを何とかしたい」——この言葉を、経営者の方から本当に多くお聞きします。しかし、いざ動き出そうとすると「何から手をつければいいのか」で止まってしまう。それがレガシーシステム刷新の難しさです。

結論から言うと、レガシーシステム刷新は「棚卸し→評価→設計→移行→運用定着」の5ステップで進めます。工程を飛ばさず、経営が意思決定に関わり続けることで、投資が成果に変わっていきます。本記事では、2025年の崖の中身、モダナイゼーションの6R、中小企業が失敗しない5ステップ、経営者が握るべき3つの意思決定、投資回収の考え方を順に解説します。

読み終えたときには、明日から社内で「では、まず何を棚卸ししようか」と会話が始まる状態を目指しました。お役に立てれば嬉しく思います。

レガシーシステムとは何か｜中小企業に潜む「見えないコスト」の正体

レガシーシステムとは、老朽化・属人化・拡張困難のいずれかを抱え、事業の変化スピードに追いつけなくなった業務システムのことです。「まだ動いているから大丈夫」と見えても、経営視点では隠れコストと機会損失が静かに膨らんでいます。ここでは、まず「何をレガシーと呼ぶか」の定義から揃えていきましょう。

レガシーの定義と3つの症状（技術的老朽・属人化・拡張困難）

経済産業省の『DXレポート』では、レガシーシステムを「技術面の老朽化」「システムの肥大化・複雑化」「ブラックボックス化」の3側面で説明しています。中小企業の現場でこの3つを翻訳すると、次のようになります。技術的老朽は「開発言語や基盤がサポート終了間近」、属人化は「あの人しか触れない」、拡張困難は「新しい要望を追加すると、他のどこかが壊れる」という状態です。

一つでも当てはまれば、そのシステムはレガシー化のプロセスに入っていると捉えて差し支えありません。逆に、稼働年数が長くても、ドキュメントが整備され、複数の技術者で扱え、機能追加が計画的にできていれば、それはレガシーではなく「熟成したシステム」と呼べます。

動いているのに危ない理由｜運用コストと機会損失の見えない膨張

レガシーシステムが厄介なのは、「動いている＝問題なし」に見えてしまう点にあります。しかし実際には、保守費用の高止まり、障害復旧の長時間化、新規事業のスピード低下という3つの隠れコストが確実に膨張していきます。

コントリが経営者インタビューを重ねてきた経験から言えば、「システム更新の見積もりが年々上がっている」というお声は共通の課題として何度も浮上します。ベンダー側から見れば、担当できる技術者が減り、部品調達も難しくなるため、単価が上がるのは避けられません。放置するほど、選択肢と交渉力が同時に失われていく——これが動いているシステムを危ないと呼ぶ理由です。

中小企業に多いレガシーの典型パターン（表計算・オフコン・自作CRM）

中小企業でよく見かけるレガシーは、大きく3タイプに分かれます。一つ目は「巨大化した表計算ファイル」、二つ目は「オフコンやオープン系の古い基幹システム」、三つ目は「10年以上前に自社で作った顧客管理システム」です。

私自身、複数の経営者の方から「そういえば、あのExcelはもう誰が作ったか分からなくて」というご相談を受けた場面が何度もあります。属人化の入り口はいつも身近な場所にあります。まずは自社のシステム地図を描き、どのタイプがどこに存在するかを可視化することから始めてみてはいかがでしょうか。

なぜ今、刷新が必要なのか｜2025年の崖と経営リスクの棚卸し

2025年の崖とは、経済産業省が2018年の『DXレポート』で提示した警鐘で、レガシーシステムを刷新しないまま2025年を越えると、年間最大12兆円の経済損失が生じる可能性があるとされています。中小企業にとってのリスクは、保守要員の枯渇、サイバー攻撃、事業承継の妨げの3つに集約されます。

経済産業省DXレポートが示す「2025年の崖」の中身

『DXレポート』は、老朽化した基幹システムが「新しいデジタル技術の活用を阻害する」ことに加え、「保守運用コストの高騰」「サイバーセキュリティリスクの増大」「事業継続の脅威」を招くと指摘しています。特に基幹系システムのユーザー企業のうち、8割超が21年以上稼働しているという実態にも触れられており、決して他人事ではありません。

大企業向けの話に聞こえるかもしれませんが、実は中小企業のほうが影響を強く受けます。理由は、独自カスタマイズが多く、外部支援に頼りきれないケースが多いためです。埼玉県DX推進支援ネットワークで行われたリコージャパンの講演でも、中小企業ならではの基幹業務デジタル化の進め方が繰り返し語られています。

サポート終了・技術者枯渇・セキュリティ｜3つの経営リスク

刷新を先送りにすると、経営リスクは3段階で顕在化していきます。第1段階は「サポート終了」——OSやミドルウェアの保守が切れ、脆弱性が放置されます。第2段階は「技術者の枯渇」——扱える人がいなくなり、修正見積もりが跳ね上がります。第3段階は「事業インパクト」——障害発生時に業務が止まり、取引先の信用に直接影響します。

情報処理推進機構（IPA）の『情報セキュリティ10大脅威 2025』でも、サポート切れ製品の悪用は組織部門の脅威として繰り返し取り上げられています。「まだ動いているから」と据え置くほど、リスクの複利は静かに効いていくと言えます。

刷新を先送りにした場合の隠れコスト試算（保守費・機会損失）

隠れコストは、「保守費の年率上昇」「障害時の機会損失」「新規事業スピードの遅延」の3項目で試算すると経営会議で議論しやすくなります。年商5億円、保守費600万円/年の企業なら、年率10%の保守費上昇が3年続けば、単純計算で保守費だけで200万円弱の追加負担が発生します。

新規施策のリードタイムが2倍になれば、競合との差はさらに広がっていきます。放置は無料ではなく、静かに支払っている——そのことをまず経営者自身が数値化しておくことをおすすめします。

レガシー刷新の6つのアプローチ｜6Rで自社に合う道を選ぶ

レガシー刷新は「全部作り直す」ことではなく、6R（Retain／Rehost／Replatform／Refactor／Rearchitect／Rebuild・Replace）の6アプローチから、投資額と効果のバランスで選ぶ意思決定です。中小企業では、いきなり最上位の再構築を選ぶより、Rehost（再ホスト）やReplatform（再プラットフォーム）から入るケースが現実的です。

6Rの全体像｜維持・再ホスト・再プラットフォーム・再構成・再アーキ・再構築

6Rは、米国の調査会社ガートナー社が示したクラウド移行の6分類が起源で、レガシー刷新の意思決定にも広く使われています。Relipa Softwareが公開する解説動画『レガシーシステム刷新の6Rs：最適なモダナイゼーション手法』でも、この6分類が刷新プロジェクトの共通言語として紹介されています。

具体的には、Retainが「現状維持」、Rehostが「基盤だけクラウドに載せ替え」、Replatformが「基盤＋一部改修」、Refactorが「コード内部の書き換え」、Rearchitectが「アーキテクチャの再設計」、Rebuild／Replaceが「作り直しorパッケージ乗り換え」という順番で、投資額と効果が段階的に大きくなります。

コスト×効果マトリクスで見る中小企業の推奨パターン

中小企業では、まず「業務が止まらない範囲でどこまで進められるか」を軸に選びます。株式会社ripla『モダナイゼーションの方法／手法／工程／手順や進め方』でも、業務停止リスクを抑えつつ段階移行する重要性が繰り返し語られています。多くのケースで、以下のような順序が現実的です。

• 第1弾：Rehost または Replatform（基盤更新・SaaS移行）で足元のリスクを下げる
• 第2弾：Refactor で内部を整理し、拡張しやすい状態を作る
• 第3弾：Rearchitect または Rebuild で、事業モデルに合わせた再設計を行う

いきなり第3弾から入ろうとすると、要件が固まらず、投資が回収できないままプロジェクトが漂流します。段階を分けることで、経営が意思決定と学習を繰り返しながら前進できます。

SaaS移行・パッケージ導入・スクラッチ再開発、それぞれの向き不向き

SaaS移行は、汎用業務（会計・給与・勤怠・SFA等）に強く、初期費用が低く始めやすい選択肢です。パッケージ導入は、業界標準の業務プロセスに寄せられる場合に有効です。スクラッチ再開発は、他社と差別化する独自業務が競争力の源泉である場合に検討します。

私が経営者の方々と対話してきた経験から言えば、「独自業務」と呼ばれているものの多くが、実は業務側の標準化で解消できるケースが少なくありません。「独自だから作らなければ」と思い込む前に、SaaSやパッケージで7割カバーできるかを冷静に見極める姿勢が、投資判断を軽くしていきます。

レガシーシステム刷新の手順｜中小企業が失敗しない5ステップ

レガシーシステム刷新の手順は、①現状棚卸し→②評価と方針決定→③要件定義と設計→④移行と並行稼働→⑤運用定着とKPI管理、の5ステップで進めます。順序を飛ばさないことと、経営者が各ステップの節目で意思決定に関わることが、成否を分ける8割です。

STEP1｜現状棚卸し：業務・データ・システムを1枚の地図にする

刷新の第一歩は、業務・データ・システムの3層を1枚の地図に描くことです。業務層は「誰が、何のために、どんな判断をしているか」、データ層は「どこにどのデータが、どんな形式で存在するか」、システム層は「何が、どのバージョンで、どのように連携しているか」を書き出します。

この地図は「完璧」を目指さなくて構いません。3日〜1週間で第1版を作り、走りながら更新する運用に切り替えます。ここで時間をかけすぎると、次の意思決定が止まってしまうためです。棚卸しの目的は情報の整備ではなく、「どこから手を付けるか」を決めるための材料集めにあります。

STEP2｜評価と方針決定：残す／載せ替える／作り直すの判断基準

棚卸しが済んだら、6Rのどれに寄せるかを判断します。判断基準は「業務への影響度」「技術的老朽度」「変化への対応必要度」の3軸で、これを表形式で見える化します。ここで大切なのは、「載せ替える」と「作り直す」を混同しないことです。

「作り直す」を選んだ瞬間、投資額と期間は数倍に膨らみます。まず「載せ替え」で足元のリスクを下げ、事業側の要件が固まってから作り直しを検討する、という順序を守るだけで、投資対効果は大きく変わってきます。

STEP3｜要件定義と設計：業務プロセスの再設計を先に行う

要件定義では、「今の業務をそのままシステム化する」のではなく、「あるべき業務プロセスを先に描き、それをシステム化する」順序を取ります。富士通が公開する『デザイン思考でレガシー刷新』の事例でも、業務の再設計を先に行い、その上でシステムを設計し直したことが成功要因として語られています。

要件定義で経営者が押さえるべきは、次の3点です。第一に「捨てる業務・機能」を明確にすること、第二に「例外業務は例外のまま残さない」と決めること、第三に「業務側のオーナーを1人立てる」ことです。この3つを最初に決めておけば、後工程の意思決定が驚くほどスムーズに流れていきます。

STEP4｜移行と並行稼働：データ移行・並走運用・切り戻し計画

移行フェーズでは、旧システムと新システムを一定期間並行稼働させるのが基本です。並行稼働の狙いは、「新システムでの業務検証」と「切り戻しの担保」の両方にあります。データ移行は、マスタ→トランザクション→履歴の順で段階的に進め、各段階で照合レポートを出します。

切り戻し計画は「使わないことを願う保険」ではなく、「使う前提で準備する安全装置」と捉えます。切り戻し手順と判断基準を文書化し、経営者が「いつ止めるか」を事前に決めておくことで、現場は安心して新システムを検証できます。

STEP5｜運用定着とKPI管理：現場が使い続ける仕組みを組み込む

刷新の成否は、稼働開始後3〜6ヶ月の定着期に決まります。稼働直後は「以前のやり方に戻りたい」という心理的抵抗が必ず生まれます。ここで経営が撤退すると、新システムは名ばかりになり、旧システムの残骸と併存するという最悪の状態に陥ります。

定着期には、①週次で稼働KPIを見る場を設ける、②現場のチャンピオン（推進役）を配置する、③業務ルールと運用ルールを明文化して共有する、この3点を最低限組み込みます。数値と役割と文書、この3つが揃うだけで、定着率は目に見えて変わってきます。

経営者が刷新プロジェクトで押さえるべき3つの意思決定ポイント

刷新プロジェクトを情報システム部門やベンダーに任せきりにすると、必ずどこかで意思決定が滞ります。経営者にしか決められない論点は、「投資範囲」「業務の残し方」「撤退基準」の3つです。この3つに経営者が真正面から向き合うだけで、プロジェクトの進捗は劇的に変わります。

投資範囲｜「守り」と「攻め」の予算比率をどう配分するか

刷新予算は、「守りの投資（既存業務の維持・リスク低減）」と「攻めの投資（新事業・新機能）」の2種類に分けて設計します。守りだけに寄せると、刷新後も競争力は生まれません。攻めだけに寄せると、足元の業務が不安定になります。

一つの目安は、守り6：攻め4です。あくまで目安で、業界・事業ステージによって振れ幅は変わります。経営者が握るのは比率そのものではなく、「なぜその比率にしたか」の説明責任です。この比率を社内に明示することで、現場の優先順位も揃っていきます。

業務の残し方｜例外業務を残すのか、業務側を標準化するのか

刷新プロジェクトで最も揉めるのは、「この業務は例外だから、システムでも例外扱いにしてほしい」という要望への対応です。例外を全て残せば、システムは複雑化し、また新しいレガシーが生まれます。全て切れば、現場が回らなくなります。

経営者の役割は、「業務側を標準化する部分」と「例外として残す部分」の線引きを決めることです。線を引くのは辛い作業ですが、この線引きこそが刷新プロジェクトの背骨になります。線を引かない意思決定は、実質的には「例外を全て残す」意思決定と同じであり、それがレガシーを再生産する最大の原因になっています。

撤退基準｜PoC段階で線を引く「やめる勇気」の言語化

刷新プロジェクトには「PoC（概念実証）」と呼ばれる小規模検証の段階があります。ここで「うまくいかないかもしれない」という兆候が見えたときに、続けるか止めるかを判断する基準を、事前に言語化しておきます。

撤退基準の例は、「予算超過が30%を超えたら再検討」「主要要件のうち3件以上が未達なら方針変更」など、数値と件数で示します。基準を事前に決めておかないと、埋没費用（サンクコスト）に引きずられて撤退できず、傷を広げていきます。「やめる勇気」は精神論ではなく、事前の言語化で担保するものです。

刷新後の投資回収と社内浸透｜プロジェクトを成果に変える運用設計

システムは入れて終わりではなく、使われて成果になります。刷新プロジェクトのROI（投資回収）を経営数値に接続し、現場が定着するまでを追いかける仕組みを、最初から組み込んでおきます。運用設計を後回しにする刷新は、9割が「使われないシステム」で終わっていきます。

刷新ROIを測る3指標｜工数削減・売上寄与・意思決定スピード

刷新の成果は、次の3指標で経営数値と接続します。第一に「工数削減」（対象業務の時間×人数×時給／年）、第二に「売上寄与」（対応スピード改善による受注率アップ×売上規模）、第三に「意思決定スピード」（データ集計から判断までのリードタイム短縮）。

刷新前の状態を計測しておくことが、この3指標を機能させる前提です。着工前のベースライン計測を怠ると、刷新後にどれだけ良くなったかを説明できなくなります。稼働開始後は月次で数値を追い、四半期ごとに経営会議で振り返る場を設けていただけたらと思います。

現場が使い続ける仕組み｜運用ルール・研修・チャンピオン制度

現場定着には、「運用ルール」「研修」「チャンピオン制度」の3つを組み合わせるのが有効です。運用ルールは「何をしてはいけないか」よりも「何をすると評価されるか」を先に書きます。研修は稼働直前の1回だけでなく、3ヶ月・6ヶ月の節目に振り返り研修を挟みます。

チャンピオン制度とは、部門ごとに新システムの推進役を1名指名し、その人経由で疑問と改善要望を集める仕組みのことです。人事評価にも反映することで、現場の「新システムを使いこなしたい」という熱意を引き出しやすくなります。

小さく始めて広げる進め方｜スモールスタートと横展開の設計

刷新は一気に全社展開するより、1〜2部門でのスモールスタートから入るほうが結果的に速く、確実です。理由は3つあります。第一に、小さな範囲で失敗が学びに変わりやすいこと。第二に、成功事例が社内の説得材料になること。第三に、投資判断が段階的にできることです。

劉双氏が公開する『新規開発 vs レガシー刷新：2つのワークフロー』でも、既存業務を止めずに段階的に切り替えていく設計の重要性が語られています。小さく始めて広げる——この一歩一歩の積み重ねこそ、レガシー刷新を成功に導く王道の道筋と言えます。

よくあるご質問（FAQ）

レガシーシステム刷新にはどれくらいの期間がかかりますか？

中小企業の基幹業務で、棚卸しから運用定着までおおむね6〜18ヶ月が目安です。業務範囲を絞れば3〜6ヶ月で第1弾を稼働させることも可能です。まずは対象業務を1〜2領域に絞り、スモールスタートで進めるのが現実的な道筋になります。

刷新の費用相場はどのくらいですか？

SaaSやパッケージへの載せ替えなら初期30万〜300万円＋月額数万〜数十万円、スクラッチで再構築する場合は数千万円規模になることもあります。6Rのどれを選ぶかで一桁変わってくるため、方針決定の前に見積を取ることは避けたほうが良いと言えます。

自社にIT人材がいなくても刷新は可能ですか？

可能です。ただし「丸投げ」では途中で必ず止まります。経営者と業務側のキーパーソン、ベンダー、必要に応じて伴走型の外部支援（ITコーディネータ等）の3者で意思決定の場を持ち、決めるべきことを決めていく体制がつくれれば、着実に前に進んでいきます。

既存システムを残しながら刷新する方法はありますか？

あります。「並行稼働」と呼ばれる方法で、旧システムと新システムを一定期間同時に動かし、データや業務の切り替えを段階的に行います。切り戻しの手順もあわせて設計しておくことで、業務停止リスクを抑えながら移行を進められます。

刷新の効果はどう測ればいいですか？

工数削減（時間×人数×時給）、売上寄与（対応スピード改善による受注率）、意思決定スピード（データ集計から判断までのリードタイム）の3つで測ると、経営数値との接続がしやすくなります。刷新前の状態を計測しておくことが前提です。

「2025年の崖」を過ぎたら、もう刷新は手遅れですか？

手遅れではありません。「2025年の崖」は特定の年をもって全てが崩れるという話ではなく、放置するほど選択肢と交渉力が失われるという趨勢を指しています。今日始める刷新は、5年後の会社を守る投資です。着手のタイミングとして「遅すぎる」はありません。

編集部から

レガシーシステム刷新は、実は「システムの話」ではなく「経営者が自社の未来をどう描くか」の話です。取材でお話を伺うたびに、「あの時、勇気を出して着手して良かった」と穏やかに振り返られる経営者の方の表情に、こちらも胸が熱くなります。

小さな一歩かもしれませんが、それが未来を変える大きな力になります。まずは1枚のシステム地図を描くところから、始めてみませんか。皆さまの会社の次の10年を支える意思決定を、コントリは陰ながら応援しています。

参考・一次情報

• 経済産業省『DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～』（2018年9月）
• 情報処理推進機構（IPA）『情報セキュリティ10大脅威 2025』
• YouTube『レガシーシステム刷新の6Rs：最適なモダナイゼーション手法』（Relipa Software）
• YouTube『モダナイゼーションの方法／手法／工程／手順や進め方』（株式会社ripla）
• YouTube『新規開発 vs レガシー刷新：2つのワークフロー』（劉双）
• YouTube『デザイン思考でレガシー刷新　グローバル決裁システム』（富士通株式会社）
• YouTube『２０２５年の崖から読み解くレガシーシステムからの刷新ポイント』（埼玉県DX推進支援ネットワーク／リコージャパン株式会社）