開発会社を変更する手順。関係を壊さず引き継ぐ

保守の返事が遅いです。見積もりの根拠が分かりません。担当者を替えても会話が進みません。

開発会社の変更を考え始めたとき、僕なら新しい会社へ先に発注しません。現行の契約、管理画面、ソースコード、データ、外部連携を自社で確認できる状態へ戻す作業から始めます。

乗り換えは、取引先を一社替えるだけの話ではありません。旧会社が持つ知識と操作手段を自社へ移し、新会社が小さな変更と復旧を実行できてから切り替える移行プロジェクトです。辞める意思を伝えるより、引き継ぎの合格条件を決めるほうが先です。

開発会社の変更は、解約通知より棚卸しを先にします

最初に開く資料は、新会社の提案書ではなく、現行会社との基本契約書、個別契約書、見積書、発注書、検収記録です。契約期間、更新日、通知期限、未検収の作業、保守範囲、終了時の成果物を一枚のメモへ写します。口頭で頼んだ追加作業も、メールや課題管理ツールから拾います。

契約書の表題だけで、終了条件を決めてはいけません。請負、準委任、保守契約が一つの案件に混在する場合もあるため、実際の業務と条項を合わせて確認します。

2026年7月11日の更新時点で、e-Gov法令検索の民法641条、651条、656条には、請負人が仕事を完成する前に注文者が損害を賠償して解除できる原則、委任を各当事者が解除できる原則、委任の規定を準委任へ準用する規定があります。相手方に不利な時期の解除など、損害賠償が問題になる場合も条文に定められています。

法定の原則だけを読んでも、個別案件の通知方法、支払額、未完成部分の扱いは決まりません。締結済みの条項と実際の作業を弁護士へ見せ、通知前に確認してください。僕が技術面の移行計画を作る場合も、法的な判断は専門家へつなぎます。

棚卸しでは、不満と事実を分けます。「対応が悪い」ではなく、回答を依頼した日時、回答日、止まった作業、再見積もりになった範囲を並べます。事実を共有すれば、担当者の交代で改善できるのか、会社を替える必要があるのかも判断しやすくなります。

開発会社を乗り換える前に、自社で開けるものを確認します

ソースコードを受け取った記憶があっても、保管場所へ入れるとは限りません。リポジトリの組織管理者、クラウドの契約者、ドメインの登録者、アプリ配信アカウントの所有者を画面で確認します。請求先が自社でも、最上位の管理者が旧会社だけなら、切り替え時に操作できません。

ログインできるかだけでは不十分です。社内担当者が管理者権限を持ち、多要素認証の復旧先が自社にあり、退職者や旧会社のアカウントを外せるかまで試します。パスワードや秘密鍵は課題管理ツールへ貼らず、権限を絞れる保管先を使って移管します。

引き継ぐ情報は設計書だけではありません。環境の作り方、デプロイ手順、データベース変更の手順、定期処理の時刻、監視通知の行き先、障害時の復旧順序、外部APIの窓口、未対応の課題を集めます。採用しなかった案と理由も残っていれば、新会社が同じ検討を繰り返さずに済みます。

著作権の確認も後回しにできません。e-Gov法令検索の著作権法17条、61条、63条は、著作者が権利を享有する原則、著作権の全部または一部を譲渡できる規定、利用許諾の範囲で著作物を利用できる規定を置いています。ソースコードの納品、著作権の譲渡、利用許諾を同じ意味として扱わず、契約書の帰属条項、改変できる範囲、第三者のライブラリや素材を専門家と確認します。

資料が欠けていても、すぐ全面的な作り直しへ進む必要はありません。要件定義で利用者、業務、データ、受入条件をそろえる方法と同じく、動くプログラム、利用者の業務、外部とのデータ連携を照合し、分からない場所を試験対象として残します。空欄を推測で埋めるより、安全です。

開発会社の変更は、旧会社と新会社を並走させます

引き継ぎ資料を共有しただけで、移行完了にはしません。旧会社には現行環境を説明してもらい、新会社には説明内容を使って開発環境を作り、小さな修正を一件だけデプロイしてもらいます。新会社が自力で再現できなかった箇所が、追加の引き継ぎ対象です。

次に、隔離した環境でバックアップからデータを戻します。復元に使ったバックアップの日時、戻った件数、欠けたデータ、所要時間を記録します。画面が開くだけで合格にせず、注文、予約、請求など事業上重要な処理を一つ選び、入力から通知や帳票まで通します。

並走期間は、二週間や一か月と一律に決められません。新会社がビルド、デプロイ、監視、切り戻し、データ復元を実行し、旧会社なしで日常の問い合わせを調査できる状態を終了条件にします。旧会社の説明時間と資料作成を無償の好意へ頼らず、作業範囲、窓口、回答期限、費用を合意します。

発注側は、両社を同じチャットへ招待するだけでは役割を果たせません。旧会社は現行仕様と既知の危険を説明し、新会社は再現結果と未解決事項を示します。発注側は優先順位、受け入れ条件、切り替え日を決め、会議の決定内容を自社の保管場所へ残します。

社内に技術責任者がいない場合は、外部CTOが棚卸し、成果物の定義、両社の回答比較、復旧試験の監督を担えます。旧会社の粗探しではなく、発注側が切り替え可否を判断できる材料を整える役割です。CTO業務委託で任せる仕事と責任範囲も確認し、対立を作らず指示系統を一本にします。

関係を壊さず伝えるには、評価と移行依頼を分けます

変更を決めた後に、品質への不満を長く説明しても引き継ぎは進みません。最初の面談では、取引を見直す決定、希望する終了日、移管したい成果物、並走中の連絡方法を伝えます。相手を評価する会話と、必要な作業を決める会話を分けます。

決定済みの変更を「検討中」と曖昧に伝える必要もありません。率直に伝えたうえで、現在までの開発への謝意を示し、移行作業にも対価を払います。旧会社の担当者が持つ運用上の注意点は、新会社が短期間で作れない重要な情報です。

成果物が足りない場面では、「資料がない」と責めるより、誰が、どの形式で、いつまでに作るかを決めます。たとえば構成図なら、旧会社が初版を作り、新会社が環境と照合し、発注側が自社の保管場所へ置きます。受け渡す人と確かめる人を分けると、渡したつもりを減らせます。

受領対象を資料名だけで終わらせない確認項目は、システム開発の成果物を再現可能な状態で受け取る手順で、コード、設定、データ、権限、復旧まで整理しています。

新会社にも、現行会社への不満だけを選定材料として渡してはいけません。障害記録を一件、変更依頼を一件、現行の構成図を見せ、最初の三十日で何を確認するかを聞きます。すぐ全面刷新を提案する会社より、不明点と検証順序を言葉にできる会社を選びます。

開発会社の変更日は、復旧試験に合格してから決めます

切り替え日の前に、変更を止める時間帯、直前バックアップ、公開手順、確認する業務、失敗時に旧環境へ戻す条件を一枚にします。誰が開始を承認し、誰が中止を決めるかも名前で置きます。夜間作業にするかどうかは慣例ではなく、利用者が少ない時間と、両社の担当者が復旧に参加できる時間を合わせて決めます。

当日は、サーバーが動いている表示だけを見ません。監視画面でエラーと応答時間を確認し、事業画面から一件の取引を通し、データベースの記録と通知先を照合します。数字に差が出たら切り替えを止め、決めておいた手順で旧環境へ戻します。

切り替え後は、旧会社のアカウントを即座に消す前に、必要なログと設定が自社へ移ったかを確認します。確認後に権限を外し、契約で定めた方法に沿って旧会社側のデータ削除や保管終了を記録します。移行後の問い合わせ期間を設ける場合も、期限、対象、費用を合意します。

明日は、契約書を横に置き、クラウドの権限画面、リポジトリのメンバー画面、ドメインの登録者画面、直近のバックアップ履歴、直近のデプロイ記録を開いてください。社内担当者が管理者として入れない場所と、復旧方法を説明できない場所へ印を付けます。印が付いた場所を旧会社へ依頼する順番に並べれば、感情的な解約通知ではなく、止めない乗り換えの初日になります。