開発会社を途中で変更するには：引き継ぎで確認すべき資料と手順

開発会社を途中で変更することは可能です。ただし、成否を分けるのは新しい開発会社の腕前よりも、「今の開発会社から何を、どこまで回収できるか」です。ソースコードだけ受け取っても、サーバーやドメイン、外部サービスのアカウント、設計の意図、未解決の不具合の情報が手元になければ、新しい会社はシステムを動かすことすら苦労します。引き継ぎの準備は、乗り換えを決める前から始まっていると考えてください。

結論を先にまとめると、手順は「契約と権利の確認 → 回収物の棚卸し → 旧開発会社との引き継ぎ期間の合意 → 新開発会社による調査 → 段階的な切り替え」の順です。いきなり契約を切ったり、旧開発会社との関係が悪化した状態で交渉を始めたりすると、回収できるはずのものまで回収できなくなります。感情的な対立が背景にある場合ほど、淡々と事実と必要物を整理することが大切です。

この記事は、開発途中のプロジェクトや運用中のシステムについて、開発会社の変更を検討している事業責任者・担当者に向けて書いています。変更すべきかどうかの判断基準、回収すべき資料とアカウントの一覧、引き継ぎの手順、新しい会社に最初に依頼すべきこと、よくある失敗までを順に説明します。

開発会社を変更すべきか：判断基準と、変えない方がよい場合

まず、本当に変更が必要かを見極めます。開発会社の変更は、引き継ぎの調査費用や、新しい会社がシステムを理解するまでの時間という確実なコストを伴います。不満の原因が会社そのものではなく、発注側の要件の伝え方や進め方にある場合、会社を変えても同じ問題が繰り返されます。

「費用が高い」「要望が通らない」の背景には、仕様変更の積み重ねや、契約で決めた範囲と期待のずれがあることが少なくありません。仕様変更の扱いについては開発途中の仕様変更への対応で整理しています。発注側の進め方を見直すだけで改善する余地がないかを、一度は確かめてください。

逆に、連絡がつかない、体制が維持できない、セキュリティ上の問題を放置している、といった状況は、事業の継続に直接関わります。この場合は、迷っている時間そのものがリスクになるため、変更を前提に準備を進めるべきです。保守を担う会社の切り替えに特化した観点は保守会社の切り替えも参考になります。

切り替え前に確認すること：契約・権利・アカウントの名義

回収の交渉に入る前に、手元の契約書と現状を確認します。ここが曖昧なまま話を進めると、「それは契約に含まれていない」「その権利は当社にある」というやり取りで時間を失います。

ソースコードの権利がどちらにあるか

開発委託の契約では、成果物の著作権を発注者に移すか、開発会社に残したまま利用を許諾するかを定めるのが一般的です。権利が開発会社に残っている場合や、開発会社が以前から持っている部品（共通の仕組みやライブラリ）を使っている場合は、他社に改修させてよいかが問題になります。契約書の該当条項を確認し、不明な点は法律の専門家に相談してください。権利の考え方はソースコードの著作権と権利帰属で詳しく解説しています。

契約の終了条件と、引き継ぎ協力の義務

契約の解除や終了の手続き、予告期間、終了時の資料の引き渡しや引き継ぎ協力について定めがあるかを確認します。定めがない場合でも、引き継ぎの協力は別途の有償作業として依頼できることが多いです。旧開発会社にとっても、円満に終わることは評判の面で利点があるため、協力を依頼する余地は十分にあります。

アカウントの名義が誰にあるか

見落とされやすいのがアカウントの名義です。サーバーやクラウド、ドメイン、メール配信、決済、地図、アプリストアなどのアカウントが、開発会社の名義や担当者個人のメールアドレスで作られていることがあります。名義が開発会社にあると、契約が切れた瞬間にサービスが止まったり、ドメインを失ったりする危険があります。名義と支払い元を一覧にし、発注者名義への移管を最優先で進めます。

回収すべきもの一覧：ソースコードだけでは足りない

回収すべきものは、大きく五つに分けられます。

ソースコードは、圧縮ファイルで受け取るより、Gitなどのバージョン管理の履歴ごと受け取ることが重要です。履歴があれば「いつ、なぜこの変更をしたか」を後から追えます。また、本番で動いているものとリポジトリの最新版が一致しているかを必ず確認してください。本番サーバー上で直接修正されたまま、リポジトリに反映されていないケースもあります。

環境については、本番・ステージング・開発の各環境がどう分かれているかを把握します。環境の考え方は開発環境・ステージング環境・本番環境の用語ページで説明しています。パスワードや鍵などの秘密情報は、メールやチャットに平文で貼らず、パスワード管理ツールの共有機能など安全な方法で受け渡し、受け取った後に変更します。

資料が足りないときに発注者が自分で用意できるもの

旧開発会社から十分な設計資料が出てこないことは珍しくありません。その場合でも、発注者の手元で作れる資料があります。新しい開発会社の調査を早め、推測に頼る部分を減らすために、次のものを用意しておくと役立ちます。

• 画面の一覧と操作の録画：本番の画面を一通り操作し、画面ごとのスクリーンショットや操作の録画を残します。利用者側だけでなく、管理画面も漏れなく残します。
• 業務の流れのメモ：誰が、どのタイミングで、どの画面を使って何をしているかを書き出します。システムの外で手作業している部分も書きます。
• 外部サービスと請求の一覧：毎月どのサービスにいくら払っているかを、請求書やカード明細から洗い出します。把握していなかった外部サービスが見つかる糸口になります。
• 過去のやり取りの記録：メールやチャットで合意した仕様、障害時の報告、見積書や納品書を時系列で集めます。設計資料がなくても、過去の判断の理由を追える場合があります。

これらは開発の知識がなくても作れるうえ、新しい開発会社にとっては、ソースコードを読むだけでは分からない「なぜこう作ったのか」を知る手がかりになります。

引き継ぎの手順：旧開発会社との並走期間を作る

回収と切り替えは、次の順番で進めます。

1. 回収物の一覧を作る：前述の五分類で、自社が把握しているものと把握していないものを書き出します。把握していないものこそ、旧開発会社に確認すべき項目です。
2. アカウントの名義を移す：ドメイン、クラウド、決済などの名義と支払い元を発注者に移します。サービスの停止に直結するため最優先です。
3. 旧開発会社に引き継ぎ協力を依頼する：回収物の一覧を示し、引き渡しの期限と、質問に答えてもらう期間（並走期間）を合意します。有償になる場合は範囲と費用を書面で決めます。
4. 新しい開発会社を選び、現状調査を依頼する：いきなり改修を依頼せず、まずソースコードと環境を読んで現状を報告してもらいます。
5. 新しい開発会社の環境でシステムを再現する：受け取った資料だけで、検証環境を一から構築できるかを確かめます。再現できなければ、何かが欠けています。
6. 小さな改修で引き継ぎを確認する：影響の小さい修正を一つ、新しい会社に最後までやってもらい、本番への反映まで問題なくできるかを確かめます。
7. 運用・保守の窓口を切り替える：障害時の連絡先、監視の通知先、問い合わせ窓口を新しい会社に移し、旧開発会社との契約を終了します。
8. 旧開発会社のアクセス権を外す：すべてのアカウントから旧開発会社の権限を削除し、共有していたパスワードや鍵を変更します。

並走期間中は、新しい機能の追加や大きな改修をできるだけ止めておくことをおすすめします。引き継ぎの最中にコードが変わり続けると、新しい会社が読んでいる内容がすぐに古くなり、どちらの会社がどの変更に責任を持つのかも曖昧になります。どうしても必要な修正は、旧開発会社が行うのか新しい会社が行うのかをその都度決め、変更の記録を両社で共有します。障害が起きたときの一次対応をどちらが担うかも、並走期間の開始時に決めておきます。

並走期間の長さは、システムの規模や資料の充実度によって変わるため一概には言えませんが、「新しい会社が環境を再現し、小さな改修を一度やり終えるまで」を目安に考えると、必要な期間を見積もりやすくなります。

新しい開発会社に最初に依頼すべきこと：現状調査

新しい開発会社には、改修の見積もりより先に、現状調査を依頼するのが安全です。他社が作ったシステムは、読んでみないと品質や構造が分かりません。調査をせずに改修の見積もりを出してもらうと、作業を始めてから「想定より手を入れにくい」と判明し、費用や期間が膨らむ原因になります。

現状調査では、次のような点を報告してもらいます。

• システムの構成（使っている言語、フレームワーク、データベース、外部サービス）
• ソースコードの状態（読みやすさ、テストの有無、古くなった部品の有無）
• 環境の状態（構築手順の再現性、バックアップ、監視の有無）
• セキュリティ上の懸念（更新されていない部品、秘密情報の扱い）
• 今後の選択肢（このまま保守する、部分的に直す、作り直す）と、それぞれの考え方

資料が少なく、中身が分からない状態になっているシステムは、いわゆるブラックボックスです。その場合の進め方はブラックボックス化したレガシーシステムへの対応で解説しています。調査の結果、作り直した方が合理的という判断になることもありますが、その判断は調査の後に行うものです。

新しい会社を選ぶときの確認点

途中からの引き継ぎは、新規開発とは違う力が要ります。候補の会社には、次の点を確認するとよいでしょう。

• 他社が作ったシステムの引き継ぎを手がけたことがあるか、そのときどう進めたか
• 現状調査をどのような観点で、どれくらいの期間で行うか
• 調査の結果、自社の得意な技術に作り直すことを前提にしていないか
• 引き継ぎ後の保守・運用の体制をどう考えているか

具体例：架空の会員制サービスの乗り換え

架空の例として、会員制の学習サービスを運営する会社が、開発会社の担当者の退職をきっかけに乗り換えを決めた場面を考えます。

最初に回収物の一覧を作ったところ、ソースコードは受け取れる見込みでしたが、次のことが分かりました。

• クラウドのアカウントは開発会社の名義で、利用料は開発会社の請求に含まれていた
• ドメインは自社名義だったが、DNSの管理画面のログイン情報は開発会社だけが持っていた
• メール配信サービスは退職した担当者個人のメールアドレスで登録されていた
• データベース設計の資料はなく、要件定義書は初期のものから更新されていなかった
• 決済の不具合が二件、未解決のまま残っていた

この会社は、まずクラウドとメール配信の名義移管を最優先で旧開発会社に依頼し、DNSのログイン情報を受け取って変更しました。次に、旧開発会社と一か月程度の質問対応の期間を有償で合意し、その間に新しい開発会社が現状調査と検証環境の構築を行いました。調査の過程で、本番サーバー上で直接修正されたファイルが見つかり、リポジトリとの差分を旧開発会社に確認して解消しました。未解決だった決済の不具合は、旧開発会社から経緯の説明を受けたうえで、新しい会社が最初の改修として対応しました。

もし名義の確認をせずに契約を終えていたら、クラウドの利用料の支払いが止まり、サービスが停止していた可能性があります。

よくある失敗とその避け方

開発会社の変更で起こりがちな失敗を挙げます。

• 先に契約を終了してしまう：契約を切ってから回収を始めると、協力を得にくくなります。回収と並走期間の合意を先に行い、契約の終了は最後にします。
• ソースコードだけで安心する：環境やアカウント、設計資料がなければ、ソースコードだけでは動かせないことが多いです。前述の五分類で確認します。
• 本番とリポジトリの差分を確認しない：本番だけに存在する修正があると、新しい会社が反映した瞬間に過去の修正が消えます。差分の確認を引き継ぎの必須項目にします。
• 秘密情報を変更しない：引き継ぎ後も旧開発会社が本番に入れる状態を放置すると、セキュリティ上の問題になります。最後に必ず権限の削除とパスワード・鍵の変更を行います。
• 新しい会社にいきなり大きな改修を頼む：現状を理解する前の大きな改修は失敗しやすくなります。調査と小さな改修を経てから本格的な開発に入ります。
• 旧開発会社を一方的に責める：対立が深まると、引き継ぎに必要な説明を得られなくなります。不満は不満として、引き継ぎの場では事実と必要物に集中します。

引き継ぎ完了のチェックリスト

• 全リポジトリを変更履歴ごと受け取り、本番との差分がないことを確認した
• ドメイン、DNS、クラウド、メール配信、決済、外部API、アプリストアの名義と支払い元が自社になっている
• 新しい開発会社が、受け取った資料だけで検証環境を構築できた
• バックアップの場所と復元手順を確認し、一度は復元を試した
• 既知の不具合と対応中の要望の一覧を受け取った
• 新しい開発会社が小さな改修を本番に反映できた
• 障害時の連絡先と監視の通知先を切り替えた
• 旧開発会社のアクセス権を削除し、パスワードと鍵を変更した

よくある質問

Q. 旧開発会社がソースコードの引き渡しを拒んだらどうすればよいですか？

まず契約書で権利と引き渡しの定めを確認します。契約上引き渡しを受けられるはずなのに応じてもらえない場合や、契約に定めがなく交渉がまとまらない場合は、早めに法律の専門家に相談してください。並行して、自社で取得できる情報（公開されている画面、データベースのデータ、アカウントの情報）を整理しておくと、最悪の場合に作り直す判断の材料になります。

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

システムの規模、資料の充実度、旧開発会社の協力度によって大きく変わります。期間を見積もるには、新しい開発会社に現状調査を依頼し、その結果をもとに判断するのが確実です。並走期間は、新しい会社が環境を再現し、小さな改修を一度終えるまでを目安にすると、不足を防ぎやすくなります。

Q. 途中で変えるより、最初から作り直した方が早いことはありますか？

あります。資料がほとんどなく、ソースコードの品質も低く、今後も大きな機能追加を予定している場合は、作り直しの方が合理的なこともあります。ただし、作り直しにもデータ移行や業務の切り替えという大きな負担があります。現状調査の結果を見てから比較してください。

Otsumuに相談できること

旧開発会社との関係が良好で、資料もそろっており、引き継ぎ協力に前向きな場合は、この記事の手順とチェックリストに沿って、新しい開発会社と一緒に自社で十分に進められます。特にアカウントの名義確認と移管は、外部の力を借りなくても今日から始められることです。

一方で、資料がほとんどなく中身が分からない場合、旧開発会社と連絡がつきにくい場合、事業が動いている最中で止められないサービスを抱えている場合は、引き継ぎの経験がある外部の力を借りた方が安全です。何を回収すべきかの判断や、現状調査の観点の設計には、作り手としての知見が必要になるからです。

Otsumuは、他社が作ったシステムの現状調査から、引き継ぎ計画の作成、保守・改修、必要に応じた作り直しの判断までを一気通貫で支援しています。運用中のシステムの保守の切り替えは保守・運用、作り直しを含めた検討はリプレイス、開発全般はシステム開発をご覧ください。

「今の状態で何が回収できていないか分からない」という段階でも構いません。手元の契約書や資料の状況を伺いながら、優先して確保すべきものを一緒に整理します。まずは30分の無料相談でお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01