レガシーシステムの運用管理を立て直す3つの手順：属人化からの脱却

「あのシステムは、Aさんしか分からないんですよ」——古い業務システムを抱える企業を訪問すると、判で押したように同じセリフを聞きます。担当者の名前と、申し訳なさそうな笑顔だけが、毎回違うだけです。

IPA（情報処理推進機構）が公開した「DX白書 2023」では、国内ユーザー企業の61.0%が稼働中のレガシーシステムを保有していると回答しています。そのうち少なくない企業が、システム本体の老朽化以上に「中身を把握している人がいない」という構造的な問題に直面しています。

属人化を解消するために必要なのは、技術的な大改修ではありません。「現状の可視化」と「特定の個人に依存しない体制づくり」、この2つを地道に積み上げることです。本記事では、three dots. がレガシーシステムの引き取り案件で実際に踏んでいる、運用管理の立て直し手順を3ステップで解説します。

なぜレガシーシステムの運用管理は属人化しやすいのか

長年運用されているシステムが属人化していく背景には、ほぼ共通したシナリオがあります。引き取り案件のヒアリングを重ねるなかで、私たちが繰り返し出会う典型パターンを3つ紹介します。

1. ドキュメントが消えている、または嘘になっている

導入時に作った仕様書が紛失している、あるいは度重なる改修で実装と乖離しているケースです。「設計書はあります」と言われて開いてみると、最終更新が10年前で、今動いている画面とは別物だった——というのは珍しくありません。

仕様書が信用できなくなった瞬間、システムの正解はソースコードと「担当者の記憶」だけになります。担当者が辞めた瞬間、正解そのものが失われる構造です。

2. 技術スタックが時代と乖離している

サポート終了済みの PHP5 や Windows Server 2012、いまや講習会の題材にもならない旧世代の Java フレームワーク。中小企業の場合、そもそも社内に常駐エンジニアはほとんどおらず、導入当時の開発会社や、その後に引き継いだフリーランスが片手間で見続けているケースが大半です。

ここで効いてくるのが「読めるエンジニアの母数」そのものの縮小です。古い言語やフレームワークを実戦で触ってきたのは40〜50代以上のベテランがほとんどで、人材市場にもなかなか出てきません。いざ保守を頼める人を探しても、見つかった頃には単価が跳ね上がっている、あるいは「もうそのバージョンは受けていません」と断られる——という事態が現実に起きています。

外注先の開発会社自体が高齢化や事業縮小で撤退するパターンもあります。「長く面倒を見てくれていた1社が廃業した瞬間、相談先がゼロになった」という相談は、私たちのもとにも繰り返し届きます。

3. 「動いているから触らない」という文化

過去のトラブルがトラウマになり、関係者全員が積極的に距離を置く——これが一番厄介なパターンです。情シス担当や現場の業務担当者が「この処理はどうなっているのか」と疑問を持っても、「あれは触らないほうがいい」「下手に動かすと止まる」で会話が終わってしまう。社内で問いを立てること自体がタブー化していきます。

結果、システムは内部から静かに腐っていきます。動いているうちは問題ありませんが、OS の EOL、決済代行の仕様変更、税制改正といった外部要因で「動くだけ」では済まなくなった瞬間に、誰も対応できないことが露呈します。

属人化した古いシステムを放置する3つのリスク

属人化したまま放置することは、現場の手間という話では済みません。経営に直接ダメージを与える、リアルなリスクが3つあります。

経済産業省が2018年に公表した「DXレポート」では、レガシーシステムを放置した場合、2025年以降に最大年間12兆円規模の経済損失が生じる可能性があると試算されています。いわゆる「2025年の崖」です。指摘から数年が経ちましたが、現場感覚として、状況が劇的に改善したとは言えません。

担当者の不在で業務が止まる: 退職、休職、長期入院、家族の介護。担当者が長期離脱する理由はさまざまです。「あの人が戻らないと月次バッチが組み直せない」「データ抽出の手順を知っているのは1人だけ」——こうした状態は、いつ事業停止につながってもおかしくありません。
セキュリティの穴がふさげない: OS やミドルウェアがサポート終了を迎えても、改修の影響範囲が読めないためにバージョンアップに踏み切れない。脆弱性を認識しながら放置せざるを得ない状態です。ランサムウェアの侵入経路として、EOL を迎えた基幹システムが狙われる事例も増えています。
新しいビジネスに対応できない: 「請求書のフォーマットを少し変えたい」「新しい決済方法に対応したい」——その程度の改修でさえ、中身がわからないために実現できなくなります。市場の変化に追従できず、競合との差がじわじわ広がっていきます。

レガシーシステムの運用管理を立て直す3つの手順

リプレース(システムを刷新)に踏み切らない選択をするなら、運用管理そのものを立て直すしかありません。three dots. が引き取り案件で実際に踏んでいる手順を、順を追って紹介します。

手順1. 資産の棚卸し——「何がどこで動いているか」を地図にする

最初にやるのは、システム資産の物理的・論理的な棚卸しです。具体的には次のような項目を洗い出します。

稼働しているサーバー（オンプレかクラウドか、設置場所、契約状態）
OS、ミドルウェア、データベースの種類とバージョン
ソースコードのリポジトリ所在（Git の有無、バックアップ）
外部連携先（決済、CRM、メール配信、SaaS など）
ドメイン、SSL 証明書、メールサーバーの契約者と更新時期

地味に重要なのが、ドメイン契約者名と SSL 証明書の管理者です。「契約者が退任した役員のままで、更新通知が誰にも届かない」というケースを、私たちは何度も見てきました。証明書の期限切れで、ある朝突然サイトが見えなくなる——その「事故」の半数くらいは、この種の管理漏れが原因です。

この段階では、システムの「外枠」を可視化することがゴールです。中身の処理ロジックには、まだ踏み込みません。

手順2. 中身の解読とドキュメント再生

外枠が把握できたら、ソースコードとデータベースの構造を読み解き、業務との対応関係をドキュメントに起こします。

仕様書が残っていなくても、ソースコードと稼働中のシステムがあれば、中身の解明は可能です。私たちが実際に進めている手順は次のとおりです。

データベースのテーブル定義とリレーションを書き起こす
主要画面の処理を追い、エントリポイントから関数呼び出しを図にする
業務担当者にヒアリングしながら、画面・帳票・バッチを業務フローに紐づける
ヒアリング結果と実装が食い違う箇所を「要確認リスト」として積む

このプロセスで一番大切なのは、完璧なドキュメントを目指さないことです。「100点の設計書を1冊」より「60点でいいから業務に紐づいた資料を一式」のほうが、現場では何倍も役に立ちます。属人化を解消するためのドキュメントは、読まれてはじめて意味を持ちます。

手順3. 属人化を前提から壊す保守体制の構築

可視化された情報をもとに、特定の個人に依存しない保守体制をつくります。

社内で引き継ぎが可能なら、ペアでの障害対応や、月次の運用レビューを習慣化することから始めます。社内リソースが足りないなら、保守を外部のパートナー企業に委託するのも有効な選択肢です。

外部委託する場合、契約前に確認しておきたいポイントが4つあります。

設計書がない前提で、引き取りに着手してくれるか
障害対応だけでなく、能動的な改善提案まで契約に含まれるか
「3年後にリプレースする」というシナリオまで、一緒に考えてくれるか
料金形態が自社の稼働量に合っているか（月額固定か、実際に動いた分だけ請求する実働ベースか）

保守委託は「丸投げして安心」では終わりません。委託先と社内で情報を共有し続ける仕組みまで含めて、はじめて属人化からの脱却になります。

全面リプレース以外の「現実的な選択肢」

中小企業のシステム刷新となると、「全面リプレース」一択で語られがちです。技術的な負債を一気に清算できる魅力はたしかにあります。しかし、コストは数千万から億単位、期間は1〜2年。プロジェクトの進行中もシステムは動かし続けなければならず、現業との両立に疲弊してしまう例も少なくありません。

three dots. が提案することが多いのは、現状のシステムを引き取って保守を継続しながら、ボトルネックの箇所だけを段階的に作り直していく「漸進的改善」のアプローチです。

まず保守を引き取り、ブラックボックスを解明する
業務に支障が出ている箇所、リスクの高い箇所から順に改修する
数年かけて、新しい技術スタックへ静かに置き換えていく

予算を平準化しながら、リプレースと同じ効果を時間をかけて得る、という発想です。「2025年の崖」を一気に飛び越えるのではなく、橋をかけて渡る——そう言ったほうがイメージしやすいかもしれません。

まとめ

担当者が辞めたら終わりかもしれない——その不安は、放置すれば現実になります。一方で、「資産の棚卸し」「中身の解読とドキュメント化」「属人化しない保守体制」の3ステップを踏めば、立て直しは十分に可能です。

大事なのは、完璧を目指さず、まず着手することです。設計書がなくても、技術スタックが古くても、動いているシステムがあれば、そこから読み解くことはできます。私たちが何度も体験してきたとおりです。

動かしているシステムの将来に不安をお持ちでしたら、状況の整理からでもお気軽にご相談ください。弊社のシステムレスキューは月額固定ではなく、実際に動いた分だけ請求する実働ベース（従量課金）の保守です。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/