開発会社の乗り換え手順: 引き継ぎに必要な資料一覧

「今の開発会社とは、もう長くやっていけない」。そう腹をくくって、別の開発会社に見積もりを取り始めた。ところが、いざ相手先の担当者から「現行システムの仕様書はありますか」「今のソースコードの権利関係はどうなっていますか」「データはどんな形式で管理されていますか」と聞かれると、答えられない項目がいくつも出てくる。乗り換えを決意すること自体は勢いでできても、その先の「何を準備すればいいのか」という具体的な引き継ぎ手順は、経験がなければ見当がつかないものです。

開発会社の乗り換えは、単に契約先を切り替えるだけの話ではありません。旧開発会社からソースコード・データ・ドキュメント・アカウント情報を漏れなく引き継ぎ、新開発会社が「これなら安全に引き受けられる」と判断できる材料を揃える作業が必要になります。この準備が不十分なまま進めると、移行作業が想定より長引いたり、旧開発会社との間でトラブルになったり、最悪の場合は新開発会社から「これでは引き受けられない」と断られることもあります。

この記事では、開発会社を乗り換えると決めた担当者が、実際に何を準備し、どんな順序で引き継ぎを進めればよいのかを、具体的な資料一覧とともに解説します。

• 乗り換え引き継ぎの全体像: 何を、誰から、どんな順序で受け取るのか
• 最優先で確保すべき5つの資料: ソースコード・データ・契約書・アカウント・仕様書
• 旧開発会社への依頼で気をつけるポイント: 円滑に進めるための伝え方
• 新開発会社に提示すべき情報: 見積もりの精度を上げるために必要な材料
• 引き継ぎがうまくいかないときの対処法: 協力が得られない場合の選択肢
• 乗り換え後にやるべきこと: 資料を受け取って終わりにしないために

なお、この記事の運営元である株式会社ゼットリンカーはシステムの受託開発を事業としており、開発会社の乗り換え先になり得る立場です。ただし、ここで書く内容は特定の乗り換えを煽るものではなく、どの開発会社に依頼する場合でも共通して必要になる引き継ぎの手順を中立的に整理したものです。乗り換えるかどうかの判断そのものは、あくまで自社の状況次第です。

この記事で分かること

この記事は、「今の開発会社から別の会社へ乗り換えることをすでに決めた」担当者を対象に、引き継ぎに必要な資料を漏れなく洗い出すためのチェックリストと、それぞれの資料を集める際の実務上の注意点を解説します。乗り換えるべきかどうかの判断基準そのものは扱いません（判断基準については後述の関連記事で扱っています）。

すでに旧開発会社に解約や乗り換えの意向を伝えた方だけでなく、これから伝えようとしている段階の方にも、事前に読んでおいていただきたい内容です。何を準備すべきかを知らないまま解約の話を切り出すと、資料の受け渡しが後手に回り、旧開発会社側の協力を得にくくなるためです。

なぜ「資料一覧」が引き継ぎの成否を分けるのか

開発会社の乗り換えがうまくいくかどうかは、多くの場合、最初の資料引き継ぎの段階で決まります。新しい開発会社は、現行システムの中身を理解できなければ、正確な見積もりも出せませんし、安全に改修を引き受けることもできません。逆に言えば、必要な資料が揃っていれば、乗り換えに伴う不確実性の大部分は解消されます。

ところが実務では、この資料集めが後回しにされがちです。理由は単純で、「まず新しい開発会社を探す」ことに意識が向き、「旧開発会社から何を受け取るべきか」を先に整理する担当者が少ないためです。結果として、新開発会社との商談が進んだ段階になって初めて「仕様書はありますか」と聞かれ、そこから慌てて旧開発会社に連絡を取る、という順序になりがちです。

• 旧開発会社への連絡が解約通知と同時になり、心証が悪化しやすい
• 資料が揃っていないまま新開発会社に相談し、見積もりの精度が落ちる
• 引き継ぎに必要な期間を見誤り、旧システムの保守契約が切れる前に間に合わない
• 退職者が管理していたアカウント情報など、後から発覚する抜け漏れがある

これらは、資料を「何が必要か」を先に洗い出し、旧開発会社との交渉より先に着手することで、多くが避けられる問題です。次の章から、具体的にどんな資料が必要になるのかを見ていきます。

引き継ぎ資料の全体像。5つのカテゴリで整理する

開発会社の乗り換えに必要な資料は、性質の異なる5つのカテゴリに分けて考えると整理しやすくなります。

すべてが同じ重要度というわけではありません。ソースコードとデータは「これがなければ乗り換え自体が成立しない」最優先の資料です。一方、仕様書や設計書は「あれば見積もりの精度が上がり、移行後のトラブルも減る」という位置づけで、旧開発会社が保有していない場合には、新開発会社側で現行システムを解析しながら補っていくことも可能です。

この記事では、まず最優先で確保すべき資料から順に解説し、そのあとで旧開発会社・新開発会社それぞれとのやり取りのコツを説明します。

最優先1: ソースコードとその実行環境一式

乗り換えにあたって最も重要なのが、稼働中のシステムのソースコード一式です。ただし、単に「ソースコードのファイルをもらえればいい」というものではなく、そのコードを実際に動かすための環境情報までセットで確保する必要があります。

• ソースコード一式（最新版であること。開発中の未反映分がないか確認する）
• ビルド・デプロイの手順書、またはビルドスクリプト
• 使用しているプログラミング言語・フレームワークのバージョン情報
• 外部ライブラリ・パッケージの一覧とバージョン
• 開発環境・本番環境それぞれの設定ファイル（パスワード等の機密情報は別途安全な方法で受け渡す）
• データベースのスキーマ定義（テーブル構成、カラム定義）

ここで特に見落とされがちなのが、ソースコードは受け取れても「どうビルドすれば動くのか」という手順が分からず、新開発会社が動かせないというケースです。長年運用されてきたシステムほど、環境構築の手順が担当者の頭の中にしかなく、文書化されていないことが珍しくありません。可能であれば、旧開発会社にソースコードの受け渡しと合わせて、簡単な環境構築手順のメモだけでも作成してもらえないか依頼しておくと、後の移行作業が格段に楽になります。

なお、そもそも自社がソースコードを受け取る権利を持っているかどうかは、契約書の契約不適合責任や著作権に関する条項を確認する必要があります。この点は当メディアの別記事「ソースコードの著作権は誰のもの？契約書の確認ポイント」で詳しく解説していますので、契約書の該当箇所が見当たらない場合は先にそちらを確認してください。

最優先2: 業務データとそのエクスポート形式

システムの中身と同じくらい重要なのが、そのシステムに蓄積されてきた業務データです。顧客情報、取引履歴、在庫データなど、日々の業務で使われてきたデータそのものは、システムを乗り換えても引き継がなければならない資産です。

データの移行可否は、多くの場合「エクスポート機能があるかどうか」ではなく「エクスポートしたデータを他社が扱える形式で出せるかどうか」で決まります。汎用性の低い独自形式でしかエクスポートできない場合、新開発会社側での変換作業に追加の工数がかかることがあります。

• 全業務データを標準的な形式（CSV等）でエクスポートできるか、旧開発会社に確認する
• データ量が多い場合、エクスポートにどの程度の時間・追加費用がかかるか見積もってもらう
• マスタデータ（商品マスタ、顧客マスタ等）とトランザクションデータ（取引履歴等）を分けて確認する
• 削除・アーカイブ済みのデータが必要な場合、それらも含めて取得できるか確認する
• 文字コードの違いによる文字化けが起きないか、少量のデータで試験的にエクスポートして確認する

このデータポータビリティの高さは、開発会社やシステムを選ぶ段階であらかじめ意識しておくべき観点でもあります。すでに乗り換えを決めた今の時点では、まずは今あるデータをできる限り汎用的な形式で確保することを優先してください。データエクスポートの具体的な手順については、当メディアの別記事「SaaS解約前にやるべきデータエクスポート手順」でも扱っていますので、SaaS型のシステムを使っている場合はあわせて参照してください。

最優先3: 契約関連書類一式

技術的な資料と並んで欠かせないのが、旧開発会社との契約関係を証明する書類一式です。これらは新開発会社への提示というより、旧開発会社との交渉や、万一トラブルになった際に自社を守るための資料という位置づけになります。

• 当初の開発契約書（発注時のもの一式）
• 保守契約書（現在有効なもの。更新履歴があれば旧版も）
• 見積書・発注書・請書
• 過去の請求書（支払い実績の証跡として）
• 契約時に交わしたSOW（作業範囲記述書）や仕様確認書
• 契約解除・解約に関するやり取りの記録（メール等）

特に確認しておきたいのが、保守契約の解約条件です。解約の申し出から実際に契約が終了するまでの予告期間が定められていることが多く、この期間を把握しないまま新開発会社との契約を先行させると、旧・新の契約期間が重なって二重に費用が発生したり、逆に空白期間ができてシステムの保守が誰も担当していない状態が生まれたりします。

• 保守契約の解約予告期間は何ヶ月前までに通知が必要か
• 解約時に旧開発会社側に発生する義務（データ引き渡し等）が契約書に明記されているか
• 契約書に「引き継ぎに協力する」旨の条項があるか（なければ交渉の余地がある）

これらの契約書類は、経理部門や総務部門のファイリング、あるいは稟議申請時の添付書類として社内に保管されていることが多いため、システム担当者だけで抱え込まず、関連部署に確認を依頼するのも有効です。

最優先4: アカウント・インフラ情報一式

見落とされやすいものの、これがないと乗り換え作業そのものが止まってしまうのが、各種アカウントとインフラの管理者情報です。ソースコードとデータを受け取れても、それを動かすサーバーやドメインの管理権限が旧開発会社側に残ったままでは、新開発会社は身動きが取れません。

• サーバー（レンタルサーバー、クラウドサービス）の管理者アカウント
• ドメインの管理者アカウント、レジストラの契約情報
• データベースの管理者アカウント
• 利用している各種SaaS・APIサービスの管理者アカウント
• SSL証明書の契約・更新情報
• SSHキー、APIキーなど各種認証情報

これらの情報が旧開発会社の名義で契約されている場合、乗り換えのタイミングで自社名義への切り替え（名義変更）が必要になることがあります。名義変更には旧開発会社の協力が前提となる手続きも多いため、早めに確認しておくべき項目です。ドメインやサーバー契約が退職した担当者や旧開発会社の個人名義になっているケースについては、当メディアで「退職者名義のドメイン・サーバー契約を取り戻す手順」として個別に詳しく解説していますので、心当たりがある場合はあわせて確認してください。

資料5: 仕様書・設計書・運用マニュアル

最優先の4項目と比べると緊急度はやや下がりますが、あれば移行作業の精度を大きく左右するのが仕様書・設計書・運用マニュアル類です。

• 要件定義書、機能仕様書
• 画面設計書、データベース設計書
• システム構成図（インフラ構成、ネットワーク構成）
• 運用マニュアル、障害対応手順書
• 過去の改修履歴、変更管理台帳

こうした文書が最初から存在しない、あるいは古いバージョンのまま更新されていないケースは、中小企業のシステムでは珍しくありません。旧開発会社に確認して「そもそも存在しない」と分かった場合、慌てる必要はありません。新開発会社の中には、ソースコードとデータベースの構造を解析して仕様を逆引きする作業（リバースエンジニアリング）に対応できる会社もあります。ただし、この作業には追加の工数がかかるため、見積もり段階で「仕様書が存在しない前提での見積もりか」を明確にしておく必要があります。

自社側でシステムの現状を把握しておく仕組みとしては、システム管理台帳の整備が有効です。乗り換えを機に、今後は同じような資料の散逸が起きないよう、契約情報・アカウント情報・仕様の要点を一つの台帳にまとめておくことをおすすめします。作り方の具体的な手順は「社内システムの現状調査（棚卸し）のやり方」で解説しています。

引き継ぎ全体のスケジュール感をつかむ

具体的な資料一覧を把握したところで、次に気になるのは「全体としてどれくらいの期間を見込んでおけばよいか」という点です。厳密な日数は案件ごとに異なりますが、大まかな流れとしては次のような順序で進みます。

1. 旧開発会社へ資料提供の依頼を行う（依頼から回答まで、相手の対応状況によって幅がある)
2. 資料を受け取り、自社側で内容を確認する。不足があれば追加依頼を行う
3. 新開発会社の候補に資料を提示し、見積もりを取得する
4. 新開発会社を決定し、正式に契約する
5. 旧開発会社の保守契約を解約する。あるいは移行期間として一定期間並走させる
6. 新開発会社による移行作業・テストを経て、本番切り替えを行う

このうち、担当者の努力だけではコントロールしにくいのが1番目の「旧開発会社からの回答待ち」の期間です。相手企業の繁忙状況によっては、依頼してから資料が揃うまでに相応の時間がかかることもあります。逆算すると、保守契約の解約を通知するよりも前、できれば新開発会社を探し始めるのと同じタイミングで、資料提供の依頼だけは先に旧開発会社へ出しておくという進め方が現実的です。

• 資料提供の依頼と、解約の意向表明は必ずしも同時に行う必要はない
• 「資料をいただけますか」という依頼だけであれば、解約を確定する前の段階でも出しやすい
• 資料が揃ってから初めて、新開発会社との具体的な商談・解約手続きに進むと手戻りが少ない

なお、社内の決裁フローによっては、新開発会社への発注自体に稟議申請が必要になる場合もあります。稟議の準備にも一定の時間がかかるため、資料集めと並行して、社内の意思決定プロセスも早めに動かしておくと、全体のスケジュールが詰まりにくくなります。

引き継ぎ作業でありがちな失敗パターン

最後に、実際の引き継ぎ現場でつまずきやすい失敗パターンをいくつか紹介します。事前に知っておくことで、同じ失敗を避けやすくなります。

資料を受け取った時点で安心してしまう。 ソースコードやデータを受け取ったこと自体をゴールと捉え、その中身が本当に最新版か、正しく開くことができるかを確認しないまま次の工程に進んでしまうケースです。受け取った直後に、簡単でよいので内容の整合性を確認する時間を確保してください。

担当者個人のメールやパソコンに資料が集約される。 引き継ぎ資料のやり取りが、システム担当者個人のメールボックスやローカルのパソコンにしか残らず、その担当者が異動・退職した場合に再び行方不明になってしまうケースです。受け取った資料は、個人のメールだけに留めず、部署で共有できる場所に保管し直すことをおすすめします。

新開発会社への情報共有が口頭中心になる。 資料一式を渡したつもりでも、実際には口頭での補足説明に頼りきりで、後から「言った内容が正確に伝わっていなかった」というすれ違いが起きるケースです。重要な補足事項は、簡単なメモでもよいので文書として残し、新開発会社と共有しておくと認識のズレを防げます。

旧システムの並走期間を短く見積もりすぎる。 新システムへの切り替え後にトラブルが起きないことを前提にスケジュールを組んでしまい、いざ不具合が出たときに旧システムにも旧開発会社にも頼れる先がない状態になってしまうケースです。特に業務への影響が大きいシステムほど、切り替え直後の一定期間は旧環境をすぐに戻せる状態で残しておく、あるいは旧開発会社への緊急連絡先だけは維持しておくといった保険をかけておくと安心です。

旧開発会社への依頼で気をつけるポイント

資料そのものの一覧が分かっても、実際にそれを旧開発会社から受け取る交渉の進め方でつまずくケースは少なくありません。ここでは円滑に進めるための実務上のポイントを整理します。

依頼の順序を意識する

解約の意向をいきなり伝えるのではなく、まずは「資料一式を提供してもらえるか」を確認してから、正式な解約の手続きに進むという順序を意識してください。解約通知と資料請求を同時に行うと、相手側の担当者に「もう関係が終わるのだから協力する動機がない」という受け止め方をされ、対応が後回しにされるリスクがあります。

依頼内容を書面で残す

口頭でのやり取りだけで進めず、依頼する資料の一覧をメールなど文書の形で送付し、相手からの回答も文書で残すようにしてください。「言った・言わない」のトラブルを避けるだけでなく、万一資料の提供が滞った場合に、依頼の事実を示す証跡として使えます。

追加費用の有無を事前に確認する

契約書に「引き継ぎ資料の提供は無償で行う」と明記されていない限り、旧開発会社側から資料作成やデータエクスポートの作業に対して追加費用を請求される可能性があります。金額の妥当性を判断する材料として、あらかじめベンダーロックインに関する当メディアの別記事も参考にしつつ、費用が発生する場合は見積もりを事前に取っておくことをおすすめします。

期限を明確に区切る

「なるべく早く」ではなく、「〇月〇日までに」という具体的な期限を設定して依頼してください。期限を曖昧にしたまま依頼すると、旧開発会社側の他の業務が優先され、対応が後回しにされがちです。保守契約の解約予告期間と、新開発会社への引き継ぎに必要な期間を逆算し、余裕を持った期限を設定することが重要です。

新開発会社に提示すべき情報と見積もり精度の関係

資料を集める作業と並行して意識しておきたいのが、集めた資料をどう新開発会社に提示するかという点です。同じ資料を渡すのでも、提示の仕方次第で見積もりの精度が変わってきます。

• 集めた資料を項目ごとに整理し、「ある」「ない」「調査中」を一覧化して渡す
• 資料が存在しない項目については、その理由（旧開発会社が非協力的、そもそも作成されていない等）を伝える
• システムの利用者数、データ量、稼働頻度など、資料だけでは分からない運用実態も併せて共有する
• 移行にあたって「変えたくない部分」と「この機会に見直したい部分」を分けて伝える

新開発会社は、資料が完璧に揃っていなくても見積もり自体は可能な場合が多いですが、「何が分からないか」が曖昧なまま相談すると、見積もりに大きな幅（バッファ）を取らざるを得なくなります。逆に、「ここは不明」と明確に伝えられれば、その部分だけを調査工程として切り出した見積もりを提示してもらいやすくなります。

複数の開発会社から見積もりを取る場合は、各社に同じ資料・同じ条件を提示することも重要です。提示する情報が会社によってばらつくと、見積もりの比較そのものが成立しなくなります。

引き継ぎがうまくいかないときの対処法

ここまでは旧開発会社が一定の協力をしてくれる前提で進めてきましたが、実務では資料の提供を渋られる、連絡への反応が遅い、あるいは全く応じてもらえないというケースも起こり得ます。

• 契約書に「引き継ぎ協力義務」の条項がないか、あらためて確認する
• 個人の担当者ベースではなく、旧開発会社の窓口・上長宛に正式な文書で依頼し直す
• どうしても資料が得られない場合、新開発会社に「資料がない前提での対応」が可能か相談する
• ソースコードそのものが提供されない場合、新開発会社によるリバースエンジニアリングでの再構築を検討する
• 悪質な引き延ばしや不当な高額請求があった場合は、弁護士など専門家への相談を検討する

すでに開発会社と完全に連絡が取れなくなっている、あるいは廃業している場合は、また異なる対処が必要になります。そうした状況については、当メディアの「開発会社と完全に連絡が取れなくなった。廃業・音信不通時の放置システム対処法」で個別に扱っていますので、該当する場合はそちらを参照してください。

トラブルが起きた際、社内での対応窓口を一本化しておくことも重要です。担当者が複数の連絡ルートを使い分けてしまうと、話が食い違い、かえって解決が遠のくことがあります。問題が現場レベルで解決しない場合に、誰が上位の判断者にエスカレーションするのかを、社内であらかじめ決めておくとスムーズです。

乗り換え後にやるべきこと

資料を受け取り、新開発会社との契約が始まったら、それで引き継ぎ作業が終わりというわけではありません。乗り換え後も継続してやっておくべきことがあります。

1. 受け取った資料一式のバックアップを、新開発会社任せにせず自社側でも保管する
2. 旧システムのアカウント・契約が確実に解約されているか、請求書等で確認する
3. 新開発会社との契約書に、今回の教訓を反映させる（引き継ぎ協力義務、著作権の帰属等を明記する）
4. 今後同じ状況に陥らないよう、システム管理台帳を整備し、定期的に更新する運用を決める

特に3点目は重要です。今回、旧開発会社との契約書に引き継ぎ協力に関する条項がなく苦労した場合、その反省を新開発会社との契約書に反映させておけば、将来再び乗り換えが必要になったときの負担を大きく減らせます。1社に依存しすぎない体制として、あえて機能ごとに複数の開発会社へ発注を分散するマルチベンダーという考え方もありますが、これは組織の体制やリソースによって向き不向きがあるため、自社の状況を踏まえて検討してください。

まとめ

開発会社の乗り換えは、決断してからが本番です。ソースコード・データ・契約書・アカウント情報・仕様書という5つのカテゴリに沿って必要な資料を洗い出し、旧開発会社には順序と期限を明確にして依頼する。そして集めた資料を整理した形で新開発会社に提示することで、見積もりの精度と移行作業の安全性が大きく変わります。

一度この手順を経験しておけば、次に同じような場面に直面したときの負担は格段に軽くなります。今回の引き継ぎを機に、自社のシステム管理体制そのものを見直すきっかけにしていただければ幸いです。

乗り換えを決める前の判断基準について整理し直したい方は、「開発会社を変えたいのに変えられない理由。ロックインの構造を分解する」もあわせてご覧ください。また、乗り換え後の保守費用が適正かどうか気になる方は、「月額保守費の相場と見直し方」も参考になります。