2025年の崖とは?その後の現状とレガシーシステムの対策を解説

2025年を過ぎた今、「2025年の崖」は結局どうなったのか、自社に関係があるのかと疑問に思っている方もいるでしょう。
古いシステムの担当者が辞めた、ソフトのサポート終了の案内が届いたなど、思い当たることはあっても、何から手を付けるかは決めにくいものです。

この記事では、2025年の崖の意味と「12兆円」という試算の意味、2026年時点の現状を、公式資料をもとに整理しました。
経済産業省のまとめでは、2025年時点でも、システムを使う側の企業(ユーザー企業)の61%が古いシステム(レガシーシステム)を保有しているのが現状です(出典:経済産業省「レガシーシステムモダン化委員会総括レポート」)。
中小企業が自社に当てはまるかを見分ける5つのサインと、標準の仕組みに合わせる業務・作り込む業務の分け方も紹介します。

EPICsは業務システムの受託開発会社で、開発実績は250件以上です(出典:EPICs アプリ・システム受託開発サービス)。
業務診断から始め、既製のSaaS(インターネット経由で使うソフト)で足りる業務と作り込む業務の切り分けから、段階的な開発・導入まで支援しています。

監修者

石森裕也(EPICs株式会社 CTO)
サイバーエージェントのグループ会社での経験を経てEPICsに参画。開発経験10年。専門は、新規事業のアプリ開発(MVP開発を含む)と、業務システムの開発・刷新。ノーコード・AI駆動開発・スクラッチのすべてで開発経験を持つ。EPICsでは100件以上の新規事業・業務システム開発に携わり、主要プロジェクトで技術責任者を務める。

中原啓(EPICs株式会社 エンジニア)
NTTデータビジネスシステムズでWebアプリケーション開発に従事した後、EPICsに参画。専門は、新規事業のアプリ開発と、業務システムの開発・刷新。PMとして、EPICsの新規事業・業務システム開発の主要プロジェクトで開発工程の全体を管理する。ノーコードとAI駆動開発の両方で開発経験を持つ。

この記事の結論

1.2025年の崖は今も続く問題で、2025年時点でもユーザー企業の61%がレガシーシステムを保有している

2.仕組みを分かる人が1人しかいないなど、5つのサインに1つでも当てはまれば見直しを始める時期

3.対策は、経営層の方針、見える化、標準に合わせる業務と作り込む業務の切り分け、段階的な導入の順に進める

目次

2025年の崖とは?古いシステムがDXの足かせになる問題

2025年の崖とは、古くなった既存システムが足かせとなって企業のDXが進まず、2025年以降に大きな経済損失が生じるおそれがあるとして、経済産業省が2018年に示した問題です。
DXとは、デジタル技術で業務やビジネスの仕組みを変えることで、複雑になり中身が見えなくなった古いシステムが、その妨げになるとされました。

2025年の崖とは、既存システムの維持に予算と人を取られて新しい投資やDXが進まず、2025年以降に最大で年間12兆円の経済損失が生じるおそれがあるという問題(出典:経済産業省「DXレポート」)

経済産業省が2018年のDXレポートで示した警告

2025年の崖は、経済産業省が2018年9月に公表した「DXレポート」で使われた言葉です。
正式な名称は「DXレポート ~ITシステム『2025年の崖』の克服とDXの本格的な展開~」で、同省の研究会が2018年9月7日に公表しました。
レポートが指摘したのは、多くの企業がDXの必要性を理解していても、既存システムの複雑化や中身の見えにくさ、現場の抵抗によって、刷新が進まないという点です(出典:経済産業省「DXレポート」)。

放置すれば最大で年間12兆円の経済損失が出ると試算された

DXレポートは、既存システムの問題を放置した場合、2025年以降に最大で年間12兆円の経済損失が生じる可能性があると試算しました。
原文の表現は「2025年以降、最大12兆円/年(現在の約3倍)の経済損失が生じる可能性」です(出典:経済産業省「DXレポート」)。
この数字は、課題を克服できず何も手を打たなかった場合のシナリオに基づく試算で、実際に発生した損失額ではありません。

2025年が区切りなのは、古いシステムと人材の期限が重なるため

2025年が区切りとされたのは、古いシステムの老朽化、IT人材の不足、業務ソフトのサポート終了が、この時期に重なると見込まれたためです。
DXレポートは、2025年にはIT人材の不足が約43万人まで広がり、広く使われている業務ソフト「SAP ERP」のサポートも終了する予定だと示しました(出典:経済産業省「DXレポート」)。
同じレポートでは、21年以上稼働している基幹系システム(販売・在庫・会計など、会社の中心となる業務を支える仕組みで、基幹システムとも呼ばれる)が6割に増えるとも示されています。
人とシステムの両方の期限が同じ時期に来ることが、「崖」と呼ばれた理由です。

2025年の崖は結局どうなった?2026年時点の現状

2025年を過ぎた今、企業が一斉に崖から落ちるような出来事は起きていませんが、古いシステムの問題は解消されないまま続いています。
2025年の崖のその後を確かめる根拠となるのは、経済産業省が2025年5月に公表した総括レポートと、IPA(情報処理推進機構)の調査です。

企業が一斉に「崖から落ちる」出来事は起きていない

2025年の崖は、ある年に一斉に起きる出来事ではなく、古いシステムを抱えた会社で、障害や担当者の退職といった形で1社ずつ表面化していく問題です。
経済産業省の総括レポートは、2025年の崖を迎える中でも、産業界のDXと古いシステムからの脱却の進み具合は「依然としてスピード感に欠ける」と評価しました。
見直しを決めるきっかけも、大規模なシステム障害や保守を担う人の離脱といった受け身の要因が上位で、問題が起きてから動く企業が多い様子がうかがえます(出典:経済産業省「総括レポート」)。

2025年時点でも、6割の企業にレガシーシステムが残る

経済産業省の総括レポートによると、2025年時点でもユーザー企業の61%がレガシーシステムを保有しています。
もとになったのは、IPAが2024年12月〜2025年2月に約4,000社のユーザー企業・ベンダー企業へ行い、799社が回答した「2024年度ソフトウェア動向調査」の結果です(出典:経済産業省「総括レポート」、IPA「2024年度ソフトウェア動向調査」)。
ユーザー企業とは、システムを使う側の企業のことで、開発会社(ベンダー企業)と区別するときに使われます。

レガシーシステムとは、運用・保守や機能の改良が難しくなり、経営・事業戦略の足かせや高コストの原因になっているシステムを指します。
総括レポートは、古い技術で作られていても、保守の体制が整い、仕様が明確で改良を続けられるならレガシーシステムではないという立場です(出典:経済産業省「総括レポート」)。
問題になるのは古さではなく、直せない・変えられない状態のほう。

刷新が進んだ企業と進まない企業に分かれ、頭打ちになっている

IPAの調査では、古いシステムの刷新を終えた企業と、ほとんど手を付けられていない企業に分かれ、刷新のペースは頭打ちの様子が見られます。
IPA「DX動向2025」によると、日本は「レガシーシステムはない」と答えた企業の割合が、日本・米国・ドイツの3か国で最も高い一方、「ほとんどがレガシーシステムである」「わからない」の割合も最も高い結果でした。
2022年度から2023年度にかけては「ない」が増えたものの、2024年度は2023年度と傾向があまり変わらず、刷新が頭打ちになっている様子がうかがえるという分析です(出典:IPA「DX動向2025」)。

2025年の崖の何が問題?古いシステムが会社の足かせになる4つの理由

古いシステムが問題になるのは、古いこと自体ではなく、仕様が分からず直せない、費用ばかりかかるといった状態が、会社の判断と投資を縛るからです。
主な理由として、次の4つが挙げられます。

  • 仕様が分からず、直せる人がいなくなる
  • 維持費に予算を取られ、新しい投資に回せない
  • 保守できる人材が減り、サポート終了の期限も迫る
  • セキュリティの弱点が残り、データも活用できない

仕様が分からず、直せる人がいなくなる(ブラックボックス化)

長年の改修で仕組みが複雑になり、設計書も残っていないと、システムの中身を誰も説明できないブラックボックスになります。
総括レポートは、レガシーシステムの要因の一つに、仕様や設計のドキュメント(資料)が整っておらず、移行や作り直しのときに支障が出ることを挙げました。
保守が特定の人に頼った、属人的な状態になっていることも要因の一つです。
多くのユーザー企業がベンダー企業(開発会社)に依存し、IT人材がベンダー企業に偏っているとも指摘しています(出典:経済産業省「総括レポート」)。

ブラックボックス化したシステムでは、作った担当者が退職した、開発を頼んだ会社と連絡が取れないといった状況になると、小さな不具合でも直せなくなりがちです。
大企業では、COBOLという古いプログラミング言語や、メインフレーム(大型の汎用コンピューター)で動くシステムで、こうした状態が起きやすいとされています。
後回しにした改修が借金のように将来の負担として積み重なったものは「技術的負債」と呼ばれ、放置するほど見直しの手間が増えるのが特徴です。

維持費に予算を取られ、新しい投資に回せない

古いシステムを動かし続けるための保守費が膨らむと、業務を良くするための新しい投資に予算を回せなくなります。
DXレポートは、問題を放置した場合、システムの維持管理費が高額化し、IT予算の9割以上を占めるようになると見込みました(出典:経済産業省「DXレポート」)。
中小企業では、小さな修正を頼んだだけでも見積もりが高く、対応に時間がかかる、といった形で表れることがあります。
守りの費用に予算を取られるほど、攻めの投資は後回しになるという構図です。

保守できる人材が減り、サポート終了の期限も迫る

古い技術を扱える人が減る一方で、ソフトのサポート終了の期限は決まっているため、直せないまま使い続けるリスクが高まります。
総括レポートは、2025年度のIT人材の需給を試算し、ユーザー企業の需要に対して、ベンダー企業の供給は66%の充足率にとどまるとしました。
ITの担い手は、人口減少と熟練者の離脱によって減り続けているとも指摘しています(出典:経済産業省「総括レポート」)。
サポート終了の例としてよく挙げられるのが、業務パッケージ「SAP ERP 6.0」の「2027年問題」です。

セキュリティの弱点が残り、データも活用できない

サポートが終わったソフトは弱点を直す更新が届かないため、攻撃や情報漏えいのリスクを抱えたまま使うことになります。
IPA「DX動向2025」では、従業員100人以下の企業の34.6%が、サイバーセキュリティ対策について「特に対策は実施してない」という結果でした(出典:IPA「DX動向2025」)。

総括レポートによると、システムの作りやデータの形式が古いと、最新のツールやサービスでデータの利活用を適切に行えません(出典:経済産業省「総括レポート」)。
売上や在庫のデータがあっても、新しいツールに取り込めなければ、経営判断に生かすことは難しいでしょう。

2025年の崖は中小企業にも関係ある?自社が当てはまるかの見分け方

2025年の崖は中小企業にも関係があります。規模が小さくても、作った人しか分からない仕組みに業務を頼っていれば、同じ問題を抱えているからです。

中小企業は大企業より保有率が低いが、無関係ではない

経済産業省の総括レポートでは、レガシーシステムの保有率は大企業のほうが高いものの、中小企業には投資の体力や人材の面で別の課題があるとされています。
同レポートは、中小企業は投資の体力に加え、経営としてのITへの理解や人材の面の問題が大きいと指摘しました。
地方企業・中小企業は1社ではリソースが足りず、古いシステムの見直しの検討が進まないとも書かれています(出典:経済産業省「総括レポート」)。

DXへの取り組みでも、規模による差は小さくありません。
IPA「DX動向2026」(2026年7月公開)によると、DXに取り組んでいる企業の割合は、従業員1,001人以上の98.7%に対し、100人以下は41.6%にとどまり、2倍以上の差があります(出典:IPA「DX動向2026」)。
保有率の数字だけを見て「うちは関係ない」と考えるのは早計です。

5つのサインに1つでも当てはまれば、見直しを始める時期

次の5つのサインに1つでも当てはまるなら、古いシステムの見直しを始める時期です。
総括レポートが挙げるレガシーシステムの要因をもとに、自社で確かめやすい形に整理しました(出典:経済産業省「総括レポート」)。

サインなぜ危ないか
仕組みを分かっている担当者や開発会社が1人(1社)しかいない辞めたり連絡が取れなくなったりすると、直せなくなる
ソフトやパッケージのサポート終了の案内が来ている更新が止まり、不具合や弱点が直らなくなる
小さな修正でも見積もりが高く、時間がかかる仕組みが複雑になっているサイン
同じデータを複数のシステムやExcelに入力し直している・転記ミスが起きる
・データを経営判断に使えない
システムの全体像を説明できる資料がない移行や作り直しのときに支障が出る

障害が起きてから動くのではなく、サインの段階で見直しを始めれば、慌てて移行先を探す事態を避けやすくなります。
なお、このチェックは見直しの目安であり、システムの状態を診断するものではありません。

業務システムの開発・見直し、まずは無料でご相談ください

EPICsは250件以上の開発実績をもとに、現場の課題整理から業務システムの開発・導入・定着まで一気通貫で支援します。どの業務からシステム化すべきか、という段階からご相談いただけます。

2027年問題・2025年問題と何が違う?混同しやすい言葉の整理

2025年の崖と混同しやすい言葉のうち、2027年問題は崖の続きにある期限で、高齢化をめぐる2025年問題は別の問題です。
次の3つを押さえておくと、言葉の混同を防げます。

  • 呼び方の誤り:正しい名称は「2025年の崖」
  • 2025年問題:高齢化をめぐる別の問題
  • 2027年問題:崖の続きにある期限
2025年問題は団塊の世代が75歳以上になることによる医療・介護などの問題で、2025年の崖とは別物。2027年問題はSAP ERP 6.0の標準保守の期限で、崖の続きにあたる

「2025年の壁」は誤った呼び方で、正しくは「2025年の崖」

「2025年の壁」は「2025年の崖」の誤った呼び方です。IT分野では、2025年の崖を「2025年問題」と呼ぶこともあります。
正式な言葉は、経済産業省のDXレポートの副題にある「2025年の崖」です(出典:経済産業省「DXレポート」)。
社内の資料や説明で使うときは「崖」の字で統一しておくと、調べ直すときにも食い違いが起きません。

「2025年問題」は高齢化の問題で、崖とは別のもの

一般に「2025年問題」と言う場合は、団塊の世代が75歳以上になることによる医療・介護などの問題を指し、ITシステムの崖とは別のものです。
厚生労働省は、団塊の世代が75歳以上となる2025年を目途に、住まい・医療・介護・予防・生活支援を地域で一体的に提供する「地域包括ケアシステム」の構築を進めてきたとしています(出典:厚生労働省「地域包括ケアシステム」)。
同じ「2025年」が付いていても、2025年の崖は企業のITシステムの問題で、2025年問題は社会の高齢化の問題です。

「2027年問題」はSAP ERPの保守期限で、崖の続きにある

2027年問題は、業務パッケージ「SAP ERP 6.0」の標準保守の期限が2027年に来ることを指し、2025年の崖の続きにある期限です。
SAP ERP 6.0は大企業を中心に使われている業務パッケージで、DXレポートの時点では2025年にサポートが終わる予定でした(出典:経済産業省「DXレポート」)。
SAPは2024年1月の案内で、SAP ERP 6.0の標準保守(メインストリームメンテナンス)が、使っているエンハンスメントパッケージ(機能追加の単位)によって2025年・2027年・2030年のいずれかに終わると案内しています。
エンハンスメントパッケージ6〜8へ上げれば、2027年まで延長が可能です(出典:SAP ニュースセンター「SAP ERP 6.0の保守期限に関する案内」)。

SAP ERPに限らず、中小企業が使う会計ソフトや業務パッケージにも、それぞれサポートの期限があります。
期限が来てから慌てないよう、自社のソフトの期限を確かめ、そこから逆算して見直しの時期を決めておきましょう。

2025年の崖の対策は?中小企業が今から取り組む4つのこと

2025年の崖の対策は、経営層が方針を決め、今のシステムを見える化し、標準の仕組みに合わせる業務と作り込む業務を分けたうえで、段階的に進めることです。
古いシステムを今の技術に合わせて作り直したり、移し替えたりすることを「モダナイゼーション」と呼び、ここで紹介するのはその最初の一歩にあたります。

取り組むことを順に並べたのが、次の4つです。

  • 経営層が方針を決め、現場任せにしない
  • 今のシステムと業務の使われ方を見える化する
  • 標準に合わせる業務と、作り込む業務を分ける
  • 作り込む部分は、一度に入れ替えず段階的に進める
2025年の崖の対策は、経営層が方針を決め、今のシステムと業務を見える化し、標準に合わせる業務と作り込む業務を分けたうえで、作り込む部分を段階的に進めること

経営層が方針を決め、現場任せにしない

古いシステムの見直しは、経営層が自分ごととして方針を決めないと進みません。
総括レポートも、古いシステムの作り直し(モダン化)について、「レガシーシステムのモダン化は経営層のトップダウンの方針無しでは決して進まない」と言い切っています(出典:経済産業省「総括レポート」)。
現場に標準化の検討を丸投げすると、今の機能をそのまま残そうとする考え(現行踏襲)が足かせになるおそれがある、というのが同レポートの見方です。

決める人は、中小企業なら社長、規模の大きい会社ならITを担当する役員など、会社の規模や体制によって違います。大切なのは、現場任せにせず経営として決めることです。
担当者が社長などの経営層に説明するときは、「誰が決めるのか」を最初の論点にすると、話を前に進めやすいでしょう。

今のシステムと業務の使われ方を見える化する

最初にやるべきことは、社内にどんなシステムがあり、誰がどの業務でどう使っているかを一覧にすることです。
総括レポートによれば、IT資産を見える化(可視化)することで、老朽化したシステムや保守期限が近いソフトなどのリスクを特定できます。
経営層へ具体的なデータをもとに説明できるようになることも、利点の一つです(出典:経済産業省「総括レポート」)。

一覧に書き出す項目の例を、次の表に示します。

項目書く内容
システム名販売管理、勤怠管理、Excelの集計表など、業務で使っている仕組みの名前
使っている業務と部署どの部署の誰が、どの業務で使っているか
作った会社・担当者開発した会社や、社内で仕組みを分かっている人
保守・サポートの期限ソフトやパッケージのサポートが終わる時期
困っていること・動作が遅い
・入力が二度手間になっている
・直せる人がいない

一覧ができれば、どこにリスクが集まっているかが見え、経営層と優先順位を相談しやすくなるでしょう。

EPICs株式会社CTO 石森裕也からのコメント

当社では、業務の見える化の段階で、システムの一覧だけでなく、現場の方がシステムの外で行っている作業まで確かめるようにしています。たとえば、システムから出したデータをExcelに転記して集計し直す、紙に書き写してから入力するといった作業です。こうした作業は一覧には載りませんが、作り直したときに抜け落ちると、現場の業務が回らなくなります。業務診断で、運用後に起きそうな課題や仕様の抜け漏れを事前に洗い出すのは、この見落としを防ぐためです。

標準に合わせる業務と、作り込む業務を分ける

作り直す前に、SaaS(インターネット経由で使うソフト)やパッケージ(既製の業務ソフト)など標準の仕組みに合わせられる業務と、自社の強みとして作り込むべき業務を分けます。

総括レポートが「標準化対応」として示しているのは、次の4点です(出典:経済産業省「総括レポート」)。

  • 今の機能をそのまま残すこだわり(現行踏襲)を捨て、あるべき業務の姿から考え、標準的な仕様に寄せる部分と、付加価値を作り込む部分とを明確に分ける
  • 業務を見直し、標準的なパッケージやSaaSへ移行できるかを最優先で検討する
  • 経営資源の制約が大きい中堅・中小企業は、オーダーメイドのスクラッチ開発(ゼロから専用に作る開発)は避け、パッケージやSaaSを原則とすべきだとする
  • Fit&Gap分析(既製品と自社業務の合う点・合わない点を洗い出すこと)で大きなギャップがある業務は、最小限のカスタマイズで済む方法を検討する

総括レポートの標準化対応は、すべてを既製品に合わせるか、すべてを作るかの二択ではありません。
どこまでを標準に合わせ、どこを作り込むかを業務ごとに判断することが、この考え方の軸です。

分け方の目安を表にまとめました。

分け方向いている業務の例
標準に合わせやすい業務法令や一般的なルールで手順が決まっている業務
・会計
・給与
・勤怠
作り込みを検討する業務・他社との違いを生む業務
・業界特有の手順で、既製品とのギャップが大きい業務

表は一般的な目安で、同じ業務でも会社によって向き不向きは変わります。

EPICs株式会社CTO 石森裕也からのコメント

当社では、標準に合わせるか作り込むかに加えて、今のシステムの一部を改修して使い続ける選択肢も並べて比べるようにしています。システムの中身が分かっていて、困っているのが一部の機能だけであれば、全体を作り直すより、その部分だけを直すほうが費用も現場の負担も小さく済む場合があるからです。反対に、中身を説明できる人がいない、サポートの期限が近いといった場合は、一部だけ直しても同じ問題が残るため、作り直しを含めて比べます。

作り込む部分は、一度に入れ替えず段階的に進める

作り込む業務も、全体を一度に入れ替えず、影響の小さい業務から試して広げると、失敗したときの痛手を小さくできます。
総括レポートは、企業の規模やシステム化の状況に応じた進め方の例として、小規模な企業でも計画的かつ段階的にモダン化を進めることを挙げました。
業務パッケージをカスタマイズして使っている企業が、古い仕組みの業務を段階的に廃止し、クラウドサービスへ順次移行する例も紹介されています。
モダン化は一過性の取り組みではなく、時間がたてば再び必要になるものだという位置付けです(出典:経済産業省「総括レポート」)。

システムリプレイス(今のシステムを新しいものに入れ替えること)を進めるときは、次のシステムで設計書などのドキュメントを残すことも欠かせません。
資料が残っていれば、担当者や開発会社が変わっても中身を説明でき、同じブラックボックス化を繰り返さずに済みます。

古い業務システムの見直しならEPICs

EPICsは、古くなった業務システムの見直しを、標準の仕組みに合わせる業務と作り込む業務の切り分けから、段階的な開発・導入まで1社で支援する受託開発会社で、開発実績は250件以上です。
まず業務診断で現場の実態や仕様の抜け漏れを洗い出し、SaaSで足りる場合はSaaSを、一部の改修で済む場合はその方法を提案するなど、作らない選択肢も含めて検討します。

作り込む部分は、ノーコード(プログラムを書かずに作る手法)・AI駆動開発(AIを活用して開発を進める手法)・スクラッチ開発を、業務ごとに使い分けるのが基本です。
進め方は「現状把握→方針策定→パイロット→横展開→継続改善」の段階制で、一部の業務で試すパイロットの後に、拡げる・作り直す・止めるを判断できます。

次のブラックボックスを作らないよう、ドキュメントを整備し、コードとデータの所有権をお渡しして、移管しやすい状態を保つのも当社の方針です。
10年使う前提の保守しやすい構成で作り、公開後の保守や追加開発にも対応しています。

費用の目安は、業務診断が30万円〜(本開発を依頼する場合は全額充当)、一部業務のパイロット開発が50万円〜です。
まずは社内のシステムと業務を一覧にし、どこを標準に合わせ、どこを作り込むかを整理するところから、一緒に始められます。

出典:EPICs アプリ・システム受託開発サービス/EPICs 業務改善のためのアプリ・システム受託開発サービス

2025年の崖は嘘(大げさ)だったのですか?

嘘ではありません。2025年に企業が一斉に崖から落ちるような出来事は起きていませんが、経済産業省のDXレポートが示した「最大で年間12兆円」の経済損失は、古いシステムの問題を放置した場合の試算であり、実際の損失額ではありません。経済産業省が2025年5月に公表した総括レポートは、産業界のDXと、運用・保守や改良が難しくなったレガシーシステムからの脱却の進み具合を「依然としてスピード感に欠ける」と評価しました。同レポートによると、2025年時点でもユーザー企業の61%がレガシーシステムを保有しており、2025年の崖は、障害や担当者の退職といった形で1社ずつ表面化していく、今も続く問題と考えられます。

なぜ2025年を過ぎても、古いシステムから抜け出せない企業が多いのですか?

既存システムが複雑で作り直しが技術的に難しいことと、今の機能をそのまま残す(現行踏襲)という制約が大きいことが、主な理由です。経済産業省が2025年5月に公表した総括レポートでは、システムを見直すときの障壁として、既存システムが複雑で技術的に困難なことや、現行機能の保証・踏襲の制約が大きいことが挙がっています。また、見直しを決めるきっかけは、大規模なシステム障害や保守を担う人の離脱といった受け身の要因が上位を占め、問題が起きるまで先送りされやすい傾向にあるのも特徴です。中小企業の場合は、投資の体力に加え、経営としてのITへの理解や人材の面の問題も大きいとされています。

DXレポートの「12兆円」は、実際に出た損失の額ですか?

いいえ、実際に出た損失の額ではありません。経済産業省が2018年に公表したDXレポートは、古いシステムの問題などの課題を克服できなかった場合に、2025年以降、最大で年間12兆円(レポート公表時点の約3倍)の経済損失が生じる可能性があると試算しました。これは何も手を打たなかった場合のシナリオに基づく見積もりで、2025年以降に実際に発生した損失を集計した数字ではありません。社内で説明するときは、「放置した場合に、最大で年間12兆円の損失が出る可能性があるという試算」と伝えるのが正確です。

SaaSやパッケージが業務に合わない場合は、どうすればよいですか?

まず、既製品と自社の業務の合う点・合わない点を洗い出し、業務のやり方を変えて合わせられないかを確かめることから始めます。この洗い出しはFit&Gap分析と呼ばれる方法です。経済産業省が2025年5月に公表した総括レポートは、業務を見直したうえで、標準的なパッケージやSaaS(インターネット経由で使うソフト)へ移行できるかを最優先で検討し、Fit&Gap分析で大きなギャップがある業務は、最小限のカスタマイズで済む方法を検討すべきとしています。標準的な仕様に寄せる部分と、付加価値を作り込む部分とを明確に分けることも、同レポートが重視する点です。合わない業務をすべて作り込むのではなく、どこまでを標準に合わせ、どこを作り込むかを業務ごとに判断します。

業務システムの開発・見直し、まずは無料でご相談ください

EPICsは250件以上の開発実績をもとに、現場の課題整理から業務システムの開発・導入・定着まで一気通貫で支援します。どの業務からシステム化すべきか、という段階からご相談いただけます。

この記事を書いた人

石森裕也のアバター 石森裕也 EPICs株式会社 CTO

EPICs株式会社 CTO。サイバーエージェントのグループ会社での経験を経てEPICsに参画。開発経験は10年で、これまで100件以上の開発に従事。ノーコード・AI駆動開発・スクラッチ開発のいずれにも対応し、EPICsが手がける新規事業開発・業務システム開発の多くを中心メンバーとして担当している。

目次