「開発会社を変えたら、これまで作ったものが全部消えてしまうのでは？」
よく聞かれる質問です。正直に答えると、準備次第で大きく変わります。何も準備せずに切り替えると、実際にかなりのものを失います。一方、きちんと準備していれば、想定よりはるかに少ない損失で再スタートできます。
開発会社の変更は、起業家が直面する最も辛い判断のひとつです。契約時には見えなかった問題が、数ヶ月後になってようやく表に出てきます。その時点ではすでに多くの資金と時間が投じられています。「今変えるべきか」「引き継ぎに何ヶ月もかかると聞いた」「いっそゼロから作り直したほうがいいのか」——そういった迷いが重なって、判断がぼやけます。
このガイドでは、切り替えのタイミングの見極め方、現在の開発会社からできる限り資産を回収する方法、そして新しい開発会社へのコンテキスト移行をどう最小限に抑えるかを整理します。
変更を検討すべきサイン
外注プロジェクトには常に摩擦が伴います。摩擦そのものが変更の理由にはなりません。しかし、次のサインが複数重なっている場合は、真剣に検討する時期です。
技術的負債が制御不能なレベルに達しているとき
「早く開発を進めたのでコードが複雑になった」という説明は、ある程度理解できます。しかし、新しい機能を追加するたびに既存の機能が壊れたり、バグ修正1件に数週間かかるようになっていたりすれば、それは構造的な問題です。このような状態で同じ開発会社への依頼を続けると、技術的負債がサービスの成長を蝕んでいきます。
ソースコードやインフラに直接アクセスできないとき
GitHubリポジトリへのアクセスが開発会社のアカウントを経由しているか、デプロイ環境の権限がない状態であれば、すでにリスクのある状況です。開発会社と連絡が取れなくなったり、契約上のトラブルが起きたりした場合に、対処できなくなります。このような場合は、変更より先に資産の回収を優先する必要があります。
成果物の品質に対する信頼が失われたとき
バグが多い、画面が遅い、テストがないといった個別の問題は、協議によって改善できます。しかし、約束を繰り返し破り、責任をクライアント側に転嫁し、成果物の説明を避けるようなら、関係の信頼そのものが損なわれています。この状態で続けても、結果が変わることはほとんどありません。
主要な担当者が交代しているのに通知がなかったとき
プロジェクトの途中で担当開発者が変わることはよくあることです。問題は、そのことを伝えないまま交代が行われたり、新しい担当者がまったく背景知識を持たずにアサインされたりする場合です。これは、開発会社内部のマネジメントに構造的な問題があるサインです。
どれか1つだけで変更を決断するのは難しいでしょう。しかし、2〜3つが重なっているなら、「もう少し待ってみよう」よりも「今できることを把握しよう」が適切な姿勢です。外注プロジェクトで問題が起きたときの対応については、外注トラブル対応マニュアルに状況別の手順を整理しています。
作り直すか引き継ぐか——判断の基準
変更を決めたら、最初に直面するのがこの問いです。既存のコードベースを引き継ぐべきか、それとも新たに作り直すべきか。
答えは、現在のコードの状態によって異なります。
作り直したほうがよい場合
- コアとなるアーキテクチャの設計が、ビジネスの方向性と根本的に合っていない場合（例：密結合のシステムを、より分離した構成に移行しなければならないが、既存の構造ではそのコストが見合わない）
- ソースコードをまったく入手できない場合
- 技術スタックが古く、優秀な開発会社が引き受けを避けるほどである場合
- 製品の方向性が大きく変わり、既存機能の半数以上を入れ替える必要がある場合
引き継いだほうがよい場合
- 重要なデータが蓄積されており、それを新システムへ移行するコストが作り直しよりも大きい場合
- ビジネスロジックが複雑で、作り直すとエッジケースを見落とすリスクが高い場合
- 実際のユーザーがおり、サービスを止めずに移行する必要がある場合
- コードの構造自体は問題なく、特定のモジュールのみが課題である場合
実際の現場を見ると、多くの起業家が「いっそゼロから」を選びたがります。しかし実際には、引き継いでから部分的にリファクタリングするほうが早いケースがほとんどです。作り直しは思ったより時間がかかりますし、その間もビジネスは止まりません。
とはいえ、引き継ぎ自体が不可能な状況もあります。現在の開発会社がソースコードを提供しない、あるいは協力を拒否している場合は、作り直し以外の選択肢が実質的にありません。
現在の開発会社から回収すべきもの
変更を決めたら、まず確保すべき資産のリストがあります。このステップを丁寧にやらないと、その後の作業が大幅にコスト増になるか、回収できなくなることもあります。
ソースコードの全履歴
最新バージョンだけでなく、コミット履歴を含むリポジトリ全体を引き渡してもらう必要があります。「最新版だけお渡しします」では不十分です。コミット履歴があって初めて、新しいチームがコードの変更の経緯を把握できます。
データベーススキーマとデータ
スキーマのダンプと実データのバックアップファイルを確保してください。データがほとんどない状態でも、テーブル構造とインデックスの設計だけで、後任の開発会社が分析できることは多くあります。
デプロイ・インフラの設定
クラウドアカウントのアクセス権限（AWS、GCP、Azureなど）、ドメイン登録情報、SSL証明書、環境変数の一覧。特にドメインは確認が必要です。開発会社名義で登録されている場合は、すぐに移管を求めてください。
外部サービスの連携情報
決済APIキー、通知サービス、地図API、ソーシャルログイン設定など、連携している外部サービスのキーと設定値。これらがなければ、サービスが動いていても連携機能がすべて止まります。
企画・設計ドキュメント
画面の仕様書、API仕様書、DB設計書、議事録。こうした文書が体系的に残っている開発会社は少ないですが、あるものはすべて請求してください。チャットのログやメールのスレッドも、コンテキストを復元するのに役立ちます。
現在の開発会社がこれらを素直に渡してくれないこともあります。契約書に「成果物の所有権はクライアントにある」という条項があれば、法的な根拠があります。そうでなければ交渉が必要で、場合によっては法的なアドバイスが必要になることもあります。外注契約で所有権の条項をどう確認すればよいかは、外注見積もり確認ガイドを参考にしてください。
新しい開発会社へのコンテキスト移行
引き継ぎの本当の難しさは、書類の受け渡しではありません。「なぜこのコードがこうなっているか」という背景が、特定の人の頭の中にしか存在しないことがほとんどだからです。
新しい開発会社に必要なものは、大きく3つです。
1つ目は、既存コードの構造の把握です。新しいチームが初めてコードを受け取ったとき、自力で構造を理解するには時間がかかります。前の開発会社の開発者やクライアント側の担当者が、アーキテクチャを一度説明するセッションを設けるだけで、オンボーディングのコストは大きく減ります。
2つ目は、既知の問題と技術的負債のリストです。どんなバグがあるか、どの部分が暫定的な実装になっているかを事前に共有することで、新しいチームが同じ地雷を踏む可能性が下がります。このリストがなければ、新しいチームも自分で探索する時間が必要になります。
3つ目は、ビジネス判断の背景です。「なぜこの機能がこう実装されているか」の背景がなければ、新しいチームが不必要に変更したり、変えてはいけないものを変えてしまったりします。各機能の企画意図や主要な決定事項が整理されていれば、このコストを省けます。
現実には、この3つの情報を体系的に持っているクライアントはほとんどいません。開発が進む中で、文書化や記録が不足していることが多いからです。その場合、新しい開発会社とのオンボーディング期間が長くなるのは避けられません。ただ、前の開発会社とのコードレビューセッションを1〜2回持つこと、主要な設計上の決定についてのメモを確保しておくだけでも、状況は大きく変わります。
引き継ぎを構造化するための実践的な方法
コンテキストの移行が難しい場合、新しい開発会社とのオンボーディング段階を独立したフェーズとして設けることが実用的です。
最初の2〜4週間を探索フェーズ（ディスカバリーフェーズ）として定義し、この期間に新しい開発会社がコードベースを分析して質問リストを整理することを、正式な作業として契約に含めます。「すぐに開発を始めてほしい」というプレッシャーをかけるよりも、このフェーズに適切なコストをかけるほうが、プロジェクト全体のスピードと品質の両方にとってプラスです。
この探索の結果を文書化しておけば、後で別の変更が生じたときにも参照できる資産になります。
スタック概要ドキュメントを依頼してください。新しい開発会社がコードを分析した後、フレームワーク・ライブラリ・外部サービスへの依存・デプロイ構成を1ページにまとめたドキュメントを作成してもらいます。このドキュメントがあれば、その後チームが変わっても基本的なコンテキストは維持されます。
リスク領域のマッピングもこのフェーズで行うべきです。触ると予期せず別の箇所が壊れる可能性があるコードの領域、テストがなく検証が難しい部分、パフォーマンスのボトルネックが予想される箇所——これらを事前に特定しておくことで、その後の開発計画を現実的に立てられます。
インテグラビットがこの課題に取り組む理由
引き継ぎがこれほど難しい理由のひとつは、プロジェクトのコンテキストが一箇所に集まっていないことです。仕様書はどこかの共有フォルダに、会議の記録はチャットのスレッドに、バグレポートはメールに、ソースコードはリポジトリに——それぞれバラバラに散在しています。開発会社が変わると、この断片を集め直すだけで数週間かかることもあります。
インテグラビットは、プロジェクトが進む中で成果物、課題ログ、意思決定の記録、コミュニケーション履歴をポータルにアーカイブします。開発会社が変わる状況が生じても、新しいチームはポータルからプロジェクトの全履歴を一度に確認できます。「次の開発会社がポータルを見るだけで、すぐに引き継げる」——これがインテグラビットの設計段階から意図してきた方向性です。
文書化が不十分なままプロジェクトを進めてきた場合や、現在開発会社の変更を検討している場合、最初からこうした構造の上でプロジェクトを進めることが、長期的にはるかに安全です。
新しい開発会社を選ぶときに確認すること
開発会社を変えるなら、新規プロジェクトを始めるときとは異なる確認項目があります。
既存コードの引き継ぎ経験
既存のコードベースを引き継ぐことは、ゼロから開発することとは根本的に異なる作業です。「既存コードを引き継いだ経験はありますか？」という問いに、具体的な事例を挙げて答えられるかどうかを確認してください。「できます」という一般的な答えよりも、実際の経験がある開発会社のほうが、はるかに現実的なアプローチを取ります。
コード調査のプロセス
信頼できる開発会社なら、引き継ぎの前に現在のコードの状態を分析して結果を共有するステップを踏みます。「始めながら把握していきましょう」というスタンスは、後で問題が起きたときに責任の所在が曖昧になりやすい。
ディスカバリーを契約に含める構成
探索フェーズを独立した契約ステップとして設け、その結果に基づいて以降の作業範囲を協議する構成を提案する開発会社は、現実的な判断をしている会社です。コードを見もせずに全体の見積もりを先に提示する開発会社には、注意が必要です。
コミュニケーションの仕組み
前の開発会社との問題の多くは、コミュニケーションのあり方に起因していることが多いです。新しい開発会社が、どのくらいの頻度で、どのような形式で進捗を共有するかを、契約前に具体的に確認してください。
開発会社の変更は、一度決めたら終わりではありません。資産の回収、引き継ぎ、新しい開発会社のオンボーディング——各ステップに、それぞれ対処すべきことがあります。ただし、準備を整えた変更はゼロからの出発ではありません。これまで積み上げてきたものの上に、より良いパートナーと再スタートするプロセスです。
開発会社の変更を検討中であれば — 30分の無料相談で、現在の状況を一緒に整理します。