仕様書がないシステムでも、引継ぎできる場合はあります。ただし、資料がないことだけで可否は決まりません。ソースコード、DB、サーバー、管理アカウント、外部サービス、稼働中の画面など、確認できる資産から現状を調査し、保守や改修に必要な情報をどこまで復元できるかで判断します。
反対に、システムが動いていても、ソースコードや管理権限がなく、契約上の権利も確認できない場合は、引継ぎが難しくなります。先に現在の会社との契約を解除すると、必要な資産を受け取れないまま連絡経路を失う可能性もあります。
重要なのは、「仕様書がないから無理」「画面が動くから大丈夫」と即断しないことです。本記事では、仕様書がないシステムの引継ぎ可否を判断するために確認する資産、状態別の難易度、追加調査で分かることと分からないことを整理します。
1. 仕様書がなくても引継ぎできる場合がある
システムの仕様は、設計書だけに存在するわけではありません。稼働中の画面、ソースコード、DB構造、設定ファイル、ログ、サーバー構成、利用者へのヒアリングから、現在の動作や運用を確認できる場合があります。
たとえば、設計書が古くても、ソースコードと本番に近い検証環境があり、担当者が日常業務を説明できれば、現行動作を調べながら保守に必要な情報を整理できます。一方、資料が揃っていても、内容が現状と異なる、ソースコードが最新版ではない、管理アカウントを現行会社だけが持っているといった状態では、そのまま引き継げません。
したがって、引継ぎ可否は「仕様書の有無」ではなく、次の組み合わせで判断します。
- システムを動かすための資産を確保できるか
- 資産を利用・変更する権利を確認できるか
- 現行動作と業務ルールを調査できるか
- 障害時に復旧・切り戻しできるか
- 引継ぎ先が使われている技術と運用を扱えるか
仕様書不足は追加調査で補える場合がありますが、失われた資産や権利を技術調査だけで補うことはできません。
2. 最初に確認するシステム資産と権利
現行会社へ連絡できるうちに、何が自社管理で、何が委託先管理かを確認します。パスワードや秘密鍵そのものを一覧表へ記載するのではなく、対象、管理者、保管場所、引渡し方法を整理します。
アプリケーションとデータ
- 本番で使われている最新版のソースコード
- DB本体、定義、バックアップ、文字コード
- アップロードファイル、画像、帳票テンプレート
- 設定ファイル、環境変数、定期処理
- ビルド・デプロイに必要な手順とツール
- 障害履歴、改修履歴、未解決事項
ソースコードがあっても、依存ライブラリや環境固有の設定がなければ、同じ状態を再現できないことがあります。DBもデータだけでなく、テーブル構造、権限、定期バックアップ、復元方法を確認します。
インフラとアカウント
- サーバーまたはクラウドの契約・管理権限
- ドメイン、DNS、SSL証明書
- メール、ストレージ、監視、バックアップ
- ソース管理、デプロイ、外部API
- SaaS、決済、地図、認証等の外部サービス
- 管理画面、OS、DB、各サービスのアカウント
特に、会社名義で契約していると思っていたサービスが、開発会社や退職者のアカウントに紐づいていることがあります。契約名義を変えられるか、権限を追加できるか、引渡しに制約がないかを確認してください。
契約と利用権
成果物の所有・利用範囲、ソースコードの引渡し、第三者ライセンス、解約時の支援、データ返却、秘密保持を確認します。開発で使用したライブラリや外部サービスは、契約条件により別会社へそのまま移せない場合があります。
保守会社の変更判断や契約解除前の確認は、システム保守会社を変更する際の確認事項で詳しく整理しています。
3. 資産状態別に引継ぎ難易度を判断する
不足しているものによって、必要な調査とリスクは変わります。
仕様書はないが、ソースコードとDBがある
引継ぎを検討しやすい状態です。ソースコードから画面、処理、DBアクセス、外部連携を調べ、稼働中のシステムと照合します。ただし、ソースが本番と一致するか、ビルドできるか、設定や秘密情報が別管理になっていないかを確認する必要があります。
最初から完全な設計書を作り直すのではなく、障害対応や改修に必要な構成図、機能一覧、データ関係、外部連携、運用手順を優先して整備します。
ソースコードはあるが、DBやサーバーへ入れない
プログラムの構造は読めても、実際のデータ、設定、定期処理、ログを確認できません。ソース上の想定と本番の動作が一致しているか判断しにくく、障害原因やデータ不整合の調査範囲が限られます。
現行会社へ、読取権限を含む安全な調査方法、バックアップの受領、設定情報の引渡しを相談します。権限を共有する場合は、必要最小限とし、個人アカウントの使い回しを避けます。
DBや画面は確認できるが、ソースコードがない
データ構造や利用画面から業務の一部は把握できますが、処理条件、例外、外部連携、画面裏のロジックを完全には復元できません。軽微な運用支援はできても、改修や障害修正が難しい場合があります。
実行中のプログラムから元のソースを完全に戻せるとは限りません。ソースを受け取れない場合は、現行環境の維持、必要機能の再開発、データを新システムへ移す案を比較します。
サーバー権限や管理アカウントが不足している
現行環境へ安全に入れなければ、ログ、バックアップ、設定、稼働状況を確認できません。ドメインやDNSを変更できないと、新しい環境を用意しても切り替えられない場合があります。
アカウントを新規発行できる管理者、契約名義、二要素認証の受取先、退職者アカウントの扱いを確認します。認証情報をメールや問い合わせフォームで一括送付するのではなく、引継ぎ先と安全な共有方法を決めてから渡します。
担当者が不在、または現行会社と連絡できない
ヒアリングで補える情報が少なくなるため、画面、コード、DB、ログ、利用部門の操作から現状を推定する割合が増えます。日常運用を知る利用者、請求書や契約書を保管する管理部門、インフラ契約を行った担当者など、社内の情報源を分けて探します。
現行会社と連絡できない場合でも調査できることはありますが、権利や契約の確認は技術調査だけでは解決できません。必要に応じて契約・法務面を別途確認します。
4. 稼働中のシステムから確認できること
追加調査では、いきなり本番環境を変更せず、読み取りと記録を中心に現在地を把握します。
画面と業務フロー
利用者がどの画面で何を入力し、誰が承認し、どの帳票や外部サービスへ結果を渡すかを確認します。利用頻度が低い機能、月末だけ使う処理、担当者が手作業で補っている例外も対象です。
画面一覧だけでは、業務上の重要度は分かりません。「止まると何時間で業務に影響するか」「代替手順があるか」を合わせて整理します。
ソースコードと設定
使用言語、フレームワーク、依存ライブラリ、認証、DB接続、外部API、バッチ処理、ログ出力を確認します。コード量だけで難易度を判断せず、共通化の程度、テストの有無、環境差、変更履歴を見ます。
また、ソース内に認証情報や個人情報が残っていないかも確認対象です。調査のために取得したコードやデータは、閲覧者と保管場所を限定します。
DB、ログ、外部連携
DBでは、主なテーブル、データ量、更新頻度、識別子、文字コード、添付ファイルとの関係を調べます。ログでは、エラー、定期処理、外部連携、過去の障害を確認します。
APIやSaaS連携は、接続先、認証方式、送受信するデータ、実行頻度、失敗時の再処理、契約者を整理します。連携先の仕様変更が、現行システムの不具合要因になっていることもあります。
再現環境とバックアップ
本番へ直接変更を加えずに確認できる検証環境があるかを調べます。なければ、バックアップから隔離環境を用意できるか、機密データを匿名化できるかを検討します。
バックアップファイルが存在するだけでなく、復元手順と復元可能性が重要です。調査時に本番を壊さないこと、問題が起きた際に元へ戻せることを先に確認します。
5. 追加調査でも復元できない情報がある
コードやDBを調べれば、現在実装されている処理はある程度追跡できます。しかし、なぜその仕様になったか、どの例外を許容しているか、利用部門とどの合意をしたかまでは残っていない場合があります。
次の情報は、技術調査だけでは確定しにくい代表例です。
- 画面に存在しない将来要件
- 過去に却下された仕様と理由
- 手作業で補っている業務ルール
- 契約上の責任範囲や口頭合意
- 障害時に許容できる停止時間やデータ損失
- 正しい結果を判断する業務部門の基準
不明点を無理に仕様として確定せず、「確認済み」「推定」「未確認」を分けます。未確認事項の影響が大きい場合は、すぐに全面的な改修を行わず、調査、限定保守、テスト環境での検証から進めます。
6. 引継ぎ先が受入可否を判断するポイント
引継ぎ先は、開発経験があるだけでなく、既存システムを読み解き、動かしながら安全に調査できる必要があります。相談時には、次をどのように確認するか聞いてください。
- 現行資産と契約・権限を最初に棚卸しするか
- ソースと本番の一致をどう確認するか
- DB、サーバー、外部サービスまで調査範囲を分けられるか
- 調査中に本番へ与える影響と、バックアップを説明できるか
- 不明点を推定で埋めず、リスクとして報告するか
- 受入前調査、限定保守、改修、刷新を分けて提案できるか
- 引継ぎ後の監視、障害対応、変更管理を考えられるか
最初の相談だけで「必ず引き継げる」と断定する会社より、確認できている資産と不足情報を分け、追加調査の範囲を説明できる会社の方が比較しやすくなります。
調査の結果、技術や製品のサポート終了が大きな問題だと分かった場合は、保守移管だけでなく延命・更新・刷新を比較します。判断軸はシステムの保守切れ・サポート終了への対応も参照してください。
7. 調査費用と期間を左右する要素
仕様書なし案件の費用と期間は、資料の不足量だけでは決まりません。主に次の条件で調査範囲が変わります。
- システム数、画面数、コード量、DB容量
- 使用言語、フレームワーク、OS、ミドルウェア
- ソース、DB、サーバー、アカウントへのアクセス可否
- 本番と分離した検証環境の有無
- 外部API、SaaS、決済、メール等の連携数
- 障害履歴、未解決不具合、データ不整合
- 利用部門、拠点、権限、業務ルールの数
- 調査中に許容できる本番影響
- 引継ぎ後に必要な保守、改修、監視の範囲
根拠なく一律の価格や期間を示すより、最初に「引継ぎ判断に必要な調査」と「引継ぎ後の作業」を分けることが重要です。調査結果を見て、現行維持、限定改修、部分刷新、リプレイスのどれを見積もるか決めます。
8. 相談前に整理しておく情報
資料がすべて揃っていなくても、あるものとないものを分けることで、追加調査の範囲を判断しやすくなります。相談前に次を整理してください。
- システムの用途、利用者、利用拠点
- 現在困っていることと、引継ぎを検討する理由
- 開発会社、保守会社、インフラ契約先
- 契約書、見積書、納品物一覧の有無
- 仕様書、設計書、操作手順、障害履歴の有無
- ソースコード、DB、バックアップの有無と管理者
- サーバー、クラウド、ドメイン、DNS、SSLの管理者
- 外部API、SaaS、決済、メール等の連携先
- 管理アカウントを新しく発行できる人
- 現行会社へ確認できる期限
- 業務を止められる時間と、代替手順
- 引継ぎ後に希望する保守・改修の範囲
認証情報や顧客データそのものを、最初の問い合わせへ添付する必要はありません。まず、何が存在し、誰が管理しているかを共有し、安全な受渡し方法を確認します。
クラウドシードでは、他社が開発したシステムや、仕様書・資料が不足している状態についても相談を受けます。ただし、資料がなくても必ず引き継げるという意味ではありません。まず現状を確認し、引継ぎ可能性、追加調査、対応範囲を判断します。
