開発会社を乗り換えるときの引き継ぎ手順｜失敗しないための準備と確認事項
保守の対応が遅い、見積もりが高くなった、担当者が替わってから品質が落ちた。こうした理由で、システムを任せている開発会社を乗り換えたいと考える企業は少なくありません。一方で、乗り換えた後に「動かし方が分からない」「データの意味が分からない」といった問題が出て、かえって手間と費用が増えるケースもあります。
開発会社の乗り換えで難しいのは、新しい会社を選ぶことよりも、現行の会社から必要なものを確実に受け取ることです。ソースコード、サーバーやクラウドのアカウント、データ、ドキュメント、そして文書になっていない運用上の知識まで、引き継ぐべきものは多岐にわたります。
しかも引き継ぎは、現行の開発会社にとって契約が終わる相手への作業です。どれだけ誠実な会社でも、契約上の義務がなければ協力の範囲は限られます。発注側が段取りを主導しなければ、必要なものが揃わないまま契約期間が終わってしまいます。
この記事では、乗り換えを決める前の確認から、引き継ぎ対象の棚卸し、契約と権利の確認、引き継ぎの進め方、切り替え後のトラブル防止までを、発注側の手順として解説します。
乗り換えを決める前に確かめること
乗り換えには、新しい開発会社がシステムを理解するまでの調査費用と、その間の対応力の低下がともないます。不満の原因によっては、乗り換えより現行の会社との話し合いで解決したほうが早い場合もあります。まずは不満の原因がどこにあるのかを整理しましょう。
| 不満の原因 | 判断の目安 |
|---|---|
| 依頼の出し方や優先順位が曖昧で、対応が遅れている | 乗り換えても同じことが起きやすい。まず依頼の窓口と優先順位の決め方を見直す |
| 保守の範囲や単価が契約で決まっておらず、見積もりが読めない | 契約の見直しを申し入れる。応じてもらえない場合は乗り換えの候補になる |
| 担当者の退職などで、システムを理解している人がいなくなった | 現行の会社でも新しい会社でも、調査からやり直しになる点は同じ。乗り換えを検討する価値がある |
| 技術が古く、現行の会社では対応できる人材がいない | 乗り換えと同時に、作り直しや段階的な刷新も含めて検討する |
| 事業の方向性と、開発会社の得意分野が合わなくなった | 乗り換えが妥当。急がず、並走期間を取れる時期に計画する |
乗り換えを決めた場合でも、現行の会社に伝えるタイミングには注意が必要です。契約の解約予告期間を確認し、引き継ぎに必要な期間を逆算してから伝えるのが基本です。解約を伝えた後は相手の協力度合いが変わる可能性もあるため、受け取れるものは関係が良好なうちに受け取っておくのが安全です。
引き継ぐ対象を棚卸しする
引き継ぎで最も多い失敗は、「ソースコードを受け取れば引き継ぎは済む」と考えてしまうことです。システムを動かし続けるには、ソースコード以外にも多くのものが必要になります。まずは何を受け取る必要があるのかを一覧にしましょう。
| 対象 | 具体的な中身 | 確認のポイント |
|---|---|---|
| ソースコード | アプリケーション一式、設定ファイル、ビルドやデプロイの手順 | 本番で動いているものと同じ版か。変更履歴ごと受け取れるか |
| インフラ・アカウント | クラウド、サーバー、ドメイン、DNS、SSL証明書 | 契約名義が誰か。管理者権限を発注側が持っているか |
| データ | データベース、アップロードされたファイル、バックアップ | 項目の意味が分かる説明があるか。取り出しの形式と方法 |
| 外部サービス | 決済、メール配信、地図、認証などの外部サービスの契約 | 契約者と請求先が誰か。APIキーなどの認証情報の所在 |
| ドキュメント | 構成図、設計書、運用手順書、障害対応の記録 | 最新の状態か。古い場合はどこが違うか |
| 運用上の知識 | 定期的に手作業で行っている対応、過去のトラブルと対処 | 文書になっていないことが多い。聞き取りの場を設ける |
このうち、外部サービスのアカウントは見落としやすい項目です。開発会社が自社のアカウントで外部サービスを契約し、その費用を保守費用に含めて請求していることがあります。その場合、契約を終えた時点で外部サービスも止まってしまうため、事前に発注側のアカウントへの移行が必要です。
運用上の知識も同じくらい重要です。「月初に特定の処理を手動で実行している」「特定の取引先のデータだけ形式が違うので手で直している」といった作業は、ドキュメントに書かれていないことがよくあります。現行の担当者へのヒアリングでは、定期的に行っている作業と、過去に起きた障害の内容を必ず聞いておきましょう。
受け取り方にも注意が必要です。ソースコードは圧縮ファイルで一式を受け取るより、変更履歴を含むリポジトリごと発注側のアカウントに移してもらうほうが、過去の改修の経緯をたどれるため後任の調査に役立ちます。パスワードやAPIキーなどの認証情報は、メールの本文やチャットに書いて送ってもらうのではなく、パスワード管理ツールの共有機能を使うなど、記録が残りにくい方法で受け取りましょう。受け取った認証情報は、切り替えが完了した時点で変更しておくのが基本です。
受け取る対象が多い場合は、一覧表に「受領済み」「確認済み」の欄を設け、現行の会社と同じ表を見ながら進めると漏れを防げます。受け取っただけで中身を確認していないものは、後から不足が見つかっても問い合わせ先がなくなっていることがあるためです。
現行ベンダーとの契約と権利を確認する
棚卸しと並行して、現行の開発会社との契約書を確認します。確認すべきは、ソースコードの権利、引き継ぎへの協力義務、契約終了時のデータの扱いの3点です。
ソースコードについては、著作権が発注側に譲渡されているか、少なくとも発注側が自由に利用・改変できる許諾があるかを確認します。著作権法第61条第2項では、著作権を譲渡する契約で第27条（翻訳権、翻案権等）と第28条（二次的著作物の利用に関する原著作者の権利）の権利が特掲されていない場合、それらは譲渡した側に留保されたものと推定されます。契約書に「著作権を譲渡する」とだけあり、第27条・第28条への言及がない場合は、新しい会社が改修することに支障が出ないか、現行の会社と書面で確認しておくと安心です。
権利が開発会社に残っている場合や、契約書がそもそも見当たらない場合は、乗り換えの前に権利の扱いを協議する必要があります。譲渡や利用許諾に対価を求められることもあるため、乗り換えの予算に含めておきましょう。
引き継ぎへの協力義務が契約にない場合は、引き継ぎ作業を別途有償で依頼する形になるのが一般的です。作業の範囲（資料の提供、質疑対応、並走期間の立ち会いなど）と期間、費用を書面で合意してから進めると、後から「そこまでは対応できない」と言われるのを防げます。
個人情報を含むデータを扱っている場合は、契約終了時のデータの扱いにも注意が必要です。個人情報保護法第25条は、個人データの取扱いを委託する事業者に対して、委託先への必要かつ適切な監督を求めています。現行の開発会社が保守のために本番データやバックアップを手元に持っている場合は、契約終了時に返却または削除してもらい、その完了を書面で報告してもらうようにしましょう。
引き継ぎの進め方と期間の考え方
引き継ぎは、現行の会社との契約が終わる前に新しい会社が調査を始め、一定期間は両社が並走する形で進めるのが基本です。現行の契約が終わってから新しい会社が着手すると、分からないことを聞ける相手がいなくなってしまいます。
一般的な流れは次のとおりです。
- 新しい開発会社を選定し、まず調査（現状把握）だけを契約する
- 現行の会社から、ソースコード、アカウント、ドキュメントを受け取る
- 新しい会社が調査し、分からない点を一覧にして現行の会社に質問する
- インフラやアカウントの名義と権限を、発注側と新しい会社に切り替える
- 新しい会社が小さな改修や定期作業を担当し、現行の会社が確認する並走期間を設ける
- 問題がなければ保守の窓口を切り替え、現行の会社との契約を終了する
最初の調査を独立した契約にしておくのは、新しい会社の見積もりの精度を上げるためです。システムの中身を見ないまま保守費用や改修費用を確定させると、後から想定外の作業が見つかって追加費用になりがちです。調査の結果をもとに、保守や改修の契約を結ぶ順番にすると、双方にとって無理のない条件になります。
引き継ぎにかかる期間は、システムの規模、ドキュメントの状態、現行の会社の協力度合いによって大きく変わります。目安を考えるときは、次の要素を見てください。
| 状況 | 期間への影響 |
|---|---|
| ドキュメントが最新で、構成も一般的 | 調査と並走は比較的短く済む |
| ドキュメントが古い、または存在しない | ソースコードを読み解く調査に時間がかかる。並走期間も長めに取る |
| 外部システムとの連携が多い | 連携先ごとの確認が必要になり、期間が延びる |
| 現行の会社の協力が得にくい | 質疑ができない前提で、調査期間に余裕を持たせる |
繁忙期や大きな業務の切り替え時期と重ならないようにすることも大切です。切り替え直後はどうしても対応が遅くなりやすいため、業務への影響が小さい時期を選んで計画しましょう。
新しい開発会社に確認しておきたいこと
引き継ぎを伴う依頼は、ゼロから作る開発とは求められる力が違います。他社が書いたソースコードを読み解き、文書になっていない仕様を推測し、動いているシステムを止めずに手を入れる必要があるためです。新しい開発会社の候補と話すときは、提案の内容だけでなく、引き継ぎの進め方について具体的に質問してみましょう。
| 質問 | 回答で見るポイント |
|---|---|
| 他社が開発したシステムを引き継いだ経験はあるか | 経験の有無だけでなく、そのとき何に苦労し、どう対処したかを説明できるか |
| 最初の調査では何を確認し、どんな形で報告するか | 調査の範囲と成果物（構成の把握、リスクの一覧、改修の難所など）が具体的か |
| 調査の結果、想定より状態が悪かった場合はどうするか | 追加の調査や作り直しの提案など、選択肢を示す姿勢があるか |
| 現行の会社への質問は、どのように整理して出すか | 質問を一覧にまとめ、回答期限を決めて進めるなど、相手の負担に配慮しているか |
調査の前から「問題なく引き継げます」と言い切る会社よりも、「中身を見てみないと分からない部分がある」と前置きしたうえで調査の進め方を説明できる会社のほうが、実際の引き継ぎでは信頼できることが多いものです。引き継ぎの難しさは、ソースコードやドキュメントの状態を見るまで誰にも正確には分からないためです。
切り替え後に起きやすいトラブルと防ぎ方
引き継ぎが終わった後も、しばらくは想定外の問題が起きやすい期間です。よくあるトラブルと、事前にできる対策を整理します。
| よくあるトラブル | 事前の対策 |
|---|---|
| SSL証明書やドメインの更新が漏れ、サイトが表示されなくなる | 有効期限と更新方法を一覧にし、自動更新の設定を確認する |
| 現行の会社しか知らなかった定期作業が止まる | ヒアリングで定期作業を洗い出し、並走期間中に新しい会社が実施してみる |
| 受け取ったソースコードが本番と違う版だった | 受け取ったコードから環境を作り、本番と同じ動きをするか確認する |
| 外部サービスの契約が開発会社名義のまま解約される | 契約終了前に、すべての外部サービスの名義と請求先を確認・移行する |
| 旧アカウントや旧担当者の権限が残り続ける | 切り替え完了時に、現行の会社のアカウントと権限を削除する |
なかでも、受け取ったソースコードが本当に本番と同じものかの確認は重要です。現行の会社が本番環境で直接ファイルを修正していた場合、手元のソースコードには反映されていないことがあります。新しい会社には、受け取ったコードから環境を作り直し、本番と同じように動くかを早い段階で確認してもらいましょう。
また、切り替え後しばらくは、現行の会社に質問できる窓口を残しておけると安心です。契約終了後の質疑対応を、回数や時間で区切った有償のスポット契約として用意しておく方法もあります。
まとめ
開発会社の乗り換えで大切なのは、新しい会社選びよりも、現行の会社から必要なものを漏れなく受け取ることです。ソースコードだけでなく、アカウント、データ、外部サービスの契約、文書になっていない運用知識まで含めて棚卸しし、契約上の権利と協力の範囲を確認したうえで、並走期間を取って切り替えます。
明日からできることは、状況によって次のように変わります。
- まだ乗り換えるか迷っている場合は、不満の原因を書き出し、契約の見直しで解決できるものかどうかを切り分けます。
- 乗り換えを決めている場合は、契約書の解約予告期間と権利の条項を確認し、引き継ぎ対象の一覧を作ります。
- 新しい会社の候補がいる場合は、いきなり保守契約を結ばず、まず調査だけを依頼して見積もりの精度を上げます。
どの段階でも共通するのは、クラウドやドメイン、外部サービスの名義を自社で押さえておくことです。ここを先に整えておくと、どの会社と組む場合でも引き継ぎの負担は大きく下がります。