古いシステムは直すか、作り直すか：判断の基準と、決める前に調べること

10年以上使ってきた業務システムがある。少し直すだけでも時間と費用がかかるようになってきた。動かしているサーバーや部品のサポートの期限も近づいている。そんなとき、社内で必ず出てくるのが「このまま直して使い続けるか、思い切って作り直すか」という話です。

どちらを選んでも、小さな決断ではありません。直し続けると決めれば、毎年の改修と保守の費用を払い続けることになります。作り直すと決めれば、何年もかかる計画になり、その間も今のシステムを動かし続ける必要があります。判断を先送りにしているうちに、障害やサポートの終了に追われて、選べる手が少なくなることもあります。

この記事は、今動いている業務システムの更新を考えている情報システムの担当者や、事業の責任者に向けて書いています。次のことを順にまとめます。

• 「古いシステム」と「直しにくいシステム」の違い
• 選べる手は6つある（直す、機械だけ替える、基盤を移す、言語を変える、作り直す、パッケージに置き換える）
• 直すか作り直すかを決める6つの基準
• 作り直しでつまずきやすい所
• 少しずつ置き換えるという選び方
• 決める前に調べることのチェックリスト

改修の見積もりの内訳（なぜ小さな改修でも費用がかかるのか）は、前の記事「業務システムの改修の費用は何で決まるか」で詳しく書きました。この記事では、その先の「直し続けるか、別の道を選ぶか」の判断に絞ります。

結論：古さではなく「直し続けられるか」と「業務を変えたいか」で決める

先に結論を書きます。直すか作り直すかは、次の2つの問いで大きく分かれます。

1. これからも、安全に直し続けられるか：直せる人がいて、仕様が分かっていて、動かしている基盤や部品にサポートがあるか。
2. 業務の進め方を変えたいか：今のシステムの動きをそのまま残したいのか、業務のやり方から見直したいのか。

1が「はい」なら、作り直す理由は弱くなります。古い技術で作られていても、直し続けられるなら、直して使うのが合理的なことは多いです。1が「いいえ」でも、2が「いいえ」（業務は変えない）なら、全部を作り直さずに、基盤だけを移す、言語だけを変える、といった手があります。業務のやり方から変えたいときに、初めて作り直しやパッケージへの置き換えが有力になります。

そして、どの道を選ぶにしても、決める前に今のシステムを調べることが欠かせません。調べないまま作り直しを決めると、あとで「今のシステムが何をしていたか分からない」という問題にぶつかりやすいからです。

「古いシステム」と「直しにくいシステム」は違う

まず言葉を整理します。経済産業省が2025年5月にまとめた「レガシーシステムモダン化委員会 総括レポート」では、レガシーシステムを次のように定義しています。

レガシーシステムとは、以下の要因により、運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステムを指す

（経済産業省「DXの現在地とレガシーシステム脱却に向けて」より）

要因としては、技術の老朽化、肥大化・複雑化、ブラックボックス化といった技術の面と、IT への投資がされていない、古い制度やしがらみが残っている、といった経営の面が挙げられています。

大事なのは、同じレポートが、古い技術で作られていることそのものを問題にしていない点です。メインフレームのような古い仕組みでも、運用や保守の体制が整っていて、仕様が明らかで、機能を改良できるなら、レガシーシステムではないと言える、と書かれています。反対に、新しい仕組みに移したあとでも、運用や保守に問題があれば、再びレガシーになるおそれがあるとしています。

つまり、問うべきなのは「何年前に作ったか」ではなく、「今、直したいときに直せるか」です。この見方は、判断を誤らないための出発点になります。古いからという理由だけで作り直すと、新しいシステムも数年後に同じ状態になりかねません。

どのくらいの会社が、この判断に向き合っているか

この悩みは、一部の会社だけのものではありません。先ほどの総括レポートの調査（799社が回答）では、ユーザー企業の61%がレガシーシステムを持っていると答えています。中小企業よりも、大企業のほうが保有している割合が高い、とされています。

JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書2026」でも、IT 予算が増える理由の1位は「既存システム・基盤の刷新・更新・増強」でした（25年度計画で66.3%、26年度予測で60.3%）。今あるシステムをどうするかは、多くの会社で予算の大きな使い道になっています。

一方、総括レポートは、会社がシステムの刷新を決めるきっかけについて、大規模なシステム障害や、運用・保守の担当者が抜けることなど、「受動的な意思決定の要因が上位を占める」と書いています。困ったことが起きてから動き出す会社が多い、ということです。障害が起きてからでは、調べる時間も、選べる手も限られます。余裕のあるうちに判断の材料を集めておくことが、この記事でいちばん伝えたいことです。

選べる手は「直す」か「作り直す」かの2つではない

「直すか、作り直すか」と言うと、二択に聞こえます。実際には、その間にいくつもの手があります。IPA の「システム再構築を成功に導くユーザガイド 第2版」は、今のシステムを踏襲して作り直す手法を、今のシステムのどの層の設計を残すかで4つに分けています。これに「直して使い続ける」と「パッケージに置き換える」を加えると、選べる手は次のようになります。

IPA のガイドでは、「業務の仕様を変えるか」「基盤を変えるか」「開発言語を変えるか」の3つの組み合わせから、手法の候補を選ぶ表を示しています。

（IPA「システム再構築を成功に導くユーザガイド 第2版」の再構築手法選択基本パターンより）

同じガイドの使用例では、一つのシステムの中でも、業務ごとに手法を分ける例が出てきます。新しいサービスに対応したいオンラインの業務はリビルド、業務の仕様を変えない基幹のバッチ処理はリライトかリホスト、という具合です。「システム全体をどうするか」を一度に決めなくてよい、というのは覚えておきたい点です。

なお、使っていない機能は、移す前に止めるという手もあります。クラウドへの移行の手法を整理した AWS の「7 Rs」では、廃止（Retire）と、まだ移さずに残す（Retain）も、正式な選択肢として並んでいます。長く使ったシステムには、誰も使わなくなった画面や帳票が残っていることがよくあります。それを移す費用は、そのまま無駄になります。

直すか作り直すかを決める6つの基準

ここからは、判断の基準を6つに分けて書きます。一つひとつに「はい」「いいえ」で答えていくと、どの手法が候補になるかが見えてきます。

1. 動かしている基盤や部品に、サポートの期限があるか

まず確かめたいのが、システムを動かしている OS、言語、フレームワークなどのサポートの期限です。期限が過ぎると、脆弱性が見つかっても修正が出なくなります。

たとえば、2026年10月時点で、次のような期限があります。

期限が近い場合でも、それだけで作り直す理由にはなりません。言語やフレームワークの版を上げる、基盤を移す（リホスト）といった方法で対応できることも多いからです。ただ、版を上げようとしたら、古い書き方が多くて大きな改修になる、使っている部品の後継がない、といったことが分かる場合があります。そうなると、リライトやリビルドを考える理由になります。

サポートが切れた版を使い続けることの危うさは、PHPの重大な脆弱性で何が起きたかでも取り上げました。

2. 直せる人と、仕様の分かる資料があるか

次に、直せる人がいるかです。作った会社に今も保守を頼めるか。社内に仕組みを知っている人がいるか。設計書は、実際の動きと合っているか。

ここが「いいえ」になると、改修のたびに調べる時間が増え、費用も上がっていきます。ただし、この状態で作り直しを選ぶときは注意が必要です。仕様が分からないシステムは、作り直すときにも、何を作ればよいかが分からないからです。この点は、あとの「作り直しでつまずきやすい所」で詳しく書きます。

保守の会社を変えることで、直せる人の問題が解決する場合もあります。その手順は、開発会社を途中で変えるときにまとめています。

3. 改修の費用と時間が、年々増えていないか

改修の見積もりが、同じような中身なのに年々大きくなっていないか。小さな変更を頼んでも、何か月も待つようになっていないか。過去数年の改修の記録を並べてみると、傾向が見えます。

改修の費用が増える理由の多くは、直す作業そのものではなく、影響を調べる作業と、直したあとに確かめる作業です（改修の費用の記事を参照）。資料を整える、自動テストを足すといった手当てで、費用が下がることもあります。費用が増えているなら、まずその理由を開発会社に聞き、直し方を変えれば下がるのか、それとも作りそのものに限界があるのかを見極めてください。

4. 業務の進め方を変えたいか

先ほどの IPA の表のとおり、業務の仕様を変えるかどうかは、手法を分ける大きな軸です。

業務のやり方は今のままでよく、困っているのは基盤や言語だけ、という場合は、リホストやリライトで済むことがあります。業務の仕様を設計し直さないぶん、作り直しより範囲は小さくなります。

反対に、新しいサービスを始めたい、取引先とのやり取りの形を変えたい、紙や手作業を減らしたい、といった理由で、業務の進め方から見直したいなら、リビルドやパッケージへの置き換えが候補になります。この場合、作り直しは「システムの更新」ではなく「業務の見直し」の一部になります。何を作るかを決める前に、業務の流れを整理する必要があります。その進め方は、要件定義とはで書きました。

5. 標準に合わせる業務と、作り込む業務を分けられるか

経済産業省の総括レポートは、作り直すときの大原則として、今のシステムの機能をそのまま残すことへのこだわりを捨て、あるべき業務の姿から考えることを挙げています。そのうえで、標準的な仕様に寄せる部分と、付加価値を作り込む部分とを、はっきり分けることが重要だ、と書いています。

会計や勤怠のように、どの会社でもやり方がほぼ同じ業務は、パッケージや SaaS に合わせるほうが、費用も手間も抑えられます。反対に、自社の強みになっている業務や、取引先との独自のやり取りまで製品の型に合わせると、他社と同じやり方になり、強みが薄れてしまいます。製品に合わない部分を追加の作り込みで埋め続けると、製品が更新されるたびに手直しが必要になり、作り直したシステムがまた直しにくくなる原因にもなります。

業務ごとに「標準に合わせられるか」を分けて考えると、システム全体をパッケージにするか作るかの二択ではなく、組み合わせの答えが出てきます。標準の業務は製品に任せ、自社の強みになる業務と、製品どうしや今のデータをつなぐ部分を作る、という形です。どこまでを標準に寄せ、どこを作るかの線引きは、製品の機能と自社の業務の両方を見ないと決められません。作る部分を担う開発会社と一緒に、業務の棚卸しの段階から決めておくと、あとで「製品に合わなかった」という手戻りを減らせます。

6. 止まったときの影響と、移行にかけられる期間

最後に、そのシステムが止まったときに何が起きるかと、移行にかけられる期間です。

止まると売上や取引先に直接響くシステムほど、移行は慎重に、段階を分けて進める必要があります。総括レポートでも、大規模なシステムの刷新は数年がかりの計画になり、途中で計画を見直すと、さらに長い期間がかかる、と書かれています。サポートの期限や、制度の変更の施行日など、動かせない日があるなら、そこから逆算して、全部を作り直す時間があるかを考えてください。時間が足りないなら、まず基盤だけを移して期限に間に合わせ、そのあとで中身を作り直す、という順番も取れます。

作り直しでつまずきやすい所

作り直しが正しい答えになる場面は、確かにあります。業務を大きく変えたい、今の作りではどうしても新しい要望に応えられない、といった場合です。ただ、作り直しには、始める前に知っておきたい難しさがあります。

規模が大きいほど、予定どおりに進みにくい

JUAS の「企業IT動向調査報告書2026」は、システム開発のプロジェクトの規模ごとに、品質・予算・工期が予定どおりだったかを調べています。工期が予定より遅れた割合は、10人月未満のプロジェクトでは10%を下回っていましたが、500人月以上では47.8%でした。予算が予定を超えた割合も、500人月以上では42.2%です。

予定どおりに進まなかった理由として多く挙がったのは、「計画時の考慮不足」と「想定以上の現行業務・システムの複雑さ」でした。作り直しは、今のシステムが複雑であるほど、計画の段階でその複雑さを見積もりきれない、ということです。

公的な事例もあります。特許庁は、2004年（平成16年）に策定した計画のもとで2006年からシステムの設計・開発を始めましたが、開発の遅延などにより、2012年1月に開発を中断しました（特許庁「特許庁業務・システム最適化計画」の改定について）。改定した計画では、今のシステムを動かしたまま、段階的に刷新する方法に切り替えています。

今の機能を「全部そのまま」にすると難しくなる

作り直しのときによく出てくる要望が、「今のシステムでできていたことは、全部できるようにしてほしい」というものです。IPA の「レガシーシステム刷新ハンドブック」は、この「現行機能保証」を求められると、プロジェクトの難易度が高くなる、と書いています。

理由の一つは、今のシステムが何をしているかを、正確に知るのが難しいことです。同じハンドブックは、プログラムを解析すれば「処理」の仕様は取り出せるが、なぜその処理が必要なのかという「業務」の仕様を取り出すことはできない、と書いています。プログラムの中にある処理が、今も必要なのか、昔の取引先のための例外で今は要らないのか。それは、業務を知っている人に聞かなければ分かりません。

総括レポートの調査でも、刷新を阻む理由として、「既存システムが複雑でモダン化が技術的に困難（データ移行やシステムの相互依存性の課題など）」が31%、「現行機能保証や、機能踏襲の制約が大きい」が24%でした（59社の回答）。

データの移行は、終盤で問題になりやすい

もう一つの難しさが、データの移行です。総括レポートは、一般に問題が起きやすいのはデータの移行で、データの質と量、管理の精度で難しさが大きく変わる、と書いています。

IPA の再構築ガイドは、データの移行で起きる問題は開発の終盤に表に出るので、それを解消する期間も計画に入れておくべきだ、としています。そのうえで、早いうちに確かめる観点として次の6つを挙げています。

（IPA「システム再構築を成功に導くユーザガイド 第2版」表3.11「代表的な確認すべき観点」より、要約）

データの手入れや文字の対応は、発注する側にしか判断できないことが多い作業です。作り直しを決めたら、早いうちに社内で担当者を決めておくと、終盤で慌てずに済みます。

全面的な作り直しは、昔から危ういと言われてきた

ソフトウェアの世界では、全面的な作り直しの危うさが、昔から語られてきました。よく引かれるのが、ソフトウェア開発者の Joel Spolsky が2000年に書いた「Things You Should Never Do, Part I」です。当時の Netscape がブラウザを一から書き直し、次の版を出すまでに約3年かかった例を挙げ、古いコードには、使われ、試されてきた中で直された知恵が詰まっている、と書いています。

この意見は、作り直しを一切するなという話ではありません。今動いているものを捨てて一から作るときには、今のシステムが長い年月で身につけたことを、もう一度作り直す覚悟がいる、ということです。そのうえで作り直す価値があるかを、冷静に比べる必要があります。

少しずつ置き換えるという選び方

全部を一度に作り直すのでも、古いまま使い続けるのでもない、三つ目の道があります。少しずつ置き換える方法です。

ソフトウェア設計の著述で知られる Martin Fowler は、これを「Strangler Fig（絞め殺しのイチジク）」と呼んでいます。木に巻きついて育ち、やがて元の木に置き換わるイチジクになぞらえた名前です。新しい機能を今のシステムの横に作り、今のシステムの機能を少しずつ新しい側に移していきます。Fowler は、全面的な置き換えという一見簡単な計画が、多くの場合うまくいかないのを見てきた、と書き、段階的に置き換えることを勧めています。

先ほどの特許庁の改定計画が採ったのも、今のシステムを動かしたまま、段階的に刷新する方法でした。

少しずつ置き換える方法には、次のような良さがあります。

• 置き換えた部分から、新しいシステムの効果を早く得られる
• 問題が起きても、影響が置き換えた部分だけで済む
• 途中で業務の優先順位が変わっても、計画を組み替えやすい
• 今のシステムの仕様を、置き換える部分ごとに確かめていける

一方で、新旧のシステムが並んで動く期間ができるので、両方をつなぐ仕組みや、データを両方で合わせる手間がかかります。Fowler も、移行の途中だけ使う仕組みにはコストがかかるが、危険を減らす効果に見合う、と書いています。この費用は、計画の段階で見込んでおいてください。

どこから置き換えるかは、6つの基準を業務ごとに当てはめると決めやすくなります。業務を変えたい所、改修の要望が多い所、止まったときの影響が小さい所から始めるのが一般的です。

決める前に調べることのチェックリスト

直すか作り直すかを決める前に、次の項目を調べてください。社内で分かることと、開発会社や保守の会社に聞くことに分けています。

システムの今の状態

• OS、言語、フレームワーク、主な部品の版と、それぞれのサポートの期限
• 設計書や操作説明書があるか。最後に更新されたのはいつか
• ソースコードがどこにあり、誰が管理しているか
• 他のシステムや取引先とのつながり（連携先の一覧）
• データの量（何年分、何件）と、保存しておく必要のある期間

直し続ける場合の見通し

• 過去3〜5年の改修の件数と費用、1件にかかった期間
• 作った会社や保守の会社に、これからも頼めるか
• 社内に仕組みを知っている人がいるか。その人が抜けたらどうなるか
• 版を上げる場合、どのくらいの作業になるか（開発会社に見立てを聞く）

業務の側

• 使われていない画面、帳票、機能はどれか
• 業務のやり方を変えたい所と、今のままでよい所
• 標準的なやり方（パッケージ）に合わせられる業務と、自社独自の業務
• 業務の仕様（なぜその処理が必要か）を説明できる人は誰か

期限と体制

• 動かせない期限（サポートの終了、制度の施行日、契約の更新日）
• システムを止められる時間と、止まったときの影響
• 作り直す場合に、社内で業務の仕様やデータの手入れを担当する人

この一覧を埋めると、6つの基準のほとんどに答えられるようになります。全部が分からなくてもかまいません。分からない項目が多いこと自体が、「まず調べることから始める」べきだという判断の材料になります。

調べるところから、開発会社に頼んでもよい

社内だけで今のシステムを調べるのが難しい場合は、作り直しや改修を頼む前に、調査だけを開発会社に頼む方法があります。ソースコードと動いているシステムを見てもらい、版を上げる場合の作業の大きさ、仕様が分からない所、移行の難しさを報告してもらいます。

調査には費用がかかりますが、その結果があれば、直すか作り直すかを根拠をもって比べられます。作り直すことになっても、調査の結果はそのまま要件をまとめる材料になります。

調査を頼むときは、次のことを伝えると話が早く進みます。

相談の前に用意しておく資料は、開発会社に初めて相談する前にでもまとめています。

作り直したあとも、また古くなる

最後に、作り直しを選んだ場合に忘れられがちなことを書いておきます。新しいシステムも、時間がたてば、また古くなります。

総括レポートは、レガシーシステムからの脱却は一過性の取り組みではなく、時間がたてば再び必要になるものだ、と書いています。IPA の再構築ガイドも、新しいシステムが動き始めたあとに、再びレガシーになるのを防ぐ取り組みを考えることが重要だ、としています。

作り直すときには、次のことも合わせて決めておくと、10年後に同じ悩みを繰り返さずに済みます。

• 設計書を、改修のたびに直す決まりを作る
• 自動テストを用意し、改修のたびに足していく
• 言語や部品の版を、定期的に上げる予算を毎年取っておく
• 仕様を知る人が一人にならないよう、複数の人で保守する

国税庁の決まりでは、自社で使うソフトウェアの耐用年数は5年です（国税庁 No.5461）。会計の上の年数と、実際に使い続ける年数は別のものですが、5年ごとに、このまま使い続けるかを見直す区切りにするのもよいと思います。

クリーヴァに相談するとき

クリーヴァでは、今動いているシステムの改修や保守のご相談もお受けしています。クリーヴァが作ったシステムでなくてもかまいません。今のシステムの状態をうかがい、直し続けるか、どこから置き換えるかを一緒に整理します。

この記事のチェックリストと、伝えることの表は、クリーヴァに相談いただくときにもそのまま使えます。資料がそろっていなくても大丈夫です。手元にあるものから、一緒に確かめていきます。

おわりに

古いシステムを直すか作り直すかは、システムの古さだけでは決まりません。これからも安全に直し続けられるか、業務の進め方を変えたいか。この2つの問いに答えると、直す、機械だけ替える、基盤を移す、言語を変える、作り直す、パッケージに置き換える、という6つの手の中から、候補が絞られていきます。

作り直しを選ぶ場合も、全部を一度にではなく、業務ごとに分けて、少しずつ置き換える道があります。どの道を選ぶにしても、出発点は今のシステムを調べることです。

この記事のチェックリストを、まず社内で埋めてみてください。分かる所と分からない所が見えるだけでも、次に誰と何を話せばよいかが、はっきりするはずです。