システム開発を今の開発会社から別の会社へ引き継ぐ場合、単にソースコードを受け取るだけでは足りません。
開発途中のシステムを再委託先の会社が引き継ぐには、仕様書、開発環境、データベース、サーバー情報、進捗状況、未解決課題、権利関係などを先に整理しておきたいところです。
特に、中小企業のシステム開発では、仕様変更や口頭での合意、メールでのやり取りが多くなりがちです。後になって「何が正式な仕様なのか」「どこまで完成しているのか」が分からなくなることもあります。
この記事では、開発途中のシステムを別会社へ引き継ぐ際に、今の開発会社から用意してもらいたい資料や情報を、実務目線で整理します。
システム開発の引き継ぎはソースコードだけでは足りない
システム開発会社を変更する場合、まず思い浮かぶのは「ソースコードをもらえば進められるのではないか」という点かもしれません。
もちろん、ソースコードは欠かせません。
ただ、実際にはソースコードだけを受け取っても、次の開発会社がすぐに開発を再開できるとは限りません。
たとえば、次のような問題が起こることがあります。
- 開発環境の作り方が分からない
- データベースの構造が分からない
- どの機能が完成していて、どの機能が未完成なのか分からない
- 仕様書と実際のシステムが一致していない
- 本番サーバーへの反映方法が分からない
- 外部サービスとの連携方法が分からない
- そもそも第三者が改修してよい契約なのか分からない
つまり、開発会社を変更するときに見ておきたいのは、「ファイルを渡してもらえるか」だけではありません。「次の会社が迷わず開発を再開できる状態になっているか」です。
まず用意してもらうべきはソースコード一式
まず確認したいのは、現在までに作成されたソースコード一式です。
フロントエンド、バックエンド、管理画面、バッチ処理、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では、中小企業様向けに、システム開発会社とのやり取り、仕様整理、引き継ぎ資料の確認、再委託先への橋渡しなどをサポートしています。
「現在の開発状況が分からない」
「何を引き継げばよいか分からない」
「開発会社との打ち合わせに同席してほしい」
「別会社へ引き継ぐ前に契約書や資料を整理したい」
このような場合は、お気軽にご相談ください。
※本記事は、一般的なシステム開発・保守引き継ぎに関する実務上の考え方をまとめたものです。契約内容や法的判断については、個別の契約書や状況により異なります。必要に応じて弁護士などの専門家へご相談ください。
