ソースコードがない古いシステムは保守できる？判断基準と対処法

「ソースコードがない」とはどういう状態か

ソースコードとは、プログラマーが書いた「プログラムの設計図兼原稿」です。人が読み書きできる形の文章で、これを変換（コンパイル）したものが、普段パソコンで起動している実行ファイル（.exe など）になります。

実行ファイルは機械向けの形になっているため、そこから元の原稿をきれいに復元することは基本的にできません。料理にたとえると、完成した料理（実行ファイル）は毎日食べられるのに、レシピ（ソースコード）がない状態です。同じ味を出し続けることはできても、「塩を少し減らしたい」「新しい具材を加えたい」となると、途端に難しくなります。

よくある「ない」パターン

• 開発会社が廃業・連絡不能：個人事業主や小さな開発会社に依頼していたケースで多く見られます。
• 契約上、納品物に含まれていなかった：実行ファイルだけ納品され、ソースは開発会社が持っている（持っていた）状態です。
• 社内で作ったが担当者が退職：元担当者のパソコンの中にしかなく、パソコンごと廃棄されていることもあります。
• パッケージソフトの独自カスタマイズ部分：本体はメーカー製品で、自社向けに追加した部分だけ行方が分からないケースです。

製造業の生産管理、卸売業の受発注、クリーニング店の受付・顧客管理など、業務の中心にあるシステムほど「長く問題なく動いてきた」ために、誰もソースの所在を気にしてこなかった、というのが典型的な経緯です。

諦める前に「本当にないのか」を探す

相談を受けて調べてみると、実はソースコードが見つかることも少なくありません。作り直しの判断をする前に、次の場所を一通り確認してください。

Access・Excelで作られている場合

Microsoft Access（拡張子 .mdb / .accdb）や Excel マクロ（.xlsm / .xls）で作られたシステムは、ファイルの中にプログラム（VBA）がそのまま入っています。つまり「ソースがない」と思っていたが、実はファイルそのものがソースだったというケースです。

ただし、Access の .mde / .accde 形式は編集できないように変換されたもので、元になった .mdb / .accdb がないと中身を直せません。また、VBA にパスワードがかかっていて開けないこともあります。この場合も、変換前のファイルが社内のどこかに残っていないか探す価値があります。

ソースコードがなくてもできること・難しいこと

探しても見つからなかった場合、ソースなしで何ができるのかを整理しておきましょう。大まかには次のとおりです。

作業	ソースなしでの可否	補足
今のまま動かし続ける	できる	動作環境（OS・パソコン）が変わらない限りは動きます
データのバックアップ・取り出し	多くの場合できる	データベースやファイルの形式が分かれば、中身を取り出せることが多いです
別のパソコン・サーバーへの移設	条件付きでできる	必要な部品（ランタイム）や設定が分かれば再現可能。古いOSが必要なら仮想化で対応することもあります
帳票の印字位置の微調整・マスタの追加	ものによる	設定ファイルやデータ側で持っている項目なら変更できる場合があります
画面や機能の追加・計算ロジックの変更	難しい	プログラム本体の変更が必要なため、基本的にはできません
新しいOSへの対応・不具合の修正	難しい	原因がプログラム内部にある場合は手が出せません

つまり、「今の動きを守る」ことはある程度できても、「変える」ことは難しいというのが基本的な考え方です。消費税率の変更やインボイス対応のように、業務ルールの変化に合わせてシステムを変える必要が出たとき、ソースがないことが大きな壁になります。

逆コンパイル（解析）という手段について

実行ファイルから元のプログラムを推測して復元する「逆コンパイル」という技術もあります。ただし、復元のしやすさは開発に使われた言語によって大きく違います。.NET や Java で作られたものは比較的読める形に戻せることがある一方、古い Visual Basic 6.0 や C 言語などで作られたものは、実用的な形に戻すのが難しいことが多いです。また、権利や契約の問題もあるため、実施する前に後述の確認が必要です。

保守を続けるか、作り直すかの判断基準

ソースがないシステムをどうするかは、「技術的にできるか」だけでなく、「業務にとってどれだけ重要か」「この先どれくらい変更が必要か」で決まります。次の表で自社の状況に当てはまる方に印をつけてみてください。

確認項目	当面は延命でよい	置き換えを検討すべき
業務の重要度	止まっても手作業で数日しのげる	止まると出荷・請求・給与が止まる
変更の頻度	この数年、ほとんど変更していない	法改正・取引先の要望で毎年のように変更が必要
動作環境	新しいWindowsでも問題なく動いている	古いOSのパソコンでしか動かない
使う人	使う人数が少なく、操作も限られる	多くの社員が毎日使い、不満や回避策が増えている
データの扱い	データを取り出せる見通しがある	データ形式が不明で、取り出し方も分からない
今後の事業	数年以内に業務自体の見直し予定がある	今の業務を10年先も続ける予定

右側の列に多く当てはまるほど、置き換えを先延ばしにするリスクは大きくなります。特に「古いOSでしか動かない」と「データ形式が不明」が重なっている場合は、パソコンが故障した時点で業務が止まる可能性があるため、優先度を上げて検討してください。

現実的な対処法4つ

判断の結果に応じて、次の4つを組み合わせるのが現実的です。いきなり全部を作り直す必要はありません。

1. 延命する（環境を守る）

今のシステムをできるだけ長く安全に動かすための対策です。データの定期バックアップ、動作に必要な部品や設定の記録、予備機の用意などが中心になります。古いOSが必要な場合は、新しいパソコンやサーバーの中に古いOSを「仮想マシン」として再現し、その中で動かす方法もあります。ただし古いOSはセキュリティ更新が止まっているため、インターネットから切り離すなどの対策を合わせて行います。

2. 仕様を書き出す（見える化する）

ソースがなくても、「どの画面で何を入力し、どの帳票に何が出るか」「データにどんな項目があるか」は、実際に操作し、データを調べることで書き出せます。この作業は作り直すときの設計資料になるだけでなく、担当者が替わったときの引き継ぎ資料にもなります。延命と置き換えのどちらを選ぶ場合でも無駄になりません。

3. 段階的に置き換える

システム全体を一度に作り直すのではなく、変更が多い部分や困っている部分から新しい仕組みに移していく方法です。たとえば「受注入力だけ新しい画面にし、データは既存システムにも連携する」「帳票出力だけ別のツールで作り直す」といった進め方です。費用と業務への影響を分散でき、途中で方針を見直すこともできます。

4. 市販パッケージやクラウドサービスに移行する

販売管理・顧客管理・勤怠管理などは、業種向けのパッケージやクラウドサービスが多数あります。自社独自の業務に強くこだわる必要がなければ、作り直すより早く安く済む場合があります。一方で、業務のやり方をサービス側に合わせる必要が出てくるため、現場の担当者と一緒に比較検討することが大切です。

解析や作り直しの前に確認したい権利と契約

ソースがないシステムを解析したり、そっくりな仕組みを作り直したりする前に、権利関係を確認しておきましょう。

外部の開発会社に作ってもらったプログラムの著作権は、契約で譲渡の取り決めがなければ、原則として作った側（開発会社）に残ります。お金を払って作ってもらったからといって、自社が自由に改変・解析できるとは限りません。契約書に「著作権の帰属」「改変の可否」「解析（リバースエンジニアリング）の禁止」などの条項がないか確認してください。

市販パッケージをカスタマイズしている場合は、メーカーの利用規約で解析が禁止されていることも多くあります。

同じ状況を二度と作らないために

今回の問題を解決したら、次に新しいシステムを作るとき、または今あるシステムの保守を見直すときに、同じ状況を繰り返さないための備えをしておきましょう。

ソースコードは「システムを将来も自分たちの手で守るための鍵」です。今動いているシステムについても、ソースがあるかどうかを一度確認しておくだけで、いざというときの選択肢が大きく変わります。