老朽化した社内システムの「延命 vs 作り直し」判断基準

「なんとか動いている」。この一言に、古い社内システムを抱える担当者の悩みのすべてが詰まっています。導入から10年、15年と経過したそのシステムは、画面は古めかしく、動作もどこか重い。しかし業務は一応回っている。だからこそ「今すぐ何とかしなければ」という切迫感は生まれにくく、かといって「このままでいい」とも言い切れない、宙ぶらりんの状態が何年も続いてしまいます。

経営会議で「そろそろシステムを新しくしないか」という話が出ても、具体的な判断材料がなければ議論は堂々巡りになります。「壊れていないものを、なぜ今、お金をかけて作り直す必要があるのか」という経営層の疑問はもっともです。一方で、担当者としては「いつか限界が来るのではないか」という漠然とした不安を抱えている。この温度差が、多くの中小企業で老朽化システムの問題を先送りにさせている根本的な原因です。

この記事では、「延命」(今のシステムを保守しながら使い続ける)と「作り直し"(新しいシステムへ刷新する)のどちらを選ぶべきかを、感覚ではなくフレームワークで判断できるように整理します。断定的な金額基準を示すのではなく、TCO(総所有コスト)・技術的負債・機会損失という3つの視点から、自社の状況を数値化・言語化する手順を解説します。経営層への説明資料としてもそのまま使える構成にしていますので、順に読み進めてください。

この記事で分かること

古いシステムを「あと何年使うか」「作り直すべきか」を判断する際に使える、3つの評価軸(TCO・技術的負債・機会損失)の考え方と、実際に自社のケースへ当てはめるための具体的な手順を解説します。延命・作り直し・部分刷新という3つの選択肢を比較する視点も扱います。

先に結論を言うと、判断のプロセスは次の4ステップです。

• 現状把握: 今のシステムにかかっている費用と手間を洗い出す(TCOの可視化)
• リスク評価: このまま使い続けた場合の技術的負債とリスクを評価する
• 機会損失の検討: 作り直さないことで失っている可能性のある成長機会を考える
• 選択肢の比較: 延命・作り直し・部分刷新のどれが自社に合うかを比較する

「壊れているかどうか」だけで判断するのではなく、「このシステムを維持することに、これからどれだけのコストとリスクを払い続けるのか」という視点に切り替えることが、この記事全体を通じた最大のポイントです。

なぜ「動いているから大丈夫」が危険な判断なのか

結論から言うと、「動いている」は「安全である」ことをまったく意味しません。むしろ、動いているように見えることが、問題の発見を遅らせる原因になります。

古いシステムが抱えるリスクの多くは、平常時には表面化しません。EOL（サポート終了）を迎えたOS上で動くサーバーも、単一障害点（SPOF）になっている古い機器も、普段どおり業務をこなしている限りは何の異常も感じさせません。しかし、これは「リスクがない」のではなく「リスクが顕在化していないだけ」という状態です。

このタイプのリスクには、共通する厄介な特徴があります。

• 平常時は正常に動作するため、問題の深刻さが体感的に伝わりにくい
• 障害が起きたときには、原因調査や代替手段の確保に時間がかかり、被害が一気に拡大する
• 対応できる技術者やパーツがすでに市場からほとんど失われていることが多い
• 「後回しにしても今のところ困っていない」という判断が、何年も繰り返されやすい

こうした性質を持つシステムを、経済産業省は「レガシーシステム」問題として早くから警鐘を鳴らしてきました。2018年に公表された「DXレポート」では、既存システムが老朽化・複雑化・属人化した状態のまま放置されると、2025年以降、最大で年間12兆円(現在の約3倍)の経済損失が生じる可能性があるという試算を示し、これを「2025年の崖」と呼びました。

さらに2025年5月、経済産業省は「レガシーシステムモダン化委員会」の総括レポートを公表し、レガシーシステムの問題が2025年の崖という一過性の期限で終わるものではなく、継続的な経営課題であるという認識をあらためて示しています。このレポートでは、経営層の意識変革とITガバナンスの強化、情報システム部門の自律性、IT資産の可視化と内製化の重要性が指摘されました。「動いているから後回し」という判断が、公的機関からも繰り返し課題視されているという事実は、経営層への説明材料としても押さえておく価値があります。

実務上の視点: 「壊れていない」は保守エンジニアの視点での安全宣言ではなく、あくまで「今日まで壊れなかった」という結果論に過ぎません。特に一人情シスや兼任担当者の体制では、リスクが顕在化してから対応を始めるのでは間に合わないケースが多く、平常時にこそ評価をしておく必要があります。

老朽化システムの3つの選択肢を整理する

結論から言うと、老朽化したシステムへの対応は「延命」「作り直し」「部分刷新」の3つに大別できます。どれか一つが常に正解というわけではなく、システムの重要度や残された時間によって最適解が変わります。

多くの担当者が最初につまずくのは、「延命か、作り直しか」の二択で考えてしまうことです。実際には、基幹となる古いサーバーだけを新しいクラウド環境へ移し、業務アプリケーションはそのまま延命させるといった「部分刷新」が現実的な落としどころになることも少なくありません。まずは3つの選択肢があることを前提に、自社のケースを評価していきましょう。

評価軸その1: TCO(総所有コスト)を可視化する

結論から言うと、判断の出発点は「今のシステムに、実際いくらかかっているか」を正確に把握することです。多くの会社では、この金額そのものが可視化されていません。

TCO(Total Cost of Ownership、総所有コスト)とは、システムの購入・導入費用だけでなく、その後の運用・保守・トラブル対応にかかる費用まで含めた、システムを保有し続けることの総コストを指す考え方です。老朽化したシステムほど、目に見えにくいコストが積み重なっている傾向があります。

TCOを洗い出す際は、次のような項目に分けて整理すると漏れが少なくなります。

• 直接費用: 保守契約料、ライセンス費用、オンプレミスサーバーの電気代・設置スペースの賃料相当額
• 間接費用(人件費): 障害対応・不具合の問い合わせ対応に費やしている担当者の時間(時給換算)
• 属人化コスト: 特定の担当者しか対応できないことで生じている、教育・引き継ぎの負担
• 機会コスト: システムの制約によって、他の業務に振り向けられなかった時間

このうち、間接費用と属人化コストは請求書に出てこないため見落とされがちですが、実際には直接費用より大きな負担になっているケースも珍しくありません。たとえば、月に数回発生する不具合対応に担当者が半日ずつ費やしているなら、その時間だけで年間数十時間、場合によっては100時間を超える人件費が「見えないTCO」として積み上がっている計算になります。

実務上のコツ: 正確な金額を出そうとして手が止まってしまう場合は、まず「体感でどれくらいの頻度・時間がかかっているか」を書き出すところから始めてください。厳密な会計処理ではなく、経営層に規模感を伝えるための資料作りが目的です。1〜2週間、対応にかかった時間をメモしておくだけでも、十分な材料になります。

TCOを可視化したあとは、「延命した場合、このコストは今後どう変化するか」を考えます。一般的に、システムが古くなるほど、保守にかかる人件費と属人化コストは増加する傾向にあります。対応できる技術者が減り、代替パーツの調達も難しくなるためです。逆に、作り直しには初期費用がかかりますが、その後の運用コストは新しい技術に対応した分だけ効率化される可能性があります。この「初期費用は高いが将来コストは下がる」対「初期費用は低いが将来コストは増え続ける」という構図を、複数年で比較する視点がTCO評価の核心です。

評価軸その2: 技術的負債を評価する

結論から言うと、技術的負債とは「今、対応を先送りしていることで、将来より大きなコストとなって返ってくる」というリスクの蓄積のことです。金額に換算しづらいため、TCOの計算だけでは見えてこない部分を補完する視点になります。

技術的負債という言葉は、もともとソフトウェア開発の現場で使われてきた概念です。本来やるべき改修や整理を後回しにすることで、システムの内部に「借金」のような負の蓄積が生じ、あとから返済(改修)しようとするほど利息(コスト)が膨らんでいく、という比喩です。老朽化した社内システムにおいては、次のような形で技術的負債が積み上がっていきます。

• 開発時のドキュメントがなく、レガシーシステムの内部構造を把握できる人がいない
• 現在では入手困難な旧型ハードウェアや旧バージョンのソフトウェアに依存している
• VBAマクロや個人が作成したツールが、業務の根幹を支えてしまっている
• 対応できるエンジニアの高齢化・引退により、保守できる人材そのものが市場から減っている

技術的負債の怖いところは、負債が積み上がるほど「返済(刷新)のコストも同時に上がっていく」という点です。5年前なら比較的小さな改修で済んだはずの問題が、放置されたことでシステム全体に絡み合い、今では全面刷新でしか解決できない状態になっている、というケースは実務でよく見られます。

先ほど紹介した2025年のレガシーシステムモダン化委員会の総括レポートでも、企業がIT資産の全容を把握できていないこと自体が、モダン化を妨げる要因として指摘されています。技術的負債を評価する第一歩は、まず「自社のシステムに、どれだけの負債が積み上がっているか」を棚卸しすることです。これは前段のTCO算出と並行して進めると効率的です。

技術的負債のチェックリスト

以下の項目に多く当てはまるほど、技術的負債が大きく蓄積している状態と考えられます。

• [ ] システムの仕様書・設計書が存在しない、または最新の状態に更新されていない
• [ ] 開発を担当した会社や技術者に、現在は連絡が取れない
• [ ] OSやミドルウェアがすでにEOL(サポート終了)を迎えている、または近く迎える
• [ ] システムの一部が、特定の担当者しか操作方法を知らない状態になっている
• [ ] 障害が起きた際、原因の特定に日単位の時間がかかった経験がある

3つ以上当てはまる場合は、技術的負債がすでに無視できない水準に達している可能性が高く、対応の優先順位を上げて検討することをおすすめします。

評価軸その3: 機会損失を考える

結論から言うと、老朽化システムの問題は「今かかっているコスト」だけでなく、「本来得られたはずなのに得られていない利益」という視点でも捉える必要があります。これが機会損失です。

機会損失は、TCOや技術的負債と違って、目に見える請求書や不具合報告としては現れません。だからこそ経営層に伝わりにくく、見過ごされがちな観点です。しかし、老朽化したシステムを使い続けることで、次のような機会を逃している可能性があります。

• 他社が新しいツールで実現している業務効率化を、自社だけ実現できていない
• 顧客データや売上データが古いシステムに閉じ込められ、経営判断に活用できていない
• 新しい人材(特に若手)が、古いシステムの使いにくさを理由に定着しない、あるいは採用時点で敬遠される
• クラウド化やAI活用など、周辺の業務改善施策が「古いシステムとの連携ができない」という理由で頓挫する

機会損失を評価する際に注意したいのは、「断定的に金額を出そうとしない」ことです。「このシステムのせいで年間◯百万円の損失が出ている」と精緻に言い切れるケースは稀で、無理に数値化しようとすると根拠の薄い主張になってしまいます。実務的には、「◯◯という施策をやりたいが、今のシステムでは技術的に対応できない」「同業他社は◯◯を導入して受注効率を上げているが、自社は同じ土俵に立てていない」というように、具体的な事例ベースで機会損失を言語化する方法が現実的です。

実務上の視点: 機会損失は「今すぐの痛み」ではないため、経営層の優先順位では後回しにされがちです。しかし競合他社との比較や、採用活動における若手からの反応など、外部からの視点を交えて伝えると説得力が増します。可能であれば、同業種・同規模の会社がどの程度システムに投資しているか、業界団体や商工会議所などから情報を集めておくとよいでしょう。

3つの評価軸を1枚のシートにまとめる

結論から言うと、TCO・技術的負債・機会損失の3つを別々に語るのではなく、1枚の資料にまとめることで、経営層への説明が格段にしやすくなります。

以下は、実際に整理する際のシートの一例です。自社の数字やエピソードに置き換えて使ってください。

このシートを埋める過程そのものが、担当者自身の頭の中を整理する作業にもなります。感覚的に「そろそろ限界かもしれない」と思っていたことが、具体的な数字や事例として言語化されることで、経営層への説明だけでなく、自分自身の判断にも自信が持てるようになります。

判断に迷ったときの目安:フレームワークとしての考え方

ここまでの3つの評価軸を踏まえたうえで、実務でよく使われる判断の目安を紹介します。ただし、これはあくまで一般的なIT資産管理の考え方に基づくフレームワークであり、断定的な数値基準ではない点に注意してください。会社の規模、業種、資金繰りの状況によって最適な答えは変わります。

判断の際によく参照される視点は次の3つです。

• 残存耐用年数との比較: EOL(サポート終了)や機器の物理的な寿命まで残された時間が、作り直しに必要な期間(要件整理から本稼働まで、規模にもよりますが数ヶ月〜1年程度かかることが一般的です)より短い場合、延命よりも作り直しの検討を急ぐ必要性が高まります
• TCOの増加傾向: 過去数年のTCOが右肩上がりで増加している場合、延命コストは今後も膨らみ続ける可能性が高く、早期の作り直しのほうが中長期的に安く済む場合があります
• 業務変化への追随度: 会社の事業内容や業務フローが大きく変わったにもかかわらず、システムがそれに追随できていない場合は、延命による小手先の改修では限界がある可能性が高いサインです

逆に言えば、これらに当てはまらない場合、つまりEOLや機器寿命までまだ十分な時間があり、TCOも安定していて、業務内容にも大きな変化がない場合は、慌てて作り直す必要はなく、当面は延命を選びながら計画的に次の一手を準備する、という判断も十分に合理的です。判断軸をより体系的に整理したい場合は、老朽化した社内システムをいつ・どう刷新するかというリプレースの判断基準も参考になります。

参考にしてよい考え方と、避けるべき考え方

• 参考にしてよい: 「TCO・技術的負債・機会損失の3軸で毎年チェックし、傾向の変化を見る」という継続的なモニタリングの発想
• 避けるべき: 「導入から◯年経ったら自動的に作り直す」という、実態を見ない機械的なルール適用

システムの状態は会社ごと、業務ごとに大きく異なります。年数だけを基準にした判断は、まだ十分使えるシステムを不必要に早く作り直してしまう、あるいは逆に本当に危険な状態のシステムを「まだ◯年だから大丈夫」と放置してしまう、どちらの失敗にもつながりかねません。

部分刷新という第三の選択肢

結論から言うと、「延命」と「全面的な作り直し」の間には、「部分刷新」という現実的な選択肢があります。予算やスケジュールの制約が大きい中小企業では、この選択肢が最も現実的な落としどころになることが多くあります。

部分刷新とは、システム全体を一度に置き換えるのではなく、リスクや負担が大きい部分から段階的に見直していくアプローチです。たとえば次のような進め方が考えられます。

• 最もリスクの高い単一障害点(SPOF)になっているサーバーだけを、先にクラウド環境や新しいハードウェアへ移行する
• データの入出力部分だけをノーコード・ローコードツールに置き換え、中核ロジックは既存のまま延命させる
• Access（データベースソフト）など特定のソフトウェアに依存している部分だけを、他のデータベースへ段階的に移行する

部分刷新の利点は、初期投資と作業負担を分散できることに加え、一度にすべてを変えないことで業務への影響を最小限に抑えられる点にあります。一方で、新旧のシステムが混在する期間が生じるため、連携部分の設計を誤ると、かえって管理が複雑になるという弱点もあります。部分刷新を選ぶ場合は、「最終的にどこを目指すのか」という全体のゴールを最初に描いたうえで、優先順位をつけて段階的に進めることが重要です。

経営層に説明する際の伝え方

結論から言うと、経営層への説明では、この記事で整理した3つの評価軸(TCO・技術的負債・機会損失)をそのまま資料の骨格として使うと伝わりやすくなります。

情シスの専門教育を受けていない経営層にとって、「技術的負債」や「レガシーシステム」といった言葉自体が理解の壁になることがあります。説明の際は、次のような工夫を心がけてください。

• 専門用語を避け、身近な例に置き換える: 「技術的負債」ではなく「先延ばしにしている問題が、今後もっと高くつく状態」のように言い換える
• 金額と期限をセットで示す: 「あと◯年でサポートが切れます」「今の対応にかかっている人件費は年間概算で◯万円です」というように、時間軸と金額を明確にする
• 複数の選択肢と、それぞれのメリット・デメリットを並べて示す: 「延命」「作り直し」「部分刷新」の3択を提示し、経営判断としての意思決定を促す
• 今日決めなくてよいことと、今日決めるべきことを分ける: すべてを一度に決めようとせず、「まずは現状把握のための予算だけ承認してほしい」など、小さな最初の一歩を提案する

特に最後の点は重要です。「延命か作り直しか」という大きな決断を、いきなり経営会議で迫るのは現実的ではありません。まずはIT資産管理としての現状把握や、専門家による無償・低額診断を受けるところから始め、段階的に合意形成を進めるほうが、結果的にスムーズに進むケースが多く見られます。

実務上のコツ: 経営層への説明資料は、結論を最初のスライドに置き、根拠となる数字やチェックリストはあとに続ける構成にしてください。忙しい経営層は最初の1枚しか見ないことも多いため、「延命の場合、年間◯◯円のコストと◯◯のリスクがある。作り直しの場合、初期費用は◯◯円だが、◯年後には逆転する見込み」という要約を冒頭に置くだけで、伝わり方が大きく変わります。

自社だけで判断がつかないときの相談先

結論から言うと、TCO・技術的負債・機会損失を自力で整理してみても、最終的な判断が難しいと感じる場合は、無理に一人で抱え込まず、外部の視点を借りることをおすすめします。専門教育を受けていない担当者が、専門家の助けを一切借りずに最適解にたどり着くことを期待するのは、そもそも現実的ではありません。

相談先としては、次のような選択肢があります。

• 現在の保守委託先(開発会社): システムの内部事情を最もよく知っている相手ですが、前述のとおり刷新提案が自社寄りになる可能性がある点は差し引いて聞く必要があります
• セカンドオピニオンとしての別の開発会社: 現行システムの構造や技術的負債を、利害関係のない第三者の目で評価してもらう方法です。無償診断や簡易調査を提供している会社もあります
• 商工会議所・中小企業支援機関: IT導入に関する相談窓口や専門家派遣制度を設けている自治体・商工会議所が多くあります。費用をかけずに一般的なアドバイスを受けられる入り口として有効です
• 同業種の経営者・情シス担当者のコミュニティ: 同じ業種・規模の会社が、老朽化システムにどう向き合ったかという実例は、最も説得力のある参考情報になります

相談する際は、この記事で整理したTCO・技術的負債・機会損失の3つの資料を持参すると、話がスムーズに進みます。「なんとなく古くて不安です」と伝えるよりも、「このシステムに年間これだけのコストがかかっていて、こういうリスクを抱えています」と具体的に示せたほうが、相手からも精度の高いアドバイスを引き出しやすくなります。

なお、相談先を選ぶ際は、1社だけの意見を鵜呑みにせず、複数の視点を集めたうえで自社として最終判断を下すという姿勢を忘れないようにしてください。外部の専門家はあくまで判断材料を提供してくれる存在であり、最終的な意思決定の責任は自社にあります。

よくある判断ミスとその回避策

結論から言うと、老朽化システムの判断でよくある失敗は、「情報が足りないまま感覚で決める」か「情報を集めすぎて決められなくなる」かのどちらかに偏ってしまうことです。

失敗パターン1: 障害が起きてから慌てて決める

平常時には検討が進まず、実際にシステムが停止してから初めて本格的な議論が始まる、というケースは非常によくあります。しかしこの状態では、冷静な比較検討をする時間的余裕がなく、割高な緊急対応や、十分な検証をしないままの拙速な刷新につながりがちです。この記事で紹介した評価軸は、平常時にこそ実施しておくべきものです。

失敗パターン2: 「なんとなく古いから」で作り直しを決めてしまう

逆に、明確な根拠がないまま「もう古いから」という感覚だけで作り直しを決めてしまうと、実際には延命でも十分対応できたはずのコストを、不必要に前倒しで支払うことになります。特に、まだ十分な耐用年数が残っており、業務にも支障が出ていないシステムを焦って作り直す必要はありません。

失敗パターン3: 1社の意見だけを鵜呑みにする

保守を委託している開発会社に「そろそろ作り直したほうがいい」と言われ、そのまま鵜呑みにしてしまうケースにも注意が必要です。委託先にとって刷新は新たな受注機会でもあるため、悪意がなくとも、提案が刷新寄りに傾く可能性はあります。可能であれば複数の専門家や開発会社から意見を聞き、この記事で紹介したような客観的な評価軸と照らし合わせて判断することをおすすめします。

失敗パターン4: 評価だけして、意思決定に進まない

TCOや技術的負債を丁寧に洗い出したものの、資料作りに満足してしまい、実際の意思決定や予算化に進まないケースもあります。評価はあくまで意思決定のための手段です。評価が終わったら、必ず「次に誰が、いつまでに、何を決めるか」を明確にしてから会議を終えるようにしてください。

まとめ:今日からできる最初の一歩

老朽化した社内システムの「延命か、作り直しか」は、一度の判断で正解が出るものではなく、継続的に見直していくべきテーマです。しかし、判断の材料を揃えることは、今日からでも始められます。

• まず、今のシステムにかかっているTCO(直接費用+見えない人件費)を大まかにでも書き出してみる
• 技術的負債のチェックリストで、自社がどの程度リスクを抱えているかを確認する
• 「今のシステムのせいで実現できていないこと」を、具体的な事例として2〜3個挙げてみる
• 延命・作り直し・部分刷新のどれが現実的か、仮の方向性を持ってみる

完璧な結論をいきなり出す必要はありません。重要なのは、「動いているから大丈夫」という感覚的な先送りから、「これだけの根拠があって、この方向を選んでいる」という意思決定に切り替えることです。この記事の評価軸が、その第一歩の助けになれば幸いです。

次に読むべき記事

システムの中身がまだ十分に把握できていない、そもそも何が動いているか分からないという段階の方は、先に『前任者が突然辞めた。社内システムを引き継ぐ最初の1週間でやること』を読み、システムの棚卸しから始めることをおすすめします。

また、老朽化の中でも特にサーバーOSのEOL(サポート終了)対応を急ぐ必要がある方は、『Windows Server のサポート終了（EOL）対応の進め方』で、延命・移行・廃止の具体的な進め方を解説しています。この記事で扱った判断フレームワークと合わせて読むことで、より実践的な対応計画が立てられます。

保守契約が切れたまま、あるいは切れかけたまま老朽化システムを使い続けている場合は、『保守契約が切れたまま動いているシステムのリスクと再契約の判断』で、再契約すべきか延命か作り直しかを判断する軸をあわせて確認しておくと、この記事の評価軸をより早く自社に当てはめられます。