ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順

「開発した会社がもう存在しない」「作った担当者が退職して連絡が取れない」「サーバーの中に実行ファイルとデータベースはあるが、ソースコードも仕様書も見つからない」── 中小企業の業務システムの相談で、決して珍しくない状況です。それでもシステムは今日も動いていて、業務はそれに依存しています。

この状態で最悪の選択は、「よく分からないから」と手探りの改修や思いつきの環境変更を始めてしまうことです。ソースコードがないシステムは、壊れたときに直せる保証がありません。一方で、「何もできない、全面再構築しかない」と最初から結論を出すのも早計です。仕様書がなくても仕様を復元する手段はあり、ソースコードがなくても中身を読める場合があります。この記事では、何もない状態から運用・保守を成立させるまでの手順を、実務の順番どおりに整理します。

1. まず結論

• 最初にやるべきは改修ではなく「現状の保全」です。動いている本番環境そのものが最重要資産です。ディスクイメージのバックアップ(Disk2vhdによる仮想マシン化など)とデータベースのバックアップを取得し、復元できることまで確認してから次に進みます。¹
• 仕様書がなくても、仕様は復元できます。業務利用者へのヒアリング、画面・帳票、データベーススキーマ、ログ、そしてProcess Monitorによる実挙動の観察が主な材料です。²
• ソースコードの復元可能性は、技術スタックで大きく異なります。.NET製ならILSpy等の逆コンパイラでかなり読める一方、VB6やC++などネイティブコードの復元は現実的には期待できません。³⁴
• 逆コンパイルには法的な論点があります。著作権法第30条の4により調査解析目的の利用は原則許容されると整理されていますが、契約(使用許諾条項)の確認は必須です。⁵
• 「完全に理解してから」を待たないことです。止まったら業務が止まる箇所と、変更の必要が近い箇所から優先的に把握し、変更は小さく一つずつ、戻せる形で行います。
• 保守契約は準委任が基本です。中身の分からないシステムの調査に完成責任(請負)は約束できません。調査フェーズと改修フェーズを分けて契約します。

2. なぜ「何もない」状態が生まれるのか

対処を考える前に、自社がどのパターンなのかを確認しておくと、残っている手がかりの見当が付きます。

最後のパターンは見落とされがちですが、実質的には「ソースがない」のと同じ扱いが必要です。古いソースを正として改修し、実は本番の実行ファイルに数年分の修正が入っていた、という事故は典型的な失敗例です。ソースが見つかった場合も、ビルドして本番の実行ファイルと突き合わせるまでは信用しないでください。

いずれのパターンでも、まず契約書・納品書・検収書を探すことには価値があります。著作権の帰属やソースコードの納品義務が書かれていれば、その後の交渉や法的な整理の土台になります。

3. 最初の一週間でやること ── 現状の保全と棚卸し

3.1 変更の凍結

調査が終わるまで、対象のサーバー・端末には手を入れないのが原則です。「とりあえずOSを更新しよう」「使っていなさそうなファイルを整理しよう」が命取りになります。ソースコードがない以上、壊れたときに「直す」という選択肢がないからです。自動更新(Windows Update、ウイルス対策ソフトの動作変更)が勝手に環境を変えないよう、更新の適用タイミングを管理下に置くことも検討します。

3.2 バックアップ ── 環境そのものを資産として複製する

ファイル単位のバックアップだけでは不十分です。この種のシステムは、OS設定・レジストリ・ランタイム・配置場所のすべてが「動いている理由」の一部である可能性があるため、ディスクイメージ全体を保全します。

実務でよく使うのはSysinternalsのDisk2vhdです。稼働中のシステムをオンラインのままボリュームスナップショット(VSS)で一貫性のあるVHD/VHDXに変換でき、Hyper-V上の仮想マシンとして起動する検証環境の土台になります。¹ 物理サーバーの老朽化対策と検証環境の確保を一度に進められるのが利点です(なお、OEMライセンスのWindowsは仮想環境への移行がライセンス上認められない場合があるため、ライセンス形態の確認は必要です¹)。

あわせて、データベースはDBMS標準の手段でバックアップを取得します。そして最も重要なのは、バックアップから実際に復元し、起動することを確認することです。復元テストをしていないバックアップは、あるつもりの保険にすぎません。ただし、復元したイメージには本番の接続設定やスケジュールタスクがそのまま残っているため、起動確認は必ずネットワークから隔離した状態で行ってください(詳しくは第7章)。うっかり接続したまま起動すると、検証のつもりの環境が本番のデータベースや連携先を更新してしまいます。

3.3 棚卸し ── 何が動いているのかを一覧にする

次に、システムの構成要素を機械的に洗い出します。ここはセンスではなく網羅性の作業です。

設定ファイルや出力先が「どこにあるか分からない」場合は、Process Monitorでプロセスのファイル・レジストリアクセスを観測するのが早道です。アプリケーションが実際に読み書きしているパスがそのまま一覧になります。²

4. 仕様書がなくても仕様は復元できる

棚卸しで「何があるか」が分かったら、次は「何をしているか」の復元です。材料は揃っています。

• 業務利用者へのヒアリング ── 最大の仕様書は、毎日そのシステムを使っている人の頭の中です。日次・月次・年次の業務の流れに沿って、どの画面で何を入力し、何が出てくるかを聞き取ります。特に年次処理(決算、棚卸し、年度更新)は担当者も忘れていることがあり、引き継ぎ後の初回に事故が起きやすいポイントです。
• 画面と帳票 ── 全画面・全帳票をスクリーンショットと現物サンプルで台帳化します。入力項目と出力項目の対応関係だけでも、処理の骨格はかなり見えてきます。
• データベーススキーマとデータ ── テーブル定義、制約、コード値の実データは、業務ルールの化石です。「このフラグの値は3種類しか使われていない」といった観察が、画面からは見えない仕様を教えてくれます。
• ログとイベントログ ── アプリケーション独自のログがあれば処理の流れが、Windowsイベントログからは過去のエラー傾向が読み取れます。
• 実挙動の観測 ── Process Monitorでファイル・レジストリ・ネットワークのアクセスを記録すれば、「月末のこの処理は、この共有フォルダーのCSVを読んで、このデータベースサーバーと通信している」という入出力の対応関係を、ソースコードなしで裏付けできます。² ただしProcess Monitorで分かるのは通信の相手先までで、どのテーブルがどう更新されたかまでは見えません。そこから先はDBMS側のトレース・監査機能(SQL Serverの拡張イベント等)や、処理の前後でデータベースの内容を突き合わせる方法で特定します。

ここで重要なのは、全機能を均等に文書化しようとしないことです。目的は百科事典ではなく運用の継続なので、「止まったら業務が止まる処理」「エラーが出ている処理」「近々変更が必要になる箇所」から優先して、調べた範囲を台帳に積み上げていきます。

5. ソースコードがない場合に、技術的に何ができるか

「中身を読む」ことがどこまで期待できるかは、システムが何で作られているかでほぼ決まります。実行ファイルのプロパティやDLL構成から技術スタックを推定したうえで、期待値を設定してください。

通常のIL形式で配置された.NET製アプリの場合は状況がかなり良く、逆コンパイルで得られるC#コードは処理の理解には十分実用的です。ただし公式ドキュメントも明記しているとおり、コメント・ローカル変数名・空白などコンパイル時に不要な情報は失われており、元のソースコードの代替ではなく「動きを理解するための資料」と位置付けるべきです。³ また例外もあります。難読化(オブファスケーション)が施されている場合は解読の難易度が大きく上がりますし、Native AOTで発行されたバイナリはILを含まないため、「.NET製だから読める」という期待は成り立ちません。技術スタックの見立てでは、開発言語だけでなく配置形式まで含めて確認してください。

実行ファイルと一緒にPDB(シンボルファイル)が残っていれば、関数名や(埋め込みソースがあれば)ソースそのものまで復元できる場合があります。何が入っていて何が期待できるかは「PDB(プログラムデータベース)とは何か」で整理しています。

法的な留意点 ── 逆コンパイルは「調べてから」

技術的にできることと、やってよいことは別です。逆コンパイルを含むリバースエンジニアリングには著作権法上の論点があり、平成30年(2018年)改正で新設された著作権法第30条の4(著作物に表現された思想又は感情の享受を目的としない利用)により、プログラムの調査解析を目的とする複製・翻案は必要と認められる限度で原則として許容されると整理されています。ただし条文には「著作権者の利益を不当に害することとなる場合は、この限りでない」というただし書があり、たとえば解析結果を使って競合製品を作るような場合は別の評価になり得ます。⁵

また、パッケージソフトや納品物の使用許諾契約に解析禁止条項が含まれている場合、その効力をどう考えるかという契約上の論点も残ります。実施前に、対象ソフトのライセンス条項と当時の開発委託契約(著作権の帰属条項)を確認し、迷う場合は弁護士に相談してください。自社に著作権が帰属する納品物であれば、この問題は大幅にシンプルになります。契約書の読み方については「受託開発・運用保守の契約はどう結ぶべきか」も参考にしてください。

6. 延命か、包むか、作り直すか

調査で得られた理解度と業務側の事情が揃ったら、方針を決めます。ここでも「全面再構築ありき」でも「塩漬けありき」でもなく、判断表で整理します。

判断軸は、残存利用年数、変更要望の頻度と偏り、止まったときの業務影響、そして調査で復元できた理解度の4つです。理解度が低いまま全面再構築に進むと、旧システムの「誰も説明できないが業務上は正しい挙動」を取りこぼします。再構築を選ぶ場合も、第4章で復元した仕様の台帳がそのまま要件定義の下敷きになるため、調査への投資は無駄になりません。移行時は新旧システムを一定期間並行稼働させ、同じ入力に対する出力(帳票・集計・ファイル)を機械的に突き合わせるのが定石です。

なお、VB6やAccessといった具体的な技術ごとの延命・移行判断は「VB6 / Access業務アプリの延命と移行」で、社内WebシステムのIEモード依存については「IEモード依存システムの脱却ガイド」で詳しく扱っています。

7. 引き継いだ後の運用・保守体制

方針が「当面は運用を続ける」である場合(実際にはほとんどのケースがそうです)、次の型を守ると事故が減ります。

• 検証環境を持つ ── ただし初回起動は必ずネットワークから隔離する ── 3.2で作ったディスクイメージを仮想マシンとして起動すれば、本番と同じ構成の検証環境になります。ただしこのイメージには本番の接続文字列・認証情報・スケジュールタスク・自動起動サービスがそのまま残っています。ネットワークに接続したまま起動すると、夜間バッチが二重に走って本番データベースを更新したり、メールが再送されたり、外部APIを呼び出したりしかねません。初回起動は必ず仮想NICを外すか隔離ネットワークで行い、スケジュールタスクと自動起動サービスを止め、接続先を検証用に書き換えてから、必要な範囲だけ接続を許可します。
• 変更は一つずつ、戻せる形で ── 設定変更もWindows Updateの適用も、一度に一つ。変更前のイメージを残し、問題が出たら切り戻します。何を変えたかの記録(変更台帳)をセットにします。
• ドキュメントは「調べたことの副産物」として育てる ── 完璧な仕様書を書くプロジェクトを立てるのではなく、障害対応や改修のたびに分かったことを台帳に追記します。1年も運用すれば、業務上重要な箇所から順にドキュメントが揃っていきます。
• 監視を仕込む ── 死活監視、ディスク残量、エラーログ、そして「いつも出力されるはずのファイルが出ていない」の検知。ブラックボックスの内部は見えなくても、入口と出口は監視できます。
• 契約は調査と改修を分ける ── 外部に保守を依頼する場合、中身の分からないシステムの調査に完成責任は約束できないため、調査・保守は準委任、仕様が固まった個別改修は請負(または成果完成型準委任)と、フェーズで契約を分けるのが健全です。

8. まとめ

• ソースコードも仕様書もないシステムを引き継いだら、改修より先に現状の保全です。ディスクイメージ(Disk2vhd等)とDBのバックアップを取得し、復元できることまで確認します。
• 実行ファイル・自動起動・スケジュールタスク・設定・連携先・アカウントを棚卸しし、システムの全体像を一覧にします。
• 仕様は、利用者ヒアリング・画面・帳票・DBスキーマ・ログ・Process Monitorでの実挙動観測から復元できます。全機能ではなく、業務影響の大きい箇所から優先します。
• 中身の復元可能性は技術スタック次第です。.NETは逆コンパイルでかなり読めますが、元ソースの代替ではありません。実施前に著作権法第30条の4の趣旨とライセンス条項・契約書を確認します。
• 方針は「延命・包む・部分再構築・全面再構築」を、残存利用年数・変更頻度・業務影響・理解度で判断します。調査で復元した仕様は、どの道を選んでも資産になります。
• 運用フェーズでは、検証環境・一つずつの変更・変更台帳・入口と出口の監視・準委任での契約が基本の型です。

関連記事

• PDB(プログラムデータベース)とは何か ── デバッグ情報・シンボル・Source Linkを理解する
• Process Monitor実践ガイド
• VB6 / Access業務アプリの延命と移行 ── 残す・包む・置き換えるの判断表
• IEモード依存システムの脱却ガイド
• 受託開発・運用保守の契約はどう結ぶべきか ── IPA「モデル取引・契約書」に学ぶ準委任と請負の使い分け
• Windowsアプリ 外注・受託開発を依頼する前に整理したいこと

関連する相談領域

合同会社小村ソフトでは、ソースコードや仕様書が残っていない業務システムの現状調査(実行ファイル・データベース・実挙動の解析)、挙動からの仕様復元、延命・移行方針の整理、その後の運用・保守までを扱っています。「何から手を付ければいいか分からない」という段階からのご相談も歓迎です。

• 既存資産活用・移行支援
• 既存Windowsソフトの改修・保守
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

ソースコードがないシステムでも保守や改修を依頼できますか？

依頼できます。ただし通常の保守とは進め方が変わります。まず動いている環境の保全とバックアップを行ったうえで、画面・帳票・データベース・ログ・実行ファイルの解析から仕様を復元する調査フェーズを設け、そこで得られた理解の範囲で改修や周辺機能の開発に進むのが現実的です。調査は成果を事前に約束できない性質の作業なので、完成責任を負う請負ではなく準委任契約で進めるのが一般的です。

実行ファイルの逆コンパイル(リバースエンジニアリング)は違法ではないですか？

一律に違法ではありません。平成30年(2018年)改正の著作権法で新設された第30条の4により、プログラムの調査解析のような「著作物に表現された思想又は感情の享受を目的としない利用」は、必要と認められる限度で原則として許容されると整理されています。ただし「著作権者の利益を不当に害することとなる場合」は除外されるほか、使用許諾契約で解析が禁止されている場合の扱いという論点も残ります。実施前にライセンス条項と開発委託時の契約書を確認し、判断に迷う場合は弁護士等の専門家に相談してください。

開発会社が倒産してソースコードが手に入りません。どうすればよいですか？

まず過去の契約書と納品物を確認してください。開発委託契約で著作権やソースコードの帰属・納品が定められていれば、入手や利用の根拠になります。連絡が取れる関係者がいれば入手交渉の余地も探る価値があります。ただし実務では「結局手に入らなかった」で止まらないことが重要で、入手できない前提で動いている環境の保全・バックアップと、挙動やデータベースからの仕様復元を並行して始めることをおすすめします。

仕様書がないシステムは、何から手を付ければよいですか？

改修より先に、まず現状の保全です。動いている本番環境のディスクイメージとデータベースのバックアップを取得し、復元できることを確認します。次に実行ファイル・自動起動・スケジュールタスク・設定・連携先・アカウントの棚卸しを行い、システムの全体像を一覧にします。そのうえで、業務利用者へのヒアリングと画面・帳票・データベーススキーマの観察から、業務上重要な箇所に絞って仕様を文書化していくのが定石です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。