記事一覧に戻る
発注・準備

開発会社を変更するときの手順と注意点|ベンダー切り替えで失敗しないための完全ガイド

2026年5月2日 約5分で読めます
この記事のポイント
  • 開発会社の切り替えは「著作権確認→引き継ぎ→新会社選定→並行稼働」の4ステップで進める
  • 契約書の著作権条項の確認が最初の必須作業(確認しないと引き継ぎ不可になることも)
  • 移行コストはシステム規模により50〜300万円程度が目安
  • 切り替え後3か月が最もリスクが高い「品質確認期間」

開発会社を変更したくなる主な理由

一度システムを依頼した開発会社を変更したいと思うのは、よくあることです。実際に「ベンダー変更」「開発会社 切り替え」という検索が増えており、以下のような状況が背景にあります。

  • 担当者との連絡が取れなくなった:メール・電話への返答が遅くなり、対応の質が下がった
  • 品質への不満が続いている:バグが繰り返し発生し、根本的な改善がされない
  • 費用が高すぎる:軽微な修正でも高額な見積もりを提示される
  • 技術力の限界を感じている:新しい技術や要件に対応できない
  • 開発会社が倒産・廃業した:急遽、別会社への引き継ぎが必要になった

いずれの場合も、切り替えには一定のコストと準備が必要です。「もう限界だ」と感じたときに慌てて動くのではなく、計画的に進めることが成功のカギです。

開発会社切り替えを進める前に必ず確認すること

1. 現在の契約書を読み直す

最初に確認すべきは「現在の開発会社との契約書」です。特に以下の条項を確認してください。

  • 著作権の帰属:ソースコードの著作権が発注者(自社)にあるか、受託者(開発会社)にあるか
  • 契約解除条件:何か月前に通知が必要か、違約金はあるか
  • 秘密保持条項:引き継ぎ先に情報を開示できるか
  • 再委託の禁止規定:開発会社が下請けを使っている場合、引き継ぎへの影響があるか

著作権条項がない契約書の場合、ソースコードの著作権は開発会社(受託者)に残る可能性があります。この場合、新しい会社にソースコードを渡しての改修が法的にグレーになるため、まず現会社と著作権の取り扱いを合意してから動く必要があります。

著作権の取り決めは契約前に必ず明文化すること。曖昧なまま開発を始めると、ベンダー変更時に「コードは渡せない」と言われるトラブルになります。

2. 現在のシステム仕様書・ドキュメントの整備状況を確認する

新しい開発会社がシステムを引き継ぐために必要な資料を洗い出します。

資料重要度ない場合の影響
要件定義書新会社が要件を把握できず、再ヒアリングが必要
基本設計書・詳細設計書システム全体像の把握に時間がかかる
ソースコード一式必須引き継ぎ不可能
インフラ構成図(サーバー・DB)環境再現に手間がかかる
テスト仕様書品質確認に時間がかかる
運用手順書新会社の習得に時間がかかる
APIドキュメント外部連携があれば必須連携システムへの影響が読めない

資料が不十分な場合、新開発会社に「ドキュメント整備費用」として別途費用が発生することが多いため、事前に想定しておいてください。

開発会社切り替えの4ステップ

Step 1:現在の開発会社との合意形成(1〜2か月)

切り替えを決めたら、まず現在の開発会社に意思を伝え、引き継ぎ協力を依頼します。

  • 切り替えの意思を文書で通知(契約書の通知期限を確認)
  • 引き継ぎに必要な資料のリストアップと提供を依頼
  • 引き継ぎ期間中の作業継続と新会社への技術説明会の実施を交渉
  • 著作権・知的財産権の移転を契約変更書で明文化

多くの場合、追加費用なしでの協力は難しいため、「引き継ぎ費用」として数十万円を予算化しておくのが現実的です。

Step 2:新開発会社の選定(1〜2か月)

新しい開発会社を選ぶ際は、切り替えの背景を正直に伝えることが重要です。「前の会社からの引き継ぎ案件」として対応実績があるか、ドキュメントが不十分な場合でもコードから仕様を読み解けるか、などを確認してください。

選定時の確認ポイント:

  • 他社開発システムの引き継ぎ実績があるか
  • 使用技術スタック(言語・フレームワーク)に対応できるか
  • 保守契約のプランと対応時間が自社のニーズに合っているか
  • 担当エンジニアが継続して対応する体制か(担当者が頻繁に変わらないか)

Step 3:並行稼働期間(1〜2か月)

新旧両会社が一定期間並行して動く「並行稼働期間」を設けることで、移行リスクを大幅に下げられます。この期間中に以下を実施します。

  • 新会社によるシステム理解・環境構築
  • テスト環境での動作確認
  • 現会社から新会社への技術説明(直接引き継ぎ会)
  • エラー対応・障害対応手順の確認

Step 4:完全移行後の3か月集中モニタリング

切り替え完了後の最初の3か月が最もリスクの高い時期です。この期間は:

  • 週次の定例確認(障害件数・対応時間・未解決課題の確認)
  • SLAの遵守状況モニタリング
  • エンドユーザーからの不満・問い合わせの収集

この期間に問題を見つけて早期修正することで、「切り替えたら前より悪くなった」という状況を防ぎます。

切り替え費用の目安

開発会社の切り替えに伴うコストは、主に以下で構成されます。

費用項目目安
旧会社への引き継ぎ協力費20〜100万円
新会社によるシステム把握・環境構築30〜150万円
ドキュメント整備(仕様書がない場合)30〜100万円
並行稼働期間の追加費用10〜50万円
合計(目安)50〜300万円程度

仕様書がしっかり整備されているほど、新会社のキャッチアップコストが下がり、全体的なコストを抑えられます。「今のシステムのドキュメントが全くない」という場合は、費用が高めになることを想定してください。

切り替え失敗を防ぐためのよくある落とし穴

落とし穴1:著作権の確認をしないまま動く

ソースコードの著作権が旧会社にある場合、「コードを渡せない」と言われ引き継ぎが進まないことがあります。必ず契約書を確認し、著作権の帰属を明確にしてから次のステップへ進みましょう。

落とし穴2:急いで切り替えようとする

「早く切り替えたい」という気持ちから、引き継ぎ期間を短縮すると、新会社の理解が不十分なまま本番稼働に入り、障害が多発するリスクがあります。最低3か月は引き継ぎ期間を設けることを推奨します。

落とし穴3:コスト面だけで新会社を選ぶ

「安いから」という理由だけで選ぶと、引き継ぎ後に対応品質が低く、結局また切り替えが必要になるケースがあります。引き継ぎ実績・コミュニケーション品質・エンジニアの継続性を総合的に評価してください。

FUNBREWでは、他社開発システムの引き継ぎ・保守移管を多数手がけています。「ドキュメントがほとんどない」「前の会社が急に連絡不能になった」という緊急ケースにも対応可能です。まずは現状のシステムの状態をお知らせください。

まとめ:ベンダー切り替えは準備が成功の9割

開発会社の切り替えは「決断してから3〜6か月」のプロジェクトです。切り替えを成功させるためのポイントを再確認します。

  • まず契約書の著作権条項と解除条件を確認する
  • 仕様書・ドキュメントの整備状況を棚卸しする
  • 旧会社との合意形成に時間をかける(怒って急に切るのは危険)
  • 並行稼働期間を1〜2か月設ける
  • 切り替え後3か月は週次モニタリングを継続する

関連記事:他社開発システムの保守引き継ぎ開発会社が倒産したときの緊急対応システム保守引き継ぎの手順と注意点も合わせてご参照ください。

よくある質問
開発途中で開発会社を変更することはできますか?
可能ですが、リスクは高くなります。開発途中の切り替えでは、作業途中のコード・仕様書の引き継ぎコスト、現開発会社との契約解除に伴う費用が発生します。また、新開発会社がゼロから把握し直す期間が必要なため、追加で1〜2か月のリードタイムを見ておく必要があります。
システムのソースコードは引き継げますか?著作権はどこにありますか?
契約書の著作権条項によります。「著作権は発注者(自社)に帰属する」と明記されていれば、ソースコードを自由に別会社に渡せます。一方、契約書に著作権に関する記述がない場合は、開発した会社(受託者)に著作権が残る可能性があります。切り替え前に必ず契約書を確認し、不明な場合は法律専門家に相談することをお勧めします。
開発会社を切り替える際、移行費用の相場はどのくらいですか?
システムの規模により異なりますが、一般的に「旧システムの年間保守費用の1〜2倍」を移行コストとして見込むのが目安です。小規模システム(開発費500万円以下)なら50〜100万円程度、中規模(500〜2,000万円)なら100〜300万円程度が参考値です。仕様書が整備されているほどコストは下がります。
開発会社の切り替えにはどのくらいの期間が必要ですか?
準備から新会社による安定稼働まで、最低3〜6か月を見込んでください。具体的には「旧会社との契約解除・引き継ぎ期間(1〜2か月)」「新会社によるシステム理解・テスト(1〜3か月)」「並行稼働・安定確認(1か月)」の流れが一般的です。緊急性が高い場合でも、最低1〜2か月の移行期間は確保すべきです。
開発会社を変えたことで品質が下がるリスクはありますか?
新しい会社がシステムを完全に把握するまでの「キャッチアップ期間」に品質低下リスクが最も高くなります。リスクを下げるには、現会社からの引き継ぎドキュメントを充実させること、最初の3か月は定例確認を週次で実施すること、単発の改修よりも保守契約として継続的に対応させることが有効です。

この記事をシェア

開発会社の切り替えで押さえるべきポイントを資料化しました

コードの引き継ぎ・知的財産権の確認・移行コストなど、切り替え時に確認すべき事項を26ページの資料にまとめています。

この記事に関連するサービス

お困りごとのご相談は無料です。まずは状況をお聞かせください。

最新情報をお届けします

IT活用のヒントやお役立ち情報を定期的にお届けします。

あわせて読みたい

「システム保守引き継ぎ」に関連する記事です。

まとめ記事

他社が作ったシステムの引き継ぎは可能?費用と進め方を徹底解説

顧客側の担当者が代わったとき、プロジェクトはどうなるか|続いた案件と終わった案件の違い

2026年9月9日

引き継いだシステムで見つかるセキュリティ上の問題は何か|伝え方と費用の扱い

2026年9月9日

引き継ぎの見積もりが甘くなるのはどんなときか|調査を省いて難航した実例

2026年9月7日

保守を引き継いだ最初の1ヶ月に何をしているか|修正より先に環境を作る理由

2026年9月5日

システム引き継ぎで用意する資料は何か|実際に出てくるもの、役に立つもの、何も無いときの手がかり

2026年9月4日

他社システムの引き継ぎ・刷新をやり切ったあと、何が変わったか|協力してもらえて助かったこと

2026年9月4日

他社システムの引き継ぎを断られることがあるのはなぜか|開発会社が見ているポイント

2026年9月3日

システムを直すより作り直した方が早いと言われるのはなぜか|引き継ぎ調査で見ている状態

2026年9月2日

ソースコードがないシステムは保守を引き継げるのか|引き継ぎを断念して刷新に至った実例

2026年8月25日

テスト環境がないシステムを引き継いだら|医療系の現場で最初の半年にやったこと

2026年8月22日

引き継ぎ前の「無料リスク評価」の中身を公開|A4 2〜3枚で何がわかるか実物サンプル付き解説

2026年4月25日

仕様書なしのシステム保守引き継ぎ|ドキュメントがない場合の進め方

2026年4月10日

担当者退職時のシステム保守引き継ぎ|属人化を防ぐ5つの方法

2026年4月10日
まとめ記事

システム保守引き継ぎの手順と注意点|開発会社変更・担当者退職時の完全ガイド

2026年4月10日

開発会社が倒産・連絡不能に…システムを救う緊急保守引き継ぎの進め方

2026年4月9日

他社開発システムの保守引き継ぎ|確認すべき5つのポイントと成功の秘訣

2026年4月9日
まとめ記事

他社が作ったシステムの引き継ぎは可能?費用と進め方を徹底解説

2026年3月1日

関連記事

システム開発
2026年9月9日

顧客側の担当者が代わったとき、プロジェクトはどうなるか|続いた案件と終わった案件の違い

発注側の担当者が交代したとき何が起きるか。定例の差分説明が引き継ぎとして機能した経緯、続いた案件の共通点、終わった案件について開発会社側の視点から書いています。

システム保守
2026年9月9日

引き継いだシステムで見つかるセキュリティ上の問題は何か|伝え方と費用の扱い

引き継いだシステムで実際に見つかるセキュリティ上の問題と、その伝え方・費用の扱い。サーバーやドメインの引き受けで手間取る点まで、開発会社側の実際を書いています。

システム保守
2026年9月7日

引き継ぎの見積もりが甘くなるのはどんなときか|調査を省いて難航した実例

古いフレームワークで作られたサービスを引き継いだ案件で、調査を省いたために見積もりが甘くなり難航した実例。難航の兆候、増員できないままスケジュールが伸びた経緯、顧客との関係に残ったものを書いています。

システム保守
2026年9月5日

保守を引き継いだ最初の1ヶ月に何をしているか|修正より先に環境を作る理由

他社から保守を引き継いだ直後、開発会社が最初にやるのは調査結果のドキュメント化と検証環境の構築です。修正より先に環境を作る理由と、アプリを触らない保守なら開発会社でなくてよい理由を書きました。

相談のハードル、下げました

まずは気軽にご相談ください

「まだ具体的に決まっていない」「とりあえず話を聞きたい」でも大丈夫。プロトタイプを見ながら、一緒にアイデアを形にしていきましょう。

相談無料 オンライン対応 1週間でプロトタイプ