開発会社の変更は、現行契約を確認し、ソースコード・設計書・クラウド権限を自社で確保したうえで、現行会社と新会社の並行期間を設けて進めます。中小規模なら引き継ぎ関連で50万〜300万円、1〜4か月が一般的な目安ですが、資料不足や権利未整理で増額します。

開発会社への不満があっても、準備をせずに契約だけを終了すると、障害対応や機能改修が止まるおそれがあります。反対に、必要な資産と権限を整理し、段階的に移管すれば、稼働中のシステムでも発注先を変更できます。

本記事では、既存のWebサービスや業務システムの開発・保守を別会社へ引き継ぐ場合を想定し、変更の判断基準、費用相場、必要資料、進め方、見積もりの見方を解説します。

開発会社変更の判断基準と費用・期間

開発会社を変更すべきなのは、単発の不満ではなく、事業継続や改善速度に影響する問題が繰り返され、契約や体制の見直しでも解決しない場合です。まずは現行会社との改善余地を確認し、それでも難しければ移管を検討します。

変更を検討する主なサイン

次の項目が複数当てはまる場合は、発注先変更の検討を始める目安です。

  • 問い合わせへの回答期限が不明で、障害時にも連絡がつかない
  • 見積もりの作業内訳や前提条件を説明してもらえない
  • 担当者が一人しかおらず、休職や退職で対応が止まる
  • ソースコードやクラウド環境を発注者が確認できない
  • 軽微な改修でも調査に長期間を要する
  • セキュリティ更新やバックアップの実施状況が不明である
  • 事業計画に対して、必要な開発速度や技術領域が合わなくなった
  • 同じ障害が繰り返され、原因や再発防止策が共有されない
  • 保守費用が増えている一方で、対応範囲が明確になっていない

一方、担当者との意思疎通が一時的に悪い、要望の優先順位が社内で決まっていない、発注者から必要情報を渡せていない、といった問題は、定例会や窓口の変更で解決する可能性があります。

状況 推奨する対応
対応品質はおおむね良いが、連絡方法に不満がある 連絡窓口、報告頻度、回答期限を再設定する
費用の内訳が見えない 作業項目、工数、単価、対象外作業の提示を依頼する
技術領域の一部だけ不足している 現行会社を残し、不足領域のみ別会社へ依頼する
障害対応、権限管理、品質に継続的な問題がある 全体または段階的な変更を検討する
ソースコードや契約上の権利が不明である 契約確認と資産調査を先に行う

開発会社を増やすと責任分界が複雑になるため、部分的な追加発注では「どの会社が、どの機能と障害を担当するか」を文書にします。

引き継ぎ費用の一般的な目安

以下は新機能開発を除き、既存システムを理解して保守・開発を引き継ぐための費用目安です。機能数、利用者数、外部連携、セキュリティ要件、資料の整備状況によって変わります。

項目 費用の目安 主な作業
事前診断・現状調査 20万〜80万円 資料確認、構成把握、課題と移管可否の整理
技術資産の棚卸し・文書化 30万〜150万円 ソースコード、データベース、外部連携、運用手順の整理
アカウント・環境移管 10万〜100万円 クラウド、ドメイン、監視、配信サービスなどの権限移管
データ移行・検証 30万〜200万円 データ抽出、変換、移行テスト、件数照合
テスト・リリース確認 30万〜150万円 主要機能の動作確認、検証環境への反映、リリース演習
並行保守 月20万〜100万円以上 現行会社と新会社による一定期間の共同対応
不足資料の再作成 50万〜300万円以上 設計情報や運用手順がない場合の追加調査・作成

各項目は重複することがあるため、単純に合計するものではありません。全体では、小規模なWebシステムで50万〜150万円程度、中規模の業務システムで150万〜500万円程度が一つの目安です。複数拠点で使う基幹システムや、外部連携が多いサービスでは500万円を超える場合があります。

ここでいう小規模とは、主要機能が限定され、外部連携が少なく、一つのチームで管理できるシステムを想定しています。中規模とは、複数の業務機能、権限区分、外部サービスとの連携などを含むシステムです。ソースコードを取得できず再構築が必要な場合は、引き継ぎ費用ではなく新規開発に近い予算になります。

期間は1〜4か月を基本に考える

システムの状況 引き継ぎ期間の目安
小規模で資料と権限が整理されている 1〜2か月
中規模で一部資料が不足している 2〜4か月
複数システム・多数の外部連携がある 4〜6か月以上
権利関係やソースコード取得に問題がある 個別判断

急いで変更するほど、新会社の調査が不十分なまま障害対応を任せることになります。緊急性が低い場合は、現行会社の契約終了日から逆算し、少なくとも1〜2か月の並行期間を確保するのが現実的です。

また、資料不足による追加調査に備え、引き継ぎ予算とは別に10〜30%程度の予備費を置く方法もあります。予備費を含む考え方は、システム開発予算の決め方|発注前の算定手順でも解説しています。

依頼前に契約・権利・技術資産を確認する

開発会社の変更で最初に確認すべきなのは、新会社の候補ではなく、現行契約と自社が保有する資産です。ソースコードが存在していても、発注者が利用・改変できる契約になっていなければ、そのまま新会社へ渡せない場合があります。

契約書で確認する項目

契約書、注文書、見積書、仕様書、検収書を集め、次を確認します。

  • 契約の終了日と解約予告期間
  • 中途解約の条件と未払い費用
  • ソースコード、設計書、画像などの成果物の範囲
  • 著作権や利用許諾の帰属
  • 第三者のソフトウェアや素材に関する利用条件
  • 契約終了後のデータ返却・削除方法
  • 引き継ぎ作業が契約範囲に含まれるか
  • 秘密保持義務が契約終了後も継続するか
  • 再委託先が保有している成果物やアカウントの有無

「開発費を支払ったので、すべて自社のもの」とは限りません。一般的な部品や開発会社独自のプログラムは、開発会社側に権利を残し、発注者へ利用を許可する契約もあります。契約の解釈や権利帰属に疑義がある場合は、自己判断で新会社へ共有せず、IT契約に詳しい弁護士へ相談してください。

また、現行会社による引き継ぎ作業は無償とは限りません。資料作成、説明会、データ抽出、アカウント移管などを追加発注することも想定し、作業内容と費用を協議します。

引き継ぎ資産のチェックリスト

新会社が必要とする情報は、ソースコードだけではありません。発注のご相談を受ける開発会社の立場では、「コードはあるが、どう公開するか分からない」「クラウドの管理者が退職者の個人メールになっている」といった状態が、引き継ぎを難しくします。

分類 確保したいもの
業務情報 システムの目的、利用部門、業務フロー、重要機能、繁忙時間帯
要件・仕様 要件定義書、画面一覧、機能一覧、権限一覧、未対応要望
ソースコード リポジトリ(=ソースコードと変更履歴の保管場所)、対象バージョン、利用手順
システム構成 サーバー、データベース、ネットワーク、外部サービスの関係図
データ 項目定義、保存期間、容量、バックアップ、復元手順
外部連携 API(=システム同士をつなぐ仕組み)の仕様、連携先、認証方法、契約名義
運用 監視項目、障害対応手順、問い合わせ履歴、定期作業、リリース手順
品質 テスト項目、既知の不具合、障害履歴、性能上の制約
アカウント クラウド、ドメイン、DNS、メール、ソース管理、アプリストア、監視サービス
セキュリティ 管理者一覧、アクセス制御、暗号鍵、脆弱性対応履歴、ログ保存方針
契約・費用 クラウド利用料、外部サービス利用料、ライセンス、更新日、支払名義

すべてが揃っていなくても変更は可能です。ただし、「存在する資料」「存在しない資料」「現行会社だけが持つ情報」を一覧にし、不足分の調査責任と費用を決める必要があります。

アカウントは法人名義へ移す

クラウドやドメインを開発会社名義のまま利用すると、契約終了後に自社で更新・復旧できない可能性があります。少なくとも次の重要アカウントは、自社の法人メールアドレスを所有者または最上位管理者にします。

  • AWS、Google Cloud、Microsoft Azureなどのクラウド
  • ドメインの登録・更新サービス
  • DNSやSSL証明書の管理サービス
  • GitHubなどのソースコード管理サービス
  • App Store、Google Playの開発者アカウント
  • 決済、メール配信、SMS配信、地図などの外部サービス
  • 監視、バックアップ、アクセス解析サービス

パスワードを表計算ファイルで一括共有するのではなく、権限を担当者ごとに発行し、不要になった権限を削除できる状態にします。暗号鍵などの重要情報も、誰がどこで管理しているかを記録してください。

開発会社を変更する実務手順

安全な変更の基本は、調査、合意、並行運用、検証、契約終了の順に進めることです。現行契約を先に終了するのではなく、新会社が最低限の運用を再現できることを確認してから切り替えます。

1.社内責任者と変更範囲を決める

まず、発注者側の責任者を一人決めます。経営者、事業責任者、情報システム担当者などが候補です。複数部門が個別に指示すると、新旧会社の役割が曖昧になります。

次に、変更範囲を明確にします。

  • 保守運用だけを変更するのか
  • 新規開発も含めて変更するのか
  • インフラ管理も移すのか
  • 一部機能だけ別会社へ依頼するのか
  • 問い合わせ窓口を一本化するのか
  • 現行会社を助言役として一定期間残すのか

変更の目的も、「月額費用を下げたい」だけではなく、「障害時の連絡体制を整える」「開発速度を上げる」「社内で権限を管理する」のように測定できる形にします。

2.新会社へ事前診断を依頼する

新会社には、いきなり年間保守の固定見積もりを依頼するのではなく、1〜3週間程度の事前診断を相談します。資料と環境を確認しないまま出された確定見積もりは、後から対象外作業や追加費用が増える可能性があります。

診断で確認する主な内容は次のとおりです。

  • システム構成と利用技術
  • ソースコードを取得・更新できるか
  • 検証環境でシステムを動かせるか
  • データベースとバックアップを確認できるか
  • 外部連携先と認証情報が整理されているか
  • 重大な不具合やセキュリティ課題がないか
  • 引き継ぎに必要な追加資料と作業
  • 引き継ぎ後の保守体制と概算費用

事前診断は有償になるのが一般的です。調査結果として、資産一覧、課題一覧、移管計画、概算見積もりを納品してもらうと、その後の判断材料にできます。

3.現行会社と引き継ぎ条件を合意する

現行会社へ変更方針を伝え、感情的な責任追及ではなく、必要な作業と日程を協議します。最低限、次の内容を文書にします。

  • 引き渡す成果物とデータ
  • 説明会の回数と参加者
  • 質問を受け付ける期間
  • 並行期間中の障害対応責任
  • 最終リリースの担当会社
  • アカウント移管の方法と期限
  • 未完了の開発や不具合の扱い
  • 引き継ぎ費用と支払条件
  • 契約終了後のデータ削除と権限停止

「何かあれば対応する」という合意では不十分です。質問受付時間、回答期限、成果物を具体的に設定します。SLA(=対応時間などのサービス水準を定めた合意)を設ける場合は、障害の重要度別に初動時間を決めます。

4.新旧会社の並行期間を設ける

移管方法には、一括変更、段階変更、並行運用があります。

移管方法 向いている状況 注意点
一括変更 小規模で資料が揃い、更新頻度が低い 問題発生時の切り戻し手順が必要
段階変更 機能やシステムを分割できる 会社間の責任分界を明確にする
並行運用 事業上重要で停止しにくい 一時的に二重の保守費用がかかる

事業への影響が大きいシステムでは、並行運用を基本とします。新会社には、説明を聞くだけでなく、実際に次の作業を行ってもらいます。

  • 検証環境へソースコードを反映する
  • テストデータで主要機能を動かす
  • バックアップからデータを復元する
  • 軽微な修正を行い、公開手順を確認する
  • 監視通知を受け取り、一次対応を試す
  • 問い合わせを受けて調査結果を報告する

実作業を通じて初めて、足りない権限や説明が見つかります。少なくとも一度は、実際のリリースに近い手順を新会社が再現できるか確認してください。

5.受け入れ確認後に契約を終了する

受け入れ確認(=発注者が引き継ぎ完了を確認する工程)では、資料を受け取ったことだけでなく、新会社が運用可能かを確認します。

  • 新会社が検証環境を更新できた
  • 主要画面と重要な業務処理が動作した
  • バックアップを取得し、復元できた
  • 障害時の連絡先と初動手順が決まった
  • すべての重要アカウントを自社で管理できる
  • 現行会社の個人アカウントや不要な権限を特定した
  • 未解決課題と対応優先順位を一覧化した
  • 月額費用と追加作業の扱いを合意した

確認後、現行会社のアクセス権限を終了日までに削除します。ただし、ログや障害履歴まで消さないよう、保存すべき情報を先に退避してください。

乗り換え先の選び方と見積もりの比較ポイント

乗り換え先には、新規開発の実績だけでなく、他社が作ったシステムを調査し、制約を整理して引き継いだ経験が必要です。完成イメージが決まった新規開発とは異なり、引き継ぎでは不明点を発見し、優先順位を付ける能力が重要になります。

開発会社を面談で見極める質問

候補会社には、次の質問をして回答の具体性を比較します。

  • 引き継ぎ前にどの資料と権限を確認するか
  • 資料が不足している場合、何から調査するか
  • 調査期間中の契約方式と費用上限をどう決めるか
  • 現行会社との役割分担をどう整理するか
  • 引き継ぎ完了を何によって判定するか
  • 障害発生時に誰が一次対応するか
  • 担当者が不在でも対応できる体制か
  • ソースコード、設計書、アカウントを発注者へどう返却するか
  • 引き継ぎ後、最初の3か月で何を改善するか

信頼できる会社ほど、診断前に断定せず、「分かっていること」「確認が必要なこと」「見積もりに含めないこと」を分けて説明します。画面だけを見て即日で固定額を提示する会社には、見積もりの前提を詳しく確認してください。

一般的な会社選定の基準については、システム開発会社の選び方|発注前の比較ポイントも参考にしてください。

見積書で確認する項目

確認項目 見るポイント
調査範囲 対象システム、環境、資料、外部連携が明記されているか
成果物 資産一覧、課題一覧、構成図、運用手順などが明記されているか
前提条件 ソースコードや権限を取得できる前提になっていないか
対象外作業 データ移行、資料作成、緊急対応などが除外されていないか
体制 責任者、技術担当者、運用担当者と稼働量が分かるか
追加費用 どの条件で追加費用が発生するか
保守費用 月額内の作業時間、対応時間、超過単価が分かるか
完了条件 何ができれば引き継ぎ完了となるか
契約終了時 成果物、データ、アカウントを返却する条件があるか

不明点の多い初期調査は、準委任契約(=一定の業務を遂行することに対して対価を支払う契約)で期間と上限工数を定め、調査後の移管作業を改めて見積もる方法が現実的です。最初からすべてを請負契約の固定額にすると、開発会社が不確実性を見込んで高く見積もるか、対象外条件を増やすことがあります。

よくある失敗と回避策

契約終了を先に通知し、調査時間がなくなる

解約予告期間だけでなく、新会社の診断、契約締結、権限付与、並行運用に必要な日数を逆算します。事業上重要なシステムでは、契約終了日を先に決めない方が安全な場合もあります。

価格だけで乗り換え先を決める

安い月額保守でも、調査や改修がすべて別料金なら総額は増えます。月額内の作業範囲、超過単価、緊急対応、定例報告を比較してください。

引き継ぎと大規模改修を同時に行う

新会社がシステムを理解する前に大きく変更すると、不具合の原因を切り分けにくくなります。緊急の問題を除き、まず運用を再現し、その後に改善へ進む方が安全です。

資料の納品だけで完了とする

資料が最新とは限りません。検証環境への反映、バックアップ復元、軽微な修正、問い合わせ対応を新会社が実行できることまで確認します。

新会社へ無制限に本番権限を渡す

秘密保持契約を締結し、必要最小限の権限から付与します。個人情報を含む場合は、匿名化した検証データを優先し、アクセスログも保存します。

現行会社との関係を必要以上に悪化させる

引き継ぎには現行会社の協力が必要です。未払い費用や未確定仕様を整理し、責任追及と移管実務を分けて協議します。法的な争いがある場合は、開発担当者同士に解決させず、経営層や専門家を介してください。

現行システムの資産状況や、変更可能な範囲を整理したい場合は、開発のご相談はこちらからご相談ください。

まとめ

  • 開発会社の変更は、契約終了より先に現行契約と技術資産を確認します
  • 中小規模の引き継ぎ関連費用は50万〜300万円、期間は1〜4か月が一般的な目安です
  • 資料不足、外部連携の多さ、権利未整理が費用と期間を押し上げます
  • ソースコードだけでなく、クラウド、ドメイン、データ、監視、外部サービスの権限も必要です
  • 重要アカウントは開発会社名義ではなく、自社の法人名義で管理します
  • 新会社には本契約前の事前診断を依頼し、不明点と移管計画を整理してもらいます
  • 現行会社と新会社の並行期間を設け、検証環境への反映やバックアップ復元を確認します
  • 見積もりは金額だけでなく、調査範囲、成果物、対象外作業、追加費用、完了条件を比較します
  • 引き継ぎと大規模改修を同時に進めず、まず安定運用を再現することが重要です

よくある質問

現行の開発会社にはいつ変更を伝えるべきですか?

まず契約の解約予告期間と成果物・アカウントの保有状況を確認し、社内方針を固めてから伝えるのが基本です。ただし、通常運用に必要な資料を不自然に持ち出すのではなく、契約と信義則に沿って進めてください。対立が予想される場合は、通知前に弁護士などの専門家へ相談します。

ソースコードや設計書がなくても開発会社を変更できますか?

変更は可能ですが、調査費用と期間が増えます。新会社に現行システムの診断を依頼し、稼働環境、データベース、外部連携、操作結果などから復元可能な範囲を確認します。ソースコードが取得できない場合は、継続保守ではなく一部または全面的な再構築が必要になることもあります。

現行会社と新会社の並行期間は必要ですか?

原則として必要です。中小規模のシステムでは2週間〜2か月程度を確保し、新会社による検証環境への反映、バックアップ復元、問い合わせ対応、リリース作業を確認してから現行契約を終了すると安全です。システムの規模や更新頻度によっては、さらに長い期間を設けます。

新しい開発会社へ本番データを見せてもよいですか?

秘密保持契約を締結し、個人情報や機密情報の取り扱い、再委託、保存場所、削除方法を決めてから共有します。診断段階では匿名化したデータや検証環境を優先し、本番データへのアクセスは必要最小限の担当者に限定してください。