レガシーシステム刷新とは、老朽化してブラックボックス化した基幹システムを、経営判断に基づいて計画的に作り替える取り組みです。
販売管理や生産管理、会計の基幹システムは、担当者の退職や改修の重なりで誰も全体を把握できなくなり、軽微な変更にも高額な見積りと長い納期がかかるようになります。
- レガシーシステム刷新の定義と対象となる基幹システム
- レガシー化が進む背景と刷新タイミングのサイン
- アセスメントから開発・移行・安定化までの進め方
- 刷新の目的・効果とモダナイゼーションとの違い
情報システム部門の担当者はもちろん、経営層への説明や稟議を控えている方にも、自社の状況を整理して次の行動を判断できる内容を目指しました。
このテーマ全体の流れは、次の記事でも確認できます。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新の定義と全体像
レガシーシステム刷新とは、事業の根幹を支えてきた基幹システムで、技術的な老朽化によって改修や仕様変更への対応力を失ったものを、業務要件から見直して新しい基盤へ作り替えることです。
対象になるのは、汎用機(メインフレーム)上で稼働するCOBOL資産や、長年の個別カスタマイズで原形をとどめないほど複雑化したERP・業務パッケージなど、いわゆる「塩漬けシステム」です。
単なるハードウェアの更新やクラウドへの移行と違い、経営判断としてどこまで手を入れるかを決めるところから始まる点が特徴です。
刷新の対象は老朽化・ブラックボックス化した基幹システム
刷新の対象になりやすいのは、稼働年数が長く、導入時の担当者がすでに退職している基幹システムです。
設計書が更新されないまま現場の判断で機能追加が繰り返されると、画面上の表示と裏側の処理が一致しなくなります。そうなると、外部の開発会社に見積りを依頼しても、「まず現状を解析する費用」だけで数百万円規模になることも珍しくありません。
IPAの「レガシーシステムモダン化委員会総括レポート」によると、およそ6割の企業が何らかのレガシーシステムを保有しているとされています。さらに、JUASの「企業IT動向調査報告書」でも、4割の企業がいまだにレガシーシステムを使用していると報告されています。
業務と体制の再設計を伴う刷新
レガシーシステム刷新では、旧システムの機能を新しい製品へそのまま移すだけでなく、業務と体制も見直す必要があります。
長年の個別対応によって、現在の業務フローそのものが旧システムの制約に合わせて最適化されているケースが多くあります。そのため、刷新のタイミングで「なぜその手順が必要なのか」を業務部門と一緒に洗い出すことが欠かせません。
経済産業省の「DXレポート2」では、日本企業の約8割が既存システムの老朽化・ブラックボックス化をDX推進の最大の障壁として挙げています。技術的な作り替えだけでなく、業務標準化と体制の見直しをセットで進めることが、刷新を成功させる前提になっています。
レガシー化が進む背景と特徴
レガシー化は一部の企業だけに起きる特殊な事象ではありません。長く事業を続け、その都度システムに手を加えてきた企業ほど直面しやすい、構造的な課題です。
レガシー化がなぜ進み、どのような特徴を持つに至るのかを、順に見ていきます。
今なおレガシーシステムを運用する企業の多さ
経済産業省が2018年に公表した「DXレポート」は、IT予算の9割以上がレガシーシステムの維持管理費に充てられている状況を指摘しました。これを放置した場合、2025年以降に年間最大12兆円の経済損失が生じる可能性があるとして、いわゆる「2025年の崖」を示しました。
あわせて、経済産業省の「IT人材需給に関する調査」では、2030年に最大79万人のIT人材が不足し、ベンダー側の供給充足率もおよそ66%にとどまると予測されています。
保守を担える人材そのものが減っていくことは、レガシー化の解消をこれ以上先送りできない理由の一つです。
属人化とカスタマイズの積み重ねによるブラックボックス化
レガシーシステムがブラックボックス化する主な原因は、悪意ある放置ではなく、事業の要請に応え続けた結果としての複雑化です。
- 機能の追加の重なり：売上拡大や新規事業のたびに機能を足すと、担当者の異動や退職で経緯を知る人が減り、誰も全体像を把握できなくなります。
- その場しのぎのパッチ対応：表面的な不具合をその都度パッチで塞ぐ運用を続けると、システムはさらに複雑化し、次に何かを変えるときの選択肢が狭まります。
- 外部連携を想定しない設計：API連携やクラウド活用の要望が増えると、無理な接続を重ねて構造がいっそう複雑になるという悪循環も起こりやすくなります。
経営判断として刷新のタイミングを見極める視点
レガシーシステム刷新の難しさは、技術的な限界だけでなく「いつ着手するか」という経営判断が問われる点にあります。
判断を先送りするほど選択肢は狭まり、移行コストとリスクは増大していきます。
着手を検討すべきサインと、判断を後押しする外部環境の変化を見ていきます。
事業戦略への追従不能・保守費用増加・セキュリティ脆弱性という3つのサイン
新しい事業戦略を打ち出しても既存システムがまったく追従できない状態、軽微な改修でも保守費用が増え続ける状態、サポートが切れた環境のまま稼働を続けてセキュリティ上の脆弱性を抱える状態。これら3つは、いずれも刷新の検討を始めるべきサインとされています。
これら3つは、老朽化が進むにつれて連鎖的に表面化することが多いものです。そのため、どれか一つでも当てはまれば、深刻化する前にアセスメントに着手する価値があります。
外部連携の欠如と深刻な属人化というサイン
新しい技術やデータ活用の仕組みと連携できないことも、見逃せないサインです。クラウドサービスやAI活用の要望が現場から上がっても、既存システムが外部連携を想定していない設計であれば、着手する前から実現性が絶たれてしまいます。
システムの中身を理解している人材が社内にごく一部しか残っていない深刻な属人化も、事業継続そのものを揺るがすリスクとして扱う必要があります。
外部連携の欠如と属人化が重なっている企業ほど、経営会議に判断を委ねる時期は近いと考えるべきです。
「2025年の崖」とSAP ERPの「2027年問題」による緊急性
経済産業省は2021年から2025年までを、レガシーシステムからの脱却を集中的に進める期間として位置づけてきました。この位置づけは、2025年時点で稼働年数21年以上のレガシーシステムが全体の6割に達すると見込まれることを前提にしています。
- 2025年の崖：対応を怠れば、経済損失が現実のものになりかねません。
- 2027年問題：SAP ERP(ECC6.0)の標準保守サポートが2027年末に終了することも、検討時期を早める要因になっています。
- 長年のカスタマイズ：肥大化した環境ほど後継製品への移行が容易ではなく、移行計画そのものが遅れている企業が多いと指摘されています。
対象システムを抱える企業にとっては、刷新の検討時期をあらためて前倒しする材料になっています。
レガシーシステム刷新の仕組みと進め方
レガシーシステム刷新は、現状把握から本稼働まで複数の工程を経て完了する取り組みです。思い立ってすぐに開発が始まるわけではありません。
現場が見落としがちなのは、開発そのものよりも、前後の意思決定プロセスに要する期間です。
アセスメントから稟議承認までの見落とされやすい期間
開発に入る前には、現状の把握から稟議承認まで、段階を追って意思決定を進める必要があります。
- アセスメント：現行システムの構成や外部連携を洗い出し、データ量と業務フローもこの段階で整理します。
- RFPとベンダー選定：方向性がある程度固まったら、RFP(提案依頼書)を作成してベンダーの選定コンペを行います。
- 稟議と承認：稟議を通して、経営会議や取締役会の承認を得る段階です。
技術的なアセスメント自体は2〜3ヶ月程度で完了することが多い一方、この意思決定のための社内プロセスは、開発の日程とは別に確保する必要があります。想定より長引くことも珍しくありません。
RFP作成が曖昧なままだと、後工程で予算超過やスケジュール遅延の温床になりかねません。そのため、対象範囲と課題を明確にしたうえで、定量目標と希望納期、評価基準まで文書にして提示することが欠かせません。
開発・移行・安定化までのプロジェクトの流れ
稟議承認後は、要件を定めて設計し、開発を経てデータを移行します。そのうえでテストを行い、本稼働を迎えたあと、安定化へと進みます。
特に基幹システムの刷新では、旧システムのデータを新システムへどう引き継ぐかというデータ移行の設計が欠かせません。あわせて、本稼働直後に想定外の不具合が出た場合に備え、切り戻しの体制も準備しておく必要があります。
フルスクラッチやオーダーメイドで作り替える場合、期間はおおむね12〜30ヶ月、費用は3,000万円から2億円程度が目安とされます。ただし、要件変更や移行対象データの想定外の複雑さによって、実質的な総費用が当初見積りの1.3〜1.5倍に膨らむケースもあるとされています。
レガシーシステム刷新の目的と得られる効果
レガシーシステム刷新では、何のために刷新するのかを先に決めておく必要があります。その目的が曖昧だと、稟議の説明も完了後の効果測定もぼやけてしまいます。
経営層にも説明しやすい2つの観点から、目的を見ていきます。
保守コストとセキュリティリスクの継続的な抑制
レガシーシステムを放置した場合の経営リスクは、コストの肥大化と人材の枯渇、セキュリティ・コンプライアンス上の危機、競争力の喪失という3つに整理できます。
COBOL技術者の退職が進み、サポートが切れた環境のまま稼働を続ければ、サイバー攻撃のリスクも放置されたままになります。
刷新の投資対効果を経営層に説明する際は、初期構築費用だけでなく、保守運用まで含めたTCO(総保有コスト)で比べるとよいでしょう。そのうえで、クラウド移行であれば1.5〜4年程度での投資回収を見込むFinOpsの観点を示すと、単なる支出ではなく投資として理解を得やすくなります。
外部連携や新しい事業展開への対応力の向上
刷新のもう一つの目的は、AIやIoTといった新しい技術や外部サービスとのデータ連携に対応できる基盤を手に入れることです。既存システムが外部連携を想定していないままでは、新しいビジネスモデルを検討しても、実現の道筋が立たないまま終わってしまいます。
たとえば、事務作業の時間削減のような定量的なKPIをあらかじめ決めておくと、刷新後にどの程度の効果が出たかを検証でき、次の投資判断の材料としても活用できます。
モダナイゼーション・システム刷新全般との違い
「レガシーシステム刷新」という言葉は、「システムのモダナイゼーション」や、より広い意味での「システム刷新」と混同されやすい言葉です。同じ文脈で語られることが多いものの、重心を置く論点は異なります。
モダナイゼーションは技術手法、刷新は経営判断という重心の違い
システムのモダナイゼーションは、リホストやリプラットフォーム、リファクタリングといった技術的な移行手法に焦点を当てた言葉として使われることが多いです。リビルドやリプレイスを含め、既存資産をどう作り変えるかという「手法側」の議論が中心になります。
一方で、レガシーシステム刷新は、対象がCOBOL資産や塩漬けシステムといった具体的なレガシー資産であることを前提とした言葉です。そのうえで、いつ着手するか、どう予算を確保して稟議を通すか、どんな体制で推進するかという「経営判断側」の論点に重心を置いて使われます。
システム刷新全般の総論と、レガシー資産固有の対応の違い
より広い「システム刷新」という言葉は、老朽化に限らず、事業拡大や組織再編など様々な理由によるシステムの作り替え全般を指します。
レガシーシステム刷新は、その中でも老朽化とブラックボックス化がすでに進んだ状況を対象にした個別テーマです。2025年の崖や2027年問題のような外部環境の変化によって先送りが難しくなっており、より緊急性の高い課題だと捉えると位置づけが整理しやすくなります。
レガシーシステム刷新の導入前に確認すべきポイント
刷新の必要性を感じていても、いざ動き出そうとすると、誰が主導するのか、どの程度の期間がかかるのか、業務を止めずに進められるのかといった疑問が次々に出てきます。
検討の初期段階で整理しておきたい実務上のポイントを取り上げます。
情報システム部門だけでは進まない刷新の体制
レガシーシステム刷新は、技術的なプロジェクトである以前に、経営判断を伴う投資案件です。
情報システム部門だけで進めようとすると、業務部門の協力を得られず要件が固まらなかったり、経営層への説明が技術用語に偏って稟議が通らなかったりします。
そのため、三位一体の体制を早い段階で組んでおくことが、後工程の手戻りを減らします。その内訳は、経営層がプロジェクト責任者として方針を示し、情報システム部門がプロジェクトマネジメントを担い、実際に業務を担う現場部門が要件を持ち寄る形です。
検討開始から稼働までの期間の目安
対象範囲や刷新の方式によって幅はありますが、アセスメントに2〜3ヶ月、RFP作成とベンダー選定に数ヶ月かかり、稟議承認を経て開発から本稼働までフルスクラッチの場合で12〜30ヶ月程度を見込む必要があります。
検討を始める段階から「いつまでに稼働させたいか」という逆算のスケジュールを持っておかないと、稟議承認の遅れがそのまま本稼働の遅れにつながります。
現行システムを止めずに刷新を進める方法
多くの場合、旧システムを稼働させたまま新システムを並行して構築し、段階的に機能やデータを移行していく進め方が取られます。
すべての業務を一度に切り替えるビッグバン移行はリスクが高く、対象範囲を絞ったパイロット部門から段階的に展開するスモールスタートのほうが、現場の心理的な抵抗も抑えやすくなります。
ただし、並行稼働の期間は、システムの二重運用によるコストと工数を生みます。いつまで並行させるかを、あらかじめプロジェクト計画に組み込んでおくことが重要です。
まとめ
レガシーシステム刷新とは、老朽化・ブラックボックス化した基幹システムを、経営判断に基づいて計画的に作り替える取り組みです。
事業戦略への追従不能や保守費用の増加、セキュリティの脆弱性など、5つのサインのいずれかに心当たりがあれば、先送りせずアセスメントに着手する価値があります。その判断では、2025年の崖やSAP ERPの2027年問題といった外部環境の変化も併せて踏まえます。
経営判断とプロジェクト推進力が問われるレガシーシステム刷新
技術的な作り替えそのものよりも、いつ着手するかという経営判断、RFPやベンダー選定を含む稟議の実務、業務部門と経営層を巻き込む三位一体の推進体制こそが、レガシーシステム刷新の成否を分けます。
稟議を通すための投資対効果の見せ方や、PoCを投資判断のゲートとして使う進め方は、次の段階で検討することになります。パッケージ、クラウド、フルスクラッチのどれを選ぶかという評価軸も、あわせて次の段階で扱います。
現状把握から始め、進め方は選定ポイントの記事で具体化
まずは、自社のどのシステムが老朽化のサインに当てはまるかを洗い出すことから始めてください。選定ポイントや評価軸、パッケージ・クラウド・フルスクラッチの選び分けについては、レガシーシステム刷新の選定ポイント・選び方・種類で詳しく解説しています。
既製パッケージやクラウドサービスでは吸収しきれない独自の業務要件がある場合、riplaはフルスクラッチ開発の立場から、要件整理から既存システムとの連携を含む構築まで支援しています。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。