開発会社を変更したいときの手順とリスク対策
「開発が予定どおり進まない」「提案や説明に納得できない」「稼働後の改修をお願いしても対応してもらえない」——開発会社との関係に不満を抱えながらも、変更に踏み切れずにいる企業は少なくありません。開発会社の変更には、費用や期間のロス、情報の引き継ぎ漏れといったリスクがあるためです。
この記事では、開発会社を変更すべきかどうかの判断基準と、変更の手順、リスクを抑えるための対策を解説します。
- 変更を考えたら、まず問題の原因が「会社」なのか「進め方・体制」なのかを切り分ける。改善の申し入れで解決することもある
- 開発途中の変更は影響が大きい。フェーズの区切り（要件定義の完了時など）で判断するのが現実的
- 変更前に契約書（解約条件・成果物の権利）とソースコード・資料・アカウントを確認する
- 新しい開発会社には、前の会社の成果物を調査・評価してもらったうえで引き継ぐ
目次
開発会社の変更を検討すべきサイン
次のような状態が続いている場合は、変更を検討するタイミングかもしれません。
- スケジュールの遅延が繰り返される：遅れの理由や挽回策の説明がない
- 進捗や課題が見えない：報告がなく、質問しても具体的な回答が得られない
- 品質の問題が続く：不具合が多く、修正してもまた別の問題が出る
- 見積もりや追加費用の根拠が不明確：変更のたびに説明のない追加請求がある
- 担当者が頻繁に変わる：業務を理解した人がいなくなり、説明をやり直している
- 稼働後の改修に対応してもらえない：技術的な理由や体制不足で断られる
変更する前に確認すべきこと
問題の原因を切り分ける
開発がうまくいかない原因が、発注者側の要件の不明確さや、決定の遅れにあることもあります。まずは問題点を具体的に書き出して開発会社と共有し、改善を申し入れることから始めましょう。体制の変更や進め方の見直しで改善することもあります。
契約内容を確認する
契約書で次の点を確認します。
| 確認項目 | 確認する理由 |
|---|---|
| 解約条件・解約予告期間 | いつ、どんな条件で契約を終了できるか |
| 成果物の著作権・所有権 | ソースコードや設計書を他社に渡して使えるか |
| 途中解約時の精算方法 | それまでの作業分の支払いがどうなるか |
| 契約形態（請負・準委任） | 完成責任の有無と、途中成果物の扱い |
| 秘密保持・データの返却 | 預けたデータの返却・削除の取り決め |
手元にある資産を確認する
ソースコード、設計書、サーバーやドメインのアカウント、データベースの管理者権限などが、自社の手元にあるか、自社名義になっているかを確認します。これらが開発会社側にしかない場合、変更の難易度が大きく上がります。
タイミング別：変更の難しさと進め方
開発途中で変更する場合
- 作りかけの成果物の品質評価が必要
- 引き継ぐか、作り直すかの判断が必要
- 精算や契約の整理が複雑になりやすい
- スケジュールの遅れは避けにくい
稼働後に変更する場合
- システムは動いているため業務への影響は小さい
- 保守の引き継ぎとして計画的に進められる
- 並走期間を設けやすい
- 資料とソースコードの受け渡しが鍵
開発途中で変更する場合は、要件定義や設計などフェーズの区切りで判断すると、成果物の範囲が明確になり、精算や引き継ぎがしやすくなります。稼働後の保守の引き継ぎについては、次の記事で詳しく解説しています。
開発会社を変更する手順
- 問題点を整理し、改善を申し入れる具体的な事実をもとに話し合い、改善の可能性を確かめる
- 契約・資産を確認する解約条件、権利、ソースコード・資料・アカウントを確認する
- 新しい開発会社を探す他社成果物の引き継ぎ実績がある会社に相談する
- 現状の成果物を調査・評価してもらう品質と完成度を確認し、引き継ぐか作り直すかを判断する
- 現在の開発会社と契約終了の手続きを行う精算、成果物の受け渡し、データの返却を合意する
- 引き継ぎ・再計画新しい開発会社とスケジュールと体制を立て直す
変更に伴うリスクと対策
| リスク | 対策 |
|---|---|
| 成果物を受け取れない | 契約書の権利条項を確認し、受け渡し物の一覧を作って合意する |
| 引き継いだ成果物の品質が低い | 新しい開発会社にコードレビューと品質評価を依頼する |
| 費用が二重にかかる | 引き継ぐ範囲と作り直す範囲を明確にし、全体の予算を再計画する |
| 同じ失敗を繰り返す | 前回の問題点を振り返り、要件・体制・進め方を見直す |
特に最後の「同じ失敗を繰り返さない」ことは重要です。外注でよくある失敗パターンを知っておきましょう。
よくある質問
- 開発途中で開発会社を変更することはできますか？
- 可能です。ただし、それまでの成果物の評価、契約の精算、引き継ぎ作業が必要になり、費用と期間のロスが発生します。フェーズの区切りで判断すると、影響を抑えやすくなります。
- 前の会社が作ったプログラムはそのまま使えますか？
- 品質や完成度によります。新しい開発会社にソースコードを調査してもらい、引き継いで使える部分と作り直すべき部分を判断してもらいましょう。
- 開発会社を変更すると費用はどのくらい増えますか？
- 引き継ぎの調査費用に加え、成果物の品質によっては作り直しの費用がかかります。変更しない場合に見込まれる遅延や品質問題のコストと比較して判断することが大切です。
- 契約書にソースコードの権利が開発会社にあると書かれていたら？
- 著作権が開発会社にあっても、利用許諾の範囲で他社による保守・改修が認められている場合があります。契約内容の解釈に迷う場合は、弁護士などの専門家に相談しましょう。
まとめ
開発会社の変更は、問題の原因の切り分け、契約と資産の確認、新しい開発会社による現状評価を経て、計画的に進めることが大切です。開発途中の場合はフェーズの区切りで判断し、現在の会社との契約終了は引き継ぎの段取りが整ってから行いましょう。
次のパートナー選びで同じ問題を繰り返さないよう、選定の基準も見直しておくと安心です。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
