レガシーシステム保守とは？古いシステムを安全に使い続けるための考え方

「このシステム、誰も触れる人間がいなくなってしまった」「仕様書がない状態で保守を続けなければいけない」。そんな状況からご相談をいただくことが増えています。

この記事では、レガシーシステム保守とは何か、通常の保守とどう違うのか、どういった状況で外注が選ばれるのかを整理します。

レガシーシステム保守とは

レガシーシステム保守とは、古い業務システムを止めずに使い続けるために、現行のコード・環境・運用を読み解き、不具合修正や小さな改修、引き継ぎ資料の整備を継続して行う取り組みです。

この記事では、単に年数が古いだけでなく、保守できる人や情報が失われ、変更しづらくなった状態もレガシーシステムとして扱います。作って5年でも担当者が全員退職していれば、保守は難しくなります。逆に20年前のシステムでも、仕様が整理されていて担当者がいれば、保守の難易度はそれほど高くありません。

通常のシステム保守と何が違うのか

一般的なシステム保守は、仕様が整理されていて担当者が継続している状態を前提にしています。「この機能のここを直してほしい」という依頼に対して、既知の範囲で対応する仕事です。

レガシーシステム保守では、その前提がありません。

• 仕様書がないため、まず現行の動作を読み解くところから始まる
• 変更の影響範囲が把握できていないため、修正前に調査が必要
• 過去の設計意図が分からず、バグなのか仕様なのかの判断が難しい

こうした「仕様を読み解きながら保守する」作業は、通常の保守と比べて工数がかかります。見積もりや作業範囲の合意の取り方も、通常の保守とは少し異なります。

「レガシーシステム再生」とどう違うのか

似た言葉に「レガシーシステム再生」があります。保守と再生はきれいに分かれるものではなく、重なる部分があります。違いは「何を主な目的にするか」です。

レガシーシステム再生は、作り直しを急ぐ前に、現行システムを調査・整理し、まだ活かせる部分を見極めながら保守できる状態へ戻していく考え方です。リプレースするか、現行を使い続けるかを判断する前段階でも使います。

レガシーシステム保守は、止められない業務システムに対して、不具合対応・小さな改修・ドキュメント更新を続けながら、日々の運用を支える実務です。保守の中で、少しずつ再生に近い整理を進めることもあります。

分かりやすく整理すると、再生は「作り直す前に、現行を活かせる状態へ戻す考え方」、保守は「動かし続けるために、調査・修正・記録を継続する実務」です。実際の現場では、保守をしながら少しずつ再生を進めるケースも多くあります。

「リプレースか現行維持か」という大きな判断軸についてはレガシーシステム再生とは？リプレースの前に現行システムを活かす選択肢で詳しく解説しています。

よくある相談

相談のきっかけはさまざまですが、よくいただくのは次のような状況です。

担当者の退職・不在

「システムを知っていた唯一の人が辞めた」「引き継ぎが不十分なまま退職された」という状況。誰も触れない、何が動いているか分からない状態から始まることがあります。担当者退職時の引き継ぎ項目についてはシステム担当者の退職が決まったときに確認すべき引き継ぎ項目にまとめています。

開発した会社との連絡が取れなくなった

外注で作ったシステムの会社が廃業した、担当者が変わって対応してもらえなくなった、など。ソースコードは手元にあるが、どう扱えばいいか分からない状態。最初の確認事項は開発した業者と連絡が取れなくなったら最初に確認することを参照してください。

仕様書がなく次に頼めない

保守会社を変えたいが、仕様書がないため別の会社に依頼できない。仕様書がなければ見積もりすら難しいと断られた。仕様書がない状態での調査アプローチは仕様書がない古いシステムを保守するには？で、保守会社を変更する際に確認すべき項目はシステム保守会社を変えるときの引き継ぎチェックリストで詳しく解説しています。

不具合があるが誰も直せない

「触ると壊れそう」で誰も手を入れられていない。不具合があるまま運用を続けている。古い言語・フレームワークに対応できる技術者が見つからない。

保守を始める前に確認すること

外部に保守を依頼する前に、手元で確認できることがあります。

ソースコードの有無と場所

ソースコードがあるかどうかで、対応できる範囲が大きく変わります。外部委託で作ったシステムの場合は、契約書を確認し、ソースコードの権利が自社にあるかも確認してください。

サーバーとドメインの管理権限

誰が、どのアカウントで管理しているかを確認します。退職した担当者個人のメールアドレスや、廃業した業者のアカウントに紐付いている場合は、早急に整理が必要です。

直近の不具合・困りごとの整理

「どこが壊れているか」「何に困っているか」を言語化しておくと、相談がスムーズになります。

これらが整理されていなくても、相談は可能です。「何が分からないかが分からない」という段階から整理するところから始めます。

単発調査で分かること

いきなり継続保守の契約を結ぶ前に、単発の調査・診断から始めることができます。

単発調査では次のことが分かります。

• システムの全体像（使われている言語・フレームワーク・構成）
• 現在の問題箇所と、その深刻度
• 保守を続けるうえでのリスクと優先度
• 継続保守に進むべきか、別の対応が必要かの判断材料

調査の結果、「継続保守が必要」「特定の不具合だけ直せばよい」「サーバー移行を先に対処すべき」といった判断が得られます。継続保守への移行は、調査結果をもとに改めてご相談します。

継続保守で少しずつ整えること

継続保守では、不具合修正・改修対応・ドキュメント整備を積み上げていきます。

一度の作業で全体を整理できるわけではありません。対応するたびに調査した内容・修正した箇所・確認した動作を記録していくことで、「誰も知らない範囲」が少しずつ狭まっていきます。この積み上げが、担当者が変わっても保守できる状態への道筋です。担当者が在籍しているうちにできる対策はシステムの属人化を、担当者が辞める前に解消しておく方法で、改修を安全に進める具体的な手順は古い PHP システムを安全に改修する手順：準備から変更ルールまでで解説しています。

継続保守では、月次などの定期作業を前提とする場合と、都度依頼ベースで進める場合があります。状況に合わせてご提案します。

保守ではなくリプレースを検討すべきケース

レガシーシステム保守が向いていない場合もあります。

• 現行システムの仕様が業務から完全にかけ離れており、使われていない機能が大半
• 技術的な問題が深刻すぎて、保守するコストが新規構築を上回る
• システムの利用者・対象業務が大きく変わり、根本的な作り直しが必要

ただし、「作り直しが必要」かどうかは、現行を調査しないと判断できないことがほとんどです。「作り直すべきか保守すべきか」という判断自体を、調査のご依頼として受け付けています。ベンダーからリプレースを提案されて迷っている場合はベンダーにリプレースを提案されたとき、自分で判断するための確認リストが参考になります。

現行システムを活かす選択肢と、リプレースを考える判断軸についてはレガシーシステム再生とは？リプレースの前に現行システムを活かす選択肢で詳しく解説しています。

相談前に準備できるもの

相談のハードルを下げるために、事前に準備できることを整理します。ただし、これらが揃っていなくても相談はできます。

「何を準備すれば良いか分からない」という場合も、まずは現状をお聞かせください。レガシーシステム保守のページ、またはお気軽にお問い合わせください。