開発会社を乗り換える方法【完全ガイド】準備から引き継ぎ完了まで
「今の開発会社に不満はあるが、乗り換えるのが怖い」——そう感じているのはあなただけではありません。数年かけて関係を築いてきた開発会社を変えるのは、確かに不安なことです。「引き継ぎがうまくいかなくてシステムが止まったら」「ソースコードを渡してもらえなかったら」という恐怖は、多くの発注担当者が抱える共通の悩みです。
しかし実際には、事前の準備と正しい手順を踏めば、開発会社の乗り換えは安全に進められます。むしろ問題なのは、不満を持ちながらも現状維持を続けることです。適切なタイミングで乗り換えを決断しなかった結果、費用が膨らみ続けたり、ビジネスの成長に必要な機能追加ができなくなるリスクのほうが深刻です。
秋霜堂株式会社では、「前の開発会社がドキュメントを残していない」「ソースコードが渡されなかった」という状況からの引き継ぎを多数経験してきました。そうした実際の現場経験から言えるのは、最も大切なのは「正しい順序で動くこと」 だということです。
本記事では、開発会社の変更を検討されている方向けに、乗り換えを決断すべき判断基準から準備、引き継ぎプロセス、完了後の安定化まで、ステップごとに解説します。この記事を読み終えたとき、「今週から動き出せる」という確信が持てるはずです。
目次
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
こんな方におすすめです
今すぐ開発会社を乗り換えるべき5つのサイン
開発会社との関係に漠然とした不満を抱えていても、「それでも乗り換えるほどのことか」と迷ってしまうことがあります。しかし、以下のサインが当てはまるようであれば、乗り換えを真剣に検討すべきです。
品質・納期の問題（同じバグが繰り返す、約束が守られない）
開発したシステムに同じようなバグが繰り返し発生している場合、それは根本的な品質管理の問題を示しています。バグを修正するたびに別の箇所が壊れる、納品後すぐに不具合が見つかるといったサイクルが続くのは、システムの設計やテスト体制に問題がある可能性が高いです。
また、「○週間で対応します」という約束が守られないことが常態化している場合も要注意です。スポットの遅延は許容できますが、繰り返す遅延は信頼関係の破綻を意味します。
コミュニケーションの問題（返信が遅い、担当者が頻繁に変わる）
質問や相談への返信が数日かかるようになっていませんか？急ぎの障害対応を依頼しても即座に動いてもらえないのは、システムの安定運用において致命的なリスクです。
担当者が頻繁に変わり、そのたびに「前の担当が退職したため、確認に時間がかかります」と言われる場合も、社内の状況として気になるポイントです。引き継ぎが適切に行われていない開発会社では、担当変更のたびにシステムの理解がリセットされ、品質が低下しがちです。
費用の問題（見積もりが不透明、継続的に値上がりする）
毎年の保守費用が上がり続けているのに、その根拠が説明されないという状況は問題です。「システムが複雑になったので」「人件費が上がったので」という曖昧な説明では、費用の妥当性を判断できません。
また、小さな機能追加のたびに大きな追加費用を請求される場合、実態として「このベンダーから離れると困る」という状況を意図的に作られている可能性があります。
技術力・将来性の問題（最新技術への対応拒否、ドキュメントがない）
「この技術は対応していません」という回答が増えてきた場合、技術的なアップデートに追い付いていない可能性があります。セキュリティパッチの適用、フレームワークのバージョンアップ、クラウドへの移行など、時代に合わせた対応が必要な場面で柔軟に動いてもらえないのは、長期的なリスクです。
システムの仕様書や設計書がない、あるいはすでに実態と乖離した古いドキュメントしかないという状況も、将来の乗り換えを困難にする予兆です。
ベンダーロックインのサイン（ソースコードを渡してくれない、仕様が自社に共有されない）
最も深刻なサインは、開発したシステムのソースコードや仕様書を「渡せない」と言われることです。技術的な詳細が既存のベンダーだけに集中し、発注者側には何も共有されていない状態は、意図的かどうかに関わらず「ベンダーロックイン」の状態です。
ベンダーロックインに陥っていると、仮に別の会社に乗り換えたいと思っても「既存ベンダーしかシステムの詳細を知らない」「既存システムの機能に関する権利が既存ベンダーに帰属している」という状況で選択肢が狭まります（公正取引委員会: 官公庁における情報システム調達に関する実態調査について）。
これらのサインが複数重なっている場合、現状維持のコストよりも乗り換えのコストのほうが、長期的には明らかに低くなります。
乗り換え前に必ずやること——準備フェーズの全チェックリスト
乗り換えを決意したら、次は「既存ベンダーに連絡する前の準備」が最重要です。多くの乗り換え失敗は、準備不足のまま交渉を始めてしまうことから起きます。
ソースコードと知的財産権の確認（誰が所有権を持っているか）
最初に確認すべきは、開発したシステムのソースコードの著作権が誰に帰属しているかです。
日本の著作権法では、契約で明記されていない場合、ソースコードの著作権は「作った側（ベンダー）に帰属する」 のが原則です（システム幹事: システム開発の著作権とは）。これは多くの発注者が誤解しているポイントです。「お金を払ったのだから自分のもの」とはならないのです。
契約書を確認し、以下のいずれかが明記されているかを確認してください：
- 「著作権は発注者（甲）に帰属する」
- 「著作権はベンダー（乙）が保持するが、発注者は使用・改変の許諾を得る」
- 「著作権は甲乙で共有する」
著作権がベンダーに帰属する契約であっても、「使用許諾（ライセンス）」が発注者に与えられていれば、引き続きシステムを利用することは可能です。ただし、改変（機能追加・バグ修正）については別途許諾が必要になる場合があります（ビジネスロイヤーズ: 開発委託したプログラムの変更）。
契約書で著作権の帰属が明確でない場合は、専門の弁護士や法律家への相談を検討してください。
契約書の解約条項と違約金の確認
現在の契約書に記載されている「解約通告期間」と「違約金」の条件を確認します。多くの開発保守契約では、契約終了の3ヶ月〜6ヶ月前に通告が必要とされています。この期間を守らずに解約を通告すると、違約金が発生するケースがあります。
確認すべき項目：
- 解約通告に必要な事前期間
- 解約時の違約金の有無と金額
- 途中解約の際のデータ・ソースコードの引き渡し義務の有無
- 引き渡しにかかる費用の負担について
現在のシステムのドキュメント状況の確認
乗り換え先の開発会社がシステムを引き継ぐ際に必要となるドキュメントの現状を把握します。以下の項目がどの程度整備されているかを確認してください。
書類の種類 |
あり/なし |
|---|---|
要件定義書・仕様書 |
|
システム設計書（基本設計・詳細設計） |
|
データベース設計書（ER図、テーブル定義） |
|
インフラ構成図 |
|
運用マニュアル |
|
ソースコード（バージョン管理の有無） |
|
テスト仕様書・テスト結果 |
ドキュメントが整備されていない場合でも、乗り換えが不可能なわけではありません。後述のリバースエンジニアリングという手法で引き継ぎに対応できる会社もあります。ただし、その分の初期費用は増加します。
運用中のサーバー・インフラ情報の整理
システムが動いているサーバーやクラウドサービスのアカウント情報が、発注者側で把握できているかを確認します。
- サーバーはどこのクラウド（AWS、GCP、Azure 等）か
- そのアカウントは誰（発注者？ベンダー？）が持っているか
- ドメインの管理は誰が行っているか
- SSL証明書の更新担当者は誰か
アカウントがベンダー側にある場合、乗り換え時に「アカウント移管」が必要になります。移管を拒否されるケースは稀ですが、事前に把握しておくことが重要です。
新しい開発会社の選び方——乗り換え先を見誤らないための評価基準
準備が整ったら、次は乗り換え先の選定です。ここで失敗すると「また同じ苦労をする」ことになりかねません。
他社開発システムの引き継ぎ実績の確認方法
最重要の評価基準は、「他社が開発したシステムの引き継ぎ・保守移管の実績があるか」です。自社開発のシステムを保守することと、他社が作ったシステムを引き継いで保守することは、難易度が大きく異なります。
実績を確認する際は、会社のWebサイトの「サービス一覧」や「事例紹介」を確認し、「保守移管」「他社からの引き継ぎ」「引き継ぎ開発」という実績が掲載されているかを確認してください。面談では「他社が開発したシステムの引き継ぎ経験はありますか？」と直接聞くことも有効です。
初回見積もりの透明性と初期調査費用の妥当性
引き継ぎの見積もりを依頼した際に、「初期調査費用」を明確に提示する会社は信頼できます。他社が開発したシステムを引き継ぐには、まずソースコードや既存の設計を調査する時間が必ず必要です。この費用を最初から「無料」と言う会社は、後から費用が膨らむリスクがあります。
初期調査費用の相場は、システムの規模にもよりますが、数十万円から数百万円程度が一般的です。調査の結果、保守継続の費用や方針が明確になります。
担当チームの体制（個人ではなくチームか）
担当者が1人のフリーランスや、実質1人で対応する会社への発注は避けましょう。担当者が退職・入院した際に即座に対応不可になるリスクがあります。少なくとも複数人のチームで対応してもらえる体制かどうかを確認してください。
窓口のレスポンス速度とコミュニケーションスタイルの確認
見積もり・問い合わせへの返信速度は、実際の保守対応のスピードと直結することが多いです。初回の問い合わせから見積もり提示までの期間、そして面談後のフォローアップの速度を観察してください。
コミュニケーションツール（Slack, メール, 電話等）や定例MTGの頻度について、事前に合意を取っておくことも重要です。
引き継ぎプロセスの進め方——失敗しない4つのフェーズ
実際の引き継ぎは4つのフェーズに分けて進めます。焦らず順序通りに進めることが成功の鍵です。
フェーズ1: 既存ベンダーへの通知前の情報収集
既存ベンダーに「乗り換えを検討している」と伝える前に、まず手元にある情報を最大限に収集・整理します。
- 過去の請求書・見積書を全て収集し、費用の推移を把握する
- 契約書のコピーを確保する（原本がベンダー側だけにある場合は、コピーを依頼する）
- 現在稼働しているシステムのURLや機能一覧をリスト化する
- 日常的に使っている操作手順や業務フローを文書化しておく
ポイント: この段階で既存ベンダーに「乗り換えを検討している」と伝える必要はありません。情報収集は粛々と進めましょう。
フェーズ2: 新ベンダーによる現状調査と引き継ぎ計画の策定
乗り換え先候補が決まったら、既存ベンダーへの通告前に、新ベンダーによる現状調査を進めます（ただし既存ベンダーの協力が必要な場合は、このタイミングで開示することになります）。
新ベンダーが行う調査の内容：
- ソースコードのレビュー（技術的負債の確認）
- データベース構造の把握
- インフラ・サーバー構成の確認
- 既存の業務フローとシステムの整合確認
調査が完了すると、「引き継ぎ計画書」が作成されます。この計画書には、引き継ぎに必要な期間・費用・リスクが明記されます。この計画書の内容を理解してから、既存ベンダーへの正式な解約通告を行うのが最も安全な順序です。
フェーズ3: 並行運用期間（既存ベンダーと新ベンダーが同時に稼働する期間）
引き継ぎの最も安全な方法は「並行運用」です。一定期間、既存ベンダーと新ベンダーが同時に稼働し、システムの知識を移管します。並行運用期間の目安はシステムの規模にもよりますが、1ヶ月〜3ヶ月程度が一般的です（NOVEL株式会社: 保守移管とは）。
並行運用期間にやること：
- 新ベンダーが既存ベンダーの対応を観察・記録する
- 日常的な問い合わせを新ベンダーが試験的に対応してみる
- 新ベンダーがドキュメントを整備・更新する
- 障害対応のフローを新ベンダーが把握する
並行運用は費用が二重にかかりますが、「引き継ぎ後に問題が発覚して即座に困る」リスクを大幅に減らせます。予算を組む際は、この並行運用期間のコストを事前に織り込んでおきましょう。
フェーズ4: 完全移行と安定化確認
並行運用期間が終了し、新ベンダーが単独で対応できる状態になったら、完全移行です。
完全移行の際の確認事項：
- インフラ・サーバーのアカウント情報が新ベンダーに移管されているか
- ドメイン・SSL証明書の管理権限が適切な側に移っているか
- 緊急連絡先・障害対応フローが文書化されているか
- バックアップの取得・確認が新体制で動いているか
完全移行後も、最初の1〜2ヶ月は以前よりも密に状況を確認し、問題が起きたらすぐに対処できる体制を維持することを推奨します。
引き継ぎで揉めやすいポイントと対処法
実際の引き継ぎでは、以下のようなトラブルが起きることがあります。事前に対処法を知っておくことで、冷静に対応できます。
既存ベンダーが協力的でない場合の交渉方法
稀ではありますが、解約の意思を伝えた後、対応が著しく遅くなる、情報共有を拒否されるというケースがあります。
まず試みるべきは、書面（メール）での正式な要請です。口頭ではなく、「○月○日までにソースコードの引き渡しをお願いします」と明確に文書化します。応じてもらえない場合は、契約書の引き渡し義務の条項を根拠に改めて要請します。
それでも解決しない場合は、法律の専門家（IT専門の弁護士）への相談が有効です。IT法務に精通した弁護士であれば、契約上の権利関係を整理した上で交渉の糸口を見つけてくれます（IT法務.COM: システムベンダーの切換え）。
ソースコードの所有権が曖昧な場合の対処
契約書にソースコードの著作権について明記がない場合、交渉によって解決を図ることになります。「将来の修正作業のために、使用許諾（ライセンス）を与えてほしい」という形での合意を目指すことが、双方にとって現実的な解決策になる場合が多いです。
なお、著作権法上、プログラムの「使用」（そのまま動かすこと）は著作権の制限を受けません。改変（修正・機能追加）に著作権者の許諾が必要になります。したがって、ソースコードを受け取れなかった場合でも、「現状維持での運用」はできます。ただしバグ修正・機能追加が一切できなくなるため、実用上は問題です。
ドキュメントがゼロの状態からの引き継ぎ（リバースエンジニアリング）
「ドキュメントが存在しない」という状況は、引き継ぎで最もよく遭遇するケースです。ドキュメントがなくても、ソースコードがあれば引き継ぎは可能です。
ソースコードを解析してシステムの仕様・動作を把握し、ドキュメントを一から作成することを「リバースエンジニアリング」と呼びます。この作業には専門的な技術力と相応の時間・費用が必要ですが、他社開発システムの引き継ぎに慣れた開発会社であれば対応できます。
注意点として、リバースエンジニアリングは時間がかかるため、完全に把握するまでには通常数ヶ月を要します。その期間中に緊急の改修が必要になる可能性もあるため、引き継ぎ計画には余裕を持たせることが重要です。
保守の引き継ぎプロセスについての詳細は、システム保守の引き継ぎで失敗しないための完全ガイドも参考にしてください。
乗り換え後の安定化チェックリスト
引き継ぎが完了したと思っても、実際には安定化まで数ヶ月かかることがあります。以下のチェックリストで状態を確認してください。
技術・システム面
- ソースコードがバージョン管理システム（Gitなど）で管理されている
- 本番・ステージング・開発環境が整備されている
- 定期バックアップが自動実行されており、復元テストを実施済み
- 監視・アラートが設定されており、障害時に通知が届く
- SSL証明書の有効期限と自動更新の設定が確認済み
運用・体制面
- 緊急連絡先（担当者・エスカレーション先）が文書化されている
- 障害発生時の対応フロー（連絡先・手順）が定義されている
- 定期メンテナンス（セキュリティアップデート等）のスケジュールが決まっている
- 月次の定例レポートや定期ミーティングが設定されている
ドキュメント面
- システム仕様書・設計書が最新状態に更新されている
- 操作マニュアルが現状に合わせて更新されている
- 重要なアカウント・パスワード情報が発注者側でも管理されている
これらのチェックリストがすべて埋まったとき、乗り換えは「完了」といえます。
まとめ——乗り換え判断チェックリストとスケジュールテンプレート
乗り換え判断チェックリスト
以下の項目が3つ以上当てはまる場合、乗り換えを真剣に検討する時期です。
サイン |
当てはまる？ |
|---|---|
バグや不具合が繰り返し発生している |
□ |
連絡・返信に3営業日以上かかることがある |
□ |
毎年の費用が根拠なく上がり続けている |
□ |
機能追加の見積もりが毎回高くて驚く |
□ |
担当者が1年以内に複数回変わった |
□ |
ソースコードや仕様書の開示を求めても応じてもらえない |
□ |
「この技術には対応していない」という回答が増えてきた |
□ |
開発会社への依存度が高く、乗り換えたくても怖くて動けない |
□ |
引き継ぎスケジュールの目安
フェーズ |
期間の目安 |
主な作業 |
|---|---|---|
準備フェーズ |
1〜2ヶ月 |
契約書確認・ドキュメント整理・乗り換え先の選定 |
現状調査フェーズ |
2〜4週間 |
新ベンダーによるソースコード・インフラ調査 |
並行運用フェーズ |
1〜3ヶ月 |
旧ベンダー・新ベンダーの同時稼働・知識移管 |
完全移行・安定化 |
1〜2ヶ月 |
新体制での独立稼働・安定化確認 |
合計 |
5〜11ヶ月 |
システムの規模によって大きく異なる |
開発会社の乗り換えは、決して簡単ではありませんが、不可能でもありません。最も大切なのは、「怖いから動かない」という選択をしないことです。不満を抱えたまま現状維持を続けるほうが、長期的には費用も品質も悪化します。本記事のチェックリストとスケジュールを手元に置き、まず「準備フェーズ」から動き始めてみてください。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
こんな方におすすめです
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
