開発会社を変更するときの引き継ぎチェックリスト
「今の開発会社に不満があるが、切り替えたら詰むのではないか」——レスポンスが遅い、見積もりが不透明、品質が安定しない、そんな理由で開発会社の変更を考えながらも、動けずにいる発注者は少なくありません。ソースコードやインフラの所有権が今の会社側にあると、変更自体が難しくなるケースがあるためです。
移管は感情的な話ではなく、実務的な手順の問題です。この記事では、開発会社を変更するときにつまずきやすいポイントと、切り替え前に確保しておくべきもののチェックリストを整理します。
なぜ移管でつまずくのか
開発会社の変更が難航する理由は、だいたい次の3つに集約されます。
- 所有権が発注者側にない。ソースコードのリポジトリ、サーバー、ドメイン、各種SaaSアカウントが開発会社名義・開発会社の個人アカウントで作られており、契約を切った瞬間にアクセスできなくなるリスクがある
- ドキュメントがない。仕様、設計判断の経緯、環境構築手順が担当者の頭の中にしかなく、退場されると再現できない
- 円満に切れない。不満が溜まった状態で切り出すと、相手の協力を得にくくなり、引き継ぎの質が落ちる
これらは「新しい会社の実力」以前の問題です。移管前の準備を怠ると、新しい会社がどれだけ優秀でも、渡されたものが空っぽでは着手できません。
変更前に確保すべきものチェックリスト
契約を切る前、まだ今の会社と話ができる段階で、次を必ず確保してください。
コード・リポジトリ
- [ ] ソースコードのリポジトリ(GitHub / GitLab等)の所有者(Organization Owner) が自社アカウントになっているか
- [ ] 開発会社の個人アカウント配下にリポジトリがある場合、自社のOrganizationへ移管してもらう
- [ ] コミット履歴・ブランチ・タグを含めて完全な形で渡されるか(zipでの最新版だけの受け渡しは避ける)
インフラ・ドメイン
- [ ] サーバー(AWS / GCP / Vultr等)の契約名義が自社になっているか、開発会社のアカウント内で動いていないか
- [ ] ドメインの登録者・DNS管理権限が自社にあるか
- [ ] SSL証明書、CDN、監視ツールなど周辺サービスの契約主体を洗い出す
各種アカウント・認証情報
- [ ] 本番DB・管理画面・SaaS連携(決済、メール配信、分析ツール等)のログイン情報一式
- [ ] APIキー、環境変数、秘密情報とその復号キー
- [ ] Search Console、GA4、広告アカウントなどマーケティング系の権限
ドキュメント・知識
- [ ] 開発環境の構築手順(READMEだけで再現できるか実際に試す)
- [ ] デプロイ手順(手動か、CI/CDで自動化されているか)
- [ ] 仕様・設計判断の経緯が分かる資料(なくても最低限「今動いている仕様の一覧」は作ってもらう)
このリストの多くは、今の会社と関係が良好なうちにしか集めにくいものです。不満が爆発してから請求すると対応が後回しにされます。契約解除の意思を伝える前に、まず静かに棚卸しから始めるのが実務的です。
円満に切るための進め方
感情的な決別は、移管の質を落とします。次の順番で進めることをおすすめします。
- 不満の原因を言語化する。「なんとなく遅い」ではなく、「見積もりの内訳が不透明」「仕様変更の反映に3週間かかる」など具体的な事実に落とす
- 契約書を確認する。解約予告期間、成果物の権利帰属、データ引き渡し義務の条項があるか確認する
- 切り替えの意思を伝える前に棚卸しを終える。上記チェックリストの確認・請求はこの段階で済ませておく
- 並走期間を設ける。可能であれば旧チームと新チームが1〜2ヶ月重なる期間を作り、質問できる状態を残す。難しい場合でも「移管後○週間は質問に応じる」という取り決めをしておく
- 正式に契約終了を伝える。ここまで準備が整っていれば、事務的な通知で済む
不満をぶつけて関係を悪化させてから交渉するより、必要な情報を先に確保して事務的に手続きを進める方が、結果的に早く・安く切り替えが完了します。
新しい開発会社への引き継ぎの進め方
新しい会社が決まったら、次の順番で進めるとスムーズです。
- 最初の1〜2週間は「現状把握フェーズ」として区切る。いきなり機能追加を頼むのではなく、コード・インフラ・ドキュメントの現状を確認してもらう
- 引き継いだ認証情報・アカウント一覧をそのまま渡す。上記チェックリストで集めたものが、そのまま新チームへの引き継ぎ資料になる
- 「なぜこの仕様になったか」を分かる範囲で共有する。仕様の経緯が分からないまま改修すると、意図せず既存の業務フローを壊すことがある
新しい開発会社の選び方自体に迷っている場合は、開発会社の選び方も参考にしてください。要件整理から入れるか、小さく試せる契約形態があるかは、移管先を選ぶときにも同じ基準が使えます。
なお、開発会社ではなく前任のCTOやエンジニアが個人で退職して引き継ぎが必要になったケースは事情がやや異なります。個人の場合はアカウントの所在がより属人化しやすいため、前任者退職後の引き継ぎで個別に整理しています。
移管後、最初にやるべきこと
新しいチームが実際に手を動かし始める前に、torcheeesでは既存プロダクトの改善・モダナイゼーション支援として、まずコードとインフラの現状を一通り確認する診断フェーズを設けています。動かない環境を動く状態に戻す、依存関係の危険度を洗い出す、テストの有無を確認する——といった作業は、既存プロダクト改善で最初に見る観点で詳しく解説しています。移管直後のプロダクトほど、この最初の確認を丁寧に行うことが、その後の改善スピードを左右します。
まとめ
- 開発会社の変更でつまずく原因は「所有権が発注者側にない」「ドキュメントがない」「円満に切れない」の3つに集約される。技術力以前の準備不足が最大のリスク
- 契約を切る前に、コード・インフラ・アカウント・ドキュメントの棚卸しを済ませる。不満をぶつけてからでは協力を得にくくなる
- 新しい会社への引き継ぎは、最初の1〜2週間を「現状把握フェーズ」として区切ると、その後の改善がスムーズに進む
「今の開発会社を変えたいが、何から手をつければいいか分からない」という段階でも、torcheeesはご相談を受け付けています。既存プロダクトの診断と継続的な改善支援を通じて、現状のコード・インフラを確認した上でご提案します。お問い合わせフォームからお気軽にご連絡ください。