開発会社の乗り換えと引き継ぎの進め方【2026年版】資産7カテゴリ・契約9項目・並走期間の設計

「今の開発会社を変えたいが、引き継ぎでシステムが止まったらと思うと動けない」——開発の発注担当者から、こうした相談をよく受けます。保守費が毎年上がるのに根拠の説明がない、同じ不具合が再発する、担当者が入れ替わるたびに説明が振り出しに戻る。不満ははっきりしているのに、ソースコードを渡してもらえなかったら、解約を伝えた途端に対応が悪くなったら、と考えると手が止まる。これは多くの発注側が同じ場所で止まっている問題です。

結論から言うと、開発会社の乗り換えは「契約を切ること」ではなく「資産と権限を移すこと」です。ソースコードとリポジトリ、インフラのアカウントと権限、ドメインとSSL証明書、設計書、テスト、運用手順、外部サービスの契約、データ。この7カテゴリを先に洗い出し、著作権の帰属と解約予告期間を契約書で確かめ、新旧2社が並走する期間を設けて段階的に移す。順序を守れば、稼働中のシステムでも止めずに移せます。

逆に、解約を先に通知してから資料を集め始めると、旧開発会社に協力する動機が薄れ、時間も交渉力も失います。乗り換えが失敗する原因は、技術よりも順序にあるというのが実情です。そしてもう一つ、すべての不満が乗り換えで解決するわけではありません。窓口と定例の見直しで直るものまで乗り換えに持ち込むと、引き継ぎ費用と並走費用だけが残ります。

本記事では、乗り換えを検討する5つの理由と乗り換えないほうがよいケース、引き継ぎに必要な資産7カテゴリとベンダーロックインの外し方、契約で確認する9項目、移行の進め方と切り替え判断のチェックポイント、引き継ぎ先としてのベトナムオフショアと当社の体制、よくある質問の順に解説します。なお当社は乗り換え先になり得る立場ですので、変えないほうがよい場合も同じ紙幅で書きます。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。引き継ぎの相談で最も多いのは「ドキュメントがない」ではなく、「サーバーとドメインの名義が開発会社のままだった」というものです。この記事を読み終えるころには、自社が今どの段階にいて、明日どこから手をつければよいかが決まっているはずです。

開発会社を乗り換える5つの理由と、乗り換えないほうがよいケース

乗り換え(ベンダー変更)の相談は、ある日突然起きるものではありません。たいていは2〜3年かけて小さな不満が積み上がり、保守費の値上げ通知や大きな障害をきっかけに表面化します。まずは、自社の不満がどの理由に当てはまるのかを言葉にしてください。理由が特定できると、乗り換えで解決するのか、今の会社との運用を変えれば済むのかが分かれます。

相談で挙がる5つの理由——単価の値上げ、品質、遅延、担当の入れ替わり、連絡が遅い

この5つは、上位の解説記事(GeekBridge、Clane)が挙げる「乗り換えを検討するサイン」ともほぼ重なります。加えて、最も深刻なサインとして各社が共通して挙げるのが、ソースコードや仕様の開示を求めても応じてもらえない状態、つまりベンダーロックインです。これは不満ではなく、経営上のリスクとして扱ってください。

「不満」と「乗り換えるべき問題」は違う——窓口と定例の見直しで直るもの

私が相談を受けてまず確認するのは、「その不満は、今の会社と話して直せるものか」という点です。回答期限が決まっていないなら決める。報告の頻度が足りないなら月次を隔週に変える。窓口が担当者個人のメールになっているなら、会社の窓口に変えてもらう。この3つを申し入れただけで、乗り換えを取りやめた会社をいくつも見てきました。

一方、次のような場合は運用の調整では戻りません。ソースコードやクラウド環境を発注側が確認できない。障害の原因と再発防止策が共有されない。セキュリティ更新やバックアップの実施状況が分からない。必要な技術領域に対応できないと言われる。これらは体制と技術力に根がある問題で、話し合いでは変わらないことが多いというのが実情です。

乗り換えないほうがよい4つのケース——引き継ぎ先の立場から正直に書く

当社はオフショア開発を提供しており、この記事を読んだ方の乗り換え先になり得る立場です。だからこそ、先に「変えないほうがよい場合」を書いておきます。

1. 要件や優先順位が社内で固まっていない。原因が発注側にあるため、会社を変えても遅延と手戻りが再現する
2. 半年以内に大規模な刷新やリプレイスを予定している。引き継ぎ費用をかけて保守だけ移す意味が薄い
3. 社内に窓口役を置けない。引き継ぎ期間は旧会社・新会社の両方とやり取りが増えるため、最低1人の責任者が要る
4. 不満が金額だけで、月額の差が引き継ぎ費用を下回る。初期費用と並走費用を含めた総額で比べると逆転することがある

私が「今は変えないほうがよい」と伝えた場面

印象に残っているのは、遅延を理由に乗り換えを決めかけていた事業会社の相談です。詳しく聞くと、仕様の確定が毎回リリース直前になり、開発会社が着手できない期間が長く発生していました。この状態で会社だけ変えても、同じ遅延が起きます。そこで、まず優先順位を決める担当を1人決め、隔週の定例で次の2スプリント分を確定する運用に変えることを提案しました。乗り換えの判断は、その運用を3か月続けてからでも遅くありません。では、実際に乗り換えると決めた場合、何を受け取る必要があるのか。次章で資産の一覧を整理します。

引き継ぎに必要な資産7カテゴリと、ベンダーロックインの外し方

引き継ぎで受け取るものは、ソースコードだけではありません。コードがあっても、動かす手順が分からなければ新しい開発会社は起動すらできず、サーバーやドメインの管理権限が旧開発会社の名義のままなら、リリースもドメインの更新もできません。ここでは、受け取るべき資産を7つのカテゴリに分けて洗い出します。この一覧は、旧開発会社への依頼書と、新しい開発会社への提示資料の両方にそのまま使えます。

引き継ぎ資産のチェックリスト(7カテゴリ)

すべてが揃っている必要はありません。大切なのは「ある」「ない」「旧開発会社だけが持っている」を一覧にして、足りない分の調査責任と費用を先に決めておくことです。うちシスなびやGeekBridgeの解説でも、この棚卸しを解約通知より先に行うことが共通して勧められています。

見落としが多いのは「動かし方」と「名義」——ビルド手順とアカウントの所有者

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、引き継ぎの相談で最も多いのは「ドキュメントがない」ではなく、「サーバーとドメインの名義が開発会社のままだった」というものです。しかも、名義が開発会社の担当者個人のメールアドレスになっていた例も一度ではありません。その担当者が退職していると、移管の手続きに数週間かかります。

もう一つの落とし穴が、ビルドとデプロイの手順です。長く運用されてきたシステムほど、環境構築の手順が担当者の頭の中にしかなく、文書化されていません。ソースコードの引き渡しを依頼するときは、同時に「検証環境を一から立ち上げる手順のメモ」を依頼してください。A4で1〜2枚のメモがあるかないかで、その後の調査期間が数週間変わります。

ベンダーロックインの外し方4つ——法人名義、自社リポジトリ、ドキュメントの納品物化、汎用形式

今回の乗り換えを機に、次の乗り換えで同じ苦労をしない状態に変えてください。やることは4つです。

1. 重要アカウントは自社の法人メールアドレスを所有者・最上位管理者にする。クラウド、ドメイン、DNS、SSL、ソース管理、アプリストアの開発者アカウント、決済やメール配信などの外部サービスがこれに当たります
2. ソースコードは自社が契約したGitリポジトリに置き、開発会社にはメンバーとして参加してもらう。権限は担当者ごとに発行し、契約終了時に個別に外せる状態にします
3. ドキュメントを納品物に含める。設計書と運用手順を「あれば出す」ではなく、契約上の納品物として定義します
4. データは汎用形式でエクスポートできることを確認する。CSVなど標準形式で全件出せるか、文字化けが起きないかを、少量で試しておきます

資料がゼロでも乗り換えはできる——リバースエンジニアリングの現実

「ドキュメントが一切ない」という状態は珍しくありません。結論から言うと、ソースコードとデータベースが手元にあれば引き継げます。コードと構造を解析して仕様を逆引きし、ドキュメントを作り直す作業を一般にリバースエンジニアリングと呼びます。他社開発のシステムを引き継いだ経験がある会社なら対応できる範囲です。

ただし、相応の工数と期間がかかります。システムの全体像を把握するまでにまとまった調査期間が必要で、資料不足による再作成には別途の作成工数もかかります。期間も費用も、対象システムの規模と外部連携の多さで大きく動きます。再作成費用の一次統計はないため、本記事では期間と金額の目安は示しません。ソースコードそのものを受け取れない場合は、引き継ぎではなく再構築に近い予算になります。資料がないことは乗り換えの障害ではなく、調査工程として見積もりに含めるべき項目だと考えてください。

契約で確認する9項目——著作権の帰属、解約予告期間、保守契約の終了、機密保持の継続

資産の棚卸しと並行して、契約書を開いてください。開発契約書、保守契約書、注文書、見積書、仕様確認書、検収書の6種類を集めると、確認すべき条項はほぼ揃います。ここを読まずに解約を切り出すと、違約金や二重払いが後から出てくることがあります。なお、以下は契約実務の一般的な整理であり、法的な助言ではありません。判断に迷う条項は弁護士にご確認ください。

契約書で確認する9項目

この9項目は、GeekBridgeが挙げる契約確認項目とうちシスなびの契約書類の整理を統合し、当社が相談の場で実際に確認している順に並べ直したものです。1〜3が「渡してもらえるか」、4〜6が「いつ、いくらで離れられるか」、7〜9が「離れた後」に対応します。

「支払ったから自社のもの」とは限らない——著作権と利用許諾の違い

ここが最も誤解の多いところです。開発費を支払っていても、契約に定めがなければソースコードの著作権は制作した側に残るのが原則とされています。つまり「お金を払ったのだから自社のもの」とは限りません。

実務上の分かれ目は、使用と改変の違いにあります。すでに動いているシステムをそのまま使い続けることは、著作権の問題になりにくい一方、バグ修正や機能追加といった改変には、著作権者の許諾が必要になる場合があります。したがって、契約書に「著作権は開発会社に帰属する」と書かれていても、利用許諾の範囲に改変が含まれていれば、乗り換え後の保守は進められます。逆に、許諾の範囲が曖昧なまま新しい開発会社にコードを渡すのは失敗のもとです。帰属に疑義がある場合は、自己判断で共有せず、先に確認を取ってください。

解約予告期間を読み違えると、二重払いか空白期間が生まれる

保守契約には、解約の何か月前までに通知するという予告期間が定められているのが一般的です。この期間を把握しないまま新しい会社と契約すると、旧契約と新契約が重なって二重に支払うか、逆に旧契約が切れた後に引き継ぎが終わらず、保守の担当が誰もいない空白期間が生まれます。

現実的な組み立ては、解約予告期間から逆算する方法です。新しい会社の事前診断、契約と権限付与、並走期間。この3つに必要な日数を積み上げ、その合計の後に契約終了日が来るように通知の時期を決めます。必要な日数は資料の整備状況と外部連携の多さで動くため、事前診断の見積もりで工程ごとの日数を出してもらい、自社の数字で逆算してください。事業への影響が大きいシステムでは、引き継ぎの見通しが立つまで契約終了日を確定しないほうが安全な場合もあります。

本記事は法的助言ではありません——弁護士に相談すべき場面

本記事の契約に関する記述は、発注側が自社の契約書を読むための観点を整理したものであり、法的な助言ではありません。個別の契約の解釈は条項の文言と経緯によって変わります。次のような場面では、IT契約に詳しい弁護士への相談をご検討ください。著作権の帰属が契約書から読み取れない、ソースコードやアカウントの引き渡しを拒否された、引き継ぎ作業に対して妥当性の判断がつかない高額な請求が出た、未検収の開発をめぐって争いがある。こうした局面で開発担当者同士に交渉させると、関係だけが悪化して解決が遠のくため、要注意です。

移行の進め方——事前診断、並走期間、コードリーディング、小さな改修、切り替えの判断

資産と契約の確認が済んだら、実際の移行に入ります。ここでの原則は一つで、「旧契約を先に切らない」ことです。新しい開発会社が最低限の運用を再現できると確認してから切り替える。この順序さえ守れば、稼働中のシステムでも段階的に移せます。ここでは5つのステップと、切り替えを判断するチェックポイントを整理します。

5つのステップ——責任者と範囲の決定から受け入れ確認まで

全体の期間と費用は、資料と権限の整理状況、外部連携の多さで大きく動きます。引き継ぎ費用の一次統計は公開されていないため、本記事では期間と金額の目安は示しません。代わりに、事前診断の段階で「資産の棚卸しと文書化」「アカウント・環境の移管」「データ移行と検証」「並走保守」を工程として切り出し、それぞれの見積もりを出してもらってください。工程ごとに金額が出れば、どれだけ予備費を積むかも自社の数字で判断できます。

並走期間は必ず設ける——二重の費用を先に予算へ入れる

並走期間は、旧会社と新会社が同時に動く期間です。保守費が二重にかかるため削りたくなりますが、ここを削ると、切り替え直後に障害が起きたときに戻る先がなくなります。事業への影響が大きいシステムほど、並走を前提に組んでください。必要な長さは、リリースの頻度と外部連携の多さで決まります。更新頻度が高いシステムや外部連携が多いシステムほど長く取る、という考え方で見積もってください。

並走期間中に必ず試すのは、次の6つです。検証環境へのソースコードの反映、テストデータでの主要機能の動作確認、バックアップからのデータ復元、小さな改修の本番リリース、監視アラートの受信と一次対応、問い合わせを受けての調査報告。この6つを新しい会社が自力で通せたときに初めて、足りない権限や説明が何かが分かります。

コードリーディング期間と「小さな改修」で新しい会社の実力を見る

引き継ぎの立ち上がりで最も差が出るのが、コードリーディングの期間です。他社が書いたコードを読み、構造と制約を把握するには、小〜中規模のシステムでおおむね2週間〜1か月かかります。この期間を見積もりに含めず「すぐ改修できます」と言う会社は、後から追加費用が出る可能性を疑ってください。

実力を測る最も確実な方法は、小さな改修を1つ依頼することです。画面の表示項目を1つ増やす、バリデーションを1つ追加する、といった規模で構いません。見るのは出来上がりだけではなく、影響範囲をどう調べたか、テストをどう書いたか、リリース手順をどう再現したか、質問の粒度が的確かどうかです。ここで「分かっていること」「確認が必要なこと」「見積もりに含めないこと」を分けて説明できる会社は、引き継ぎ後も同じ誠実さで動きます。

また、引き継ぎと大規模な改修を同時に進めないでください。新しい会社がシステムを理解する前に大きく変えると、不具合の原因を切り分けられなくなります。まず運用を再現し、その後に改善へ進む。この順序が安全です。

切り替え判断のチェックポイント10項目

旧開発会社への伝え方と依頼の順序——資料の依頼は解約通知より先に

最後に順序の話です。資料提供の依頼と、解約の意向表明は、同時に行う必要はありません。「現行システムの資料を整理したいので一式いただけますか」という依頼だけなら、解約を確定する前でも出せます。解約通知と資料請求を同時にすると、相手側に協力する動機が薄れ、対応が後回しになりがちです。依頼は必ず書面(メール)で、資料の一覧と「○月○日まで」という期限を添えてください。

そして、旧開発会社を責めないことです。引き継ぎには相手の協力が要ります。未払いや未確定の仕様がある場合は、責任の追及と移管の実務を分けて協議してください。あなたの会社は今、どのステップにいるでしょうか。次章では、引き継ぎ先としてベトナムオフショアを選ぶ場合の体制と費用を、当社を例に整理します。

引き継ぎ先にベトナムオフショアを選ぶ——当社の体制と費用

引き継ぎ先の選択肢は、国内の受託会社だけではありません。継続的に改修と運用が発生するシステムなら、ベトナムのオフショア開発に移して人数と期間を細かく調整する形が合う場合があります。オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)では、委託先国としてベトナムのシェアが43%と最も高く、契約形態ではラボ型が45%を占めます。ここからは当社の例として、体制と費用を具体的に書きます。判断材料として読んでください。

1名から、最短2週間で開始。増員約1週間、縮小・交代は1か月単位

引き継ぎは小さく始めて広げるのが安全です。当社は1名から契約でき、最短2週間で開始できます。増員は約1週間、縮小と交代(リプレイスメント)は1か月単位で調整します。まずブリッジSE1名でコードリーディングと現状調査を進め、構造が見えた段階でエンジニアを足す、という組み方ができるのはこのためです。

フローは、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始です。候補者とは契約前に面談していただきます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。時差は2時間で、日本の午前中から同じ時間帯に動けます。ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)で、2026年のテト(旧正月)休暇は2月14日〜22日です。

引き継ぎに効く3つ——Gitでのコードレビュー標準化、ドキュメント納品、日本人PMフロント

引き継ぎを受ける側として当社が標準にしているのは3つです。1つ目は、Gitのプルリクエストによるコードレビューの標準化。変更の履歴と理由が残るため、次に誰かへ渡すときの調査期間が短くなります。2つ目は、設計書と運用手順をドキュメントとして納品すること。「あれば出す」ではなく納品物として扱います。3つ目は、日本人PM/BrSEをフロントに置くパターンA(推奨)の体制で、要件の言語化・指示・進捗管理・品質確認を当社側で巻き取る形です。加えて、日本人PMの設計レビューとリリース前のダブルチェックを品質の仕組みとして入れています。

継続開発の例としては、介護記録SaaS「CareViewer」で日本語対応のブリッジSE1名とフルスタック2名の体制を組み、週次で優先順位を判断しながら改修を続けています。コストは従来の半分以下です。ほかにHELTEQ(フルスタック4名)や金融系マッチング(PM1名+フルスタック2名)の体制も動いています。

公開単価(表)と最小構成の月額

円表記は1USD=150円での換算目安です。当社調べでは市場相場の約1/2にあたります。この水準を出せるのは、2,000名以上のIT人財データベース(日本勤務経験のあるN1〜N2相当を含む)から直接アサインしており、協力会社や紹介を経由する仲介マージンが乗らないためです。最小構成は、日本人PMをフロントに置いて2〜3人月で月額約80万円からになります。

当社に向く案件と、向かない案件

向くのは、改修と運用が継続的に発生するWebサービスや業務システム、要件が動くSaaS、少人数から始めて様子を見ながら広げたい案件です。ソースコードとデータベースが手元にあり、日本語で優先順位を判断する担当が1人いれば、ドキュメントが薄くても引き継げます。

向かないのは、要件が完全に確定した単発の開発(請負のほうが合います)、数十名を一斉に立ち上げる大規模案件、CMMIなどの認証を要件とする基幹刷新です。これらは大手のオフショア企業や国内SIerのほうが適しており、相談をいただいた際もその旨をお伝えしています。引き継ぎ先選びで最後に見るべきは単価ではなく、他社が作ったシステムを調査し、制約を整理して引き受けた経験があるかどうか。ここを外すと、安く移して高くつきます。

開発会社の乗り換えと引き継ぎでよくある質問

乗り換えと引き継ぎについて、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での説明にもお使いください。

Q1. 今の開発会社には、いつ乗り換えを伝えればよいですか?

先に契約書の解約予告期間と、成果物・アカウントの保有状況を確認し、社内の方針を固めてからです。資料提供の依頼だけであれば、解約を確定する前でも出せます。解約通知と資料請求を同時にすると、対応が後回しになりやすいためです。対立が予想される場合は、通知の前に弁護士へご相談ください。

Q2. ソースコードを渡してもらえない場合はどうすればよいですか?

まず、依頼をメールなど書面にし、資料の一覧と期限を明記して正式に要請します。契約書に引き継ぎ協力義務や成果物の引き渡しに関する条項があれば、それを根拠に再度要請します。条項がない場合、提供を強制することは難しいのが実情です。それでも応じてもらえないときは、IT契約に詳しい弁護士に相談したうえで段階的に対応を強めることになります。なお、ソースコードを受け取れない場合は、引き継ぎではなく再構築に近い予算になる点をあらかじめ見込んでおいてください。

Q3. 引き継ぎ費用はどのくらいかかりますか?

システムの規模と資料の整備状況で大きく変わります。引き継ぎ費用の公的な統計はないため、金額と期間の目安は示せません。見積もりで工程として切り出してもらうべきなのは、事前診断、資産の棚卸しと文書化、アカウント移管、データ移行と検証、並走保守です。当社の場合は、ブリッジSE1名でのコードリーディングと現状調査から始める形が多く、実務10年目安・ブリッジSEの単価は3,000USD(約45万円、1USD=150円換算目安)です。

Q4. 並走期間は必ず設けるべきですか?

事業への影響が大きいシステムでは、原則として設けてください。必要な長さは、リリースの頻度と外部連携の多さで決まります。更新頻度が高いシステムや外部連携が多いシステムほど長く取ってください。並走中は保守費が二重にかかりますが、切り替え直後に障害が起きたときに旧会社へ確認できる窓口が残っている価値のほうが大きくなります。二重分の費用は、最初から予算に入れておいてください。

Q5. 国内の開発会社から、オフショアに引き継げますか?

引き継げます。条件は、ソースコードとデータベースが手元にあること、日本語で優先順位を判断する担当が1人いること、そしてコードリーディングの期間(2週間〜1か月)を計画に入れることです。当社は1名から最短2週間で開始し、増員は約1週間、縮小・交代は1か月単位で調整できるため、ブリッジSE1名の調査から始めて段階的に広げる形が取れます。時差2時間で日本の業務時間と重なるベトナムは、引き継ぎ直後の密なやり取りが必要な時期にも相性のよい選択肢。

まとめ: 乗り換えは資産と権限の移管——順序を守れば、動いているシステムでも移せる

開発会社の乗り換えは、契約を切ることではなく資産と権限を移すことです。受け取るのはソースコードとリポジトリ、インフラのアカウントと権限、ドメインとSSL証明書、設計書、テストと品質情報、運用手順、外部サービスの契約とデータの7カテゴリ。契約書では、著作権と利用許諾の帰属、解約予告期間、引き継ぎ協力義務、機密保持の存続を含む9項目を先に読みます。支払っていても著作権が移っているとは限らず、使用と改変で必要な許諾が違う点が実務上の分かれ目です。なお本記事の契約に関する記述は法的助言ではありません。

進め方は、社内責任者と範囲の決定、新しい会社への事前診断、旧会社との引き継ぎ条件の合意、並走期間、受け入れ確認の5ステップです。並走の長さは、リリースの頻度と外部連携の多さで決めます。資料の受領を完了とせず、検証環境の構築、バックアップからの復元、小さな改修の本番リリースまで新しい会社が自力で通せたかで判断します。そして、資料提供の依頼は解約通知より先に、期限を切って書面で出してください。順序を逆にすると、時間も交渉力も失います。

一方、要件が社内で固まっていない、半年以内に刷新を予定している、窓口役を置けない、月額差が引き継ぎ費用を下回る——この4つに当てはまるなら、今は乗り換えないという判断も正解です。当社は引き継ぎ先になり得る立場ですが、合わない案件にはその旨をお伝えしています。乗り換え先の比べ方はシステム開発会社の選び方、著作権の扱いはシステム開発の知的財産の帰属、移管後の保守体制はシステム改修・開発保守の外注もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、引き継ぎの可否と進め方の判断、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。