システム開発の引き継ぎガイド【2026年】開発会社を変えるときの技術診断と実務手順

執筆：Swooo編集部／監修：北浦 聡大（Bubble公式認定デベロッパー・国内初合格）

システム開発の引き継ぎ（開発会社の変更・乗り換え）は、資産の受け取りと権利関係の確認を押さえれば、開発の途中からでも成立します。ただし、引き継ぎがうまくいくかどうかは手続きの丁寧さだけでは決まりません。「いまのシステムの何が、どう壊れているのか」を最初に診断できるかどうかが、その後の改修・再構築の成否を分けます。

この記事では、開発が頓挫してしまった方、あるいは現行の開発会社との継続に不安がある企業の事業責任者・情報システム部門の方に向けて、引き継ぎの判断基準、壊れ方を見分ける技術診断の観点、著作権・データの権利関係、実務手順までを一通り整理します。

まず、いまの状況からどの選択肢を検討すべきか、早見表で確認してください。

開発の引き継ぎが起きる、2つの典型的な状況

システム開発の引き継ぎの相談は、大きく2つの入口に分かれます。

1つめは計画的な移行です。いまのシステムは動いているものの、改修の見積もりが上がり続けている、対応のスピードが事業の速度に追いつかない、保守はしてくれるが改善の提案が出てこない──といった不満が積み重なり、次の開発フェーズを機に依頼先を見直すケースです。緊急性は低い分、権利関係と資産の整理を先に済ませられるため、正しく進めれば移行の負担は小さく抑えられます。

2つめはトラブルを起点とする引き継ぎです。納期の遅延が常態化して開発が頓挫した、開発会社が事業から撤退した、連絡が取りにくくなった、納品はされたものの性能や品質に問題があり使い続けられない──といったケースで、いわゆる「開発レスキュー」に近い状況です。この場合は原因の診断と資産の確保を並行して急ぐ必要があります。

背景には構造的な問題もあります。経済産業省のDXレポート2.1は、ユーザー企業が開発をベンダーに任せきりにすることでシステムの中身がブラックボックス化し、他社への変更が難しくなる（ロックイン）一方、ベンダー側も既存の受託関係に依存する──双方が現状維持に傾く「低位安定」の関係を指摘しています。「不満はあるが、いまの会社にしか中身が分からないので変えられない」という状態は、まさにこの構造です。

引き継ぎの検討は、この構造を断ち切る機会でもあります。だからこそ移行そのものだけでなく、次の体制ではドキュメント・アカウント・権利を自社側に置き、同じ構造に戻らない形をつくることまで含めて設計すべきです。

技術診断：何が、どう壊れているのかを見分ける

引き継ぎの相談は「遅い」「エラーが多い」「開発が止まった」という症状ベースで持ち込まれることがほとんどです。しかし、症状の裏にある原因を特定しないまま開発会社だけを変えても、同じ問題を新しい体制に引き継ぐことになります。逆に、原因が特定できれば「直せるのか、作り直すべきなのか」「費用と期間はどの範囲か」の見通しが立ちます。

この診断は、引き継ぎ先を選ぶうえでも重要な意味を持ちます。診断の粒度がそのまま見積もりの精度になるからです。原因が特定されていれば「どこまで直すか」の線引きを発注側が判断できますが、原因不明のままでは、提示された金額の妥当性を評価する手がかりがありません。

実際にご相談いただく引き継ぎ案件で多いのは、大きく2つの系統です。

症状1：「動くには動くが、遅い」──データベース設計の破綻

検収のときは問題なく動いていたのに、利用者とデータが増えるにつれて一覧表示や検索が目に見えて遅くなっていく。この症状の原因は、個々の画面の作りよりも、データベース設計そのものにあることがほとんどです。設計の段階で「データが増えたときの検索性能」と「誰がどのデータを見られるかという権限設計」を考慮していないと、次のような状態になります。

• 増え続けるデータをリスト（配列）で持たせている：少量のうちは動きますが、件数が増えると読み込みが急激に重くなります。増えるデータは別のテーブルに分けて検索で参照するのが基本です
• 全件を取得してから絞り込んでいる：本来はサーバー側で条件を絞って必要な分だけ取得すべきところを、クライアント側へ大量のデータを送ってから絞り込む実装になっている。データ量に比例して遅くなり、通信量も膨らみます
• アクセス権限が後付けになっている：権限制御（Bubbleなどのノーコードでは Privacy Rules）は、データ構造の設計時に織り込んでおく必要があります。後から足そうとするとデータ構造ごと見直すことになり、事実上の再設計になります

この種の問題が検収をすり抜けるのには理由があります。検収は少量のテストデータと少人数で行われることが多く、データが少ないうちは設計に問題があっても速度は出てしまうためです。権限設計も同様で、テスト時は関係者全員が管理者に近い権限で触るため、「一般ユーザーから見えてはいけないデータが見える」という不備は表面化しにくいのです。

この系統の厄介な点は、局所的なバグ修正では直らないことです。土台であるデータ構造に問題があるため、画面側をいくら調整しても根本は解消しません。引き継ぎの技術診断では、まずこの「土台が壊れているのか、表層の問題なのか」を切り分けます。この切り分けが、後述する改修か作り直しかの判断に直結します。

なお、権限設計の不備は性能だけでなく情報漏えいのリスクにも直結します。診断の観点はノーコード開発のセキュリティ解説記事で詳しく扱っています。

症状2：「外部サービスと連携できない・連携が不安定」──API連携の実装力不足

決済、チャット通知、AI、会計ソフトなど、外部サービスとのAPI連携は、開発会社による実装力の差がもっとも表れやすい領域です。実際にご相談いただく中には、外部APIとの連携そのものが実装できず、そこで開発が止まってしまったケースもあります。

また、いま連携が「動いている」場合でも、運用に耐える実装かどうかは別の問題です。具体的には次の観点で差が出ます。

• エラーハンドリングの有無：外部APIの呼び出しが失敗したとき、処理が黙って止まるだけの実装は珍しくありません。失敗を記録し、管理者に通知し、再実行できる仕組みがあるかどうかで、運用の安定性がまったく変わります
• タイムアウトの検知：外部サービスから応答が返ってこないケースを検知できるか。検知できないと「処理が終わったのか失敗したのか分からない」状態が発生します
• 再実行の設計：一時的な障害に対する自動リトライ（回数制限つき）と、手動で安全に再実行できる導線が用意されているか

これらがない実装は、「たまにデータが飛ぶが、原因が分からない」という症状として現れます。障害のたびに調査から始まるため保守コストがかさみ、原因不明のまま利用者からの信頼を失っていきます。

発注者が自分で確認できる質問リスト

専門知識がなくても、現行の開発会社（または納品物）に次の質問をぶつければ、問題の所在をかなり絞り込めます。

1. 本番相当のデータ量で性能を検証しましたか：テスト用の少量データでしか動作確認していない場合、データ増による性能劣化は検証されていません
2. アクセス権限はサーバー側で制御されていますか：画面上の表示・非表示の出し分けだけで「見えないから安全」としている実装は、権限制御として機能していません
3. 外部連携が失敗したとき、誰がどうやって気づけますか：通知先と再実行の手順を即答できない場合、エラーハンドリングが実装されていない可能性があります
4. 開発規約やリリース前のチェックリストはありますか：命名規則・禁止事項・リリース前の確認項目を文書として持っているかどうかは、品質管理体制の有無をそのまま示します
5. 変更履歴（バージョン管理）は残っていますか：いつ・誰が・何を変更したかが追えるかどうかは、引き継ぎのしやすさに直結します
6. 設計書・仕様書はどこまで残っていますか：ドキュメントがない場合でも引き継ぎは可能ですが、調査・解析の工程を別途見込む必要があります

回答が曖昧だったり、確認に長い時間がかかったりする領域には、問題が潜んでいる可能性が高いと考えられます。もっとも、最終的な診断は現物を見なければ確定できません。引き継ぎ先の候補に開発環境の閲覧権限を渡し、実物を見たうえで所見を出してもらうのが確実です。

作り直しか、引き継ぎ改修か──判断の分かれ目

技術診断で原因の見当がついたら、次は「いまのシステムを引き継いで改修するか、作り直すか」の判断です。分かれ目は、壊れているのが土台（データベース設計・権限設計）か、表層（画面・個別機能）かにあります。

また、改修か作り直しかは必ずしも二者択一ではありません。本番運用中で止められないシステムでも、現行システムを動かしたまま、問題の大きい領域から順に作り替えていく段階的な再構築という進め方があります。利用者への影響を抑えながら土台を刷新できる一方、新旧の並行運用を設計する力が引き継ぎ先に求められるため、この進め方を具体的に提案できるかどうかも会社選びの判断材料になります。

注意したいのは、「作り直し」は全損ではないという点です。最初の開発で確定した要件、実際に使われて分かった画面設計の改善点、運用して見えた業務フローは、再構築におけるもっとも価値の高い資産です。動いている既存システムは、不完全でも「実物で確認できる要件定義書」として機能します。ゼロからの新規開発に比べて、再構築は要件の不確実性が大幅に小さい状態から始められます。

なお、業務全体を支える基幹システム規模の刷新は、移行戦略やデータ移行の論点が加わるため、基幹システムリプレイスの解説記事を参照してください。

権利関係の確認：著作権もデータも「契約次第」

技術面と並行して、必ず確認すべきなのが権利関係です。ここを曖昧にしたまま引き継ぎを進めると、後から「改修する権利がない」という事態になりかねません。

まず著作権です。開発されたソースコードや設計書の著作権は、原則として作成した開発会社側に発生します。そして著作権法上、著作権は譲渡できますが（61条1項）、契約に譲渡の定めがなければ自動的には移転しません。開発費を全額支払っていても、契約に定めがなければ著作権は自動的には発注者へ移りません。

さらに引き継ぎで重要なのが、同条2項の扱いです。譲渡契約があっても、改変に関わる権利（翻案権など）は、譲渡の目的として契約に明記されていない場合、譲渡した側に留保されたと推定されます。システムの改修は著作物の改変にあたるため、この点が曖昧だと「引き継いだのに改修の権利関係が不明確」という状態になり得ます。契約書の著作権条項で、譲渡か利用許諾か、改修や再委託が許される範囲かを確認してください。

データについても同様です。自社の業務で蓄積したデータであっても、引き渡しの義務・形式・費用は契約の定めによります。契約書に明記がない場合は協議になるため、関係がこじれる前に、データのエクスポート形式やアカウントの扱いを含めて条件を確認しておくのが安全です。

ノーコードで開発されたシステムには、固有の論点もあります。成果物が開発プラットフォーム上のアプリケーションとして存在するため、実務上の「引き渡し」は、ソースコードのファイル納品ではなくアプリケーションの所有アカウント・管理権限の移管になります。アプリが開発会社のアカウント配下で管理されている場合、契約終了時にどのような手順で自社（または次の開発会社）へ移管されるのかを、事前に確認しておいてください。

契約書のどの条項をどう読むべきかは、システム開発の契約ガイドで詳しく解説しています。判断が難しい場合や紛争の可能性がある場合は、IT分野に詳しい弁護士への相談も検討してください。

引き継ぎの実務手順：伝え方・受け取るもの・並行期間

権利関係の確認と技術診断の目処がついたら、実務は次の順序で進めます。

手順1：引き継ぎ先の当たりを先に付ける

現行の開発会社に切り出す前に、受け皿となる引き継ぎ先の候補を決め、可能であれば技術診断まで受けておきます。順序が逆になると、現行ベンダーとの契約が終了してから受け皿を探すことになり、保守の空白期間が生まれます。診断を受けておけば、「引き継ぎ改修で進められるのか、作り直しになるのか」というもっとも大きな分岐に答えを持った状態で、現行ベンダーとの交渉に入れます。

手順2：現行の開発会社への伝え方

伝える前に、契約書の解約条項（予告期間・精算方法）と、検収・支払いの状況を確認しておきます。そのうえで、過去の責任追及と引き継ぎの実務は切り離して進めるのが原則です。感情的な対立は資産の受け渡しを停滞させ、損をするのは自社側です。

引き継ぎへの協力は、善意に期待するのではなく「最後の業務」として依頼します。資料の整理やアカウント移管の作業が有償になることもありますが、次の開発会社が調査にかける時間を大きく削減できるため、多くの場合は支払う価値があります。

手順3：資産の受け取りリスト

受け取るべき資産は次のとおりです。抜け漏れがあると、後から前の開発会社に依頼し直すことになります。

• ソースコード一式：変更履歴を含むリポジトリごと。ノーコード開発の場合は、アプリケーションの所有権・管理権限そのものの移管
• データベースのデータ：エクスポートしたデータに加えて、テーブル構成やデータ項目の定義が分かる資料
• 各種アカウントと権限：サーバー・ドメイン・DNS・外部サービス（決済、メール配信など）・APIキー。開発会社名義になっているものは自社名義への変更まで行う
• ドキュメント類：要件定義書・設計書・テスト結果・打ち合わせの議事録。完全でなくても、あるものはすべて受け取る
• 外部サービスの契約と支払い：どのサービスを誰の名義・支払いで契約しているかの一覧。解約や名義変更の漏れは、後日のサービス停止事故につながります
• 運用情報：定常運用の手順、過去の障害と対応の履歴、問い合わせ対応の記録

手順4：並行期間を設計する

本番運用中のシステムであれば、保守の空白を作らないことが最優先です。現行ベンダーの契約終了日と新体制の開始日を重ね、切り替え日までの障害対応の窓口を明文化します。本番環境へのアクセス権の移管タイミング、ドメインやDNSの切り替え日程も、この並行期間の中で計画します。

並行期間には、新しい開発会社が検証環境でシステム全体の挙動を再現し、主要な機能が想定どおり動くことを確認する時間も含めておきます。受け取った資産に不足があれば、現行ベンダーとの契約が生きているこの期間中に洗い出すのがもっとも低コストです。

引き継ぎ先の選び方：診断を最初にやる会社か

引き継ぎ先の選定では、新規開発の会社選びとは異なる観点が必要です。

• 現物を見てから見積もる会社か：既存システムの引き継ぎは、中身を見るまで作業量が確定しません。調査・診断のフェーズを最初に区切って提案する会社は、この不確実性の扱いに慣れています。現物を確認せずに確定金額を提示する提案には、前提条件の確認が必要です
• 同じ技術スタックでの開発実績があるか：とくにBubbleなどのノーコードは、プラットフォーム固有の設計知識（権限設計・性能設計）が引き継ぎの品質を左右します。公式の認定資格やパートナー制度は、客観的に確認できる判断材料のひとつです
• 品質管理の体制を文書で持っているか：開発規約・命名規則・リリース前チェックリスト・レビュー体制の有無をそのまま質問してください。引き継ぎ先にこれらがなければ、数年後に同じ問題を繰り返すおそれがあります
• 契約のフェーズ分割を提案できるか：仕様が不明な調査フェーズと、要件が固まった後の改修フェーズでは、適した契約形態が異なります。この使い分けを自分から提案できる会社は、引き継ぎ案件の進め方を理解しています
• 長く付き合える会社か：引き継ぎは保守を含む長期の関係の始まりです。運営会社の事業継続性や財務情報の開示状況も判断材料になります

比較の進め方としては、候補となる各社に同じ資料・同じ質問を渡し、回答を並べて見るのが実用的です。とくに「まず何を確認しますか」という質問への答えには、その会社の進め方がよく表れます。診断の所見を書面で出せるか、診断結果しだいで作り直しを勧める可能性まで言及するか──回答の具体性は、提示金額よりも多くのことを教えてくれます。

Swoooの引き継ぎ対応：調査は準委任、改修・再構築は請負で

本メディアを運営するSwooo（運営：東証グロース上場の株式会社アイビス、証券コード9343）は、Bubble公式Goldパートナー（日本1位）として、ノーコード開発とAI駆動開発を組み合わせ、累計50件以上の開発支援を行ってきました。他社で開発されたシステムの引き継ぎについては、仕様書やドキュメントがない状態からの調査・解析フェーズは準委任で、要件が固まった改修・再構築は請負で、というフェーズ分割のご提案が可能です。

社内では、命名規則・バージョン管理・禁止事項を定めた開発規約と、リリース前チェックリスト37項目（権限設定の漏れ、デバッグ用設定の戻し忘れなどを含む）を運用しており、引き継いだシステムの技術診断もこの観点で行います。本記事で挙げたデータベース設計や外部API連携の問題は、実際の引き継ぎ相談で繰り返し目にしてきた論点です。

「何が問題なのか分からないが、このままでは進められない」という段階からでもご相談いただけます。現行の開発会社との調整が済んでいなくても、先に技術面の所見だけ確認しておきたいというご相談も可能です。乗り換えを前提とせず、診断の結果、現行体制のまま部分的な改修で足りると分かるケースもあります。

よくある質問

前の開発会社と連絡が取りにくい状態です。引き継ぎはできますか

可能です。ただし、資産の受け取りが不完全になるほど調査・解析の工程が増えます。まずは自社側で保有しているもの（契約書、アカウント情報、受領済みの納品物や資料）を棚卸ししてください。連絡が完全に途絶する前に、ソースコードやアプリの管理権限、データのエクスポートだけでも確保しておくことが重要です。とくにサーバーやドメイン、外部サービスの契約が開発会社名義・開発会社の支払いになっている場合、放置するとある日突然サービスが止まるおそれがあるため、名義と支払いの確認を最優先にしてください。

ソースコードや設計書がなくても引き継げますか

動いているシステムそのものにアクセスできれば、調査・解析によって仕様を復元しながら引き継ぐことは可能です。その場合、通常の改修に先立って解析フェーズを区切り、そこで判明した内容をもとに改修・再構築の計画を立てる進め方になります。何も資料がない状態で確定見積もりを出すことはできないため、フェーズを分けた契約が現実的です。なお、実際に日々使っている業務担当者へのヒアリングは、失われた仕様を復元するうえで設計書に劣らない情報源になります。

引き継ぎにはどれくらいの期間がかかりますか

システムの規模、ドキュメントの残り具合、現行ベンダーの協力度合いによって大きく変わるため、一概には言えません。目安を立てるには、最初に調査フェーズを区切って現状を把握し、その結果をもとに改修・再構築の期間を見積もる進め方が確実です。逆に、現状を見ずに期間を断定する提案は、後から前提が崩れるリスクを抱えています。期間を左右する要因のうち自社でコントロールできるのは資産の受け取りと社内の意思決定速度なので、まずそこを整えるのが近道です。

現行の開発会社には、いつ乗り換えを伝えるべきですか

引き継ぎ先の候補が決まり、契約書の解約条項と権利関係を確認してからが原則です。伝えた後は現行ベンダーの対応の優先度が下がることも想定されるため、受け皿がない状態で切り出すのは避けてください。伝える際は、責任の追及ではなく引き継ぎ協力の依頼として、事務的に進めるのが結果的に得策です。

開発が頓挫した場合、支払い済みの費用は取り戻せますか

契約の形態（請負か準委任か）、検収の状況、頓挫の経緯によって扱いが変わるため、契約書の確認が出発点になります。金額が大きい場合や交渉が難航しそうな場合は、IT分野に詳しい弁護士への相談を検討してください。なお、費用の交渉と並行して、資産の確保（コード・データ・アカウント）を先に進めておくことをおすすめします。交渉が長引くほど、事業側の時間が失われるためです。

まとめ：診断が先、乗り換えはその後

システム開発の引き継ぎは、開発会社を替えること自体が目的ではありません。いまのシステムの状態を正しく把握し、事業を前に進められる体制を作り直すことが目的です。押さえるべきポイントを整理します。

引き継ぎを機に開発の内製化まで視野に入れる場合は、受託開発から内製化へ移行する手順で契約整理・引き継ぎ成果物のチェックリストを整理しています。

• 引き継ぎの成否は、手続きよりも「何がどう壊れているか」の技術診断で決まる。土台（データベース設計・権限設計）の問題か、表層の問題かをまず切り分ける
• 「動くが遅い」はデータベース設計、「連携が不安定」は外部APIのエラーハンドリングに原因があることが多い。発注者でも質問リストで所在を絞り込める
• 著作権は契約で譲渡を定めない限り移転せず（著作権法61条）、データの引き渡しも契約次第。切り出す前に契約書を確認する
• 実務は「受け皿の確保 → 現行ベンダーへの依頼 → 資産の受け取り → 並行期間」の順。保守の空白を作らない
• 引き継ぎ先は、現物の診断を最初に提案し、品質管理体制を文書で示せる会社を選ぶ

Swoooでは、ドキュメントがない状態からの調査・解析フェーズ（準委任）と、要件確定後の改修・再構築（請負）を分けた進め方をご提案しています。開発が止まってしまった方も、計画的な乗り換えを検討中の方も、現状の診断からお気軽にご相談ください。