前の開発会社と連絡が取れない・ソースコードがない既存システムを改修・引き継ぐには｜受け入れ判断・費用・進め方
「システムを作ってもらった開発会社と、もう連絡が取れない」「改修したいのに、ソースコードも仕様書も手元にない」——製造業の情シス担当者から、こうしたご相談を数多くいただきます。担当者の退職、開発会社の廃業や事業縮小、当時の担当者不在などが重なると、日々動いている業務システムが誰にも触れない「ブラックボックス」になってしまいます。本記事では、前の開発会社と連絡が取れない・ソースコードがない既存システムを、他社が改修・引き継ぐための現実的な進め方を、現状調査・受け入れ可否の判断基準・費用の考え方・開発会社の選び方まで、順を追って解説します。
目次
想定読者
本記事は、次のような方を想定しています。
- 前の開発会社と連絡が取れず、既存システムの改修を別会社に頼みたい製造業の情シス担当者
- ソースコードや仕様書がない状態でも、システムを引き継げるのか知りたい方
- 属人化・ブラックボックス化したシステムを、これ以上放置できないと感じている方
- 他社への引き継ぎにかかる費用や期間の目安を、依頼前につかんでおきたい方
前の開発会社と連絡が取れない・ソースがない、よくある状況
まず、ご相談の多くが以下のいずれか、あるいは複数に当てはまります。自社の状況がどこに近いかを整理するところから始めましょう。
| よくある状況 | 具体的な症状 | 引き継ぎ上のリスク |
|---|---|---|
| 前の開発会社と連絡不能 | 廃業・事業撤退・担当者退職で問い合わせが返ってこない | 仕様の確認先がなく、改修可否の判断材料が乏しい |
| ソースコード・仕様書がない | 納品物が実行ファイルのみ、設計書が更新されていない | 中身が読めず、影響範囲が読めない |
| 属人化・口伝運用 | 「あの人しか分からない」運用が残る、担当者が退職済み | 改修時に想定外の業務停止を招きやすい |
| 稼働環境が古い | サポート切れOS・古い言語やフレームワークで動作 | セキュリティと改修対応の両面でリスクが高い |
これらに共通するのは、「システムは今日も動いているのに、誰も安全に手を入れられない」という状態です。動いているからこそ、止まったときの影響が大きい——これがブラックボックス化した業務システムの怖さです。生産管理・受発注・在庫といった基幹に近いシステムほど、この問題は経営リスクに直結します。
なお、ここで扱うのは「開発・改修のためにシステムそのもの（ソースコード・仕様）を引き継ぐ」ケースです。運用保守の委託先（保守ベンダー）を変更する場合の引き継ぎは論点が異なるため、そちらは別記事に整理しています。
引き継ぎ前に必ず行う現状調査（リバースエンジニアリングとアセスメント）
ソースコードや仕様書がなくても、いきなり「改修できません」となるわけではありません。多くのケースで、引き継ぐ側の開発会社が現状調査（アセスメント）を行い、システムの中身を可視化するところから始めます。
何を調べるのか
現状調査では、主に次の観点でシステムの実像を把握します。
- 稼働環境：OS・ミドルウェア・データベース・言語やフレームワークのバージョン、サーバーの構成
- データ構造：データベースのテーブル・項目・リレーション、実際に格納されているデータの傾向
- 機能と業務フロー：画面・帳票・バッチ処理が、どの業務のどの場面で使われているか
- 外部連携：他システム・EDI・会計や販売管理などとの連携の有無と方式
- ソースコードの有無と状態：入手できるコードがあるか、なければ実行環境から何を復元できるか
ソースコードがない場合の進め方
ソースコードそのものが手に入らない場合でも、次のような手がかりからシステムの挙動を推定できます。
- サーバー上の実行ファイルや設定ファイルを調査する
- データベースの構造と実データから、業務ルールを逆算する
- 実際の画面操作・帳票出力を観察し、入出力の対応を記録する
- 現場の担当者へのヒアリングで、仕様書に残っていない運用ルールを補完する
この作業を通じて、「仕様書の代わりになる現状ドキュメント」を新たに作り直すのが現状調査のゴールです。ここで得た資料が、以降の改修・引き継ぎすべての土台になります。逆に、この工程を省いて見積もりだけ急ぐと、着手後に想定外が続出し、結局やり直しになりがちです。
「引き継げるシステム」と「引き継げないシステム」を分ける受け入れ判断基準
現状調査の結果を踏まえて、引き継ぐ側は「このシステムを受け入れられるか」を判断します。依頼する側も、あらかじめ判断のものさしを知っておくと、話がスムーズです。
| 判断項目 | 引き継ぎやすい | 引き継ぎが難しい |
|---|---|---|
| 稼働環境 | サポート内のOS・一般的な言語で動作 | サポート切れ・特殊な独自環境に依存 |
| ソース・資料 | 一部でもソースや設計資料が残る | 実行ファイルのみで復元手段が乏しい |
| データ構造 | テーブル設計が整理され追える | 命名も構造も不規則で解読困難 |
| 改修範囲 | 部分改修・機能追加で足りる | 全面的な作り替えに近い規模 |
| 業務知識 | 現場に運用を知る人が残っている | 知る人が誰もいない完全ブラックボックス |
多くの案件では、上の表の「難しい」側にいくつか該当していても、現状調査さえきちんと行えば引き継ぎは可能です。判断の分かれ目になるのは、「部分改修で延命すべきか、作り替え（リプレイス）に踏み切るべきか」という点です。
一般的には、以下のような場合はリプレイスを含めて検討したほうが結果的に安く済むことがあります。
- 稼働環境がサポート切れで、そもそも安全に動かし続けられない
- 改修のたびに調査コストがかさみ、部分改修の費用対効果が悪い
- 今後も機能追加を続ける予定で、拡張性の低い構造がボトルネックになる
「まず引き継いで延命し、並行して次のシステムを検討する」という二段構えが現実的な場合も多くあります。判断を誤らないためにも、リプレイスで失敗しやすいポイントは事前に押さえておきましょう。
ソースコードがない・前の会社と連絡が取れないシステムでも、まずは現状調査から相談できます。
改修・引き継ぎの進め方
受け入れが可能と判断できたら、実際の改修・引き継ぎに進みます。ブラックボックス化したシステムを扱うときは、「一気に触らない」「本番と切り離して検証する」が鉄則です。おおまかな流れは次のとおりです。
- 現状調査・アセスメント：前章までの内容を整理し、現状ドキュメントを作成する
- 改修範囲と優先順位の決定：今すぐ直す点・延命でよい点・作り替える点を切り分ける
- 検証環境の構築：本番と切り離した環境を用意し、そこで改修と動作確認を行う
- 段階的な改修：影響範囲の小さい箇所から着手し、都度テストして問題を早期に発見する
- 並行運用・切り替え：現行と新しい状態を並行させ、問題がないことを確認してから切り替える
- ドキュメントの整備と引き継ぎ：復元・作成した資料を納品物として残し、以後の運用に備える
このプロセスで特に重要なのが、最後の「ドキュメントの整備」です。せっかく現状調査で中身を可視化しても、それを資料として残さなければ、数年後に再びブラックボックス化してしまいます。今回の引き継ぎを「二度と同じ問題を起こさない」機会と捉え、設計資料・データ定義・運用手順を残せる開発会社を選ぶことが、長期的なコスト削減につながります。
あわせて、今後は特定の一社に過度に依存しない体制づくりも意識しておきたいところです。
費用の考え方と、引き継ぎを頼む開発会社の選び方
費用の考え方
他社が作ったシステムの引き継ぎ・改修費用は、新規開発と違い「調査費」がかかるのが大きな特徴です。費用は主に次の要素で構成されます。
| 費用の内訳 | 内容 | 変動要因 |
|---|---|---|
| 現状調査・アセスメント費 | 中身を可視化し、改修可否を判断する費用 | 資料の有無・システムの複雑さ |
| 改修・開発費 | 実際の修正・機能追加・作り替えの費用 | 改修範囲と規模 |
| 検証・テスト費 | 検証環境の構築と動作確認の費用 | 影響範囲の広さ |
| ドキュメント整備費 | 復元した仕様書・運用手順の作成費用 | 残す資料の範囲 |
ポイントは、いきなり全体の改修費を見積もろうとしないことです。ソースも資料もない状態では、正確な見積もりは誰にも出せません。そのため、まず現状調査だけを切り出して依頼し、「調査結果を踏まえて改修の見積もりを出す」二段階で進めるのが、双方にとって安全で無駄がありません。調査なしに「一式いくら」で請け負う会社には、着手後の追加費用リスクがある点に注意してください。
費用の絶対額は、システムの規模・複雑さ・資料の有無によって大きく変わるため、相場を一律に示すことは困難です。同じ「改修」でも、一部の画面を直すだけのケースと、全面的な作り替えに近いケースとでは、必要な工数がまったく異なります。だからこそ、現状調査で範囲と難易度を可視化したうえで見積もるというプロセスが、結果的に費用の予見性を高めます。調査費そのものは、その後の改修費の妥当性を判断するための投資と考えるとよいでしょう。あわせて、今回直す範囲・当面は延命でよい範囲・将来的に作り替える範囲を切り分けておくと、初期費用の集中を避けられます。
引き継ぎを頼む開発会社の選び方
引き継ぎ案件は、新規開発とは求められる力が異なります。次の観点で選ぶと失敗しにくくなります。
- 現状調査（リバースエンジニアリング）の実績があるか：他社製・資料なしのシステムを解読した経験があるか
- 調査と改修を段階的に分けて提案してくれるか：いきなり一括見積もりではなく、調査から始める姿勢があるか
- 幅広い技術・古い環境に対応できるか：特定の言語や新しい技術だけでなく、レガシーな環境も扱えるか
- ドキュメントを残す前提で進めてくれるか：引き継ぎ後にブラックボックス化を繰り返さない体制か
- 製造業の業務理解があるか：生産・受発注・在庫など、現場業務の文脈を踏まえて会話できるか
c3index は、製造業のお客様の既存システムについて、他社が開発したものを含めた引き継ぎ・改修をご支援しています。「作った会社と連絡が取れない」「中身が分からない」といった状態からでも、現状調査を起点に、改修・延命・作り替えのいずれが最適かを一緒に見極めてご支援します。
よくある質問
Q. ソースコードが本当に一切ない場合でも、改修は可能ですか？
A. 可能なケースが多くあります。ソースコードがなくても、稼働している実行環境・データベースの構造・実際の画面や帳票の挙動、そして現場担当者へのヒアリングから、システムの仕様を相当程度まで復元できます。まずは現状調査を行い、「どこまで可視化できるか」「安全に改修できる範囲はどこか」を見極めることから始めます。
Q. 前の開発会社と連絡が取れなくても、法律的に他社が改修して問題ありませんか？
A. 一般的に、自社の業務のために発注して納品を受けたシステムを改修すること自体は、多くの場合で実務上進められます。ただし契約内容によっては著作権や改変の扱いに注意が必要なケースもあるため、当時の契約書が残っていれば確認しておくと安心です。判断に迷う場合は、契約状況もあわせてご相談ください。
Q. 引き継ぎにはどのくらいの期間がかかりますか？
A. システムの規模と複雑さによりますが、現状調査に数週間、その後の改修は範囲に応じて変わります。資料が全くない大規模なシステムほど調査に時間がかかります。まず調査工程だけを先に進め、その結果を踏まえて改修の期間を見積もる進め方が現実的です。
Q. 費用を抑えるにはどうすればよいですか？
A. 最も効くのは、「調査を先に切り出し、改修範囲を絞り込む」ことです。全体を一度に作り替えるのではなく、今すぐ直すべき点・当面は延命でよい点を切り分けることで、初期費用を抑えられます。あわせて、今回の引き継ぎでドキュメントを整備しておくと、次回以降の改修コストが大きく下がります。
Q. 引き継いだあと、また同じようにブラックボックス化しませんか？
A. 引き継ぎ時に現状ドキュメント・データ定義・運用手順を残し、特定の一社や一人に依存しない体制を整えることで、再発を防げます。ドキュメントを納品物として残すことを前提に進めてくれる開発会社を選ぶことが、長期的な安心につながります。
まとめ
前の開発会社と連絡が取れない・ソースコードがない既存システムでも、正しい手順を踏めば改修・引き継ぎは十分に可能です。要点を整理します。
- 動いているのに誰も触れない「ブラックボックス化」は、業務停止リスクに直結する
- ソースや資料がなくても、現状調査（リバースエンジニアリング）で中身は可視化できる
- 受け入れ可否は「稼働環境・資料・データ構造・改修範囲・業務知識」で判断する
- 進め方の鉄則は「一気に触らない・検証環境で確認する・ドキュメントを残す」
- 費用は「調査を先に切り出す二段階」で見積もると無駄がなく安全
- 開発会社は、現状調査の実績とドキュメントを残す姿勢で選ぶ
ブラックボックス化したシステムは、放置するほど調査コストもリスクも膨らみます。連絡が取れない・中身が分からない今の状態こそ、早めに専門家へ相談する価値があります。
c3index は、製造業の基幹システム・保守・システム改修を専門とするシステム会社です。他社が開発したシステム、ソースコードや仕様書がないシステムの引き継ぎ・改修も、現状調査から運用定着まで一貫してご支援します。「作った会社と連絡が取れない」「中身が分からず手が付けられない」といった状態でも、まずはお気軽にお問い合わせください。
