「うちのシステムはもうレガシーだから、そろそろ何とかしないと」。経営会議でそう言われて調べ始めた方が多いのではないかと思います。ただ、レガシーシステムという言葉は、使う人によって指しているものがまるで違います。20年前に入れた販売管理システムのことなのか、COBOLで書かれた一部の処理のことなのか、それとも「使いにくい」という現場の不満の言い換えなのか。ここが曖昧なまま開発会社に相談すると、話がかみ合わないまま提案書だけが増えていきます。
レガシーシステムとは、単に古いシステムのことではありません。経済産業省の定義では、老朽化や複雑化、ブラックボックス化といった問題があり、その結果として経営や事業の足かせになっているシステムを指します。つまり、20年動いていても事業の邪魔になっていなければレガシーとは呼びませんし、5年前に作ったシステムでも誰も中身が分からず直せないなら、それはレガシーです。この記事では、基幹システムとの違いや年数の考え方を押さえたうえで、自社が当てはまるかを見分けるところまでを扱います。刷新の進め方や費用は別の記事に譲り、ここではその手前の判断を固めます。
この記事のポイント
- レガシーシステムとは古いシステムのことではなく、経営や事業の足かせになっている状態を指す
- 基幹システムは業務上の役割を表す言葉、レガシーはその状態を表す言葉なので対立しない
- 何年使ったかでは決まらず、中身が分かるか・直したいときに直せるかで判断する
- 残存率は全産業で6割、大企業では7割を超えており、放置している会社のほうが多数派
目次
レガシーシステムとは何を指すのか
まずは言葉の輪郭をはっきりさせます。レガシーシステムは、売る側の説明では「メインフレーム」「オフコン」「COBOL」といった古い技術の名前で語られがちですが、技術名を覚えても自社の判断には使えません。ここでは定義の中身を分解したうえで、混同されやすい基幹システムとの関係、年数の扱い方、そして社内で説明するときの言い方までを整理します。
古いだけではレガシーシステムと呼ばない
レガシーシステムの定義として実務で使えるのは、経済産業省が示している次の3点セットです。技術面が老朽化していること、改修を重ねてシステムが肥大化・複雑化していること、そして設計書や仕様が残っておらずブラックボックス化していること。ここまでは多くの解説記事と同じですが、大事なのはこの先です。定義には「その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっている」という条件が付いています。
この条件があるおかげで、線引きがぐっと実務的になります。10年以上動いている受注管理システムでも、業務が変わっておらず、たまの改修も1週間で終わり、保守費用も上がっていないなら、それは足かせになっていません。無理に作り替える理由はないわけです。逆に、導入5年のパッケージでも、カスタマイズを重ねた結果バージョンアップができなくなり、法改正のたびに数百万円かかるなら、こちらのほうがレガシーの実態に近いと言えます。
私が発注側の相談を受けていて一番よく見るのは、「古い」と「困っている」が混ざったまま議論が始まってしまうケースです。古さは事実ですが、それ自体は投資の理由になりません。社内で話を進めるときは、古いかどうかではなく、事業のやりたいことに対してシステムがブレーキになっている箇所を具体的に挙げるところから始めると、話が空中戦になりにくくなります。
基幹システムとの違いは役割か状態か
レガシーシステムと基幹システムは、よく並べて語られるせいで対立する概念のように見えますが、そうではありません。基幹システムは「その会社の中でどんな役割を担っているか」を表す言葉で、レガシーシステムは「そのシステムが今どんな状態にあるか」を表す言葉です。軸が違うので、両方に当てはまるシステムもあれば、どちらか一方だけのシステムもあります。
| 観点 | 基幹システム | レガシーシステム |
|---|---|---|
| 言葉が表すもの | 業務上の役割 | システムが置かれた状態 |
| 判断のものさし | 止まったときに事業が続くか | 中身が分かり、直したいときに直せるか |
| あてはまる範囲 | 販売管理・生産管理・会計・人事給与など | 基幹の外にある周辺システムや部門ツールも含む |
| 時間が経つと | 役割は変わらない | 放置すると該当する範囲が広がる |
実務上よくあるのは、長年動いてきた基幹システムがレガシー化しているというパターンです。1980年代から1990年代にメインフレームやオフコンで作られた販売管理・生産管理がその代表で、独自のハードウェアや言語に縛られ、扱える技術者も減っている状態にあります。ただし、レガシー化するのは基幹システムだけではありません。10年前に一人の社員が作り込んだ表計算のマクロや、退職者が作った部門用のデータベースも、誰も直せないなら同じ問題を抱えています。どこまでを基幹システムと呼ぶかを先に整理したい場合は、基幹システムとは？種類とERPとの違い・発注前の判断軸のほうを先に読むと順序として分かりやすいと思います。
何年使ったら古いシステムなのか
「何年経ったらレガシーなのか」は本当によく聞かれる質問ですが、年数の公式な基準はありません。よく引き合いに出される「20年」という数字は、経済産業省の調査で基幹システムの多くが20年以上稼働していると指摘されたことから広まった目安で、20年を境に性質が変わるという意味ではないんですね。
年数の代わりに使えるものさしを挙げるなら、私は次の3つで見ています。ひとつ目は、そのシステムを作った人・仕様を説明できる人が社内か取引先に残っているか。ふたつ目は、小さな改修を頼んでから本番に反映されるまでにどれくらいかかるか。みっつ目は、動かしている土台のソフトウェアやハードウェアがメーカーのサポート期間内にあるかどうかです。
この3つで見ると、年数が同じでも会社によって答えが割れます。導入から15年経っていても、毎年きちんと改修して設計書を更新し続けてきた会社は、意外なほど健全です。一方で、導入から8年でも担当者が2回入れ替わり、そのたびに引き継ぎが口頭だけで終わっていれば、中身は誰にも分からなくなっています。年数は入口の目安として使い、判断は中身で下すのが実際的です。
社内で伝わる言い換えを用意する
意外と見落とされがちなのが、社内での言葉の使い方です。経営層や業務部門に「うちのシステムはレガシーです」と説明しても、多くの場合ピンときません。カタカナ語で意味が伝わらないという問題もありますが、それ以上に、長く使ってきた仕組みを否定されたように受け取られて、話が感情的になってしまうことがあります。
そこで、相手に合わせた言い換えを用意しておくと進めやすくなります。経営層に対しては「維持費が年々増え、新しいことをやろうとすると必ずここで止まる仕組み」。業務部門に対しては「今のやり方を変えたいと言っても、直すのに何か月もかかってしまう状態」。情報システム部門の中では「設計書がなく、触れる人が限られているシステム」。どれも指しているものは同じですが、受け取られ方はまったく違います。
言い換えを考える作業そのものにも意味があります。自社のシステムのどこが足かせになっているのかを自分の言葉で説明できないうちは、まだ問題が特定できていないということだからです。開発会社に相談するときも、「レガシーなので刷新したい」ではなく「この業務を変えたいのに、ここが理由で変えられない」と伝えられるかどうかで、返ってくる提案の質が変わります。
レガシーシステムが日本企業に残る理由
ここからは、なぜこれだけ問題が指摘されていながら日本企業にレガシーシステムが残り続けているのかを見ていきます。原因を知りたいだけなら読み物で終わりますが、原因は自社の状態を確かめるチェック項目としても使えます。最後は、自社が当てはまるかを確かめる質問に落とし込みます。
残っている割合は全産業で6割超
まず実態の数字から押さえます。経済産業省が2025年5月に公表した「レガシーシステムモダン化委員会 総括レポート」によると、レガシーシステムの残存率は全産業で61%、大企業に限ると74%にのぼります。自社だけが取り残されているのではないかと心配される方がいますが、数のうえでは抱えているほうが多数派です。
もうひとつ、同じレポートで印象的なのが、中期経営計画に大規模なシステム導入や刷新を記載している大手企業が12%にとどまるという数字です。問題があると分かっていても、経営計画のレベルでは扱われていない。つまり多くの会社で、レガシーシステムは「いつかやること」の棚に置かれたままになっているということです。詳しい調査内容はIPA レガシーシステムモダン化委員会の総括レポートで公開されています。
この数字は、社内で話を進めるときの材料としても使えます。「うちだけが遅れている」という話し方は反発を招きやすいのですが、「多数派だが、動いている12%との差が開き始めている」という伝え方なら、危機感を煽らずに議論の土台を作れます。
技術面で足かせになる3つの要因
レポートでは、技術面の要因として3つが挙げられています。ひとつ目は技術の老朽化で、対応できる技術者の高齢化と引退が背景にあります。ふたつ目は肥大化・複雑化で、目の前の要望に応えるかたちで改修を重ねた結果、全体像を誰も把握できなくなる状態です。みっつ目がブラックボックス化で、設計書や仕様の管理が追いついていないことが原因になります。
発注する側の実感に翻訳すると、この3つは順番に効いてきます。最初に来るのは肥大化・複雑化で、「簡単だと思った改修の見積もりがやけに高い」というかたちで現れます。次にブラックボックス化が来て、「調査に費用と時間がかかります」と言われるようになります。最後に技術の老朽化が来て、そもそも引き受けてくれる会社が見つからない、という段階に入ります。
ここで押さえておきたいのは、3つとも一気に悪くなるわけではないという点です。特にブラックボックス化は、改修のたびに設計書を更新してもらう取り決めを契約に入れておくだけで、進行をかなり遅らせられます。すでに設計書が失われている場合でも、現行システムを調査して仕様を書き起こす作業を単独で発注することはできます。実際にどう移すかまで具体的に検討したい方は、基幹システムの移行方式はどう選ぶ？3つの選択肢と費用の見方で選択肢ごとの違いを整理しています。
経営側の判断が先送りを生む
技術面と並んで挙げられているのが、経営面の2つの要因です。ひとつは古い企業文化や固定観念で、現行のやり方を変えないことが前提になっている状態を指します。もうひとつはIT投資不足で、システムを事業戦略と切り離した単なるコストとして扱ってしまうことです。
この2つは、発注の現場ではもっと具体的な症状として出てきます。たとえば、刷新の話が出るたびに「今のやり方は変えられない」という条件が付き、結局は現行のまま作り直すことになる。あるいは、システム関連の予算が前年比で決まっていて、通常の保守費用しか枠がなく、数千万円の投資判断をする場所がそもそも社内に存在しない。どちらも、技術の問題ではなく意思決定の設計の問題です。
背景として無視できないのが人材の偏りです。日本ではIT人材の約3割がユーザー企業側、約7割がベンダー側に所属していると言われ、発注する会社の中に判断できる人が育ちにくい構造になっています。加えて、2030年には最大79万人のIT人材が不足するという予測もあります。つまり、先送りすればするほど、頼める会社も社内で判断できる人も減っていくということです。ここが「まだ動いているから大丈夫」という判断のいちばん危ういところだと思います。
自社が当てはまるか確かめる質問
ここまでの内容を、自社に当てはめられる質問にまとめます。技術の名前や導入年ではなく、事業への影響と社内の状態を確かめる形にしてあります。手元のシステムを1つ思い浮かべながら答えてみてください。
レガシーかどうかを確かめる6つの質問
- このシステムの仕様を最後まで説明できる人が、社内か取引先に残っているか
- 設計書は残っていて、直近の改修内容まで反映されているか
- 小さな機能追加を頼んだとき、見積もりの前に「調査費用」を求められないか
- 土台になっているOS・データベース・ハードウェアがサポート期間内にあるか
- 事業側からの「こうしたい」に対して、システムを理由に断ったことが直近1年であったか
- 保守費用が、機能を増やしていないのに数年前より上がっていないか
答え方の目安をお伝えすると、上の2つで詰まる場合はブラックボックス化が、真ん中の2つで詰まる場合は技術の老朽化が、下の2つで詰まる場合は事業の足かせと高コスト構造が、すでに現実になっているサインです。3つ以上に引っかかるなら、定義上のレガシーシステムに当てはまると考えて差し支えありません。
ただし、当てはまったからといって、すぐ全面刷新に進む必要はありません。延命して様子を見る、一部だけ切り出して作り替える、段階的に移すなど、打ち手には幅があります。当てはまった後の判断軸は基幹システムのリプレイスとは？進め方と発注側の判断基準で詳しく整理していますので、続けて読んでいただくと流れがつながります。開発会社に状況を伝えて選択肢を出してもらう段階に進むなら、RFI（情報提供依頼書）テンプレートを使うと、各社に同じ前提で情報提供を求められます。
レガシーシステムについてよくある質問
- Q. レガシーシステムとは結局どういう意味ですか？
- A. 技術面の老朽化、改修の積み重ねによる肥大化・複雑化、設計書が残っていないことによるブラックボックス化といった問題があり、その結果として経営や事業の足かせ、あるいは高コストの原因になっているシステムのことです。単に導入から年数が経っているだけのシステムは含みません。事業のやりたいことを止めているかどうかが判断の分かれ目になります。
- Q. レガシーシステムと基幹システムは同じものですか？
- A. 別の軸の言葉です。基幹システムは販売管理や会計のように、止まると事業が続けられなくなる業務を支える役割を指します。レガシーシステムはそのシステムが今どんな状態にあるかを指します。古くなった基幹システムがレガシー化することは多いのですが、部門で使っている小さなツールがレガシー化することもあります。
- Q. 導入から何年経つとレガシーシステムになりますか？
- A. 年数の基準はありません。20年という数字がよく使われるのは、国の調査で基幹システムの多くが20年以上稼働していると示されたためで、区切りとして定められたものではないんですね。仕様を説明できる人が残っているか、改修にどれだけ時間がかかるか、土台のソフトウェアがサポート期間内かで判断するほうが実態に合います。
- Q. クラウドに載っていればレガシーシステムではないのですか？
- A. 動いている場所は判断基準になりません。クラウド上で動いていても、カスタマイズを重ねてバージョンアップできなくなっていたり、設定した担当者が退職して誰も触れなくなっていれば、抱えている問題は同じです。逆に、社内に置いたサーバーで動いていても、中身が分かっていて計画的に更新できていれば問題は起きにくくなります。
- Q. 当てはまった場合、必ず刷新しないといけませんか？
- A. その必要はありません。今後3年から5年の事業計画の中で、そのシステムが実際に足かせになる場面があるかどうかで判断します。業務が安定していて改修の予定もなく、サポートも続くなら、延命しながら情報を整理しておく選択も現実的です。逆に、新しい販路や制度対応の予定があるなら、そこから逆算して着手時期を決めることになります。
