既存システムのソースコードを別会社へ渡す前に整理しておくこと
- 2 日前
- 読了時間: 11分
既存システムの開発会社を変更するとき、「ソースコードを渡せば引継ぎはできる」と考えがちです。
しかし実際には、ソースコードだけでは動かし方や現在の状態が分からず、新しい開発会社が大規模な調査から始めることがあります。
引継ぎ前に重要なのは、ソースコードを渡すことではなく、別の開発会社が「現在のシステムを再現できる状態」を作ることです。
はじめに：ソースコードがあっても、すぐに開発を再開できるとは限らない
既存システムの開発会社を変更するとき、最初に確認されるものの一つがソースコードです。
もちろん、ソースコードがなければ改修の難易度は上がります。
ただし、ソースコードが存在していても、
どのブランチ・バージョンが現在の本番環境なのか分からない
開発環境の作り方が分からない
使用している言語やフレームワークのバージョンが分からない
DBの構築方法や初期データが分からない
外部APIやクラウドサービスの設定が分からない
デプロイ方法が担当者の頭の中にしかない
ソースコード内にパスワードやAPIキーが残っている
といった状態では、新しい開発会社はすぐに改修へ着手できません。
開発途中で会社を変更する場合は、ソースコードなどの資産だけでなく「どの機能がどこまで完成しているか」という現在地の整理も必要です。詳しくは開発途中のシステムを別会社へ引き継ぐときの進め方で解説しています。
本記事ではそこから一歩絞り込み、ソースコードや環境情報などを新しい開発会社へ渡す前に、発注側で何を整理しておけばよいかを説明します。
結論：「ソースを渡す」ではなく「第三者が再現できる状態にする」
ソースコードの引継ぎで目指したいのは、大きく次の3つです。
現在動いているシステムが、どのソースコードなのか特定できる
別の開発者が、開発・検証環境を再現できる
機密情報や権利関係を整理したうえで、安全に渡せる
すべての資料を完璧に作り直す必要はありません。
重要なのは、新しい開発会社が、
このソースが現在の本番版である この手順で動作確認できる この情報は不足しているため調査が必要である
と判断できることです。
引継ぎでは、資料の枚数よりも、現在動いているシステムを第三者がどこまで再現できるかを見る方が実務的です。
引継ぎ前に整理したい5つの情報
1. 現在の本番環境に対応するソースコード
最初に確認したいのは、渡そうとしているソースコードが本当に現在のシステムと一致しているかです。
Gitなどで管理されていても、
mainやmasterが本番とは限らない
リリース用の別ブランチが存在する
本番だけ緊急修正されている
コミットされていない変更がある
開発途中のブランチが残っている
といったことがあります。
少なくとも、
現在本番で動いているバージョン
対応するブランチ、タグ、コミット
未反映の変更
開発途中の機能
使用しているリポジトリ
を確認します。
理想は、「この時点のソースが現在の本番環境です」と一意に示せる状態です。
ZIPファイルしか残っていない場合でも、更新日時やリリース履歴、サーバー上のファイルなどと照合し、できるだけ現在の状態を特定します。
2. 開発環境を再現するための情報
次に必要なのが、ソースコードを動かすための情報です。
たとえばWebシステムであれば、
使用言語とバージョン
フレームワークとバージョン
ビルド方法
アプリケーションの起動方法
必要な環境変数
DBの種類とバージョン
テーブル定義やマイグレーション
ローカル環境で必要な外部サービス
バッチや定期処理の起動方法
などがあります。
重要なのは、単に製品名を並べることではありません。
「何を準備して、どの手順を実行すれば動作確認できるのか」まで分かると、新しい開発会社の調査時間を減らせます。
READMEなど既存資料がある場合も、現在その手順で本当に動くのかを確認しておくことが重要です。
資料が存在しない場合でも、仕様書がない既存システムでも改修を依頼できる？最初に行う調査とはで説明しているように、現物から調査して整理することはできます。
3. パスワードやAPIキーなどの機密情報
引継ぎ時に特に注意したいのが機密情報です。
たとえば、
DBのパスワード
AWSなどクラウドのアクセスキー
外部APIのトークン
決済サービスの認証情報
SMTPの認証情報
秘密鍵
本番環境の接続情報
などが、設定ファイルやソースコードへ直接書かれている場合があります。
これらを含んだリポジトリを、そのまま別会社へ渡すことは避けます。
Gitを使用している場合、現在のファイルから秘密情報を削除しただけでは、過去の履歴に残っている可能性があります。
GitHubの公式ドキュメントでは、削除したい情報がパスワードやトークンなどの秘密情報である場合は、履歴を書き換える前に、まずその資格情報を失効またはローテーションすることが案内されています。
そのため、
現在の設定ファイルからパスワードを消したから、そのまま渡してよい
とは限りません。
リポジトリ履歴も含めて確認し、必要な認証情報はソースコードとは別の安全な方法で受け渡します。
4. DB・外部サービス・インフラなど、ソースコードの外側
Webシステムは、ソースコードだけで動いているわけではありません。
実際には、
データベース
AWSなどのクラウド環境
オブジェクトストレージ
メール配信サービス
決済サービス
外部API
DNS・ドメイン
ジョブ・キュー
CI/CD
OSSや外部ライブラリ
などと組み合わさっています。
引継ぎ時には、「何を使っているか」だけでなく、誰が契約・管理しているかまで分かると引継ぎが進めやすくなります。
依存ライブラリについては、
ライブラリ名
バージョン
利用箇所
商用製品や有償ライブラリの有無
ライセンス
なども確認します。
GitHubを利用しているリポジトリでは、Dependency graphからSBOM（Software Bill of Materials：ソフトウェア部品表）を出力する方法もあります。
GitHubの公式ドキュメントでは、SPDX形式で依存パッケージのバージョン、パッケージ識別子、ライセンスなどを含むSBOMを出力できると説明されています。
ただし、引継ぎのために必ずSBOMを新しく作成する必要があるわけではありません。
小規模なシステムであれば、使用している主要なライブラリや外部サービスが把握できているだけでも役立ちます。
5. 別会社へ渡してよい範囲
最後に、技術面とは別に契約上の確認も必要です。
たとえば、
ソースコードの権利関係
別の開発会社への開示可否
別会社による改変の可否
元の開発会社独自のライブラリや共通部品の有無
第三者製品・OSSの利用条件
NDAなどによる第三者開示の制限
です。
契約内容は案件によって異なります。
「自社がお金を払って開発したシステムだから、ソースコードを自由に他社へ渡せる」と決めつけず、既存の契約書や発注書、納品条件などを確認します。
判断が難しい場合は、必要に応じて法律の専門家へ確認します。
実際には「サーバーのログイン情報だけ」で引き継いだこともある
筆者が過去に引き継いだシステムでは、最初に渡されたものが、
本番サーバーと開発環境サーバーのログイン情報だけ
という案件がありました。
ソースコードの説明、構成資料、環境構築手順などはありませんでした。
実際に中を確認すると、当時すでに10年前にEOLを迎えていたバージョンの言語で動作するCakePHPのシステムでした。
旧担当者へ確認しても、
「確か、こうだったかもしれない」
という回答が多く、現在の状態を説明できる人もほとんど残っていませんでした。
さらに、使用されているフレームワークのバージョンが古く、Web上にも当該バージョンの情報が十分に残っていませんでした。
最終的には、古い技術書を探して購入し、実際に動いているコード、設定、DB、画面の挙動を一つずつ確認しながら、システムの構造と処理をほぼ一から解析し、そのうえで改修を行いました。
このような状態でも引継ぎ自体はできます。
ただし当然、最初から現在の構成や開発方法が整理されている案件と比べれば、改修へ入る前の調査量は大きくなります。
「整理されていない渡し方」と「整理された渡し方」の違い
たとえば同じソースコードを渡す場合でも、次の2つでは新しい開発会社が最初に行う作業が大きく変わります。
整理されていない状態 | 整理されている状態 |
GitのURLだけ渡される | 本番に対応するブランチ・タグまで分かる |
サーバーのログイン情報だけ渡される | 言語・フレームワーク・DBのバージョンが分かる |
READMEはあるが古い | 現在の起動手順が確認されている |
外部サービスの一覧がない | API・クラウド・決済等の依存先が一覧化されている |
APIキーがソース内に残っている | 秘密情報を分離して安全に受け渡せる |
「たぶんこのソースが最新」 | 現在の本番版を特定できる |
後者であれば、引継ぎ先は比較的早く「何を改修するか」の確認へ進めます。
前者の場合は、その前に**「このシステムはどう動いているのか」を調べる工程**が必要になります。
分からない項目がある場合は、無理に通常の改修見積へ進まない
ここまでの項目をすべて発注側で埋められなくても問題ありません。
重要なのは、分からないことを分からないまま固定価格の改修案件へ持ち込まないことです。
プレイリーソリューションズでは、既存システム案件の見積前に状態を確認し、概ね次の4区分で判断します。
判定 | 状態 | 進め方 |
見積OK | 改修対象・現行環境・成果物などが概ね把握できる | 本開発の見積へ進む |
条件付き | 一部不明点はあるが、前提条件を置けば積算できる | 条件を明記して見積 |
調査先行 | ソースや環境の状態が不明で、工数・責任・納期への影響が大きい | 調査工程を先に実施 |
保留 | 必要な資産や権限そのものを確認できない | 不足情報の確認から進める |
チェックリストで答えられない項目があること自体が問題なのではありません。
たとえば、
使用しているメール配信サービスのプラン名が分からない
程度であれば、改修内容によっては大きな問題にならないこともあります。
一方、
どのソースコードが本番なのか分からない 開発環境を起動できない 本番DBへどう接続しているか分からない
といった未確定事項は、改修工数や責任範囲へ大きく影響します。
この場合は、先に調査工程を設けた方が安全です。
調査先行となった場合は、たとえば次の順番で進めます。
現在のシステム構成を調査する
開発・検証環境を再現する
分かっていることと不明点を整理する
改修できる範囲とリスクを整理する
調査結果をもとに本開発の範囲と見積を決める
最初から大きな改修を固定価格で請け負うのではなく、調査を一つの工程として分けることで、不確実な部分を減らしてから本開発へ進めます。
また、ソースコード、構成図、ログ、本番環境情報など未公開の情報を新しい開発会社へ渡す段階では、必要に応じて秘密保持契約（NDA）を締結してから開示します。
プレイリーソリューションズでも、秘密情報を具体的に扱う必要がある案件ではNDAを締結したうえで、ソースコード・DB定義・サーバー・構成・運用状態などを確認する調査工程を小さく切り出し、その結果をもとに改修範囲と見積を決める進め方が可能です。
ソースコードを渡す前の確認チェックリスト
引継ぎ前には、最低限次の項目を確認してみてください。
現在本番で使っているソースコードを特定できる
Gitなどのリポジトリがどこにあるか分かる
使用言語・フレームワーク・主要バージョンが分かる
ビルド・起動方法が分かる
DB定義やマイグレーション方法が分かる
使用している外部API・クラウドサービスが分かる
各サービスを誰が契約・管理しているか分かる
パスワードやAPIキーなどの機密情報がソースに残っていないか確認した
依存ライブラリや商用製品を把握している
未完成機能・既知の不具合・保留事項を整理している
契約上、ソースコードを別会社へ開示・改変依頼できるか確認した
すべてに答えられなくても問題ありません。
答えられない項目が、そのまま引継ぎ時に調査すべき項目になります。
また、開発会社そのものがすでに不在で、契約や管理者権限から確認しなければならない場合は、開発会社がいなくなった既存システムでも、別会社へ改修を依頼できるのかも参考にしてください。
まとめ：ソースコードより「再現できる情報」を引き継ぐ
既存システムを別会社へ引き継ぐとき、ソースコードは重要な資産です。
ただし、本当に必要なのはソースコードそのものだけではありません。
どのソースが現在の本番なのか
どうすれば開発環境を再現できるのか
DBや外部サービスとどうつながっているのか
機密情報をどう扱うのか
どこまで別会社へ開示・改変依頼できるのか
まで整理できると、引継ぎ後の調査期間や認識違いを減らしやすくなります。
まずは、**「このソースコードを受け取った別の技術者が、現在のシステムを再現できるだろうか」**という視点で確認してみてください。
すべてを説明できなくても構いません。
分からない部分を明確にしておけば、「そのまま改修を見積もれるのか」「先に調査が必要なのか」を判断できます。
既存システムの引継ぎ・技術調査について
プレイリーソリューションズでは、他社が開発したWebシステムについて、ソースコードや既存環境の調査から、改修・機能追加まで対応しています。
「ソースコードはあるが、何を渡せばよいか分からない」
「サーバーの情報しか残っていない」
「資料がほとんどない」
といった段階でも、現在の状態を確認するところからご相談いただけます。
