仕様書がないシステムを改修・移行するには｜現状調査（リバースエンジニアリング）の進め方と期間・費用の目安、調査後の選択肢
「システムを改修したいが、仕様書が見当たらない」「作った担当者も開発会社もいなくなり、中身が誰にもわからない」。長く使っている業務システムでは、こうした状況が珍しくありません。仕様書がないまま改修や移行を進めると、思わぬ不具合や、データの取りこぼしにつながります。
この記事では、仕様書がないシステムを改修・移行するための現状調査（リバースエンジニアリング）について、調べる対象、進め方、期間と費用の目安、ソースコードが手元にない場合の対応、調査後の選択肢、そして同じことを繰り返さないための資料の残し方までを解説します。
- 仕様書がないシステムでも、画面・データベース・ソースコード・サーバー・連携・業務の6つを調べれば、改修や移行に必要な情報は復元できます。
- 現状調査の期間と費用は規模次第で、小規模なら数週間・数十万円程度から、大規模では数か月・1,000万円を超えることもあります（目安）。
- ソースコードが手元にない場合は、まず元の開発会社や契約書で権利と所在を確認し、入手できなければ画面とデータから仕様を起こして作り直す方法を検討します。
- 調査の成果物は次の改修・移行の土台です。調査後も更新し続ける仕組みを作りましょう。
目次
仕様書がないシステムの現状調査とは
仕様書がないシステムの現状調査とは、動いているシステムやソースコード、データ、業務の実態から、システムが何をしているのかを読み解き、改修や移行に必要な資料を作り直す作業です。完成品から設計を逆にたどることから、「リバースエンジニアリング」とも呼ばれます。
ここでいう仕様書には、機能の一覧、画面や帳票の設計書、データベースの設計書（テーブル定義書）、外部連携の仕様、サーバー構成図、運用手順書などが含まれます。どれか一つでも欠けていれば、その部分は調査で補う必要があります。
なぜ仕様書がなくなるのか
仕様書は、最初から作られていないこともあれば、作られたあとに失われることもあります。よくある原因は次のとおりです。
- 最初から作られていない：社内の担当者が自作した、小規模な開発で設計書を省いた、納品物に設計書を含めない契約だった、といったケースです
- 改修のたびに更新されなかった：最初の設計書はあっても、その後の改修が反映されず、現状と合わなくなっています
- 担当者の退職・異動：資料の保管場所を知る人や、仕様を覚えていた人がいなくなります
- 開発会社の撤退・交代：資料が開発会社の手元にしかなく、契約の終了とともに引き渡されないままになります
経済産業省の「DXレポート」（2018年）も、既存システムの調査に時間がかかる理由として「ドキュメントが整備されていない」ことを挙げ、有識者の退職によるノウハウの喪失や、システムのブラックボックス化をレガシーシステムの問題として指摘しています。
2025年5月に経済産業省が公表した「レガシーシステムモダン化委員会総括レポート」でも、ユーザー企業に対して、自社のIT資産を可視化することが求められています。現状調査は、その第一歩になる作業です。
仕様書がないまま改修・移行するリスク
仕様書がない状態で作業を進めると、次のようなリスクがあります。
- 改修の影響を見落とす：直した箇所とは別の画面や帳票、夜間の自動処理が動かなくなることがあります
- 移行で機能が漏れる：誰も意識していなかった計算ルールや例外処理が、新しいシステムに引き継がれないことがあります
- データを正しく移せない：項目の意味やコードの値が分からず、移行後に数字が合わなくなります
- 見積もりが膨らむ・ぶれる：開発会社は不明な部分をリスクとして見込むため、見積もりが高くなったり、会社によって大きく違ったりします
- 障害時に原因を特定できない：止まったときに、どこを見ればよいか分からず、復旧に時間がかかります
こうしたリスクを減らすために、改修や移行の前に現状調査の工程を独立して設けるのが一般的です。調査をせずに「動いているものと同じものを作ってください」と依頼すると、後から追加費用や手戻りが発生しやすくなります。
現状調査で調べるもの
現状調査では、システムを6つの方向から調べ、それぞれの結果を突き合わせて全体像を組み立てます。
現状調査の対象と作る資料
| 調べる対象 | 主な調査内容 | 作る資料の例 |
|---|---|---|
| 画面・帳票 | すべての画面を操作し、入力項目、ボタンの動き、エラー表示、出力される帳票を記録する | 画面一覧、画面遷移図、帳票一覧 |
| データベース | テーブルと項目、データの件数、コードの値の意味、テーブル同士の関係を調べる | テーブル定義書、ER図（データの関係図）、コード一覧 |
| ソースコード | 処理の流れ、計算ルール、使っている言語・ライブラリのバージョン、夜間処理を読み解く | 機能一覧、処理の概要書、技術要素の一覧 |
| サーバー・環境 | OS・ミドルウェアのバージョン、サーバーの構成、バックアップ、定期実行の設定、アカウントを確認する | 環境構成図、サポート期限の一覧、アカウント一覧 |
| 外部連携 | 会計ソフトや取引先とのファイル・APIのやり取り、タイミング、形式を調べる | 連携一覧、ファイル・データの形式定義 |
| 業務 | 利用部門へのヒアリングで、誰がいつ何に使っているか、システム外の手作業を確認する | 業務フロー図、利用者・権限の一覧 |
特に見落とされやすいのが、業務のヒアリングです。ソースコードからは「何をしているか」は分かっても、「なぜそうしているか」「今も必要か」は分かりません。使われていない機能を見つけられれば、移行の範囲を減らすこともできます。
現状調査の進め方
現状調査は、おおむね次の流れで進めます。
- 目的と範囲を決める改修のためか、移行のためか、保守を引き継ぐためかで、調べる深さが変わります。対象のシステムと期限を決めます
- 手元にあるものを集める古い資料、契約書、見積書、メール、マニュアル、ソースコード、サーバーやクラウドのアカウント情報を集めます
- 調査用の環境を用意する本番に影響を与えないよう、可能であれば本番のコピー環境やデータのバックアップを使って調べます
- 6つの対象を調べる画面・データベース・ソースコード・サーバー・連携を調べ、並行して業務のヒアリングを行います
- 資料にまとめ、確認する調査結果を資料にまとめ、利用部門や担当者に内容が合っているかを確認してもらいます
- 課題と選択肢を整理するサポート切れの技術やセキュリティ上の問題、改修の難しさを整理し、今後の方針を判断する材料にします
期間と費用の目安
現状調査の費用は、ほとんどがエンジニアの作業時間です。人月単価の目安（60万〜160万円）をもとにすると、次のような幅になります。
現状調査の期間・費用の目安
| システムの規模 | 規模の例 | 期間の目安 | 費用の目安 |
|---|---|---|---|
| 小規模 | 画面が数十程度、利用部門が1つ、連携が少ない | 2週間〜1か月程度 | 数十万〜200万円程度 |
| 中規模 | 複数の部門で使う、会計や取引先との連携がある | 1〜3か月程度 | 100万〜500万円程度 |
| 大規模 | 基幹システムなど多数の機能と連携があり、複数のサーバーで動く | 3か月〜 | 数百万円〜1,000万円以上 |
費用を抑えるには、目的に必要な範囲に絞ることが効果的です。たとえば、作り直しを前提にするなら、プログラムの細部よりも、業務のルールとデータの意味の把握に重点を置きます。反対に、今のシステムを改修し続けるなら、ソースコードと影響範囲の調査を厚くします。
また、現状調査を改修や移行の見積もりの前に別契約で行うと、その後の見積もりの精度が上がり、複数の会社に同じ条件で見積もりを依頼しやすくなります。
関連記事システム改修の費用相場｜小規模な改修から大規模改修までの種類別の目安と、改修か作り直しかの判断基準・費用を抑えるコツ
ソースコードがない場合の対応
手元にソースコードがない場合は、次の順で対応を検討します。
- 所在を探す：社内のサーバーや古いパソコン、開発会社への問い合わせ、納品時の記録媒体を確認します。サーバー上に残っていることもあります
- 契約と権利を確認する：契約書で、ソースコードの著作権や引き渡しの取り決めを確認します。権利が開発会社にある場合でも、利用や改修の範囲が定められていることがあります
- 元の開発会社に相談する：有償での引き渡しや、改修の協力を依頼できないか相談します
- 画面とデータから仕様を起こす：入手できない場合は、画面の動きとデータベースの中身、業務のヒアリングから仕様を復元し、新しいシステムとして作り直すことを検討します
実行ファイルからプログラムを解析する方法もありますが、契約や著作権の問題が関わるうえ、元のソースコードと同じ形で復元できるわけではありません。権利関係の判断が必要な場合は、弁護士など専門家に確認してください。
関連記事ベンダーロックインとは｜技術・契約・知識の3つの原因と抜け出す手順、契約で防ぐ方法（著作権・ソースコード・名義）
調査後の選択肢と、資料の残し方
現状調査が終わったら、その結果をもとに今後の方針を決めます。主な選択肢は次の3つです。
どれを選ぶ場合でも、調査で作った資料は大切な資産です。次に同じ状況を起こさないために、次の点を決めておきましょう。
- 資料を発注者側で保管する：開発会社の手元だけでなく、自社の共有フォルダやクラウドにも保管します
- 改修のたびに資料を更新する：設計書の更新を、改修の作業範囲と納品物に含めます
- ソースコードを自社管理のリポジトリに置く：ソースコードの保管場所（リポジトリ）を自社名義で用意し、変更の履歴を残します
- アカウントを自社名義にする：サーバー、クラウド、ドメインの契約や管理者アカウントは自社名義にし、一覧にしておきます
- 納品物を契約で決める：設計書やソースコードを納品物として契約書に明記します
関連記事システム開発の成果物一覧｜工程ごとのドキュメントと発注者が受け取るべき納品物
要件定義書や保守契約チェックリストなどをまとめた無料テンプレート集を用意しています。現状調査で分かったことの整理や、次の保守契約で納品物を決めるときにお使いください。
よくある質問
- 仕様書がないシステムでも、改修を引き受けてもらえますか？
- 多くの場合は可能です。ただし、最初に現状調査の工程が必要になるため、仕様書がある場合より費用と期間がかかります。調査を先に行い、その結果をもとに改修の見積もりを出す進め方が一般的です。
- 現状調査だけを依頼することはできますか？
- できます。調査だけを別契約にすると、その結果を使って複数の会社から改修や移行の見積もりを取ることもできます。調査結果の資料を自社のものとして受け取れるよう、契約で納品物を決めておきましょう。
- 社内でできる調査はありますか？
- あります。手元の資料や契約書、アカウント情報を集めること、使っている画面や帳票の一覧を作ること、業務の流れを書き出すことは社内でも進められます。これらがそろっていると、外部に依頼する調査の期間と費用を減らせます。
- 調査にはどれくらい社内の協力が必要ですか？
- 業務のヒアリングや、調査結果の確認に時間をいただきます。利用部門ごとに数回の打ち合わせが入ることが多いため、窓口となる担当者を決めておくとスムーズです。
- 元の開発会社が協力してくれない場合はどうすればよいですか？
- まず契約書で、ソースコードや資料の引き渡しの取り決めを確認します。引き渡しが難しい場合でも、画面やデータベース、業務のヒアリングから仕様を復元することは可能です。権利関係で争いがある場合は、弁護士に相談してください。
まとめ
仕様書がないシステムでも、画面・データベース・ソースコード・サーバー・連携・業務の6つを調べれば、改修や移行に必要な情報を復元できます。期間と費用は規模と目的で大きく変わるため、まず目的を決めて調査範囲を絞ることが大切です。ソースコードがない場合は、契約と権利を確認したうえで、画面とデータから作り直す方法も検討しましょう。調査で作った資料は、自社で保管し、改修のたびに更新することで、同じ問題の再発を防げます。
参考：経済産業省「DXレポート ～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月7日）、経済産業省「レガシーシステムモダン化委員会総括レポート」（2025年5月28日）。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
