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

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

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

1. まず結論

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

この記事は、実務で踏む順番どおりに構成しています。全体像は次のとおりです。

flowchart TD
    A["第3章 保全<br/>変更凍結・ディスクイメージ<br/>DBバックアップと復元確認"] --> B["第3章 棚卸し<br/>実行ファイル・自動起動・タスク<br/>設定・連携先・アカウント"]
    B --> C["第4章 仕様復元<br/>ヒアリング・画面と帳票<br/>DBスキーマ・実挙動の観測"]
    C --> D["第5章 技術的な可否<br/>技術スタックの見立て<br/>逆コンパイルと法的確認"]
    D --> E["第6章 方針決定<br/>延命・包む・部分再構築・全面再構築"]
    E --> F["第7章 運用移行<br/>検証環境・変更台帳・監視・契約"]
    C -.->|"復元した仕様の台帳は<br/>どの方針を選んでも資産になる"| E

図1: 引き継ぎの全体フローと対応する章

工程ごとの所要期間は、システムの規模(画面・帳票・バッチの本数)、技術スタック、業務側からヒアリングに割いてもらえる時間、そして「どこまで分かれば十分とするか」の目標設定で大きく変わるため、着手前に一律の目安を置くことはできません。見積もりの精度を上げる唯一の近道は、第3章の棚卸しを先に終えて対象の本数を数えることです。本数が出るまで仕様復元の期間は見積もれません。裏を返せば、棚卸しは短期間で切り上げるべき工程で、ここを引き延ばすと以降の計画がすべて立たなくなります。

この記事の知識マップ

ソースコードも仕様書もない業務システムを引き継いだ場合、最初にすべきは改修ではなく現状の保全で、Disk2vhdによるディスクイメージ化とVSSを使ったバックアップを取得し、復元できることまで確かめる。次に実行ファイル・自動起動・スケジュールタスクなどをAutorunsやProcess Monitorで棚卸しし、業務利用者へのヒアリングや実挙動の観測から仕様を復元していく。中身の復元可能性は技術スタック次第で、通常のIL形式の.NETアセンブリはILSpyでかなり読める一方、Native AOT発行やVB6は逆コンパイルによる復元が現実的でなく、著作権法第30条の4や使用許諾契約の解析禁止条項も事前に確認する必要がある。中身の分からないシステムの調査は準委任契約で進め、仕様が固まった個別改修だけ請負に切り替えるのが健全な進め方である。

flowchart LR
    accTitle: ソース・仕様書のないシステム引き継ぎの知識マップ
    accDescr: 現状の保全・棚卸し・仕様復元という実務の順序と、技術スタックによる逆コンパイルの可否、著作権法上の留意点、契約形態の選び方の関係を示す図
    legacy_system_handover["ソースコード・仕様書がないシステムの引き継ぎ"]
    environment_preservation["現状の保全"]
    spec_recovery["仕様の復元"]
    disk2vhd["Disk2vhd"]
    vss["VSS(ボリュームシャドウコピーサービス)"]
    asset_inventory["構成要素の棚卸し"]
    autoruns["Autoruns"]
    procmon["Process Monitor(procmon.exe)"]
    user_hearing["業務利用者へのヒアリング"]
    decompilation["逆コンパイル"]
    ilspy["ILSpy"]
    dotnet[".NET(Core以降)"]
    native_aot["Native AOT"]
    vb6["Visual Basic 6.0(VB6)"]
    obfuscation["難読化(オブファスケーション)"]
    pdb["PDB(プログラムデータベース)"]
    copyright_law_article_30_4["著作権法第30条の4"]
    eula_restriction["使用許諾契約(EULA)の解析禁止条項"]
    quasi_mandate_contract["準委任契約"]
    ukeoi_contract["請負契約"]
    legacy_system_handover -->|"前提とする"| environment_preservation
    environment_preservation -.->|"利用する"| disk2vhd
    disk2vhd -->|"利用する"| vss
    legacy_system_handover -->|"前提とする"| asset_inventory
    asset_inventory -.->|"利用する"| autoruns
    asset_inventory -.->|"利用する"| procmon
    legacy_system_handover -->|"前提とする"| spec_recovery
    spec_recovery -->|"利用する"| user_hearing
    spec_recovery -->|"利用する"| procmon
    spec_recovery -.->|"前提とする"| decompilation
    decompilation -.->|"利用する"| ilspy
    decompilation -.->|"前提とする"| dotnet
    decompilation -->|"用いるのは非推奨"| native_aot
    decompilation -->|"用いるのは非推奨"| vb6
    obfuscation -.->|"軽減する"| decompilation
    pdb -.->|"推奨される対応"| decompilation
    decompilation -->|"前提とする"| copyright_law_article_30_4
    eula_restriction -.->|"両立しない"| decompilation
    legacy_system_handover -.->|"前提とする"| quasi_mandate_contract
    quasi_mandate_contract -->|"より先に行うべき"| ukeoi_contract
    environment_preservation -->|"より先に行うべき"| asset_inventory
    asset_inventory -->|"より先に行うべき"| spec_recovery

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

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

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

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

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

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

3.1 変更の凍結

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

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

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

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

Disk2vhdは画面が1枚だけの単純なツールですが、選択を間違えると「起動しないイメージ」ができあがります。次の順で進めてください。¹

1. 出力先を用意する。VHD/VHDXは変換対象のボリューム上にも作成できますが、対象とは別のディスク(外付けドライブやNASなど)に出力するほうが性能が良い、と公式ドキュメントも明記しています。空き容量は、選択するボリュームの使用領域の合計以上を見ておきます。
2. BitLockerを確認する。Disk2vhdはBitLockerが有効なボリュームの変換に非対応です。対象になっている場合は、事前にBitLockerを解除し、復号が完了するまで待ってから実行します。
3. 取り込むボリュームを選ぶ。起動したままのシステムでツールを実行すると、そのシステムのボリューム一覧が表示されます。ここで選んだボリュームが存在するディスクごとに1つのVHDが作られ、パーティション構成は保持される一方、中身が複写されるのは選択したボリュームだけです。したがって、検証起動したいならWindowsが入っているボリューム(通常はC:)と、起動に必要なシステムパーティション(システム予約/EFIシステムパーティション)の両方を選びます。純粋なデータ用ボリュームを外せば、そのぶん容量と時間を節約できます。
4. 必要ならコマンドラインで回す。夜間に流したい場合などは、disk2vhd <ドライブ:> [ドライブ:] ... <出力ファイル> の形でスクリプト化できます。全ボリュームを対象にするなら disk2vhd * e:\backup\snapshot.vhdx のように * を指定します。
5. 検証起動はHyper-Vで行う。Hyper-Vマネージャーで仮想マシンを作成し、できあがったVHDをIDEディスクとして構成に追加します。初回起動時にWindowsが仮想マシンのハードウェアを検出し、イメージ内にドライバーがあれば自動的に導入します。無ければHyper-Vの統合コンポーネントを導入します。
6. 作成元のマシンにアタッチして起動しない。同じシステム上でVHDをアタッチすると、Windowsは元のディスクとの署名衝突を避けるためVHDに新しいディスク署名を割り当てます。起動構成データ(BCD)はディスク署名でディスクを参照しているため、この状態で仮想マシンを起動すると起動ディスクを見つけられずに失敗します。検証起動は必ず別のマシン(Hyper-Vホスト)で行ってください。

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

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

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

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

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

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

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

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

ヒアリングの型 ── 誰に、何を、どう記録するか

「利用者に聞く」は言うのは簡単ですが、聞く相手と質問を決めておかないと雑談で終わります。実務では次の3層に分けて、それぞれ別の時間を取るのが確実です。

質問は毎回同じ項目を使い回します。次の10問を土台にすると、システムをまたいでも使えます。

1. このシステムで、毎日必ず行う操作は何ですか。何時ごろ、何件くらいですか。
2. 月次・年次にだけ行う操作はありますか(締め処理、決算、棚卸し、年度更新など)。前回はいつ、誰が行いましたか。
3. 入力の元になる紙・ファイル・メールは何ですか。どこから来ますか。
4. このシステムが出力するもの(帳票、CSV、外部への送信)は何で、その後どこへ渡りますか。
5. システムが止まったら、業務は何時間まで耐えられますか。そのとき手作業での代替はできますか。
6. 「この操作だけはやってはいけない」という言い伝えはありますか。理由は分かりますか。
7. 現在、手作業で補っていることはありますか(転記、Excelでの再集計、目視チェックなど)。
8. 直近1年でエラーやトラブルはありましたか。どう対処しましたか。
9. 使っていない画面・機能はどれですか。いつから使っていませんか。
10. もし直せるなら、いちばん困っていることは何ですか。

記録の仕方も決めておきます。回答は画面名・帳票名・テーブル名といった固有名詞に紐づけて残すのが要点で、「月末に集計する」ではなく「月次売上集計画面(F050)から売上月報を印刷する」の粒度まで落とすと、第3章の棚卸し表や後のデータベース調査と突き合わせられます。可能なら録音し、その場では固有名詞と操作順のメモに集中してください。5.の回答は第6章の方針判断に、6.と7.の回答は隠れ仕様の在りかを示す手がかりになります。

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

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

先に、この章で使う用語を短く定義しておきます。

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

実行ファイルと一緒に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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。