システム開発を現在の開発会社から別の会社へ引き継ぐ場合、単にソースコードを受け取るだけでは不十分です。
開発途中のシステムを再委託先の会社がスムーズに引き継ぐためには、仕様書、開発環境、データベース、サーバー情報、進捗状況、未解決課題、権利関係などを整理しておく必要があります。
特に、中小企業のシステム開発では、仕様変更や口頭での合意、メールでのやり取りが多く、後から「何が正式な仕様なのか」「どこまで完成しているのか」が分からなくなることがあります。
この記事では、開発途中のシステムを別会社へ引き継ぐ際に、現在の開発会社から用意してもらうべき資料や情報を実務目線で整理します。
システム開発の引き継ぎはソースコードだけでは足りない
システム開発会社を変更する場合、まず思い浮かぶのは「ソースコードをもらえばよい」という点かもしれません。
もちろん、ソースコードは非常に重要です。
しかし、実際にはソースコードだけを受け取っても、次の開発会社がすぐに開発を再開できるとは限りません。
たとえば、次のような問題が起こることがあります。
- 開発環境の作り方が分からない
- データベースの構造が分からない
- どの機能が完成していて、どの機能が未完成なのか分からない
- 仕様書と実際のシステムが一致していない
- 本番サーバーへの反映方法が分からない
- 外部サービスとの連携方法が分からない
- そもそも第三者が改修してよい契約なのか分からない
つまり、開発会社の変更で重要なのは、「ファイルを渡してもらうこと」ではなく、「次の会社が迷わず開発を再開できる状態にすること」です。
まず用意してもらうべきはソースコード一式
最初に必要になるのは、現在までに作成されたソースコード一式です。
フロントエンド、バックエンド、管理画面、バッチ処理、API、設定ファイルなど、開発に関係するファイルを漏れなく引き渡してもらう必要があります。
具体的には、次のようなものです。
- フロントエンドのソースコード
- バックエンドのソースコード
- 管理画面のソースコード
- バッチ処理・定期処理のソースコード
- API関連のソースコード
- データベースマイグレーションファイル
- 設定ファイル一式
- Gitなどのリポジトリ情報
- 最新版のブランチ・コミット情報
可能であれば、単なるZIPファイルではなく、GitHub、GitLab、Bitbucketなどのリポジトリ履歴ごと引き渡してもらうのが理想です。
Gitの履歴があれば、どのような変更が行われたのか、どの作業が途中なのか、どの時点で不具合が発生したのかを追いやすくなります。
開発環境の構築手順書も必要
ソースコードがあっても、開発環境を再現できなければ作業は進みません。
再委託先の開発会社が、自社のPCや検証環境でシステムを起動できるように、開発環境の構築手順を用意してもらう必要があります。
確認すべき項目は次のとおりです。
- 使用しているプログラミング言語とバージョン
- フレームワークとバージョン
- データベースの種類とバージョン
- 必要なライブラリのインストール方法
- 環境変数ファイルのサンプル
- ローカル環境の構築手順
- 起動コマンド
- ビルドコマンド
- テスト実行コマンド
- 初期データの投入方法
Dockerを使っている場合は、Dockerfileやdocker-compose.ymlも必要です。
理想は、新しい開発者が手順書を見るだけで、ローカル環境を構築し、システムを起動できる状態です。
データベース関連資料を用意してもらう
業務システムでは、データベースの情報が非常に重要です。
画面や機能の仕様は、最終的にはデータベースの構造と密接に関係しています。
そのため、次のような資料を用意してもらう必要があります。
- データベース定義書
- テーブル一覧
- カラム一覧
- 主キー・外部キーの情報
- インデックス情報
- ER図
- マスターデータ
- テスト用データ
- 開発環境用のDBダンプ
- データ移行手順
特に、ER図とテーブル定義書は重要です。
ただし、実務上は資料が古くなっていて、実際のデータベース構造と一致していない場合もあります。
そのため、再委託先には資料だけでなく、実際のデータベース定義も確認してもらう必要があります。
要件定義書・設計書・画面仕様書を確認する
次の開発会社がもっとも知りたいのは、「このシステムは最終的に何を実現するものなのか」です。
そのため、要件定義書や設計書、画面仕様書などの資料が必要です。
用意してもらいたい資料は次のとおりです。
- 要件定義書
- 基本設計書
- 詳細設計書
- 画面設計書
- 画面遷移図
- 機能一覧
- 帳票設計書
- API仕様書
- 権限設計書
- 業務フロー図
開発途中のシステムでは、当初の仕様から変更されていることも多くあります。
そのため、仕様変更履歴、議事録、メール、チャット履歴なども重要です。
古い仕様書だけを見て開発を進めると、すでに合意済みの内容とズレてしまう可能性があります。
画面・機能ごとの進捗一覧を作成してもらう
開発途中のシステムを引き継ぐ場合、「どこまで完成しているのか」を明確にすることが非常に重要です。
再委託先が知りたいのは、単に「何割くらい完成しているか」ではありません。
次のような具体的な状態です。
- 完成している機能
- 実装途中の機能
- 未着手の機能
- 動作確認済みの機能
- 不具合が残っている機能
- 仕様が未確定の機能
- 発注者確認待ちの機能
- 開発会社側で保留していた機能
たとえば、次のような一覧にしてもらうと分かりやすくなります。
| 機能 | 状態 | 補足 |
|---|---|---|
| ログイン機能 | 完了 | 基本的な動作確認済み |
| 顧客登録 | 実装中 | 入力チェックが未完成 |
| 見積書出力 | 未着手 | 帳票レイアウト未確定 |
| 権限管理 | 一部完了 | 管理者権限のみ実装済み |
| CSV出力 | 不具合あり | 文字化けの修正が必要 |
このような進捗表がないと、再委託先はソースコードを読みながら進捗を推測することになります。
それには時間も費用もかかるため、現在の開発会社に必ず整理してもらいたい資料です。
未解決課題・既知の不具合一覧も重要
現在の開発会社が把握している課題や不具合も、すべて出してもらうべきです。
特に、開発会社が内部的に把握していた問題は、資料に残っていないことがあります。
確認したい項目は次のとおりです。
- 既知のバグ一覧
- 未解決の技術課題
- 暫定対応している箇所
- 後回しにしている機能
- パフォーマンス上の懸念
- セキュリティ上の懸念
- 今後修正予定だった箇所
特に注意したいのは、暫定対応している箇所です。
納期や予算の都合で一時的な実装になっている部分がある場合、それを知らずに開発を続けると、後から大きな修正が必要になることがあります。
サーバー・インフラ情報を確認する
システムは、ソースコードだけで動いているわけではありません。
本番環境、検証環境、開発環境のサーバー情報や、デプロイ手順も必要です。
確認すべき項目は次のとおりです。
- 本番サーバー情報
- 検証サーバー情報
- 開発サーバー情報
- OS情報
- Webサーバー情報
- データベースサーバー情報
- ドメイン・DNS設定
- SSL証明書情報
- メール送信設定
- バックアップ設定
- cron・タスクスケジューラの設定
- デプロイ手順
- ログの場所
AWS、Azure、Google Cloudなどのクラウド環境を利用している場合は、クラウドの構成図や権限情報も必要です。
ここが不明確だと、次の開発会社が「ソースコードは分かるが、本番環境に反映できない」という状態になります。
外部サービス・API連携情報を整理する
決済、メール送信、SMS、地図、電子申請、会計ソフト、基幹システムなど、外部サービスと連携している場合は、その情報も整理してもらう必要があります。
確認すべき項目は次のとおりです。
- 利用している外部サービス一覧
- API仕様
- APIキーの管理場所
- Webhook設定
- コールバックURL
- 連携処理の流れ
- エラー時の挙動
- テスト環境の有無
- 本番環境と検証環境の違い
- 外部サービスの契約者情報
外部連携があるシステムでは、APIキーやWebhookの設定が分からないだけで、一部機能が動かなくなることがあります。
また、外部サービスが前の開発会社名義で契約されている場合、引き継ぎ後に利用できなくなる可能性もあります。
アカウント・権限情報を整理する
開発や運用に必要なアカウントも整理が必要です。
たとえば、次のようなアカウントです。
- GitHub / GitLab / Bitbucket
- サーバー管理画面
- SSH / SFTPアカウント
- データベース接続情報
- クラウド管理画面
- ドメイン・DNS管理画面
- 外部API管理画面
- 課題管理ツール
- チャットツール
ただし、パスワードをメール本文にそのまま書いて送るような方法は避けるべきです。
パスワード管理ツールや、安全な共有方法を使って引き継ぐ必要があります。
また、引き継ぎ後は不要なアカウントの削除、パスワード変更、権限の見直し作業も適宜必要になります。
テスト資料・テストデータも用意してもらう
再委託先が修正や追加開発を行う場合、既存機能を壊していないか確認できる状態が必要です。
そのため、テストに関する資料やデータも用意してもらいます。
- テスト仕様書
- テスト結果
- 単体テストコード
- 結合テスト項目
- 受入テスト項目
- テスト用アカウント
- テストデータ
- 不具合の再現手順
特に業務システムでは、実際の業務に近いテストデータがないと、十分な動作確認ができません。
空のデータベースだけを渡されても、実際の運用に近い確認は難しくなります。
課題管理・やり取り履歴も引き継ぎ対象にする
開発中にBacklog、Redmine、GitHub Issues、Notion、Chatwork、Slack、Teams、メールなどでやり取りしていた場合、その履歴も重要です。
仕様書には書かれていなくても、チャットやチケット上で重要な決定がされていることがあります。
確認すべきものは次のとおりです。
- 課題管理ツールのチケット一覧
- 完了済みチケット
- 未完了チケット
- 保留中チケット
- 質疑応答履歴
- 議事録
- 仕様変更の合意履歴
- 発注者からの要望履歴
実務上、仕様書よりもメールやチャットのほうに重要な情報が残っていることもあります。
可能であれば、開発に関するやり取り履歴一式を引き継ぎ対象にしたほうが安全です。
ライセンス・利用技術の情報を確認する
システム内で利用しているライブラリ、テンプレート、フォント、画像素材、有償ツールなどのライセンス情報も確認が必要です。
確認すべき項目は次のとおりです。
- 使用ライブラリ一覧
- OSSライセンス情報
- 有償ライブラリの有無
- テンプレート・テーマのライセンス
- フォント・画像素材の利用権
- 開発ツールのライセンス
- 商用利用の可否
- 契約者名義
- 更新期限
前の開発会社名義で契約している有償ライブラリや外部サービスがある場合、引き継ぎ後に利用できなくなる可能性があります。
そのため、どの技術や素材をどの条件で使っているのかを確認しておくことが重要です。
権利関係は必ず書面で確認する
システム開発会社を変更する場合、技術的な引き継ぎだけでなく、契約上の確認も重要です。
特に確認したいのは、発注者が、引き渡されたソースコード・設計資料・成果物を、保守・改修・追加開発の目的で第三者へ提供し、利用・改変させることができるかどうかです。
確認すべき項目は次のとおりです。
- 現在までの成果物の著作権は誰にあるか
- 発注者がソースコードを利用・改変できるか
- 第三者の開発会社へ提供してよいか
- 開発会社独自の共通部品が含まれていないか
- 第三者ライブラリの利用条件に問題がないか
- 契約終了後の利用制限がないか
この部分は、トラブルになりやすいところです。
契約書の内容によって判断が変わるため、重要な案件では弁護士などの専門家にも確認することをおすすめします。
最低限これだけは用意してもらいたい10項目
すべての資料を完璧に揃えるのが難しい場合でも、最低限、次の10項目は用意してもらうべきです。
- ソースコード一式
- Gitリポジトリ履歴
- データベース定義書・ER図
- 開発環境構築手順書
- 本番・検証環境のサーバー情報
- デプロイ手順書
- 要件定義書・画面設計書・機能一覧
- 画面・機能ごとの進捗一覧
- 未解決課題・バグ一覧
- 第三者への提供・改修許可の確認書面
この10項目が揃っていれば、再委託先の開発会社は、現在のシステムの状態を把握しやすくなります。
反対に、この情報が不足していると、調査だけで多くの時間と費用がかかる可能性があります。
現在の開発会社へ依頼するときの文面例
現在の開発会社へ資料提供を依頼する場合は、次のような文面が使えます。
件名：開発中システムの引き継ぎ資料ご提供のお願い
お世話になっております。
現在開発中のシステムにつきまして、今後の保守・改修・運用継続を円滑に行うため、現時点での成果物および関連資料をご提供いただきたくお願いいたします。
可能であれば、ソースコード一式、開発環境構築手順、データベース定義書、画面設計書、機能一覧、進捗一覧、未解決課題、サーバー構成情報、デプロイ手順、外部サービス連携情報など、現時点でご提供可能なものから順次ご共有いただけますと幸いです。
また、今後の保守・改修・追加開発のため、これらの成果物・資料を第三者の開発会社へ共有し、調査・改修を依頼できるかについても、あわせてご確認いただけますでしょうか。
お手数をおかけいたしますが、よろしくお願いいたします。
最初から「別会社に変更するため」と強く伝えると、相手との関係が悪化する場合があります。
そのため、まずは「今後の保守・改修・運用継続に備えて整理したい」という表現にするほうが、現実的に進めやすい場合があります。
引き継ぎ説明会を行う
資料だけでは分からないことも多いため、可能であれば、現在の開発会社、発注者、再委託先の3者で引き継ぎミーティングを行うことをおすすめします。
確認すべき内容は次のとおりです。
- システム全体の概要
- 現在の進捗状況
- 未完了機能
- 仕様未確定部分
- 技術的に難しい部分
- 既知の不具合
- サーバー構成
- デプロイ方法
- 注意すべき実装箇所
- 今後の開発で想定していた方針
可能であれば、引き継ぎミーティングは録画しておくとよいでしょう。
後から再委託先が確認できるため、認識違いを防ぎやすくなります。
開発会社変更で特に注意すべきこと
開発会社を変更する場合、現在の開発会社が必ずしも協力的とは限りません。
そのため、感情的な表現や対立的な表現は避け、まずは事実確認と資料整理を目的に進めることが重要です。
特に注意したいのは次の点です。
- 契約書の納品物にソースコードが含まれているか
- 設計資料や仕様書が納品対象になっているか
- 第三者への提供が禁止されていないか
- 未払い費用や精算条件が残っていないか
- 契約解除の手続きに問題がないか
- 本番環境やデータの管理権限が誰にあるか
対応を誤ると、ソースコードやデータの引き渡しが進まなかったり、逆に開発会社から費用請求を受けたりする可能性もあります。
重要な案件では、契約書と証拠資料を整理したうえで、必要に応じて弁護士などの専門家へ相談したほうが安全です。
まとめ：引き継ぎで重要なのは再委託先が迷わない状態にすること
システム開発を現在の開発会社から別会社へ引き継ぐ場合、ソースコードを受け取るだけでは十分ではありません。
再委託先がスムーズに開発を再開するには、仕様、進捗、データベース、開発環境、サーバー、外部連携、未解決課題、権利関係まで整理されている必要があります。
特に重要なのは、次の6点です。
- 何を作る予定だったのか
- どこまで作ったのか
- 何が未完成なのか
- どうすれば動かせるのか
- どこに注意すべきなのか
- 第三者が改修してよいのか
この6点を明確にすることが、システム開発の引き継ぎを成功させるための重要なポイントです。
開発会社の変更は、対応を誤ると追加費用や納期遅延につながります。
早い段階で必要資料を整理し、技術面と契約面の両方から慎重に進めることが大切です。
システム開発の引き継ぎ・開発会社変更でお困りではありませんか？
IT顧問のITAでは、中小企業様向けに、システム開発会社とのやり取り、仕様整理、引き継ぎ資料の確認、再委託先への橋渡しなどをサポートしています。
「現在の開発状況が分からない」
「何を引き継げばよいか分からない」
「開発会社との打ち合わせに同席してほしい」
「別会社へ引き継ぐ前に契約書や資料を整理したい」
このような場合は、お気軽にご相談ください。
※本記事は、一般的なシステム開発・保守引き継ぎに関する実務上の考え方をまとめたものです。契約内容や法的判断については、個別の契約書や状況により異なります。必要に応じて弁護士などの専門家へご相談ください。
