LASSIC Media らしくメディア
レガシーの仕様書の引き継ぎ方｜書いてあることと動きが違うとき
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- レガシーシステムを使っている企業の回答では、システムの仕様書が変更のたびに更新されているのは47.9％です。
- 仕様書が古いまま、または大部分が書かれていない企業は37.2％で、業務手順の文書も37.2％でした。
- 引き継ぎでは対象のシステムを1つに絞り、仕様と業務手順のどちらが古いかを確かめてから書き直します。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
担当者の退職が決まり、システムを引き継ぐ準備を始めた。仕様書は見つかったのに、いつの版なのかがはっきりせず、書いてあることと実際の動きが合わない——。長く使われてきたシステムの引き継ぎでは、こうした食い違いが起こりがちです。レガシーの仕様書とは、長年使い続けてきた古い仕組みのシステム（レガシーシステム）について、何をどう処理しているかを書いた文書のことです。
仕様書は、引き継ぐ人が最初に読む手がかりです。ただし万能ではなく、書いてあっても古ければ、読んだ内容と動いている中身を一つずつ確かめ直すことになります。本記事では、レガシーシステムを引き継ぐ実務担当者に向けて、調査で見た仕様書の状態、業務手順の文書との違い、引き継げる形に直す手順、そして外部に委託するときに確認したい点を整理します。
目次
レガシーの仕様書とは
引き継ぎで読む文書は、大きく2つに分けられます。1つは、システムがどんなデータを受け取り、どう処理して、何を出すかを書いたシステム仕様の文書です。もう1つは、そのシステムを使って人がどんな順番で仕事を進めるかを書いた業務手順の文書です。前者が古いとプログラムを直す人が困り、後者が古いとシステムを使って仕事を回す人が困ります。
IPA（情報処理推進機構）の調査は、この2つを「システム仕様」と「業務オペレーションやプロセス」に分け、それぞれがどこまで可視化されているかを尋ねています。*3 可視化とは、文書などにして誰でも読める状態にしておくことです。選択肢は6つあり、変更のたびに更新されているか、一度書いたまま古くなっているか、大部分が書かれていないか、といった違いで分かれています。
レガシーの仕様書で問題になりやすいのは、文書が無いことよりも、あるのに古いことです。文書が無ければ、調べる時間を最初から予定に入れられます。ところが、古い文書が残っていると、引き継ぐ人はまずそれを信じて読み、あとで実際の動きとの違いに気づくことになります。
調査で見るレガシーの状態
取り上げるのは、IPAの「2024年度ソフトウェア動向調査」です。2024年12月17日から2025年2月14日にかけて実施され、2025年4月7日時点で企業799件、個人74件の回答がありました。*1 回答は匿名化したうえで誰でも入手できる形で公開されており、ここでは企業向けの回答をCSV（表の形式のデータファイル）から集計しました。*2
レガシーに関する設問は、答える企業が絞られています。ユーザー企業662件とユーザー系情報システム子会社20件の合わせて682件が対象で、ベンダー系の117件は回答対象外として空欄になっています。*2 ユーザー企業はシステムを自社の業務に使う側、ベンダー系はシステムを作って納める側の企業です。
682件のうち「レガシーに該当するシステムを保有している」と答えたのは322件で、47.2％でした。「以前から保有していない」と「わからない」がそれぞれ149件21.8％、「過去に保有していたが今は保有していない」が62件9.1％です。*2 システムを自社で使う企業のおよそ半分が、いまも古い仕組みのシステムを動かしていることになります。
保有している322件と過去に保有していた62件を足すと384件で、682件に対して56.3％です。この384件が、仕様書の状態を尋ねる設問の対象になっています。以下の割合は、すべてこの384件を母数にしています。
なぜ引き継ぎで困るのか
システム仕様の可視化状況で最も多かったのは、「変更毎に最新化されているが、部分的に可視化されていないものが存在する」の113件29.4％でした。次いで「変更毎に最新化され、大部分が可視化されている」が71件18.5％、「大部分が可視化されていない」が65件16.9％です。*2
残りは、「一度可視化したが最新化されておらず、情報が古いままである」が59件15.4％、「わからない」が57件14.8％、「全く可視化されていない」が19件4.9％でした。変更のたびに更新されている2つの区分を足すと184件で47.9％、古いか書かれていない3つの区分を足すと143件で37.2％になります。
この分布から分かるのは、仕様書が変更のたびに更新され、しかも大部分がそろっている状態は2割弱にとどまるということです。最も多いのは、更新はされているものの一部が書かれていない状態でした。引き継ぐ人は仕様書を手がかりにできますが、書かれていない部分に当たったところで、プログラムを読んだり前任者に聞いたりして確かめることになります。
古いか書かれていない側の37.2％に当たるシステムでは、引き継ぎの最初に、文書の中身と実際の動きを突き合わせる作業が要ります。引き継ぎの予定を組むときは、仕様書を読む時間だけでなく、突き合わせる時間を最初から入れておくと進めやすくなります。
業務手順の文書との違い
業務オペレーションやプロセスの側も、最も多かったのは「部分的に可視化されていないものが存在する」の111件28.9％でした。続いて「一度可視化したが情報が古いままである」が68件17.7％、「変更毎に最新化され、大部分が可視化されている」が67件17.4％です。「わからない」は63件16.4％、「大部分が可視化されていない」は60件15.6％、「全く可視化されていない」は15件3.9％でした。*2
システム仕様と同じようにまとめると、変更のたびに更新されている側が178件で46.4％、古いか書かれていない側が143件で37.2％です。古い側は件数も割合もシステム仕様と同じになりましたが、同じ企業が両方でそう答えたという意味ではありません。
両者の差も小さく、大部分がそろっている区分では18.5％と17.4％で1.1ポイント、全く可視化されていない区分では4.9％と3.9％で1.0ポイントです。更新されている側をまとめても47.9％と46.4％で、差は1.5ポイントでした。どちらかが特に整っているとはいえず、仕様書と業務手順の文書はほぼ同じ程度に古くなっていると考えるのが自然です。
引き継ぎの実務に当てはめると、仕様書だけを読めば足りるとは言い切れません。プログラムの処理が仕様書どおりでも、人がそのシステムをどの順番で使っているかが書かれていなければ、引き継いだ人は日々の運用で迷います。仕様と業務手順の両方に目を通してから、どちらを先に直すかを決めます。
引き継げる形に直す手順
ここからは調査の結果を、引き継ぎの手順に当てはめます。手順の根拠にする区分ごとの内訳は次のとおりです。
| 区分 | システム仕様 | 業務オペレーションやプロセス |
|---|---|---|
| 変更毎に最新化されているが、部分的に可視化されていないものが存在する | 113件／29.4％ | 111件／28.9％ |
| 変更毎に最新化され、大部分が可視化されている | 71件／18.5％ | 67件／17.4％ |
| 大部分が可視化されていない | 65件／16.9％ | 60件／15.6％ |
| 一度可視化したが最新化されておらず、情報が古いままである | 59件／15.4％ | 68件／17.7％ |
| わからない | 57件／14.8％ | 63件／16.4％ |
| 全く可視化されていない | 19件／4.9％ | 15件／3.9％ |
1つ目の手順は、担当者が1人しかおらず、引き継ぐ相手も決まっていないシステムを1つ選ぶことです。すべてのシステムの文書を一度に調べ直そうとすると、作業が終わりません。最も多い状態が「一部が書かれていない」なので、書かれていない部分を埋める作業は、対象のシステムを決めないと際限なく増えます。
2つ目は、仕様と業務手順のどちらが古いかを確かめることです。調査では古い側の割合がどちらも37.2％で、片方だけが特に悪いという結果ではありませんでした。だからこそ、自社のシステムでどちらが古いかを先に確かめ、古いほうから手をつけます。両方を同時に直そうとすると、どちらも途中で止まりがちです。なお、この調査は文書の量や、どれだけ古いかまでは尋ねていないため、自社の文書の状態は実物を開いて確かめます。
3つ目は、文書を書き直す作業と、何を残すかを決める作業を分けることです。書き直す作業は、プログラムや画面を確かめて文書に起こす仕事で、手順が決まれば担当者を増やせます。何を残すかを決める作業は、使っていない機能を文書から外すかどうかといった判断で、業務を知る社内の人でなければ決められません。
4つ目は、書き直す作業を期間で区切って外部に委託することです。大部分がそろっている仕様書は2割弱なので、書き直す作業の量は少なくないと見込んでおきます。社内の担当者が日々の運用と並行して書き直す予定を組むより、対象のシステムと期間を決めて依頼するほうが進めやすくなります。
つまずきやすい点
一つ目は、全部のシステムを洗い出してから始めようとすることです。洗い出しに時間がかかるうちに担当者の退職日が来てしまうと、肝心のシステムの文書が手つかずのまま残ります。担当者が1人しかいないシステムから始め、終わったら次へ進むほうが確実です。
二つ目は、仕様書だけを直して業務手順の文書を後回しにすることです。調査では、業務手順の側も仕様と同じ程度に古くなっていました。プログラムの動きが分かっても、月末に何をどの順で実行するかが分からなければ、引き継いだ人は運用で迷います。
三つ目は、何を残すかの判断まで委託先に任せてしまうことです。委託先は書き直す作業には慣れていても、どの機能が今も業務で使われているかは知りません。判断を任せると、使っていない機能まで丁寧に文書にしたり、必要な機能を外したりするおそれがあります。
外部に委託するときに確認しておきたい点
書き直す作業を外部に委託するときは、対象のシステム、書き直す文書、期間の3つを先に決めておきます。たとえば「受注処理のシステムについて、現在のプログラムと突き合わせながら仕様書を書き直す」のように、どのシステムのどの文書かまで書いておくと、委託先は必要な人数と期間を見積もりやすくなります。
フリーランスを含む業務委託は、このような期間の決まった作業に向いています。作業を期間で区切って依頼し、終わったら文書を社内の担当者に引き渡してもらえるためです。一方で、何を残すかを決める作業と、書き直した文書を確認する作業は社内に残します。委託先には、判断に迷った箇所を一覧にして渡してもらうと、社内の確認が早く進みます。
担当者が辞める前に何を確かめるかは「担当者の離脱に備える3つの確認、技術情報は41.2％が個人依存」で、レガシーシステムの刷新が進まない理由は「レガシー刷新を止めるのは理解不足ではなく要員の不足」で扱っています。
まとめ：レガシーの仕様書で確かめておきたい3つの点
レガシーシステムを引き継げる形に直すうえで、確かめておきたい点は3つに整理できます。第一に、仕様書が変更のたびに更新されている企業は半分に届かず、古いか書かれていない企業が4割近くあると知っておくこと。第二に、対象のシステムを1つに絞り、仕様と業務手順のどちらが古いかを確かめてから直すこと。第三に、何を残すかは社内で決め、書き直す作業は期間で区切って依頼することです。この3点を踏まえておけば、「仕様書はあったのに、引き継いでみたら実際の動きと違っていた」という事態を避けやすくなります。仕様書の書き直しに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
なぜ2025年度ではなく2024年度の調査を使っているのですか
2025年度の調査には、この可視化状況を尋ねる設問がないためです。2025年度のレガシーに関する設問は、保有の有無、影響、刷新の課題に絞られています。*3 仕様と業務手順の状態を6つの区分で尋ねたのは2024年度の調査でした。
ベンダー系の企業が集計に入っていないのはなぜですか
レガシーに関する設問は、企業の種別で答える企業が決められているためです。ユーザー企業とユーザー系情報システム子会社の682件が対象で、ベンダー系の117件は回答対象外として空欄になっています。*2 システムを自社で使う側の状況を示した数値として見ておくとよいでしょう。
調査の回答は、いつの時点のものですか
2025年4月7日時点で集まった回答です。*1 調査は任意の回答で、企業全体を代表するように抽出したものではありません。自社の状況と比べるときは、目安として使うのが適しています。
書き直した仕様書を、その後も最新に保つにはどうすればよいですか
システムを変更する手順の中に、仕様書を更新する作業を組み込んでおくのがおすすめです。変更の依頼書に「更新した文書」の欄を設け、欄が空のままでは変更を終えられないようにしておくと、更新の漏れに気づきやすくなります。
レガシーシステムの引き継ぎを相談したいとき
仕様書を書き直す作業のうち、どこを外部に依頼するかの切り分けからご相談いただけます。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「2024年度ソフトウェア動向調査」調査結果データの公開と分析レポートの募集（https://www.ipa.go.jp/digital/software-survey/software-engineering/result-software2024.html）。出典：公開日2025年2月27日・最終更新日2025年4月25日、調査期間2024年12月17日から2025年2月14日、2025年4月7日時点で企業799件と個人74件の計873件の回答、匿名化してオープンデータとして公開していることを参照（2026年9月確認）
- *2 参考：IPA「2024年度ソフトウェア動向調査 企業向け 調査結果（選択肢項目文字列）」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-result-data-str.csv）。出典：Q5-2とQ5-8の回答。本文・図・表の件数と比率はこのCSVから集計し、区分をまとめた値は件数を足して計算した（2026年9月確認）
- *3 参考：IPA「2024年度ソフトウェア動向調査 企業向け 設問一覧」（https://www.ipa.go.jp/digital/software-survey/software-engineering/h5f8pg00000028n8-att/software2024-c-questions.xlsx）。出典：Q5-2とQ5-8の設問文・選択肢・回答種別・企業種別による回答対象の条件を参照。2025年度の設問一覧との比較で、可視化状況の設問が2024年度のみであることも確認（2026年9月確認）
- *4 参考：IPA「ソフトウェア開発関連調査」（https://www.ipa.go.jp/digital/software-survey/index.html）。出典：この調査が置かれている調査群の構成と、年度ごとに調査が公開されていることを参照（2026年9月確認）
