結論から： システムがまだ動いているなら、まだ時間はあります。選択肢を奪うのはコードの品質ではなく、アクセス権を失うことです。ですから最初にやるべきは引き継ぎ先を探すことではなく、ドメインとホスティングアカウントが自社名義かどうかを確認することです。技術の話はその後で構いません。
他社が開発したシステムを十数件引き継いできました。ご連絡いただく内容はよく似ています。ベンダーから返信が来ない、そのシステムを理解していた唯一のエンジニアが退職した、フォームに項目を 1 つ足したいが誰も触れない。
そしてほぼ毎回、技術に関する資料が手元に何も残っていません。ソースコードもアーキテクチャ図もデプロイ手順もなく、どこでホスティングしているのか請求書から調べることさえあります。残っているのは、まだ動いているサイトと、返信のない連絡先だけです。
今まさにその状況なら、この記事はあなたのために書いています。
まず何をすべきですか？
見積もりを取ることではありません。何が自社名義で残っているかを、この順で確認してください。
- ドメイン：誰の名義で登録されているか、レジストラの管理画面のパスワードが手元にあるか。これを失うのが最も厄介です。技術ではなく所有権移転の手続きになるからです。
- ホスティングまたはクラウドアカウント：AWS、GCP、レンタルサーバーの主アカウントを誰が開設したか。ベンダーが自社アカウントで開設していた場合、購入したつもりのものは借家です。
- コード：どこにあり、読める権限があるか。この段階で「一度も受け取っていなかった」と気づく方は少なくありません。
- データ：バックアップが動いているかと、実際に復元したことがあるかは別の問題です。復元試験をしていないバックアップは、バックアップとは言えません。
上の 2 つが自社名義であれば交渉の余地は十分にあり、依頼先は自由に選べます。欠けている場合は、開発会社を探すより先にそちらを片付けてください。
何も残っていません。もう手遅れですか？
いいえ。技術資料が何も残っていないのは例外ではなく、通常の状態です。
コードとデータベース自体が最も完全なドキュメントであり、アーキテクチャはそこから復元できます。ドキュメントの整備は引き継ぎ作業の一部であって、引き継ぎの前提条件ではありません。
本当に行き詰まるのはコードが入手できない場合であり、コードが読めないこととは難易度がまったく違います。
引き継いだ途端に作り直しを勧められませんか？
いいえ。多くのシステムはそのまま引き継いで保守できますし、段階的に改善することもできます。
作り直しをお勧めするのは、実質的に 1 つの状況だけです。保守が困難で、かつコードが古すぎる場合。 両方が同時に成立している必要があります。
「保守が困難」かどうかは、ご自身でも判断できます。
- フォームに項目を 1 つ足すような小さな変更で、多数のファイルを触ることになる
- 修正するたびに別の箇所が壊れ、1 つ直すと 1 つ出てくる
- 前のベンダーの開発速度が、後半になって目に見えて落ちていた
「古すぎる」はフレームワークや言語のバージョンがまだセキュリティ更新を受けているかどうかで、推測する必要はありません。公式が時期を公開しています。PHP は php.net の Supported Versions、Node.js は Previous Releases、その他の主要なフレームワークは endoflife.date で確認できます。
誰も保守していないバージョンに留まることは、脆弱性が積み上がり続けることを意味します。OWASP はこれを独立したトップ 10 リスクとして挙げており（A06: Vulnerable and Outdated Components）、跨ぐバージョンが増えるため、放置するほど費用は上がります。
逆に言えば、「コードが汚い」ことは作り直しの理由になりません。 汚くても構造が明確なシステムは、見た目よりずっと安く保守できます。作り直しを勧めてくる相手が、必ずしもシステムの都合でそう言っているとは限りません。
引き継ぎ前の調査にいくらかかりますか？
システム規模により US$950 から、1 週間以内に答えをお出しします。ご発注の場合、この費用は全額を充当します。
レポートを販売しているわけではありません。コード、アーキテクチャ、ホスティング、セキュリティを実際に見て、このシステムをそのまま引き継げるのか、作り直すべきかを判断するためのものです。見る前に出す金額は推測にすぎないので、推測ではお見積もりしません。
終わった時点で 3 つが分かります。現在のリスクがどこにあるか、引き継ぎにいくらかかるか、そもそも引き継ぐべきかどうか。他社に依頼すると決めた場合でも、結論はお客様のものです。
引き継ぎ後、通常稼働までどのくらいですか？
調査に約 1 週間、その後が移管です。各種アクセス権の取得、ドキュメントの整備、繰り返し実行できるデプロイ手順の整備を行います。
この期間の長さは技術ではなく、アクセス権がどれだけ早く戻るかで決まります。前のベンダーと連絡が取れる案件は、はるかに速く進みます。
移管が完了すれば通常の保守運用に入り、同じチームが監視、修正、変更を担当します。
その後の保守費用は？
月額の保守運用は US$220 から、システム規模と必要な応答速度によって決まります。実際に見たうえで確定します。
バグ修正だけでなく新しい要件が継続的に発生する場合は、専任チームのほうが月額プランより割安になることが多く、保守はそこに含まれます。
ベンダーを変えても、また同じことが起きませんか？
保証はできませんが、契約時に費用ゼロで防げることが 3 つあります。
- アカウントを自社名義で開設する：クラウド、ドメイン、コードリポジトリを自社アカウントで作成し、ベンダーには共同編集権限のみを渡します。
- 成果物を契約書に明記する：「システム公開」ではなく、ソースコード、データベース、デプロイ手順書として書きます。
- 公開後に誰が保守するのかを、署名前に確認する：多くのトラブルは開発中ではなく、保証期間の終了後に誰も引き継がないことで起きます。
これらを契約に書くのは無料です。後から立て直す費用が、この記事で述べてきたことすべてです。