システム引き継ぎの進め方｜開発会社を乗り換える前に確保すべきものと手続きの順番

開発会社を替えたいと思ったら、解約より先に「持ち出せるもの」を確かめる

問い合わせへの返事が遅い、見積もりの根拠が分からない、仕様を知っていた担当者が辞めてしまった。外部の開発会社に作ってもらったシステムを抱える発注担当者が「そろそろ別の会社に替えたい」と考え始めるきっかけは、たいていこうした不満の積み重ねです。

このとき、最初にやりがちなのが今の会社への解約の相談です。しかし順番を誤ると、ソースコードや本番環境のアカウントを受け取れないまま関係だけが終わり、新しい会社はシステムに手を付けられなくなります。システムの引き継ぎで最初に確かめるのは、新しい会社の候補ではなく、自社がいま何を手元に持っているかです。

システム引き継ぎとは、システムの保守・運用・追加開発の担い手を、別の組織や担当者へ移すことです。本記事ではそのうち、外部の開発会社から別の会社へ移す場合を対象に、確保すべき資産と契約書で見る条項、そして資産の確保・現状調査・並行期間・切り替えの 4 段階の手続きを整理します。社内の担当者の退職や異動に伴う引き継ぎは扱いません。不満の原因が業者にあるのか発注体制にあるのかを先に見極めたい場合は、システム導入が失敗する 12 の兆候 もあわせて読んでみてください。

乗り換えを考えるサインと、替えても解決しない不満

開発会社を替えるタイミングは、不満の大きさではなく、不満の原因が今の会社との関係の中で直せるかどうかで判断します。代表的なサインを、乗り換えで解決する見込みとあわせて並べます。

サイン	背景にありがちな原因	乗り換えで解決するか
仕様を知る担当者が退職し、後任が把握していない	知識が個人に閉じ、文書が残っていない	解決しやすい。ただし引き継ぐ側も調査から始まる
軽微な修正にも時間と費用がかかる	コードの構造、テスト不足、体制の縮小	構造が原因なら、会社を替えても遅さと費用は残るため、調査で見極める
見積もりの内訳を聞いても説明がない	作業範囲の前提が文書になっていない	解決しやすい
本番環境の状態を誰も説明できない	構成が手作業で作られ、記録がない	引き継ぎの難易度が上がる。アカウントと構成情報の確保を急ぐ
要望が伝わらず、作り直しが続く	発注側の要件の渡し方にも原因がある	発注側の進め方を変えないと再発する
連絡がつかない、事業を縮小している	保守の担い手がいなくなる見込みが出ている	急いで資産を確保し、乗り換えを進める

表のうち「発注側の進め方を変えないと再発する」に当たる不満は、会社を替えるだけでは解消しません。一方、担当者の退職や連絡が取れない状態は、放置するほど資産を受け取る機会が減るため、早めに動く理由になります。開発が途中で止まったまま連絡が取れない場合の進め方は、システム開発の失敗から立て直す で扱っています。

もう 1 つ、何を別の会社に移すのかも先に決めます。選択肢は大きく 3 つです。

移すもの	向いている状況	詳しく扱う記事
保守・運用だけ	システムに大きな不満はなく、日々の対応だけを見直したい	システム保守の引き継ぎ
保守と追加開発のすべて	今後も機能を育てたいが、今の会社との関係を終えたい	本記事
システムそのもの (作り直し)	構造や技術が古く、直すより作り直すほうが安い	システムリプレイスの進め方

どれを選ぶかは、後述する現状調査の結果で決め直してかまいません。最初の段階では「保守と追加開発を移す」を前提に資産を確保しておくと、どの選択肢にも対応できます。

システム引き継ぎの全体像は、資産の確保、現状調査、並行期間、切り替えの 4 段階

開発会社の乗り換えは、次の 4 段階で進めます。段階ごとに完了条件を決め、満たしてから次へ進むのが原則です。

flowchart LR
  A["資産の確保<br/>(自社で実施)"] --> B["現状調査<br/>(新しい会社)"]
  B --> C{"引き継げるか"}
  C -->|引き継ぐ| D["並行期間<br/>(新旧 2 社)"]
  C -->|作り直す| R["リプレイスの計画へ"]
  D --> E["切り替え<br/>(旧会社の権限を削除)"]

段階	やること	完了条件の例
資産の確保	ソースコード、アカウント、ドメイン、データ、文書、契約書を集める	自社の管理者アカウントで、すべてにログインできる
現状調査	新しい会社がコード、構成、運用を読み、引き継ぎ計画を作る	引き継げる範囲、リスク、並行期間の計画と見積もりが文書で出ている
並行期間	旧会社から手順を受け取り、新しい会社が実際の作業を一巡させる	新しい会社が単独で修正からリリースまでを完了し、障害時の連絡先も決まる
切り替え	保守の窓口を移し、旧会社のアクセス権を外す	旧会社のアカウントと鍵が残っていないことを確認済み

発注側がこの順番を握っておくと、「まだ調査も終わっていないのに解約日だけ決まっている」という状態を避けられます。解約予告期間が長い契約なら、その期間を並行期間に充てる計画も立てられます。

関係を切る前に確保する 7 つの資産

引き継ぎで最も取り返しがつかないのは、今の会社との関係が終わった後に、必要なものが手元にないと分かることです。解約を伝える前に、次の 7 つが自社の管理下にあるかを確かめます。

資産	確認すること	手元にないと起きること
ソースコードとリポジトリ	本番で動いている版がどこにあるか。リポジトリの管理者権限が自社にあるか	修正も機能追加もできない
クラウドやサーバーのアカウント	契約名義、管理者のメールアドレス、支払い方法が誰のものか	本番環境を操作できず、請求も止められない
ドメインと DNS、証明書	ドメインの登録者名義と、管理画面にログインできる人	サイトやメールの向き先を変えられない
外部サービスの契約と API キー	決済、メール配信、地図、認証などの契約名義と鍵の保管場所。請求サイクル、契約更新日、先方の連絡先	切り替え後に外部サービスとの連携が止まり、鍵を作り直すまで機能が使えない
データとバックアップ	契約上の権限を確認したうえで、本番データベースの最新バックアップを自社で取得・保管できるか	データ移行ができず、障害時に復元もできない
設計書、運用手順、障害履歴	どの文書があり、実態とずれていないか。使っている言語・フレームワーク・ミドルウェアとそのバージョン	調査に時間がかかり、過去に起きた障害を繰り返す
契約書と発注書	著作権の帰属、納入物の範囲、解約と引き継ぎ協力の条項	受け取れるはずのものを請求する根拠がない

リポジトリは、開発会社の組織アカウントに置かれていることがよくあります。GitHub であれば、リポジトリを自社の組織へ移管する機能があり、Issue や Pull Request、コミット履歴もあわせて移ります (GitHub Docs)。移管には送り出す側と受け取る側の両方に権限が必要なので、今の会社の協力が得られるうちに済ませます。ただし、リポジトリに登録された Webhook、シークレット、デプロイキーは移管後もリポジトリに残るため、旧会社が登録した鍵や通知先は切り替えの段階で洗い出して削除します。

クラウドのアカウントも同様です。たとえば AWS では、アカウント作成時のメールアドレスとパスワードで入るルートユーザーが、アカウント内のすべてのサービスとリソースに完全なアクセス権を持ちます (AWS IAM ユーザーガイド)。このメールアドレスが開発会社の社員のものなら、本番環境の最終的な管理権限は自社にありません。

契約書で確認する条項 ─ 著作権の帰属と、解約・引き継ぎの定め

資産の確保と並行して、契約書を読み直します。ここでは乗り換えの判断に直結する条項だけを挙げます。

なお、本節は一般的な確認点の整理であり、個別の契約についての法的助言ではありません。解釈に迷う条項や、相手と主張が食い違う場合は弁護士に相談してください。

著作権がどちらに帰属するか

納入物の著作権が発注者と開発会社のどちらにあるかで、乗り換え後に別の会社が改修できる範囲が変わります。「著作権を譲渡する」とだけ書いた契約では、改修に関わる権利が開発会社に残ると推定されます (著作権法 第 61 条第 2 項)。条文と確認の仕方、ソースコードを渡してもらえないときの対応は システム開発の著作権は誰のもの？ で扱っています。

解約と引き継ぎ協力の定め

契約の型によって、解約のルールも異なります。民法では、委任 (準委任にも準用) は各当事者がいつでも解除できる一方、相手方に不利な時期に解除した場合などは、やむを得ない事由がない限り損害賠償の責任を負います。請負は、仕事が完成するまでは注文者が損害を賠償して解除できます (民法 第 641 条・第 651 条・第 656 条)。実際の契約では、これに加えて解約予告期間や精算方法が定められていることが多いため、条文より契約書の記載を先に確認します。

あわせて、契約終了時の資料の返還、納入物の引き渡し、引き継ぎへの協力義務が書かれているかも見ます。準委任と請負の違いは 準委任と請負の違い で、次の発注で同じ状況にならないための条項は ベンダーロックインを避ける発注設計 で整理しています。

新しい会社に最初に頼むのは、機能追加ではなく「現状調査」

乗り換え先を選ぶ段階から、最初の発注は現状調査にすると決めておきます。いきなり機能追加や保守契約を結ぶと、引き継ぐ側はシステムの中身を知らないまま金額と期限を約束することになり、後から追加費用や遅延が出やすくなります。

引き継ぎ先を選ぶときに確かめること

候補の会社との面談では、次の 6 点を質問として聞きます。回答が文書で返ってくるかも、あわせて見ておきます。

面談で聞くこと	確かめる理由
今のシステムの言語・フレームワーク・バージョンを扱えますか	扱えない会社に移すと、引き継いだ後で直せる人がいないと分かる
他社が作ったシステムを、どのような進め方で引き受けますか	調査から始める提案が出るか、いきなり保守の見積もりを出すかを見分ける
現状調査だけを単独で発注できますか	調査の結果を見てから、引き継ぐかどうかを決められる
引き継ぐ場合と作り直す場合を比べて出せますか	どちらか一方しか提案できない会社では、比較の材料がそろわない
引き継ぎ後の保守と追加開発まで担えますか	調査と並行期間だけで手を離されると、再び依頼先を探すことになる
見積もりの前提と作業範囲を文書で出せますか	今の会社への不満と同じ「内訳が分からない」を繰り返さないため

1 つ目の質問には、7 つの資産を確かめたときに整理した言語・フレームワーク・バージョンを伝えたうえで答えてもらいます。

現状調査で出してもらう成果物と費用

成果物の例は次のとおりです。

成果物	中身
システム構成の整理	サーバー、データベース、外部サービス、ドメインのつながりを図にしたもの
機能と業務ルールの一覧	どの画面・処理が何をしているか、コードから読み取った業務ルール
リスクの一覧	テストがない箇所、サポートが終わった技術、秘密情報の置き場所など
引き継ぎ計画と見積もり	並行期間でやること、完了条件、期間と費用
引き継ぐか作り直すかの提案	直して使い続ける場合と、作り直す場合の比較

調査にあたっては、秘密保持契約を結んだうえで、ソースコードの閲覧権限と、本番環境の読み取り専用の権限を渡します。本番のデータに触れる必要がある場合は、個人情報を含むかを確認し、渡し方を決めてから共有します。

費用感については、規模の異なるシステムに共通して当てはまる相場を示すことはできません。調査と引き継ぎ全体の金額と期間を左右するのは、コードの量、外部サービスとの連携の数、文書の有無、本番環境にアクセスできるか、旧会社が説明に協力するか、そして調査の深さです。比較しやすくするには、「何週間で、どの成果物までを出すか」を先に決め、調査を独立した小さな発注として見積もってもらいます。範囲を決めにくい作業なので、成果物の完成を約束する請負より、作業期間を区切る準委任で契約するほうがなじみます。

FIXIT

調査だけにお金を払うのって、遠回りじゃない？

Dodai

逆です。中身を調べずに出した保守の見積もりは、推測でしかありません。

FIXIT

じゃあ、調査の結果「引き継げない」ってなることもあるの？

Dodai

あります。その判断が保守契約の前に出ることが、調査を先に頼む意味です。

仕様書がないなら、AI でコードを読み解く選択肢がある

引き継ぎの相談では、仕様書が最初から存在しないケースや、あっても実態と食い違っているケースが珍しくありません。この場合でも、ソースコードと本番環境にアクセスできれば、現行仕様を組み立て直せます。

最近は、AI エージェントにコードベースを読ませ、機能の一覧、データの流れ、コードに埋め込まれた業務ルールの候補を書き出させる方法が使えます。人がすべてのファイルを読むより早く全体像をつかめるため、現状調査の期間を短くできる可能性があります。

ただし、AI が読み取れるのはコードがどう動くかまでです。「特定の取引先だけ締め日が違う」という処理が今も有効なルールなのか、過去の特例の名残なのかは、コードだけでは分かりません。業務上の意味を発注側の担当者が確かめる工程を、必ず入れます。読み解きの具体的な手順と、AI が読めるもの・読めないものの境界は 仕様書のないレガシーを AI で読み解く で解説しています。

一方、ソースコードそのものが手元にない場合、AI で補える範囲は限られます。画面の操作やデータベースの中身から仕様を推定することはできても、同じシステムを直して使い続けることはできません。この場合は、ソースコードの引き渡しを求めるか、作り直しを検討するかの判断になります。

並行期間と切り替えの進め方 ─ 手続きの順番

現状調査で引き継ぐと決めたら、並行期間に入ります。並行期間は、旧会社と新しい会社の両方が関わる期間です。ここでの目的は、文書を受け取ることではなく、新しい会社が単独で運用できることを実際の作業で確かめることにあります。

並行期間の長さは、月次の締め処理のように定期的に動く処理と本番へのリリースを、新しい会社が少なくとも 1 回ずつ経験できるように決めます。そのうえで、旧会社の解約予告期間と重ねて計画します。

手続きの順番は、次のとおりに進めると抜けが出にくくなります。

1. 旧会社に、解約日と、並行期間中に依頼する引き継ぎ作業を書面で伝える
2. 引き継ぎ作業の範囲と費用の扱いを旧会社と合意する (契約に協力義務がなければ、別の作業として発注する)
3. 旧会社から、デプロイ手順、定期的に動く処理、障害時の対応手順を説明してもらう
4. 新しい会社が、小さな修正を開発から本番リリースまで一巡させる
5. 障害時の一次連絡先を新しい会社に切り替え、社内の関係者に周知する
6. 旧会社のアカウント、SSH 鍵、API キー、リポジトリへのアクセス権を削除し、必要な鍵は作り直す
7. 保守の窓口と請求の切り替えを確認し、旧会社との契約を終了する

手順 4 を省くと、切り替え後に初めてデプロイを試して失敗する、という事態が起きます。

旧会社への協力依頼は有償になることが多く、費用と範囲の決め方は システム保守の引き継ぎ で扱っています。

FIXIT

今の会社に「替えます」って言いにくいんだけど、どう伝えればいいの？

Dodai

感情は書かず、解約日と依頼する作業を書面で淡々と伝えます。そのほうが揉めません。

切り替えにあわせてサーバーの移設やデータベースの移行を行う場合は、データ移行のリハーサルを別の計画として立てます。進め方は データ移行で失敗しないための ETL リハーサル を参考にしてください。切り替え後の保守費の妥当性は 保守・運用・追加開発の見積 の観点で確認できます。

システム乗り換えのリスク ─ よくある 5 つの失敗と回避策

最後に、開発会社の乗り換えで起きやすい失敗を、回避策とあわせてまとめます。

失敗	何が起きるか	回避策
先に解約を伝え、アカウントの名義変更が進まない	本番環境や DNS を操作できない期間が生じる	7 つの資産を確保してから解約を伝える
受け取ったソースコードが本番で動いている版と違う	修正をリリースすると、過去の修正が消える	本番環境の中身とリポジトリの差分を、現状調査の項目に入れる
引き継ぎ協力を無償の好意として頼む	旧会社の優先順位が下がり、説明が進まない	協力の範囲と費用を書面で合意する
調査を飛ばし、新しい会社に機能追加を先に発注する	想定外の構造が見つかり、見積もりと期限が崩れる	現状調査を独立した発注として先に行う
切り替え後も旧会社のアクセス権と鍵が残っている	誰がいつ本番環境に触れたかを管理できない	並行期間の最後に、アカウントと鍵の棚卸しと削除を行う

どの失敗も、技術力の問題というより順番の問題です。資産の確保、現状調査、並行期間、切り替えの順を崩さなければ、多くは避けられます。

FIXIT の運用 ─ 乗り換えの相談では、最初に調べる対象を決める

AI 駆動開発のクリエイティブスタジオである FIXIT は、他社が開発したシステムの引き継ぎや、現状調査だけのご依頼、途中で止まった開発の立て直しのご相談もお受けしています。開発会社の乗り換えの相談では、保守や追加開発の見積もりより先に、何から調べるかを決めます。最初に確かめるのは、7 つの資産がそれぞれ誰の名義で手元にあるかと、リポジトリのコードが本番で動いている版と一致しているかです。ここが確かでないと、その後のコードの読み解きも見積もりも前提から崩れるためです。あわせて、契約書の権利条項と、実際のリポジトリやアカウントの名義・構成が食い違っていないかを突き合わせます。条項の法的な解釈は弁護士の領域なので、FIXIT は判断しません。

名義と版を確かめたら、AI にコードベースを読ませて全体像を書き出し、業務上の意味は発注側の担当者と一緒に確かめます。調査の結果、引き継ぐより作り直すほうが合理的だと判断すれば、その比較をお伝えします。今の開発会社と条件を見直して続けるほうがよい場合も同様です。乗り換えを前提にせず、選択肢を並べることを調査の目的にしています。

引き継ぎを決めるかどうかは、まず自社が何を持っているかを確かめるところから始まります。この記事の 7 つの資産の表を手元に置き、ソースコード、アカウント、ドメイン、データ、契約書がどこにあるかを 1 つずつ埋めてみてください。空欄が残った項目が、今の開発会社に解約を伝える前に取りに行くものです。

表を埋めたうえで、引き継げるかどうかの判断材料が欲しい場合は、システム刷新・リプレイス のサービスページをご覧いただくか、お問い合わせ から現状調査・引き継ぎについてご相談ください。契約書の中身や本番環境の状態が分からない段階でも、何を確認すればよいかの整理からお手伝いします。