LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

古いシステムの保守を任せていた担当者が辞めて、誰に聞けばよいか分からない。SES（システムエンジニアリングサービス）で技術者に来てもらったものの、何から頼めばよいか決まらない——。長く使っている業務システムを抱える現場では、こうした悩みが起こりがちです。レガシーシステムとは、古い技術で作られていて直しにくい、複雑になりすぎて変更しにくい、仕様が分かる人がいない、のいずれかに当てはまるシステムを指します。^*2

こうしたシステムの保守に社外の技術者に加わってもらうのは、社内の人だけでは手が回らないときの現実的な方法です。ただし万能ではなく、頼む作業と報告の中身を決めずに始めると、仕様を知っている人が社内にも社外にもいない状態が続きます。本記事では、開発の現場を任されているマネージャーに向けて、保守の担い手が問題になる理由、レガシーと判断された理由ごとの作業の頼み方、報告と文書の確かめ方、そして外部に頼むときに確認したい点を整理します。

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

保守は、動いているシステムを使い続けられるように直したり変えたりする仕事です。不具合を直す作業、法令や税率が変わったときにプログラムを変える作業、使っているOSやデータベースソフトの新しい版に合わせる作業などが含まれます。デジタル庁の標準ガイドラインも、保守には自社で作ったプログラムを直すアプリケーション保守のほか、市販のソフトや機器の保守があり、それぞれ作業内容が異なるとしています。^*3 SESの技術者に主に任せるのは、このうちアプリケーション保守です。

レガシーシステムの保守が難しいのは、直す前に調べる時間が長くかかるためです。どのプログラムがどの画面や帳票（請求書や一覧表などの出力）につながっているのかが書かれた資料が古いと、1行を直すために何日も調べることがあります。その調べた結果が担当者の手元にしか残っていないと、担当者が替わるたびに同じ調査をやり直すことになります。

SESの技術者は、期間を決めて作業に加わってもらう人です。契約が終われば別の現場へ移ることもあるため、調べた結果を社内に残す手順を始めに決めておくことが、社員に任せる場合よりも大切になります。

なぜ保守の担い手が問題になるのか

独立行政法人情報処理推進機構（IPA）の「2024年度ソフトウェア動向調査」は、レガシーシステムを持っている、または以前持っていた企業に、移行を決めるうえで特に重要な要素を、3つまで選ぶ形で尋ねています。^*2 答えたのは384社で、IT製品を使う側のユーザー企業373社と、その情報システムを担うユーザー系情報システム子会社11社です。公開されている回答データを本記事で集計すると、結果は次の図のとおりです。

最も多いのは「基幹システムの障害の頻発、リカバリができないといったシステム保守の限界」で209社、54.4%です。次いで「保守サポート要員の確保ができない、ソフトウェア、ハードウェアの保守料アップ」が205社、53.4%でした。^*1 経営者のビジョンや危機感を挙げた124社、競合他社や市場の変化を挙げた136社を、どちらも大きく上回っています。

「保守の限界」と「要員・保守料」のどちらか、または両方を選んだのは285社で、384社の74.2%に当たります。両方を選んだ企業も129社ありました。^*1 ただし、2つ目の選択肢は要員の確保と保守料の値上がりを1つにまとめているので、要員だけを理由にした企業の数は分かりません。

この結果から分かるのは、移行するかどうかの判断が、いまの保守を続けられるかどうかと強く結び付いていることです。移行を決めるまでの間も、決めてから新しいシステムが動き出すまでの間も、古いシステムの保守は止められません。その期間の保守を誰が担うかを決めておかないと、移行の準備に社内の人を回す余裕も生まれません。

レガシーと判断された理由

同じ調査は、そのシステムをレガシーと判断した要因も、当てはまるものをすべて選ぶ形で尋ねています。^*2 384社の回答は、老朽化・陳腐化が275社で71.6%、肥大化・複雑化が197社で51.3%、ブラックボックス化が182社で47.4%でした。^*1 老朽化・陳腐化は古い技術で作られていて技術者を確保しにくい状態、肥大化・複雑化は機能の追加や変更が難しくなった状態、ブラックボックス化は資料が整っておらず特定の人だけで保守していて仕様が分からない状態を指します。^*2

選んだ要因の数を見ると、1つだけが179社、2つが98社、3つすべてが93社で、分からないとした企業が14社です。^*1 4社に1社ほどは、3つの要因をすべて抱えていることになります。

移行の決め手の回答と組み合わせると、ブラックボックス化を選んだ企業ほど、保守の限界を決め手に挙げています。ブラックボックス化を選んだ182社のうち、保守の限界を決め手に挙げたのは121社で66.5%でした。ブラックボックス化を選ばなかった202社では88社、43.6%です。^*1 仕様が分からないシステムほど、障害の対応や復旧に行き詰まりやすいことがうかがえます。

最初に任せる作業の決め方

SESの技術者に加わってもらうとき、最初の1〜2か月に何をしてもらうかは、レガシーになった理由から決めると迷いにくくなります。理由によって、保守を難しくしている原因が違うからです。次の表は、3つの要因ごとに最初に頼む作業と、事前の面談で確かめたい経験を並べた例です。

老朽化・陳腐化が理由なら、まず確保すべきはその技術を扱える人です。古い言語の経験者は少ないため、面談では言語名だけでなく、どの年代の版でどんな改修をしたかを尋ねます。サポートの期限の一覧ができれば、どの言語やソフトから手を付けるかの順番も決めやすくなります。

肥大化・複雑化が理由なら、変更を入れる前の調べ方をそろえることが先です。影響を受けるプログラムの一覧を毎回残してもらえば、次に同じ機能を変えるときの調査が短くなります。ブラックボックス化が理由なら、最初の作業は直すことではなく、読んで書き残すことです。この段階を省いて改修を急ぐと、調べた内容が文書に残らないままになります。3つすべてが当てはまる場合は、ブラックボックス化への作業から始めると、ほかの2つの作業にもそのまま使えます。

変更の手順と月ごとの報告

作業が決まったら、変更をどう進めるかと、何を報告してもらうかを決めます。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（文書番号DS-100）は国の情報システムのためのルールですが、保守の管理のしかたは民間の企業でも参考になります。このガイドラインは、保守の進め方を定める文書に、保守で生じる変更について、何を管理の対象にするか、どんな手順で変えるか、どう管理するかを書くよう求めています。^*3

レガシーシステムでは、誰がどの変更を認めたのかが残っていないことがよくあります。変更の依頼を受け付ける窓口、影響を調べる人、本番（業務で実際に使っている環境）に反映してよいと判断する社内の担当者、の3つを決めておくと、SESの技術者が入れ替わっても変更の履歴が途切れません。

報告について、同じガイドラインは、保守を担う事業者に月ごとの作業実績をまとめて報告させ、少なくとも次の5つを確かめるよう定めています。^*3

• 成果指標とサービスレベルの達成状況
• 作業の計画と実績状況
• 障害やインシデントの発生と対応状況
• 情報システムの構成と稼働監視状況
• リスク・課題の把握・対応状況

サービスレベルは応答の速さや止まらずに動いた時間など前もって約束した水準、インシデントは業務に影響した出来事を指します。レガシーシステムの保守に当てはめるなら、これに「その月に新しく書いた文書、直した文書」を加えておくと役に立ちます。ブラックボックス化したシステムでは、分かったことを文書にする作業そのものが保守の成果です。報告の中で文書の増え方が見えていれば、契約が終わるときに何が社内に残るのかも前もって分かります。

年に一度の文書の突き合わせ

月ごとの報告に加えて、年に一度は文書とシステムの現状が合っているかを確かめます。DS-100は、システムに関する文書の内容が実際のシステムの状況を反映するよう、毎年度末までに運用や保守を担う事業者とともに、文書と現況を突き合わせて確認するよう定めています。^*3 違いが見つかった場合は、文書を更新し、再発を防ぐ方法を考えて実施するとしています。

突き合わせでは、たとえばプログラムの一覧と本番で動いているプログラム、構成の資料と実際のサーバーやデータベースの版、帳票の一覧と実際に出力している帳票を、1つずつ見比べます。違いが多い箇所は、変更の手順のどこかで文書の更新が抜けている箇所です。その手順を見直せば、同じ違いが翌年に起きにくくなります。

この作業は、SESの技術者がいる間に一緒に行うのが効果的です。技術者が契約を終える前に突き合わせを済ませておけば、後任や社内の担当者は、正しい文書から保守を始められます。レガシーの仕様書を引き継げる形に直す手順は「レガシーの仕様書が古いときに引き継げる形へ直す4つの手順」で、契約が終わるときの後任への引き継ぎは「SES契約終了の後任への引き継ぎ」で扱っています。

外部に委託するときに確認しておきたい点

SESの会社に技術者の紹介を相談するときは、まず対象のシステムについて、使っている言語と版、プログラムのおおよその本数、資料がどこまで残っているかを伝えます。レガシーと判断した理由が3つのどれに当たるかも伝えると、先に挙げた表のどの経験を持つ人が必要かを、相手の会社も判断しやすくなります。

次に、月ごとの報告の項目と、書いた文書をどこに置くかを契約の前に伝えておきます。文書を技術者の手元のファイルではなく、社内の共有の場所に置いてもらうだけで、契約が終わったあとに残るものが変わります。途中で技術者が替わる可能性と、替わるときに前の人と後の人が一緒に作業する期間を取れるかも聞いておきます。

最後に、社内に残す役割をはっきりさせます。変更を本番に反映してよいかの判断、移行するかどうかの判断、年に一度の突き合わせの結果を確かめる役割は、社内の担当者が持ちます。保守の作業を任せても、システムの状態を知っている人が社内に1人はいる状態を保つことが、次の移行の準備にもつながります。

まとめ：保守を任せる前に確かめておきたい3つの点

SESの技術者にレガシーシステムの保守を任せるうえで、確かめておきたい点は3つに整理できます。第一に、老朽化・陳腐化、肥大化・複雑化、ブラックボックス化のどれが理由でレガシーになったのかを見て、最初に頼む作業を決めること。第二に、変更の手順と月ごとの報告の項目を決め、書いた文書を報告に含めてもらうこと。第三に、年に一度は文書とシステムの現状を突き合わせ、違いを直しておくことです。この3点を踏まえておけば、「技術者が替わったら、また一から調べ直しになった」という事態を避けやすくなります。保守の担い手の探し方や頼む作業の決め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「2024年度ソフトウェア動向調査 企業向け 調査結果（選択肢項目文字列）」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-result-data-str.csv）。出典：独立行政法人情報処理推進機構。Q5-2・Q5-4・Q5-15と企業種別の回答。社数・割合・選んだ要因の数・設問の組み合わせは、このCSVから集計・計算した値（回答対象はQ5-2でレガシーシステムを保有している、または過去に保有していたと答えた384社）（2026年9月確認）
2. *2　参考：IPA「2024年度ソフトウェア動向調査 企業向け 設問一覧」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-questions.xlsx）。出典：Q5-2のレガシーシステムの考え方、Q5-4とQ5-15の設問文・選択肢・回答の形式（Q5-15は3つまで選ぶ形式）を参照（2026年9月確認）
3. *3　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。第3編第9章の冒頭（保守の種類）、1.5)キ（保守実施要領の変更管理）、2.2)ア（保守の定常時対応で確認する事項）、2.3)（情報システムの現況確認）を参照（2026年9月確認）
4. *4　参考：IPA「2024年度ソフトウェア動向調査」調査結果データの公開と分析レポートの募集（https://www.ipa.go.jp/digital/software-survey/software-engineering/result-software2024.html）。出典：調査期間（2024年12月17日〜2025年2月14日）と、回答を匿名化してオープンデータとして公開していることを参照（2026年9月確認）

Tweet