開発プロジェクトが途中で止まった、委託先との連絡が滞っている、品質や進め方に不安があり別会社への切り替えを検討している――。こうした状況では、「完成していないシステムを本当に引き継げるのか」と悩む方も多いでしょう。
結論から言えば、開発途中でも引き継ぎは可能です。ただし、完成済みシステムの保守移管よりも、現時点の状態を正しく把握し、継続に必要な情報と権限を確保する作業が重要になります。
引き継ぎで最初に目指すべきなのは、資料を完璧にそろえることではありません。新しい開発会社が「現状を確認できる」「動かせる」「未完了部分を判断できる」状態をつくることです。
本記事では、そのために確保したい6つの成果物と、資料が不足している場合の進め方を解説します。
開発途中の案件で、何が不足しているか整理できていない段階でも相談できます。
開発・保守について相談する
開発途中の引き継ぎが難しい理由
完成済みのシステムであれば、本番環境で稼働している機能や運用手順を起点に調査できます。一方、開発途中の案件には、複数の「未確定」が残っています。
- どこまで実装が終わっているのか
- 実装済み機能が要件どおりに動くのか
- 未着手の機能は何か
- 途中で変更された要件が反映されているか
- テストがどの範囲まで行われたか
- 本番公開までに何が必要か
この状態で「残りを作ってください」と依頼しても、新しい会社は作業量やリスクを正しく見積もれません。まず必要なのは、完成度の見立てではなく、確認可能な材料を集めることです。
最初に確保したい6つの成果物
1. ソースコードとバージョン管理情報
最優先で確保したいのは、現在までに作成されたソースコードです。単に圧縮ファイルを受け取るだけでなく、可能であればGitなどのリポジトリ、ブランチ構成、コミット履歴、タグ、未反映の変更も確認します。
履歴が残っていれば、どの機能がいつ追加されたか、途中でどのような修正が行われたかを追いやすくなります。逆に、最新版が担当者の端末にしかない状態では、引き継ぎ後に差分が判明する恐れがあります。
最低限、次の点を確認しましょう。
- 正式な最新版はどれか
- 未コミット・未マージの変更がないか
- 外部ライブラリや自社共通部品をどこから取得するか
- ライセンスや利用条件に問題がないか
- ソースコードの権利関係が契約上どう定められているか
2. 開発・検証・公開環境の情報
ソースコードがあっても、動かす環境が分からなければ調査は進みません。開発環境、テスト環境、本番予定環境について、構成と接続方法を整理します。
対象には、サーバー、クラウドアカウント、コンテナ、ミドルウェア、ランタイム、環境変数、CI/CD、ビルド手順、デプロイ手順などが含まれます。秘密情報は安全な方法で移管し、チャットや平文ファイルに残さない運用も必要です。
環境が再現できるかどうかは、引き継ぎ難易度を左右します。手順がない場合は、現行担当者による画面共有や作業記録を残し、実際の操作から手順を復元します。
3. データベースと外部連携の情報
システムの振る舞いは、ソースコードだけでは理解できません。テーブル定義、データ項目の意味、初期データ、マスターデータ、バッチ処理、ファイル連携、外部APIなども確認対象です。
特に注意したいのは、「接続先は分かるが、業務上の意味が分からない」状態です。例えば同じ“ステータス”という項目でも、値の意味や更新条件を知らなければ正しく改修できません。
データそのものを移管する際は、個人情報や機密情報を含む可能性があります。開発会社へ渡せる範囲、マスキングの要否、閲覧権限を事前に整理してください。
4. 要件・設計・課題管理の資料
企画書、要件一覧、画面設計、API仕様、データ設計、議事録、チケット、バックログ、課題一覧など、意思決定の経緯が分かる資料を集めます。
重要なのは、「最新の仕様書があるか」だけではありません。文書と実装が一致しているか、変更要求がどこまで反映されたか、保留中の判断が何かを区別することです。
資料には、次のような状態ラベルを付けると確認しやすくなります。
- 確定・実装済み
- 確定・未実装
- 実装済み・未確認
- 検討中
- 廃止
- 状態不明
資料が少ない場合でも、チケットやメール、チャット、会議録から判断履歴を拾えることがあります。すべてをきれいな設計書に作り直してから移管する必要はありません。
5. テスト成果物と品質状況
開発途中の引き継ぎでは、「コードがある」と「完成している」を分けて考える必要があります。テスト計画、テストケース、実施結果、不具合一覧、再現手順、既知の制約を確認しましょう。
テスト結果が残っていない場合は、新しい会社が現状確認テストを行い、機能ごとに次のように分類します。
- 動作確認済み
- 条件付きで動作
- 不具合あり
- 未確認
- 実行不能
この分類によって、未完了作業と作り直しが必要な箇所を切り分けられます。引き継ぎ直後に納期を確定するのではなく、現状確認を経て再計画する方が安全です。
6. アカウント・権限・契約・連絡先
見落とされやすいのが、作業を進めるための権限です。クラウド、リポジトリ、ドメイン、証明書、各種SaaS、監視サービス、デザインツール、外部APIなどの管理主体を確認します。
また、現行ベンダーや再委託先、インフラ会社、外部サービス提供者の連絡先、契約期間、解約条件、成果物の帰属、利用中の有償ライセンスも整理が必要です。
アカウントが現行会社名義の場合、契約終了と同時に利用できなくなる可能性があります。引き継ぎの技術作業だけでなく、契約・権限の移管スケジュールを並行して進めてください。
成果物がそろわない場合はどうするか
6つすべてがそろっていなくても、直ちに引き継ぎ不能とは限りません。大切なのは、不足を曖昧にせず、調査で補えるものと、現行会社の協力が必要なものを分けることです。
コードや環境から復元できるもの
ソースコード、画面、DB、ログ、設定ファイルを調査すれば、機能一覧や処理フロー、データ項目の関係を一定範囲まで整理できます。ただし、業務上の判断理由や例外処理はコードだけで分からないことがあります。
担当者ヒアリングで補うもの
運用上の注意点、顧客ごとの例外、障害時の判断、過去の経緯などは、現行担当者へのヒアリングが有効です。退職や契約終了が近い場合は、資料作成より先にヒアリング日程を確保した方がよいケースもあります。
新しい会社が検証して確定するもの
品質状況や残作業は、実際に環境を動かして確認しなければ判断できません。短期間の調査フェーズを設け、調査結果をもとに開発再開の範囲・優先順位・体制を決めます。
スマラボのシステム開発・保守運用支援では、仕様書がない・古い場合でも現状調査から着手し、段階的な引き継ぎを支援しています。
システム開発・保守運用支援を見る
引き継ぎは3段階で進める
第1段階：保全
まず、失われると復元が難しいものを確保します。ソースコード、アカウント、契約情報、担当者の知識などです。現行会社との関係が悪化していても、感情的に即時切り替えを進めるのではなく、必要情報の保全を優先します。
第2段階：現状調査
新しい会社が環境を構築し、コード・データ・テスト状況を確認します。機能一覧、残課題、技術的リスク、権限不足を整理し、継続可能な範囲を明らかにします。
第3段階：再計画と段階移管
調査結果をもとに、短期的に必要な機能、修正が必要な機能、後回しにできる機能を分けます。可能であれば、現行会社と新会社の並行期間を設け、質問と検証を繰り返しながら移管します。
すべてを一度に切り替えるより、対象機能や環境を限定して引き継ぎ、安定を確認しながら範囲を広げる方がリスクを抑えやすくなります。
まとめ：完璧な資料より「確認して動かせる状態」をつくる
開発途中のシステムを別会社へ引き継ぐ際、最初に確保したい成果物は次の6つです。
- ソースコードとバージョン管理情報
- 開発・検証・公開環境の情報
- データベースと外部連携の情報
- 要件・設計・課題管理の資料
- テスト成果物と品質状況
- アカウント・権限・契約・連絡先
不足資料をすべて完成させてから移管する必要はありません。まず情報と権限を保全し、新しい会社が現状を調査できる状態をつくります。そのうえで、残作業とリスクを可視化し、再計画して段階的に引き継ぐことが重要です。
開発が止まっている、現行会社と連絡が取りづらい、資料不足で相談内容をまとめられない場合でも、現状整理から始められます。