【実録】レガシーシステムを抱える社内SEの現実｜属人化・ベンダー依存から脱却する方法

こんな状況になっていませんか？

社内SEとして働いていて、こんな経験はありませんか？

• 前任者が退職して、システムの仕様がまったくわからない
• 「このシステム、何でこうなってるの？」と聞かれても答えられない
• ベンダーに聞かないと、ちょっとした修正もできない
• 設計書がない、あっても10年前のまま更新されていない
• 「動いているから触らない」で放置しているシステムがある
• 経営層に「そろそろ刷新しないとまずい」と言っても予算がつかない

一つでも当てはまるなら、あなたの会社は「レガシーシステム問題」を抱えています。

私は社内SEとして10年間、9社を経験してきました。その中で、レガシーシステムに苦しむ現場を何度も見てきました。「誰も仕様を知らない基幹システム」「ベンダーの言いなりで毎年高額な保守費を払い続ける」「担当者が辞めた瞬間に詰む」——これらは決して珍しい話ではありません。

この記事では、レガシーシステムを抱える社内SEが今すぐできる対策と、経営層を動かすための説明方法を解説します。

レガシーシステムとは

まず「レガシーシステム」の定義を確認しておきましょう。

レガシーシステムの定義

経済産業省のDXレポートでは、レガシーシステムを次のように定義しています。

技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム

ポイントは「古い＝レガシー」ではないということです。20年前のシステムでも、仕様が明確で保守できる状態なら問題ありません。逆に、5年前に導入したシステムでも、ブラックボックス化していればレガシーシステムです。

2025年の崖とは

2018年に経済産業省が発表した「DXレポート」で、こんな警告が出されました。

• 2025年には、21年以上稼働している基幹系システムが約6割に達する
• レガシーシステムを放置すると、2025年以降年間最大12兆円の経済損失が発生する
• レガシーシステムを支えてきた技術者が定年退職で現場を離れる

そして今、2025年を過ぎた現在、この問題は「警告」から「現実」になっています。

2025年5月に公開された「レガシーシステムモダン化委員会総括レポート」によると、いまだに企業の61%がレガシーシステムを抱えているという調査結果が出ています。

社内SEが直面する3つの課題

レガシーシステムについての解説記事は多いですが、そのほとんどは「経営層向け」や「DX推進担当向け」です。ここでは、現場の社内SEが実際に直面する課題に焦点を当てます。

課題1：属人化・ブラックボックス化

最も深刻な課題が属人化です。

よくある状況：

• 「このシステムは○○さんしかわからない」が常態化
• 設計書がない、あっても現状と一致していない
• ソースコードにコメントがない、変数名が意味不明
• 「なぜこの処理があるのか」を知る人がいない
• 前任者が退職したら、もう誰も触れない

こうなると、簡単な修正でも「影響範囲がわからないから怖くて触れない」という状態になります。結果として「動いているから触らない」という判断になり、問題が先送りされ続けます。

課題2：ベンダーロックイン

中小企業で特に多いのがベンダーロックインです。

よくある状況：

• システムの中身は全部ベンダー任せで、社内に技術者がいない
• ちょっとした修正でも「見積もり→発注→作業」で数週間かかる
• 保守費用が毎年上がるが、他社に乗り換えられない
• ベンダーの担当者が変わるたびに、話が通じなくなる
• 「この機能を追加したい」と言っても「現行システムでは難しい」と断られる

ベンダーが悪いわけではありません。問題は、社内にシステムを理解している人がいないことです。ベンダーの提案や見積もりが適正かどうか判断できず、言われるがまま契約を更新し続けることになります。

課題3：経営層の理解不足

社内SEが最も苦労するのが、経営層への説明です。

よくある状況：

• 「動いてるなら問題ないでしょ」と言われる
• 「刷新にいくらかかるの？」→ 金額を言うと「高すぎる」で終了
• 「今期は予算がない、来期検討しよう」が毎年続く
• 「セキュリティリスク」と言っても響かない
• システム障害が起きて初めて重要性に気づく（そして社内SEが責められる）

経営層にとって、ITシステムは「コスト」であり「投資」ではありません。目に見える売上に直結しないため、優先度が下がりがちです。

今すぐできる対策（予算ゼロ編）

「刷新したいけど予算がない」という状況でも、今すぐできることはあります。むしろ、これらをやっておかないと、いざ刷新するときに困ります。

対策1：システム構成図を作る

まずは現状の可視化です。以下の情報を整理してください。

【システム台帳に記載すべき項目】

■ 基本情報
・システム名
・導入年
・ベンダー名（開発元・保守元）
・利用部署
・利用者数

■ 技術情報
・サーバー（オンプレ/クラウド/SaaS）
・OS・ミドルウェア・バージョン
・開発言語
・データベース

■ 契約情報
・保守契約の有無・期限
・ライセンス数・費用
・年間保守費用

■ リスク評価
・サポート終了予定日
・属人化度（高/中/低）
・代替手段の有無

Excelやスプレッドシートで十分です。まずは「うちの会社にはどんなシステムがあるのか」を一覧化しましょう。

対策2：設計書・仕様書を整理する

設計書がない場合は、今からでも作り始めてください。

最低限残すべきドキュメント：

• システム概要図：どのシステムがどうつながっているか
• データフロー図：データがどこからどこに流れるか
• テーブル定義書：データベースの構造
• 運用手順書：日次・月次でやっている作業
• 障害対応手順書：トラブル時の対応フロー

完璧を目指す必要はありません。「今わかっていること」を文書化するだけでも、将来の自分や後任者を救います。

対策3：ベンダーとの契約内容を確認する

意外と見落としがちなのが契約内容の確認です。

確認すべきポイント：

• 保守契約の範囲（何をやってくれて、何は別料金か）
• ソースコードの所有権（自社にあるか、ベンダーにあるか）
• データの取り出し方法（乗り換え時にデータを持ち出せるか）
• 契約更新の条件（自動更新か、値上げ条項はあるか）
• 解約時の手続き（何ヶ月前に通知が必要か）

特にソースコードの所有権は重要です。「ベンダーが倒産したらシステムが使えなくなる」というリスクを回避するためにも、契約書を確認しておきましょう。

対策4：トラブル履歴を記録する

レガシーシステムで発生したトラブルは、必ず記録してください。

【トラブル記録テンプレート】

発生日時：2025/12/15 09:30
システム名：販売管理システム
事象：月次処理が途中でエラー停止
影響範囲：営業部全員（20名）が午前中業務停止
原因：ディスク容量不足
対応：不要ログを削除して復旧
対応時間：3時間
対応費用：ベンダー緊急対応費 5万円
再発防止策：ディスク監視の導入（未実施）

この記録が、後で経営層に説明するときの根拠資料になります。「年に○回トラブルが発生し、○時間の業務停止、○万円のコストが発生している」と数字で示せると説得力が増します。

経営層への説明方法

予算を獲得するには、経営層の言葉で説明する必要があります。技術的な話は響きません。

説明のフレームワーク

経営層に響く説明には、以下の3点を含めてください。

① リスク（放置したらどうなるか）

• 担当者が退職したら、システムを維持できなくなる
• サポート終了後にセキュリティ事故が起きたら、会社の信用問題になる
• 法改正（電子帳簿保存法など）に対応できず、罰則の対象になる

② コスト（現状維持にいくらかかっているか）

• 年間の保守費用：○○万円
• トラブル対応の人件費：○○万円相当
• 業務停止による機会損失：○○万円相当

③ 期限（いつまでに対応が必要か）

• ○○システムのサポート終了日：20XX年X月
• 担当ベンダーの撤退予定：20XX年X月
• 法改正の施行日：20XX年X月

説明テンプレート

以下のテンプレートを参考に、経営層向けの資料を作成してください。

【基幹システム刷新の提案】

■ 現状
・導入から15年が経過し、開発元のサポートが20XX年に終了予定
・システムを理解している担当者は1名のみ（退職リスク）
・年間保守費用：300万円（5年前比で1.5倍に増加）

■ リスク
・サポート終了後にセキュリティ脆弱性が発見されても修正不可
・担当者退職時、システム維持が困難になる可能性
・電子帳簿保存法への対応ができず、税務調査で指摘されるリスク

■ 現状維持のコスト（5年間）
・保守費用：300万円×5年＝1,500万円
・トラブル対応：50万円×5年＝250万円
・合計：1,750万円（最低限）

■ 刷新した場合のコスト
・初期費用：1,000万円
・年間保守：100万円×5年＝500万円
・合計：1,500万円

■ 提案
・20XX年度予算で基幹システム刷新のプロジェクトを開始
・まずは現状調査（3ヶ月、100万円）から着手

ポイントは「刷新しないほうが高くつく」ことを数字で示すことです。感情ではなく、論理で説得しましょう。

レガシーシステムからの脱却方法

予算が確保できたら、いよいよ刷新に向けて動き出します。ここでは、一般的な脱却方法を紹介します。

方法1：リプレース（置き換え）

既存システムを完全に新しいシステムに置き換える方法です。

メリット：最新技術を採用でき、長期的な保守性が高い

デメリット：コストが高い、移行リスクがある、時間がかかる

向いているケース：システムが完全にブラックボックス化している、業務プロセス自体を見直したい

方法2：マイグレーション（移行）

既存のシステム構造を維持しつつ、新しい基盤（クラウドなど）に移行する方法です。

メリット：業務への影響が少ない、リプレースより低コスト

デメリット：根本的な問題は解決しない場合がある

向いているケース：システム自体は使えるが、ハードウェアやOSが古い

方法3：モダナイゼーション（近代化）

既存システムを活かしながら、段階的に新しい技術を取り入れる方法です。

メリット：リスクを分散できる、段階的に投資できる

デメリット：時間がかかる、中途半端な状態が続くリスク

向いているケース：一度に大きな投資ができない、部分的に改善したい

方法	コスト	リスク	期間
リプレース	高	高	長い
マイグレーション	中	中	中程度
モダナイゼーション	低〜中	低	長い

まとめ

項目	内容
レガシーシステムとは	老朽化・複雑化・ブラックボックス化により、経営の足かせになっているシステム
2025年の崖	企業の61%がレガシーシステムを抱えたまま2025年を迎えた
社内SEの課題	属人化、ベンダーロックイン、経営層の理解不足
今すぐできること	システム台帳作成、設計書整理、契約確認、トラブル記録
経営層への説明	リスク・コスト・期限を数字で示す

レガシーシステム問題は、放置すればするほど解決が難しくなります。「いつかやらなきゃ」と思っているなら、今日から動き始めてください。

まずはシステム台帳を作るところから。それだけでも、現状が可視化され、次のアクションが見えてきます。