レガシーシステムの問題点とは、技術が古いこと自体ではなく、「変更できない・中身が分からない・特定の人に依存する」という状態が引き起こす業務上・経営上の不都合を指します。経済産業省のレガシーシステムモダン化委員会も、レガシーシステムを「技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等により、経営・事業戦略上の足かせや高コスト構造の原因となっているシステム」と定義しており、判断基準を年数ではなく状態に置いています。
具体的な症状は、技術・構造／データと連携／コストと契約／組織と人という4つの領域にまたがって現れます。重要なのは、これらの問題の重みが同じではないという点です。まず自社で実際に起きている症状を切り分け、影響度と緊急度で優先順位をつける——この手順を飛ばした刷新プロジェクトは、予算審議や要件定義の段階で停滞しがちです。
本記事では、レガシーシステムに現れる問題点を14項目に整理し、それぞれが起きる仕組み、見分けるためのサイン、放置した場合の帰結、そして「どこから手を付けるべきか」までを解説します。
📌 この記事でわかること
- レガシーシステムの問題点を技術・データ・コスト・組織の4分類で整理して把握できる
- 14項目のセルフチェックリストで、自社のシステムがどの段階にあるか判定できる
- 影響度×緊急度マトリクスで、どの問題から着手すべきかを判断できる
- 経営層の合意を得るために準備すべき3つの数字と、稟議資料の構成がわかる
レガシーシステムの問題点とは？「古さ」ではなく「変えられなさ」
多くの解説記事は、レガシーシステムを「稼働年数が長いシステム」と定義します。しかし、現場で実際にコストを発生させているのは年数そのものではありません。問題の本質は、変更しようとしたときに、想定した時間と費用で変更できないことにあります。
この視点に切り替えると、問題の分解の仕方が変わります。「古いから替える」ではなく、「変える必要があるのに変えられない部分だけを特定して替える」という発想になり、投資の対象範囲が絞り込まれ、現実的な規模に収まります。
問題を3つの層に分けて捉える
レガシーシステムの議論が噛み合わないのは、症状・仕組み・構造要因が混ざったまま語られるためです。整理すると次の3層になります。
| 層 | 内容 | 例 |
|---|---|---|
| ① 症状（見えるもの） | 現場が日々体感している不便 | 改修に3か月かかる／障害の原因が特定できない |
| ② 仕組み（なぜ起きるか） | 症状を生んでいる技術的・構造的な仕組み | ドキュメント欠落、密結合、API不在 |
| ③ 構造要因（なぜ直らないか） | 直す判断が下りない組織側の事情 | 効果の数値化が困難、合意形成の負担、IT投資の不足 |
対策を誤る典型は、①の症状に対処しただけで②を解消したつもりになるケース、あるいは②を解消しても③が手つかずのまま新たなレガシーを生むケースです。経済産業省の委員会レポートも、レガシー化の要因を技術的観点（技術の老朽化／肥大化・複雑化／ブラックボックス化）と経営的観点（古い企業文化への固執／IT投資不足）の両面から整理しており、技術だけの問題として扱っていません。
「老朽化」と「レガシー化」は別の問題
実務で最も混同されやすいのがこの2つです。対策の内容も、見積もりの立て方もまったく異なります。
| 老朽化 | レガシー化 | |
|---|---|---|
| 何が古いか | ハードウェア・OS・ミドルウェアなど基盤 | 設計・ドキュメント・知識の所在 |
| 典型的な症状 | サポート終了、部品調達不可、性能不足 | 仕様が分からない、影響範囲が読めない |
| 主な対策 | 基盤更改・クラウド移行（リホスト等） | 現状可視化・リバースエンジニアリング・再設計 |
| 見積もりの性質 | 仕様が変わらないため積算できる | 調査しないと積算できない |
| 失敗パターン | 移行後に性能要件を満たさない | 基盤だけ新しくなり中身は不明のまま |
稼働20年でも、設計書が継続的に更新され、担当者が交代しても改修できるシステムは、レガシーシステムではありません。逆に、稼働5年でも仕様を説明できる人が1人しかいないシステムは、すでにレガシー化しています。
ここを取り違えたまま基盤更改だけを実施すると、「サーバーは最新になったが、中身は相変わらず誰も分からない」という、最も避けるべき結果を招きます。レガシーシステムの問題点を正しく診断することが、投資の無駄を防ぐ最初の一歩です。
問題点が表面化する3つのきっかけ
レガシーシステムは、平時は「動いている」ため問題として認識されにくいものです。顕在化するのは、多くの場合、次の3つのタイミングです。
- 障害・停止 — 原因調査に数日を要し、影響範囲が特定できない。復旧できても再発防止策が立てられない
- 法改正・制度変更 — インボイス制度や電子帳簿保存法のように、外部から期限を指定される改修が発生する
- 有識者の退職・ベンダーの体制変更 — 「聞ける人」がいなくなった瞬間に、改修そのものが止まる
3つのうち2つ以上に心当たりがあるなら、それは偶然の重なりではなく構造的な問題です。特に3つ目は予兆が見えにくく、起きてから対処するとリカバリーに年単位を要します。
背景：「2025年の崖」はどこまで現実になったか
経済産業省が2018年の「DXレポート」で提起した「2025年の崖」は、レガシーシステムの問題点を語るうえで避けて通れない前提です。同レポートは、システム刷新が進まない場合に2025年以降最大で年間12兆円規模の経済損失が生じうると指摘し、2025年時点で稼働21年以上の基幹システムを抱える企業が約6割に達すると試算しました。なお、レポートの位置づけと論点の整理はDXレポートの解説記事でも扱っています。
では、実際にどうなったのか。経済産業省が2025年に公表したレガシーシステムモダン化委員会の総括レポートでは、全産業でレガシーシステムが残存している企業が61%、大企業に限ると74%という調査結果が示されています。つまり、崖は「回避された」のではなく、期限だけが過ぎたというのが現状です。
さらに今後も、期限の決まった事象が控えています。
- SAP ERP 6.0のメインストリーム保守が2027年末に終了（追加料金による延長保守も2030年末まで）——いわゆる2027年問題。移行方式の選択肢は「マイグレーションの基本」で整理しています。
- IT人材の不足は2030年に最大約79万人と試算されており、レガシー技術に限れば需給はさらに逼迫すると考えられます
IPAの「DX動向2025」（2025年6月公開）も、日本・米国・ドイツの3か国比較のなかでレガシーシステム刷新を技術利活用の主要テーマの一つに位置づけています。レガシーシステムの問題点は、もはや個社の事情ではなく、産業全体の構造課題として扱われている——これが議論の出発点です。
参考・出典
・経済産業省「DXレポート（サマリー）」
・デジタル庁「レガシーシステムモダン化委員会 総括レポート」
・IPA「DX動向2025」
では、実際にどのような問題が起きるのか。ここからは、現場で観測できる症状ごとに4つのグループへ分けて見ていきます。
レガシーシステムの問題点①技術・構造の問題
最も多く語られる領域ですが、一覧を眺めるだけでは対策になりません。ここでは5つの症状を、現場で分かるサイン → なぜ起きるのか → 放置した場合の帰結という順で整理します。
ブラックボックス化：仕様が分かる資料も人もいない
改修を依頼するたびに「まず調査から」と言われ、調査だけで数週間かかる。設計書はあるが最終更新が数年前で、実装と一致しているか誰も保証できない——これがブラックボックス化の典型的なサインです。
仕組みは単純です。追加開発のたびにコードは変わる一方、ドキュメントの更新は契約にも工数にも含まれていないことが少なくありません。結果として、実装が正、ドキュメントは参考資料という状態になり、やがて誰も参照しなくなります。
放置した場合の帰結は、コストよりも交渉力の喪失として現れます。仕様が分からなければ他社に見積もりを依頼できず、提示された金額の妥当性を検証する手段もありません。ブラックボックス化そのものの構造と自己診断の方法は、関連記事「レガシーシステム刷新の判断時期と定量シグナル」で詳しく解説しています。
密結合・スパゲッティ化：1か所直すと別の場所が壊れる
小さな改修でも広範囲のテストを求められる。テスト工数が開発工数を上回る。こうした状態は、機能間の結合度が高く、変更の影響が局所にとどまらないことを示しています。
長年の改修で共通処理が増築され、1つのモジュールが複数業務から呼ばれるようになると、変更の影響範囲を事前に読むこと自体が調査タスクになります。しかも回帰テストを支えるテストデータやテスト仕様書が整備されていないケースが多く、「全部テストする」以外の選択肢がなくなります。
放置すると、改修のたびにコストが逓増し、最終的には「触らないこと」が唯一のリスク回避策になります。これに後述する属人化が重なると、システムは事実上凍結されます。
EOL（サポート終了）とハードウェア老朽化による障害リスク
OS、データベース、ミドルウェア、アプリケーションサーバー、あるいは物理サーバーの保守期限が切れている、もしくは1〜2年以内に切れる状態です。
EOLは交渉できない期限である点が他の問題と決定的に異なります。技術的負債は先送りできますが、ベンダーのサポート終了日は自社の都合で動きません。放置すれば、障害発生時に一次切り分けから自社で行うことになり、復旧時間が読めなくなります。老朽化した専用ハードウェアでは、部品の調達に数週間かかる例も珍しくありません。
セキュリティパッチが適用できない
「パッチを当てると業務アプリケーションが動かなくなる」ため、脆弱性を認識しながら適用を見送っている——これは多くの現場で起きているパターンです。原因は、アプリケーションが古いミドルウェアのバージョン固有の挙動に依存していることにあります。
リスクは時間の経過とともに増え続けます。公開された脆弱性情報は攻撃者も入手できるため、放置期間がそのまま攻撃の機会になります。近年は取引先経由で侵入されるサプライチェーン型の事案も増えており、自社のセキュリティ体制について取引先から説明を求められる場面も多くなっています。「動いているから触らない」という判断は、この領域では成立しません。
技術的負債の複利：改修するほど直しにくくなる
場当たり的な改修は、次の改修をさらに難しくします。負債は元本に加えて利息を生む、という比喩がそのまま当てはまります。
サインは単純です。「同じ規模の改修なのに、3年前より見積もりが高い」。物価や人件費の上昇を差し引いてもなお単価が上がっているなら、増えているのは作業量ではなく調査量です。これは負債の利息そのものです。
症状早見表
| 症状 | 現場で分かるサイン | 放置1年後に起きること |
|---|---|---|
| ブラックボックス化 | 改修前に必ず「調査費」が発生する | 相見積もりが取れず価格交渉力を失う |
| 密結合・スパゲッティ化 | 小改修でも全体テストが必要 | 改修そのものを断念するようになる |
| EOL・老朽化 | 保守期限切れ／1〜2年以内に到来 | 障害時に復旧時間が見通せない |
| パッチ未適用 | 既知の脆弱性を認識しつつ放置 | インシデント時に説明責任を果たせない |
| 技術的負債 | 同規模改修の単価が年々上昇 | 保守コストが膨らみIT予算が固定化される |
レガシーシステムの問題点②データと連携の問題
この領域は一般的な解説記事ではあまり触れられていませんが、DXやAI活用が実務レベルで止まる原因はここに集中しています。技術的には動いているのに成果が出ない、という状況の多くは、データ側に原因があります。
データがシステムの中に閉じ込められている（サイロ化）
売上、在庫、顧客情報がそれぞれ別のシステムに存在し、横断的に見るには誰かが手作業でExcelに集約している。この状態では、経営層が確認したい数字が出てくるまでに数日かかり、しかも集計した人以外は再現できません。
原因は、部門ごとの部分最適を繰り返した結果としてシステムが増築されたことにあります。個々のシステムは要件を満たしているため、担当部門から見れば問題は存在しません。サイロ化は、誰も困っていないのに全体としては機能していないという形で現れるため、発見が遅れます。
APIがなく、夜間バッチでしか連携できない
新しいSaaSやツールを導入しようとすると「連携できません」と言われる。連携できてもリアルタイムではなく翌日反映になる——外部接続用のインターフェース（API）が設計されていないことが原因です。
背景には、システムが構築された当時の前提があります。日次のバッチ処理で十分だった時代の設計では、外部公開インターフェースは想定されていませんでした。そこに個別の連携要件が発生するたび、専用のファイル受け渡し処理が1本ずつ増えていきます。
放置した場合の帰結はより深刻です。新しいツールを導入するたびに個別開発が発生し、その連携処理自体が誰も仕様を把握していない新たなレガシーになります。つまり、モダンなツールを増やすほどレガシー資産も増えるという構造です。
マスタ不整合・データ品質の劣化でBI・AIが使えない
同じ取引先が複数のコードで登録されている、退職者のデータが残っている、単位や桁が統一されていない、履歴が上書きされていて過去時点の状態を復元できない——こうした状態では、BIツールを導入しても部門ごとに数字が合わず、AIに学習させても十分な精度が得られません。
ここで起きているのは技術の問題ではなく、マスタの管理責任が定義されていないという運用設計の問題です。どの部門がどのマスタの正本を管理するかが決まっていなければ、データ品質は時間とともに必ず劣化します。
AI導入プロジェクトが期待どおりに進まない原因は、多くの場合モデルではなくデータと連携点にあります。レガシーシステムとData＆AI活用の関係、およびシステムが「AIレディ」と言えるための条件は、関連記事「レガシーシステム刷新の判断時期と定量シグナル」の該当セクションで詳しく解説しています。
🔘 自社のデータ連携がどこで詰まっているか分からない場合
HBLABの無償AIアセスメントでは、現行システムの構造とデータの流れを可視化し、24時間以内にレポートをお渡しします。
レガシーシステムの問題点③コストと契約の問題
技術の議論より経営層に届きやすいのがこの領域です。ただし、「高い」と訴えるだけでは経営層は動きません。何が、どういう仕組みで増えているのかを示す必要があります。
保守運用費がIT予算を食いつぶし、「攻めのIT」に回せない
保守コストの増大は、レガシーシステムの問題点のなかで最も経営に伝わりやすい症状です。IT予算の大半が現行維持（ラン・ザ・ビジネス）に消え、新規投資に回せる割合がわずかになっている状態を指します。
近年は、この構造がさらに悪化しやすい条件が重なっています。JUASの「企業IT動向調査2026」では、IT予算のDI値が2025年度計画で43.3ポイントと、2012年度以降の最高値を記録しました。一方で、増加要因としては既存システムの更新・円安・値上げといった不可避の項目が大きな割合を占めており、AI関連投資（2025年度計画36.3%→2026年度予測43.7%）と予算を奪い合う構図が示されています。
つまり、予算総額が増えても、新しい取り組みに使える分が増えるとは限りません。問題は金額そのものではなく、比率が年々悪化していることです。
ベンダーロックインと見積もりの不透明化
仕様を把握しているのが特定ベンダーだけになると、相見積もりが取れません。結果として、提示された見積もりの妥当性を検証する手段が失われます。
これは必ずしもベンダーの姿勢だけの問題ではなく、背景には構造的な要因があります。経済産業省の委員会レポートは、日本のITエンジニアの配置比率がユーザー企業:ベンダー企業＝3:7であるのに対し、米国では7:3と逆転している点を指摘しています。設計や運用の知識が発注側に蓄積されにくい構造が、そのままロックインの土壌になっているわけです。同レポートが対策として「ベンダーへの100%丸投げからの脱却」と「ユーザー企業の自律性確保」を挙げているのも、この認識に基づいています。
契約面で確認すべきポイントは3つです。
- 過去3年で、同規模改修の単価はどう変化したか（作業量ではなく単価を見る）
- 保守契約の範囲に「調査費」が都度見積もりとして切り出されていないか
- ソースコード・設計書・データの所有権と引き渡し条件が契約書に明記されているか
3つ目は、将来ベンダーを変更する可能性を残せるかどうかを決める、最も重要な条項です。
改修リードタイムの長期化が生む機会損失
「その改修は3か月かかります」と言われ、事業側が施策そのものを取り下げる。この損失は会計上どこにも計上されませんが、実質的には最も大きなコストになり得ます。
単位で累積すると市場対応力の差として表面化します。しかも、断られ続けた事業部門は次第にIT部門に相談しなくなり、シャドーITや部門独自のSaaS導入が始まります。これが新たなサイロ化を生む、という悪循環です。
見えているコストと見えていないコスト
| 見えているコスト | 見えていないコスト |
|---|---|
| 保守契約費・ライセンス費 | 障害対応に割かれる情報システム部門（情シス）の人件費 |
| サーバー・データセンター費用 | 意思決定が遅れることによる機会損失 |
| 改修の外注費 | 手作業のデータ集計にかかる現場の工数 |
| 移行・更改の一時費用 | 古い技術環境を理由とした採用の難航 |
| — | 断られ続けた結果生まれるシャドーIT |
稟議で効果を示す際は、「見えていないコスト」をいかに具体的な数字に落とし込めるかが鍵になります。
レガシーシステムの問題点④組織と人の問題
技術的にはまだ延命できても、人がいなくなればシステムは維持できません。この領域の問題は最も予兆が見えにくく、しかも回復に最も時間がかかります。
属人化：仕様を知っているのは数名だけ
「この処理はAさんに聞かないと分からない」という状態です。知識が文書ではなく個人の記憶に存在するため、退職・異動・長期休暇がそのまま事業リスクになります。
判定はシンプルです。その人が1か月不在でも改修を進められるか——答えが「いいえ」なら、属人化しています。なお、属人化は担当者個人の責任ではありません。ドキュメント整備が工数として認められない環境では、属人化は必然的な帰結です。
COBOL・メインフレーム人材の高齢化と採用難
基幹システムを支える技術者の年齢構成が高齢層に偏り、新規採用も難しい状態です。前述のとおり2030年には最大約79万人のIT人材不足が見込まれており、レガシー技術に限れば需給はさらに厳しくなると見込まれます。
この問題の性質は他と異なります。自社の努力では解決できない外部環境由来の制約であり、待っても状況は改善しません。放置すれば、保守を引き受けられる会社そのものが市場から減っていきます。対応の選択肢は実質的に、①保守可能な人材が市場に存在するうちに移行する、②知識を文書化・コード化して属人性を外す、の2つです。①を検討する場合の移行方式と体制についてはMigration Solutionをご覧ください。
情シスが「運用の番人」になり、企画に手が回らない
障害対応と問い合わせ対応で1日が終わり、中期的な構想を描く時間が確保できない。結果として現状維持が続き、負債がさらに積み上がるという悪循環です。
これは担当者の能力ではなく役割設計の問題として扱う必要があります。経済産業省のレポートが「情報システム部門と業務部門の融合体制」や「システムの可視化と内製化」を対策として挙げているのも、個人の努力では解決できない構造的な問題だからです。
レガシーシステムの問題点が分かっていても脱却が進まない4つの壁
ここまで挙げた問題点の多くは、すでに社内で認識されています。それでも刷新が進まないのは、問題の認識とは別に4つの壁が存在するためです。
コストの壁：投資対効果が示しにくい
刷新は多額の投資を要する一方、効果は「売上増」ではなく「損失回避」として現れます。売上のように「増える数字」ではなく、「回避できる損失」を根拠に投資を説明しなければならない難しさが最初の壁です。加えて、効果が出るのは移行完了後であり、投資と効果の間に数年のタイムラグが生じます。
リスクの壁：止められない・失敗できない
基幹システムは停止できません。移行に失敗したときの業務影響が大きすぎるため、意思決定は「今のままなら少なくとも動いている」という方向に傾きます。この判断にはむしろ合理性があり、正面から「安全だ」と説得しても意思決定者は動きません。有効なのは、移行範囲を小さく切り、失敗しても戻せる単位に分割することです。
現状不明の壁：何を作り替えるのかが分からない
ブラックボックス化していると、そもそも移行範囲を確定できません。範囲が決まらなければ見積もりも計画も作れない、いわば入口で詰まっている状態です。多くの企業が最初の一歩で止まるのはこの壁が理由であり、だからこそ「まず可視化」が定石になります。
合意形成の壁：稟議・根回しで止まる
日本企業に特有で、かつ最も語られることの少ない壁がこれです。経済産業省のレポートでは、中期経営計画にシステム導入・刷新を記載している大手企業は12%にとどまるという調査結果が示されています。経営のアジェンダに載っていないテーマを、現場発の稟議だけで通すのは構造的に困難です。
情報システム部門が必要性を理解していても、関係者それぞれの言語に翻訳しなければ合意は形成されません。
| 相手 | 響く論点 | 響かない論点 |
|---|---|---|
| 経営層 | やらなかった場合に増え続けるコスト | 技術的負債、アーキテクチャの説明 |
| 財務 | 単年度ではなく複数年のキャッシュフロー | 初年度投資額のみの提示 |
| 事業部門 | 移行期間中の業務影響と代替手段 | 完成後の理想像 |
| 監査・情報セキュリティ | EOLと法令対応の期限 | 全体最適の必要性 |
技術的に正しい資料が、社内で通る資料とは限りません。この翻訳作業こそが情シス担当者の実務の中核であり、具体的な型は後述のセクションで紹介します。社内共有用の資料が必要な場合は、資料請求ページから関連資料をお申し込みいただけます。
【自己診断】レガシーシステムの問題点チェックリスト14項目
自社の状況を客観視するために、以下の14項目のうち当てはまるものを数えてください。直感ではなく、直近1年間の事実に基づいて判定するのがポイントです。
技術・構造
- ☐ 改修の前に、毎回「現状調査」の工数が必要になる
- ☐ 小さな改修でも、広範囲のテストを求められる
- ☐ OS・DB・ミドルウェアのいずれかが保守期限切れ、または2年以内に到来する
- ☐ 既知の脆弱性に対してパッチを適用できていない
- ☐ 同規模の改修の見積単価が、3年前より明確に上がっている
データと連携
- ☐ 経営層が確認したい数字を出すのに、手作業のExcel集計が必要
- ☐ 外部サービスと連携する際、APIがなく個別開発になる
- ☐ 同一の取引先・商品が複数のコードで登録されている
コストと契約
- ☐ IT予算に占める保守運用費の比率が年々上がっている
- ☐ 現行システムについて相見積もりが取れない
- ☐ 事業側の要望に対し、リードタイムを理由に断ることがある
組織と人
- ☐ 仕様を説明できる担当者が2名以下である
- ☐ 主要技術（COBOL等）の担当者の後任が決まっていない
- ☐ 情報システム部門の業務が、運用・障害対応でほぼ埋まっている
点数の読み方
| 該当数 | 状態 | 推奨アクション |
|---|---|---|
| 0〜3項目 | 健全。個別課題として対応可能 | 該当項目のみ計画的に解消 |
| 4〜8項目 | レガシー化が進行中 | 現状可視化に着手し、3年計画を策定 |
| 9項目以上 | 事業リスクの段階 | 経営課題として位置づけ、外部の診断を推奨 |
チェックを「数字」で裏づける5つの指標
チェックリストは主観が入りやすいため、次の指標を年次で記録しておくと判断が安定し、稟議での説得力も上がります。
| 指標 | 測り方 | 危険な傾向 |
|---|---|---|
| 年間の重大障害件数 | 業務停止を伴った件数 | 2年連続で増加 |
| 標準的な改修のリードタイム | 要望受付から本番反映までの平均日数 | 前年比で長期化 |
| IT予算に占める保守運用費の比率 | 保守運用費÷IT予算総額 | 毎年上昇 |
| 仕様を説明できる人数 | 主要サブシステムごとの人数 | 減少、または1〜2名で横ばい |
| ベンダー見積もりの単価推移 | 同規模改修あたりの単価 | 物価上昇分を超えて上昇 |
これら5指標は、後述する経営層向けの説明資料でもそのまま使えます。
🔘 チェックが4項目以上だった方へ
次の一歩は「現状の可視化」です。AIを活用した現状把握・リスク分析・移行ロードマップ策定の進め方はMigration Assessment Serviceのご案内で解説しています。自社システムの診断結果がすぐに必要な場合は無償AIアセスメントをご利用ください。
レガシーシステムの問題点に優先順位をつける — 影響度×緊急度マトリクス
14項目すべてを同時に解決することはできませんし、その必要もありません。影響度（事業へのダメージの大きさ）と緊急度（期限の有無）の2軸で優先順位をつけます。
今すぐ手を打つべき問題（影響度：高／緊急度：高）
- EOL（サポート終了） — 期限が外部から与えられ、動かせない
- 未適用のセキュリティ脆弱性 — 事故発生後では対応の妥当性を説明できない
- 単一障害点 — 1か所の故障がシステム全体の停止につながる構成
この3つに共通するのは、全体刷新の計画とは独立して処理できるという性質です。範囲が明確で、効果も期限も説明しやすいため、大きな予算審議を待つ理由がありません。逆に、これらを刷新計画に含めてしまうと、計画の遅延がそのままリスクの延長になります。
計画的に解消する問題（影響度：高／緊急度：中）
- ブラックボックス化・ドキュメント不在
- データのサイロ化とAPI不在
- 属人化と後継者不在
これらは一度に解決できません。現状可視化 → 対象範囲の切り出し → 段階的な移行という順序で、複数年の計画に落とし込みます。全面刷新を一括で狙うと、前述の「リスクの壁」と「現状不明の壁」に同時にぶつかり、ほぼ確実に停滞します。
なお、どの移行手法（リホスト／リライト／リビルド等）を選ぶかは可視化の結果で決まります。手法の比較は「システムモダナイゼーションの手法」で扱っています。
今はあえて放置してよい問題（影響度：低）
すべてを直す必要はありません。むしろ、直さない判断を明文化することが計画の実行可能性を高めます。以下は優先度を下げてよい典型例です。
- 画面UIの古さ — 業務に支障がなく、利用者がすでに習熟している場合
- 利用頻度の低いサブシステム — 廃止や手運用への切り替えのほうが安価なことがある
- 技術的には古いが、変更予定のない機能 — 法改正の影響を受けず、外部接続も持たない領域
ただし「放置」は「無視」ではありません。受容したリスクとして一覧に残し、年次で再評価する——この手続きを踏むことで、監査にも対応できます。
判断基準はひとつに集約できます。「古いから直す」のではなく、「変更する必要があるのに変更できないから直す」。この基準を適用するだけで、刷新の対象範囲は現実的な規模に収まります。
レガシーシステムの問題点を「社内で通る言葉」に翻訳する
前述の「合意形成の壁」を越えるには、技術の言葉を経営の言葉に置き換える工程が必要です。この工程は多くの現場で属人的に行われていますが、一定の型があります。
経営層に響く3つの数字
稟議の前に、最低限この3つを用意してください。技術用語は一切不要です。
- 年間の維持コスト — 保守契約費＋障害対応に費やした社内工数（時間×人件費単価）。社内工数を金額に換算する点が重要です
- 停止コスト — システムが1日停止した場合の売上・業務影響額。過去の障害実績をもとにした概算で構いません
- 改修リードタイム — 事業側の要望から本番反映までの平均日数と、過去3年間の推移
この3つに共通するのは、何もしなければ増え続ける数字だという点です。投資額と並べて提示することで、議論の性質が「費用の是非」から「実施時期の選択」に変わります。これが最も重要な効果です。
稟議資料に使える1ページの構成
A4一枚に、次の5ブロックで収めます。分量を増やすほど通りにくくなります。
| ブロック | 書く内容 | 分量の目安 |
|---|---|---|
| ① 現状 | 対象システムと、チェックリストの該当項目数 | 3行 |
| ② リスク | 期限のある項目（EOL・法改正）と、その期日 | 表で3行 |
| ③ 選択肢 | 何もしない／部分対応／段階的刷新 の3案と概算 | 表で3行 |
| ④ やらない場合のコスト | 上記3つの数字の3年後の見込み | グラフ1つ |
| ⑤ 依頼事項 | 今回決めてほしいこと | 1行 |
最も重要なのは⑤です。初回の稟議で全額の承認を求める必要はありません。「現状調査の実施承認」という小さな意思決定に絞ったほうが、はるかに通りやすく、かつ調査結果が次の稟議の根拠になります。
③で「何もしない」案を必ず並べるのもポイントです。比較対象がなければ、投資額だけが議題になってしまいます。
🔘 社内説得用の現状レポートが必要な方へ
HBLABの無償AIアセスメントは、現行システムの構造・依存関係・リスク箇所を整理したレポートを24時間以内にご提供します。稟議資料の①〜④の材料としてそのままご利用いただけます。
レガシーシステムの問題点の洗い出しから対応へ — 最初の一歩は現状の可視化
優先順位が決まったら、次は対応です。ただし、手法を選ぶ前にやるべきことがあります。経済産業省のレポートが対策の筆頭に「全IT資産の棚卸し・可視化」と「ビジネス上の重要度に基づく優先順位付け」を挙げているとおり、可視化は刷新の前提条件です。
自社で洗い出すときの3ステップ
- 棚卸し — システム一覧、稼働年数、保守期限、連携関係、担当者、年間費用を1枚の表に集約する
- 定量化 — 前述の5指標（障害件数・リードタイム・保守費比率・説明できる人数・単価推移）を数字で埋める
- 範囲決め — マトリクスで「今すぐ」に分類された項目を切り出し、「計画的に解消」は複数年計画へ、「あえて放置」は年次再評価リストに回す
この3ステップは外部に依頼しなくても着手できます。まずは社内で1〜2週間かけて表を埋めてみてください。これがあるだけで、以後どのベンダーから提案を受けても評価軸を持って判断できるようになります。
HBLABのアプローチ：AIを活用した現状可視化
ドキュメントが失われている場合、棚卸しの段階で止まってしまうことがあります。「調べないと見積もれない、しかし調べる工数の見積もりも立たない」という、入口で詰まってしまう状態です。
HBLABでは、既存ソースコードの解析とリバースエンジニアリングにAIを組み合わせ、設計書が現存しない状態からでも仕様と依存関係を再構成する支援を行っています。ベトナムオフショアによる開発体制とAI支援を組み合わせることで、これまで費用対効果が合わないとされてきた調査フェーズにも着手しやすくなります。
移行そのものの進め方はMigration Solution、モダナイゼーション全体の考え方はモダナイゼーションサービスをご覧ください。
次に読むべき記事
- レガシーシステム刷新の判断時期と定量シグナル — 「いつ刷新すべきか」の判断基準
- システムモダナイゼーションの手法 — リホスト・リライト・リビルドの選び方
- モダナイゼーションとマイグレーションの違い — 用語の整理
- マイグレーションの基本 — 移行方式の全体像
- DXレポートの解説 — 2025年の崖の原典を読み解く
- レガシーシステムとは何か — 基礎から確認したい方へ
レガシーシステムの問題点に関するよくあるご質問
Q1. レガシーシステムの問題点は何ですか？
技術・構造（ブラックボックス化、密結合、EOL、脆弱性、技術的負債）、データと連携（サイロ化、API不在、データ品質の劣化）、コストと契約（保守費の膨張、ベンダーロックイン、リードタイム長期化）、組織と人（属人化、人材の高齢化、情シスの疲弊）の4領域に整理できます。共通する本質は「変更したいときに変更できない」ことであり、経済産業省の委員会の定義もこの考え方に沿っています。
Q2. レガシーシステムの具体例は？
COBOLで構築されたメインフレーム上の基幹システム、サポート終了したOS上で稼働する業務システム、部門ごとに増築されたスクラッチ開発の基幹システム、Access・Excelマクロで属人的に運用されている業務ツールなどが代表例です。ただし判断基準は技術の種類ではなく、保守可能かどうかです。新しい技術で構築されていても、仕様が文書化されておらず担当者が1名なら同じ問題を抱えます。用語の基礎は「レガシーシステムとは何か」で解説しています。
Q3. 自社のシステムがレガシーかどうかはどう判断しますか？
本記事の14項目チェックリストで4項目以上に該当する場合、レガシー化が進行しています。より定量的な判断基準については、関連記事「レガシーシステム刷新の判断時期と定量シグナル」で解説している4つの定量シグナルをご参照ください。
Q4. 問題点はあるが予算がない場合、何から着手すべきですか？
まず「今すぐ手を打つべき問題」（EOL・脆弱性・単一障害点）だけを切り出してください。この3つは全体計画を待つ必要がなく、範囲が限定的なため比較的小さな投資で対応できます。並行して、棚卸しと定量化を社内で進めておけば、予算が確保できた時点ですぐ動けます。
Q5. レガシーシステムを放置すると具体的に何が起きますか？
短期（1年）では改修コストの上昇とリードタイムの長期化、中期（3年）では障害対応の長期化とセキュリティリスクの蓄積、長期（5年〜）では保守可能な人材・ベンダーの消失です。3つ目は自社の努力では回復できない点が他と異なります。
Q6. 刷新にはどのくらいの期間と費用がかかりますか？
対象範囲とブラックボックス化の度合いによって大きく変動するため、調査前の概算は実態と乖離しがちです。特にドキュメントが欠落している場合、調査で判明する仕様の量によって工数が数倍変わることもあります。まず現状可視化を行い、範囲を確定させたうえで見積もることを推奨します。手法ごとの費用感の違いは「システムモダナイゼーションの手法」、用語の整理は「モダナイゼーションとマイグレーションの違い」をご参照ください。
まとめ｜レガシーシステムの問題点は「切り分け」から始まる
レガシーシステムに現れる不都合は、技術・構造／データと連携／コストと契約／組織と人という4つの領域に整理できます。ただし、それぞれの重みは同じではありません。EOLと脆弱性は今すぐ、ブラックボックス化とデータ連携は計画的に、そして一部は受容したリスクとしてあえて放置する——この切り分けができれば、刷新は実行可能な規模になります。
経済産業省の委員会レポートが示すとおり、レガシーシステムは全産業の61%、大企業の74%に残存しています。つまりこれは、自社だけが遅れているという話ではありません。差がつくのは、問題を把握しているかどうか、そして着手の順番を決められているかどうかです。
まずは14項目のチェックリストで現在地を確認し、5つの指標を数字で埋め、影響度と緊急度で優先順位をつけてください。レガシーシステムの問題点は、すべてを一度に直すものではなく、順番を決めて手を付けるものです。
📣 レガシーシステムの問題点の把握から始めませんか
